Quote from: Phinnaeus Gage on May 02, 2014, 07:40:16 PM

Quote from: DeathAndTaxes on February 13, 2014, 06:45:48 AM

Quote from: waxwing on February 13, 2014, 06:38:24 AM

Quote from: Peter R on February 13, 2014, 04:04:05 AM

Here in Vancouver, several brick-and-mortar businesses accept zero-confirm transactions using BitPay. If you are buying a coffee, no one is going to wait 10 minutes (or longer) for confirmation; it is critical that zero-confirm transactions are reasonably secure in order for this business model to work.

So let me see if I understand the transaction malleability problem in relation to brick-and-mortar stores:

I pay for my coffee at Waves for 4mBTC. Assume that to avoid "address reuse," my phone uses the full balance in 1AddressA, sends 4mBTC to Waves, and the rest to a new change address 1AddressB. BitPay accepts this transaction and I get my coffee. As soon as I finish paying, I realize that I also wanted a donut. So I pay for this using what are now unconfirmed coins sitting in 1AddressB. BitPay still approves the transaction and I get my donut too.

But my first transaction was mutated, and the mutated version was accepted into the blockchain. This means that the transaction I used to pay for my donut is now invalid, and Waves/BitPay won't get the money (and I've already left the store).

This seems like a messy problem to deal with. If we disallow spending unconfirmed change outputs, then there will be certain cases when I can't actually purchase my donut [without a long wait], correct? Ideally, my wallet would try to break up my coins so that there are always plenty of fully-confirmed outputs ready for spending. But how do most wallets actually work? The Blockchain.info mobile wallet [that I use] sends the change back to the same address, so I'd expect that it would be very rare to have exhausted all of the confirmed outputs. But for mobile wallets that avoid address reuse [do these even exist?], would it be less likely that you'd have confirmed coins available?

And should BitPay do anything to protect itself?

Very good example to think about, but: did I miss something? I think it won't happen, or at least doesn't have to. When you try to pay for the donut, assuming your wallet makes use of the change utxo which has been malled and is not yet confirmed, will bitpay accept it? I don't know whether they would today, but isn't it trivial to just check each utxo used as input and look at the blockchain to see if that transaction has any confirms? That way, they can accept unconfirmed spends, but not accept unconfirmed spends of unconfirmed spends, which is practically absolutely fine. Except you don't get your donut Cheesy

Unless your wallet is coded to not use unconfirmed change...

Today BitPay would accept it. Unconfirmed change is used rather routinely although probably will be changing soon. In your scenario though the bad news is not BitPay needs to figure out a way to return your coins. You can't undo it and eventually it will confirm (unless a duplicate of the prior output is what confirms). So you are now out the donut and coins. Of course the shop will have no clue how to get your coins back, and "you" (or a less educated user) might be kinda upset seeing the donut funds deducted from your wallet but not getting the donut and the clueless clerk having no idea how to get your coins back or even where they went.

If this happened enough the store might just not accept Bitcoin in the future. Now I am not going all doom and gloom and none of this is unsolvable but you can see how all this starts to get really ugly real quick. Transaction Ids need to be immutable. Period. There is no other viable long term option. However that is going to take some time so things might get a little clunky for service providers before they get better.

It's must likely BitPay, of which I'm sure will be resolved ASAP as soon as it's brought to their attention, for they're a fine org.

I am not so sure it is BitPay, given that this is just not like them. These quotes are from over two and a half months ago.