Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.
I haven't taken multisig into account, just two factor. That's mostly because it's a new concept I'm not sure I fully understand. Is there a really good explanation of how that would work in the Bitcoin system? It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.
It is at dev stage, afaik, but Gavin has done a lot of work/testing on it and he is the lead dev. so it is probably not that far away ...
Thanks! You know that was very helpful information and greatly simplifies the design for this... Assuming i understand it correctly.
Instead of a 0.01BTC broadcast to a constantly changing key that then has to be picked up and processed by the primary wallet.
The merchant gateway is actually a fullblown node.
The gateway would initiate a TxDP, essentially just a note specifying where the money needs to go, but the TxIn field is left blank.
This is then signed with the users semi-private key which was generated by a hash of the card details and PIN.
The signing system (primary wallet or wallet protection service or whatever) sees the TxDP then does some confirmation checking either sending an SMS, or popping a message on an android app, or just checking for the presence of a static PIN and if the confirmation checks out.
Fills out the TxInput fields, then signs it and sends it off to the network.
This makes sense to me, except I don't see how the primary wallet is supposed to know to look for the transaction, but maybe I'm just missing something simple.
Still, I'll keep digging.