Topic: Was not able to purchase my food with Bitcoin at Waves in Vancouver. (Read 517 times)

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?