Well, currently more research is needed. Because, from what I've read, custom ECDSA implementation for JavaCard is really slow, so, either the card must support it natively, or a C implementation is required.
http://amadousarr.free.fr/crypto/ECDSAJAVACARD.pdf
Topic: Bitcoin smartcard Point of Sale terminal - page 8. (Read 26856 times)
First of all, this is an obvious way to go and entirely doable so I'm not sure I understand why anyone would say it isn't Bitcoin related. A smartcard is just a small tamper-resistant computer.
And I'm thinking a store with several POS terminals could theoretically have their own dedicated miner on-site just to process their own transactions. Wouldn't this speed up the transaction time or am I missing something important?
And I'm thinking a store with several POS terminals could theoretically have their own dedicated miner on-site just to process their own transactions. Wouldn't this speed up the transaction time or am I missing something important?
Yes, but if you'd read my original post in whole, you might notice the section when I mull on the idea of reciprocal authorization between the card and POS terminal, which would allow for advanced options for payment. If you have a "hacked" POS, it wouldn't authenticate and prevent you from signing transactions in bulk. Or just making you wait for confirmation.
If Plato works out something with his global WoT, if might be integrated into this system as well... So that various trust levels would require various amount of required confirmations.
If Plato works out something with his global WoT, if might be integrated into this system as well... So that various trust levels would require various amount of required confirmations.
How can you sign a lot of transactions without having the private key?
The point of a smart card is you give it data and it signs it. So if I have my smart card which I use to pay, I send it txes to sign with each address that it might use to send money.
How can you sign a lot of transactions without having the private key?
Well, that's the thing - the smart card can generate the keypair. You are not able to get it, ever. You can still use it, if you know the pin code. But you cannot clone the wallet onto another card or on a computer. Therefore possibility of double spending is severely restricted using this method.
That doesn't prevent double spends, I can write sign a ton of txes ready to double spend and then go to a store and the second it spends, send all those txes to the big miners from my phone. Still, its a great idea and a cool dream but until we actually have a use for it (ie PoSs ready for use and stores ready to accept bitcoin), spending time on it seems like a waste of resources.
Well, that's the thing - the smart card can generate the keypair. You are not able to get it, ever. You can still use it, if you know the pin code. But you cannot clone the wallet onto another card or on a computer. Therefore possibility of double spending is severely restricted using this method.
This is great. However, there are too many problems for bitcoin PoS use which need to be solved first anyway. (like the confirmation delay, etc). For now, its much easier to just figure out bitcoin PoS payments with QR codes and such and see if it ever catches on before we start going off defining standards which will be used by 10 people.
Well, for smartphone clients it would be a printed receipt with a payee address. Or a QR code, or something.
I guess that type of POS is beyond this particular topic. I want to focus on the smart card implementation...
I guess that type of POS is beyond this particular topic. I want to focus on the smart card implementation...
Not sure what lfm is talking about, but this sounds good. Of course, we still have work to do on the pure internet side of things, but work on physical bitcoin implementations should be a priority too.
Looks good, the only thing I'd be concerned about is making sure that smartphone clients can use the same system.
Looks good, the only thing I'd be concerned about is making sure that smartphone clients can use the same system.
Which specific points are you disagreeing about?
I dont see what this has to do with bitcoin, in fact it looks nothing like bitcoin.
Hello all,
I've been having these ideas lately, about how to implement a bitcoin PoS with a physical card, akin to a Debit Card. I'm pretty sure my ideas are correct, but I'd like to validate a few assumptions first.
After reading some on SIM cards and smart cards in general, I've established following:
With this is mind, it's not possible to put the block chain on the card, or do any extensive validation, due to processing power constraints.
So the job of doing that should be performed by a terminal. Modern terminals are essentially computers, connected to the network, either via modem, broadband, or GPRS connection. So they are able to keep the block chain fresh.
The issue is this - due to a limited space on the card, I'm not sure if it's possible to keep the entire wallet on the card. So there needs to be some sort of algorithm to quickly scan the block chain to establish the balance available for the keys that are stored on the card.
I've talked to a guy, who's job is writing software for SIM cards, the ones in everyone's cell phones. He said, that a 1Mb JavaCard would cost about $1, if the order is for 50000 cards at once. So it's not too bad.
Next step would be to research how modern POS terminals operate, and whether it's possible to add support for bitcoin processing on them, or maybe even develop something from scratch.
Other things
Technically the card can be limited to one keypair, but that would greatly reduce anonymity. I guess there's a possibility of having various classes of bitcoin cards with different amount of keypairs available for usage.
The keypair(s) could be programmed into the card at the time of manufacturing. Problem is that then the keys are available to 3rd party. But then it would be possible to create pre-paid bitcoin cards.
Alternatively, the keypairs could be created by the card itself, at the POS, when money is added.
Also, POS terminal can print out a bitcoin address on the receipt, so you can add more money to the card with regular bitcoin software.
It's also possible to have the card validate the POS, to ensure compliance. If the POS is validated (by crypto-key verification) of course, then (probably) additional safeguards can be implemented, like accepting transactions with no confirmations, but somehow temporarily preventing the card from double-spending, etc. Or give option at payment like "pay with no validations, but the card is locked for next 10 minutes" or "pay regularly, but goods are released upon validation"
Issues
This is not a bank account access card. It would be an actual wallet card, so if it's lost - the money is gone forever. If it's stolen - the PIN code should prevent access to private keys. It would be possible to create 2 level PIN protection, similar to PIN and PUK in cell phones.
It's also possible to create a "doomsday pin" that wipes the card clean, in case you're under duress, or something out of a spy novel
What do you guys think?
I've been having these ideas lately, about how to implement a bitcoin PoS with a physical card, akin to a Debit Card. I'm pretty sure my ideas are correct, but I'd like to validate a few assumptions first.
After reading some on SIM cards and smart cards in general, I've established following:
- There is protected storage (r/w) on the smart card, and the only way to access it is by using the API provided by the software loaded on the card. (Unless you have a scanning tunneling microscope).
- Software that runs on the card can be either in C or Java
- C is cheaper hardware-wise, but very inflexible. Any changes required at later stages mean huge costs
- Java is cheaper to develop, as it has an integrated development environment and lots of classes (including cryptoapi), but the cards themselves are more expensive
- You can write a program for the smartcard, that executes on the smart card, and is able to do various actions like:
- Authorizing access to the private keys with a PIN
- Validating a digital signature
- Signing a block of data
- Initializing a blank card with a bunch of keypairs
With this is mind, it's not possible to put the block chain on the card, or do any extensive validation, due to processing power constraints.
So the job of doing that should be performed by a terminal. Modern terminals are essentially computers, connected to the network, either via modem, broadband, or GPRS connection. So they are able to keep the block chain fresh.
The issue is this - due to a limited space on the card, I'm not sure if it's possible to keep the entire wallet on the card. So there needs to be some sort of algorithm to quickly scan the block chain to establish the balance available for the keys that are stored on the card.
I've talked to a guy, who's job is writing software for SIM cards, the ones in everyone's cell phones. He said, that a 1Mb JavaCard would cost about $1, if the order is for 50000 cards at once. So it's not too bad.
Next step would be to research how modern POS terminals operate, and whether it's possible to add support for bitcoin processing on them, or maybe even develop something from scratch.
Other things
Technically the card can be limited to one keypair, but that would greatly reduce anonymity. I guess there's a possibility of having various classes of bitcoin cards with different amount of keypairs available for usage.
The keypair(s) could be programmed into the card at the time of manufacturing. Problem is that then the keys are available to 3rd party. But then it would be possible to create pre-paid bitcoin cards.
Alternatively, the keypairs could be created by the card itself, at the POS, when money is added.
Also, POS terminal can print out a bitcoin address on the receipt, so you can add more money to the card with regular bitcoin software.
It's also possible to have the card validate the POS, to ensure compliance. If the POS is validated (by crypto-key verification) of course, then (probably) additional safeguards can be implemented, like accepting transactions with no confirmations, but somehow temporarily preventing the card from double-spending, etc. Or give option at payment like "pay with no validations, but the card is locked for next 10 minutes" or "pay regularly, but goods are released upon validation"
Issues
This is not a bank account access card. It would be an actual wallet card, so if it's lost - the money is gone forever. If it's stolen - the PIN code should prevent access to private keys. It would be possible to create 2 level PIN protection, similar to PIN and PUK in cell phones.
It's also possible to create a "doomsday pin" that wipes the card clean, in case you're under duress, or something out of a spy novel
What do you guys think?
Jump to: