discussion cont'd here : http://bitcointalk.org/index.php?topic=7872.0

bitcoin debit card in physical form might not be best idea.

Or that Even better But I guess in the case of 3rd party, parts of the risk can be handled by said party.

The whole point of posting ideas here, that there'd be a devil's advocate, such as yourself.

After having a discussion about bitcoin PoS and debit card here (http://bitcointalk.org/index.php?topic=7539.0), the conclusion was that the smart card route it's probably not the best idea. Payment with smart device (smartphone, pda) is preferable and less hassle for everyone. There was a mention of sites like mybitcoin to arbitrate payments. Having one site means centralization, which is kinda against bitcoin philosophy. So here's a list of ideas in that regard.

• There should be a public RFC spec for the online wallet site
• Anyone should be able to deploy such site online, in case that person has reservations about other such sites out there, aka open source reference design
• There should be a common API for sending transactions to such site, authorizing the site to perform a money transfer

The way I see it is something like this (from Point of Sale perspective):

Setup
You'd find a site that agrees to keep a certain bitcoin balance on your behalf. You supply the site with your GPG public key. You have the private key on your mobile device.
Sale
When merchant presents you with the total for your transaction and receiving address in some machine readable form, like a QR code or Aztec code, your device would scan it, display the total on your screen and present you with a prompt to agree with the transaction. Once you do that, it would prepare a data packet to the aforementioned spec, authorizing the site to transfer amount X into the address Y. (Ref: http://bitcointalk.org/index.php?topic=5171.0). The packet will include the API endpoint for the wallet site of your choice. It will then encrypt and sign it with your private key and generate another machine readable data packet for the merchant to scan. Once he scans it, the packet would be submitted to the site, and upon successful decryption the funds could be transferred to the merchant's account. And the sale would be concluded.

Best part about it - they don't even need the hardware terminal for processing. A simple app would do, all it needs is a total and an address.
And your mobile device does not need internet access for this to work. Which can make it rather simple. Even a palm pilot would be able to do that

Thoughts?

Good point, casascius. Looks like the implementation of this particular scheme is way to expensive and hard to integrate. If the window for potential doublespend is indeed short, at shouldn't be a problem for 99% of all use cases.

A few things were voiced in this topic, one of them is the use of sites like mybitcoin to arbitrate payments. That kinda makes it centralized, and the whole point of bitcoin is to avoid centralization.
I have a few ideas on the subject, which I'll voice in another topic.

The problem with using bitcoin in PoS scenarios is the necessity to wait for confirmations. And smart cards are infinitely more tamper proof compared to cell phone apps. One reads about many hardware platforms (like high-end phones, or game consoles) being hacked and made run custom software. In the case of SIM cards, for instance, you might hear a story, that involved SIM cloning, and it was only possible with very low-grade cryptography used, which allowed to be broken after 65536 brute force attempts.

And if you can easily clone things, that means that the merchant will have to wait for confirmations, in order to avoid double-spent coins. It will render the PoS unusable in most cases.

Well, it's still possible to browse. Plus there's wiki, weusecoins, and other great resources, amirite?

Again, skimming credit cards works, because they only contain reference to the account number or whatever. And therefore can be duplicated. With single wallet copy in secure area on the card skimming becomes useless. They might skim your pin with a camera, but without that same card it's useless. At least my proposal for bitcoin debit card tries to make it so...

There's "Report to moderator" button. However the registration is probably not as bot-proof. Maybe people who want to use the site have to send BTC 0.01 to the forum, and then once registration is complete - they'd get it back

Then we know that person's interest in bitcoin is genuine

Update from the guy who works with SIMs. He talked to his sales rep, and rep said that with such small order volume a 64K JavaCard would probably go for $0.55-0.60. That is in Singapore. More volume obviously means cheaper cards.

Спокойствие, только спокойствие

Покупайте поп-корн и наслаждайтесь шоу.

Looks that is a compiled module. Did you follow the instructions from github page? Also, do you have 'build-essential' metapackage installed? (I assume you're on ubuntu).
If you install bitcoin-p2p via npm it should do build for you. If you did `git clone` then there was that extra step, that probably bootstraps the native module.

Install npmjs, all the modules are installed with this tool.

Gift cards are different from debit card. Gift card contains a reference to the money stored at the particular store/chain. Sorta like store credit. You can make arrangements with the merchant to simply buy gift cards with bitcoin, no need to keep the wallet on those cards.

And if you do simply keep the wallet there - it's insecure, because the merchant can keep both pin and wallet and use them later.

My idea is that the encryption routine is performed by the card, so when the card is gone - there's nothing the merchant can do to access your wallet.

Looks like those terminals go for about $300-$500 on ebay... Pretty pricy.
Do you have one to play around with in spare time? Just to run some crypto code to see how fast it is?
Do they have a dedicated crypto chip by chance to speed things up?

Well, that's a start Sprinkle it with some cryptography and we're almost there...


Excellent. Also, would they have enough resources to support both debit/credit/bitcoin in same software?
Although that probably would not be possible due to the fact that companies who lend those terminals to people would object. Because the transaction fees are their bread and butter...

Okay, so we have our PoS developer. Now we need a smart card developer

Cool. I think I'd establish a wiki page for this project first, put all details there so that people can contribute.
I don't really have any specific questions about the PoS part right now. Unless maybe this: is it possible to make them work with any arbitrary smart card? Is it just a matter of the software running on it? I would imagine so...

If that's the case - will they be fast enough to perform block scanning and signature validation and stuff? Not to mention that they'd basically be running a version of bitcoin software, and that means validating the block chain and all the other stuff that it does...

That would be another avenue of research.

The price I had was approximate, but other types of cards, like visa or mc are of no use to us, because we have to implement bitcoin specific algorithms. In order to have a bitcoin cards - the development is a necessity. However, I'm pretty sure there are enough geeks that do it for fun anyway, just a matter of finding some

It is possible to obtain development kits from major smart card manufacturers, they are around $300 per kit. So if we find someone willing - a bounty could be established.

Also, more cards are ordered - lower the per-card price is. Considering it's quite a massive up-front investment, something like a http://www.KickStarter.com project can be established, where many people can participate and pay a small amount to get a card or multiple cards they could distribute locally.

Yes. That is one of the reasons I'm posting this.

If we could research the possibility of a) Low cost smart card manufacture process and b) cheap pos hardware, that would make it super easy to approach merchants and say, hey, hate those Visa and Interac (canadian debit system) fees you have to pay for each transaction - here's BitCoin terminal.

Actually, a lot of smaller establishments remain cash only, simply because merchant transaction fees are so damn high. So that would be an easy sell, i think.

<pipedream>
Then they'd get their suppliers to switch to bitcoin, and so on, and so forth
</pipedream>

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

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.