What happen with double-spendings?
Will the payer wait an hour for the transaction to be verified?
Topic: PROTON-like payments / Smart card for Bitcoins (Read 4714 times)
Oh I see, the terminal would just look back at the most recent payment to this address, which would usually be the "change" from the previous payment, and use that as the source transaction. Ye, that should work I think.
I think it will work to give change to the paying Bitcoin address. The client avoids this for privacy reasons - it tries to hide which output is payment and which is change. But it should work.
Yes, that was my interpretation too, but didn't have a time yet to look at the source code.Oh, wait, you want to feed the change back into the card, don't you? That's trickier, because Bitcoin payments must reference the hash of the source transaction.
Yes, payments need the hash, but these are available in the blockchain: you can easily check this with the Blockexplorer: just enter your Bitcoin address (which would also be the Bitcoin address on the card) and you can see the balance and all transactions involved.My idea is that you ONLY need to store the private/public key combination of ONE bitcoin address (all other data is in the block chain !), so that the merchant can easily query the card for your Bitcoin address, and the card can use the private key to sign the transaction created by the merchant.
- Trust: I have to trust that the store creates the correct transaction (transaction on screen is the same as sent to the smart card for signing). I have not yet come up with a good answer here...
There are cards with display and press button where the amount could be confirmed direct on the card:
http://silicontrust.files.wordpress.com/2010/11/maia-display_custom_items-download_seealso_file.jpeg
http://www.incard.com/products.html
I think it will work to give change to the paying Bitcoin address. The client avoids this for privacy reasons - it tries to hide which output is payment and which is change. But it should work.
Oh, wait, you want to feed the change back into the card, don't you? That's trickier, because Bitcoin payments must reference the hash of the source transaction. What you need to do is store on the card the original source transaction hash (that funded the address on the card). Then when you make a payment, the terminal uses this for the txin, and creates a tx that gives change back to your address. It computes the hash of this new transaction and writes it back to the card. This will then be used as the txin for the next payment.
Does anyone know a smart card that supports ECDSA signatures?
Oh, wait, you want to feed the change back into the card, don't you? That's trickier, because Bitcoin payments must reference the hash of the source transaction. What you need to do is store on the card the original source transaction hash (that funded the address on the card). Then when you make a payment, the terminal uses this for the txin, and creates a tx that gives change back to your address. It computes the hash of this new transaction and writes it back to the card. This will then be used as the txin for the next payment.
Does anyone know a smart card that supports ECDSA signatures?
Change can also be solved by not using the bitcoin network directly. There could be a site called BitcoinPOS where you send coins to fill your card and then the merchant gets their coins from the site. I think this is roughly the idea of Bruce's "Account Hubs". You don't have to trust all merchants this way either since you could have recourse thorough BitcoinPOS if you were charged incorrectly.
The "change" problem is easily solved by making sure that none is needed. The card can be pre-loaded with keys for coins that can make up any amount without the need for change.
For example, with the following hundred keys you can make many payments (worst case is 10, but probably many more) of any amount from 1 to 99 BTC before you need to recharge your card:
25 x 1 BTC, 25 x 3 BTC, 25 x 10 BTC, 25 x 30 BTC
For example, with the following hundred keys you can make many payments (worst case is 10, but probably many more) of any amount from 1 to 99 BTC before you need to recharge your card:
25 x 1 BTC, 25 x 3 BTC, 25 x 10 BTC, 25 x 30 BTC
Probably most of you never heard of a "PROTON" card, but it is an electronic form of cash introduced in Belgium with moderate success.
It is designed for small payments (1 to 50 Euro), for instance in grocery shops. It is in fact an additional function on a normal debet bank card and from a user's perspective very easy to use:
No PIN is necessary.
For the shops it is more interesting then normal payments as PROTON is cheaper (less commission and no online costs) for them, so they can accept small amounts (less then 10 Euro). See http://www.atosworldline.be/index/en_US/5118014/5126207/Proton.htm for more info.
I've been thinking how this could be translated to the Bitcoin environment.
The most important difference in my opinion with the actual implementation of Bitcoin is the "client": if I want to do a payment, I need to carry with me some form of the client (on a laptop, smartphone or similar device) with my wallet.dat and it needs an internet connection to post the transaction to the Bitcoin network. Probably in a few years, many people will have smartphones and mobile Internet, but then there is still the security risk of carrying your wallet.dat on such a device with you.
So the question is: can we eliminate the need for a "smart phone client" with a wallet.dat ?
What if we use the following set-up (in short):
In long:
AT HOME:
AT THE STORE: I want to pay X BTC: I insert the card into a card reader, I type the amount I want to pay and confirm.
The Bitcoin client on the machine should now make the transaction:
The whole can be secured a bit more by using a PIN needed when signing (and after 3 wrong PINs, the card no longer accepts to sign anything, it has to be reset by sending the private/public key pair again, the same one or a different one).
I can see 2 problems remaining:
Anyways, if the 2 problems remain so that this scenario is not good for a payment in a store, it is still a valid solution to reduce (even eliminate ?) the security risk of stolen wallets (as once the private key is only on the smart card, it cannot be copied/retrieved in any way).
Any thoughts ? And sorry for the long post.
It is designed for small payments (1 to 50 Euro), for instance in grocery shops. It is in fact an additional function on a normal debet bank card and from a user's perspective very easy to use:
- you upload money from your bank account onto the card (up to 125 Euro) on any ATM machine
- in a store you put the card in a terminal, they type the amount to pay and you accept that by pressing the OK button. DONE !
No PIN is necessary.
For the shops it is more interesting then normal payments as PROTON is cheaper (less commission and no online costs) for them, so they can accept small amounts (less then 10 Euro). See http://www.atosworldline.be/index/en_US/5118014/5126207/Proton.htm for more info.
I've been thinking how this could be translated to the Bitcoin environment.
The most important difference in my opinion with the actual implementation of Bitcoin is the "client": if I want to do a payment, I need to carry with me some form of the client (on a laptop, smartphone or similar device) with my wallet.dat and it needs an internet connection to post the transaction to the Bitcoin network. Probably in a few years, many people will have smartphones and mobile Internet, but then there is still the security risk of carrying your wallet.dat on such a device with you.
So the question is: can we eliminate the need for a "smart phone client" with a wallet.dat ?
What if we use the following set-up (in short):
- I have a smart card with crypto module that can store the key pair (private + public key) of one of my Bitcoin addresses;
- In the shop, they have a running Bitcoin client (or any similar app) and I put my smart card into a card reader and confirm on screen that I want to pay X BTC.
In long:
AT HOME:
- I can upload to the smart card a key pair of my choosing (one of ones in my normal Bitcoin wallet). The private key part is only writeable to the card, never readable. The public part is writeable/readable (or its hash/bitcoin address).
- Using the normal Bitcoin client, I can transfer any amount to this Bitcoin address, which has the effect of uploading BTC to the card.
- I can even retransfer any amount from this Bitcoin address to another of my addresses (in case the card is lost or stolen) !
- Protection against viruses: I can remove the keypair from my everyday wallet.dat (I keep the original wallet.dat in a secure place, offline) so the BTC from this address can never be stolen.
AT THE STORE: I want to pay X BTC: I insert the card into a card reader, I type the amount I want to pay and confirm.
The Bitcoin client on the machine should now make the transaction:
- TXIN: It can read my Bitcoin address (from the public key or its hash or the bitcoin address immediately, as this is world readable), so it can look for the necessary data in the block chain, correct ?
- TXOUT: The system knows to which Bitcoin address the payment should go and it knows the amount. Leaves the problem what to do with the change (see below).
- The transaction data are sent to the smartcard and the crypto module inside signs it with the private key on the card, to validate the transaction.
- The Bitcoin client sends the signed transaction to the Bitcoin network. Done.
The whole can be secured a bit more by using a PIN needed when signing (and after 3 wrong PINs, the card no longer accepts to sign anything, it has to be reset by sending the private/public key pair again, the same one or a different one).
I can see 2 problems remaining:
- The change: for some reason I do not yet understand fully, TXIN are always complete amounts of coins sent to that bitcoin address before (for easy checking of double-spending ??), so if you sent 50 BTC to the address, and you only need to pay 10 BTC, there is 40 BTC change, which the client now sends to a new generated Bitcoin address (whihc belongs to the same wallet.dat/same user). A solution could be to sent the 40 BTC back to the same smartcard Bitcoin address, but I do not know if that is a valid transaction.
- Trust: I have to trust that the store creates the correct transaction (transaction on screen is the same as sent to the smart card for signing). I have not yet come up with a good answer here...
Anyways, if the 2 problems remain so that this scenario is not good for a payment in a store, it is still a valid solution to reduce (even eliminate ?) the security risk of stolen wallets (as once the private key is only on the smart card, it cannot be copied/retrieved in any way).
Any thoughts ? And sorry for the long post.
Jump to: