I see a problem with our system. If someone (assume a merchant) requests instant send, the other user can still choose not to send fund via instant send by unclicking that box. Because funds are then in limbo, the customer won't resend, and the merchant is stuck with waiting for the funds, completely ruining the point of instant send.
This is why I brought it up... IX was designed from a snowflake perspective; me me me me me. So much "me" that it doesn't even realize that it does not actually deliver on it's premise.
So the merchant either has to detain the customer or make them come back to pick up their merchandise, or else he's stuck with the same problem as Bitcoin has, to risk the customer leaving with the goods while he waits for a confirmation.
We need a way, so that when the merchant, or the receiver requests a payment with instant send, the payer can not change that to non-instant. Is that possible? It has to be part of the system, not just the wallets. Otherwise, a wallet that allows you to uncheck the instant pay box will simply be made. There needs to be something that blocks acceptance of non-instant sends.
We're not supposed to be
testing the fundamentals, I guess....
This is
a defect that was exposed in the IX model by the DASH vending machine a year ago. What was done about it? Changed the name to something even less sensible, altered the failed dynamic not at all... This is why I don't call it IS/InstantSend. Bitcoin has InstantSend... Hell, all cryptos have InstantSend... Locks are supposed to be about Instant RECEIVE. IX, InstanTX, at least makes half sense...
The whole point of Transaction Locks is that the RECEIVER can be assured. Thus, it has to be initiated from the RECEIVER side.
The clueless snowflake mentality is painfully obvious in that all that is talked about is how the end user can spend, with no concern for how the vendor would receive.
If a TX lock is initiated by the recipient as soon as the owning client detects it's own address in the memory pool, we not only have a way of making this more real-world workable (eliminate the derps, the deliberate un-ckechers, and the black-hat modified clients), we can also detect and mark known bad actors who attempt to defraud TXes; there should be only one lock request presented to the network for any TX, ever! The submitting client should be able to present an appropriate signature based on the keypair. Anything else submitted can be flagged as a bad actor, and if any available deterministic string exists for that address (or just that address if not, which trivializes the potential repercussions), there could be consequences for the user without exposing his identity. Anyone attempting to submit multiple sends with one of his own addresses as the receiving address, which then makes the lock request, gives us positive feedback that the TX in question definitely won't reach the appropriate recipient... It works out perfectly. Closed-loop. It's a thing. A measurable response, not a blind hope. 3rd party observers submitting Lock requests just to spam it up or create false positives on the fraud check? They won't have a valid keysig, so throw it out. Nip it in the bud to save pipe... We've reduced bad actors to nothing but an increasingly futile attempt to waste bandwidth.
Has any thought even been given to this? Just how totally unconcerned is DASH with the recipient actually getting his money? IX is a gimmick in it's current implementation. How is it being changed? Is it being changed? Does anyone give a damn?
It looks like the network currently locks an input until it's one block deep. In case of chain wag, I think this should be deeper.
InstantReceive, not instant re-receive. This gives assurance that no TX can come from nowhere, like chainless instant re-send techs. The money has to be "seasoned" by the ledger before it can be IXed. Kinda like trying to buy a $0.5mil house with cash...