Bitcoin smartcard Point of Sale terminal

[BitcoinAndie]

Western democracies are indeed looking to extend the current card based platform for as long as they can.  That said, mobile payments is the future particularly among the youth under 30, of the western democracies.  As for the rest of world, which is larger than the North America, Europe & Australia, card based systems are not in the... wait for it... "cards"     (I know a bit lame) b/c there is no point in going backwards to install the old infrastructure that we are busy milking. Card payments rode to prominence on land lines and a government back postal system with carriers, zip codes, etc.  For most of the planet, where ever you go, there you are! You will be known/located by your cell phone. No need to stamp out plastic cards to be mailed to non existent addresses, to run on non existent or very thin land lines.

Clearly, we will need a dual system for some time to come. That said, BTC solutions should be low cost, secure and readily accessible.

[1715189473]

1715189473

[1715189473]

1715189473

[1715189473]

1715189473

[1715189473]

1715189473

[jim618]

I am writing a command line interface to MultiBit and mainly to make it a bit more interesting I am going try to hook it up over a serial line to an HP graphing calculator:

https://bitcointalk.org/index.php?topic=76004.0
(see bottom of thread)

I thought I would cross post here as it is "kinda" related.


I was looking for a cheapish device that:

+ had a reasonable screen
+ keyboard
+ serial IO
+ programmable

and those HP50G calculators looked promising.

The serial IO is some sort of USB/ RS232 hybrid and there is also an IRDA connection.

[2_Thumbs_Up]

Why should we divert resources into creating smart cards when the rest of the world are moving away from them?

What are your sources?

My government just sank the equivalent of 120 million US dollars into another smartcard system (public transport).
Its waaay to expensive and unnecessary, but the system itself actually seems to work well enough.

Everyone here uses smartcard credit cards too.

I am currently in the neighboring country and they also use smart cards - THEIR similar system has been in place for a while and works perfectly.


I remember using mag cards once but those days are gone now and I honestly find the difference is nil and both are faster to use than cash.

Sure, we still use smart cards here as well.

But look on the horizon and what the credit card companies are doing. NFC is about to become standard in smart phones. Google is releasing google wallet. The next iPhone will most likely have NFC as well. The general trend is that people want to do more and more with their phone, and the payment processors have finally caught up on this trend. Sure, it will take a long time to phase out smart cards considering how integrated with society they have become. But the newer card readers are already NFC capable. Those who want to will be able to pay with their phone almost anywhere in the very near future. And that is the future that bitcoin should be aiming at.

[Realpra]

I don't understand this line of argument:

1. Phone payments are the future.
2. Hence, we should focus on doing that.

It WOULD make sense EXCEPT both android and IPhone clients have already been made so there's almost no work needed in that area.


Additionally BTC is already heavily entrenched in the first world so focus should be on the third/second.

While it is true they use mobiles a lot more than us their mobiles are often older and will not support a BTC client.


A smart card costs 2$ and the POS using my design would be 15$ and an Android phone.


Given rising metal, fuel, food prices and economic crises I do not see 1 billion Indians all getting a phone in the foreseeable future let alone a even near fancy one.

Anyway I'm busy with another important project right now, but I'll come back to this; buy some BTC develop the system, release and see the BTC range rise further still.
It seems until then there will be only talking here.

[BitcoinAndie]

I don't understand this line of argument:

1. Phone payments are the future.
2. Hence, we should focus on doing that.

It WOULD make sense EXCEPT both android and IPhone clients have already been made so there's almost no work needed in that area.


Additionally BTC is already heavily entrenched in the first world so focus should be on the third/second.

While it is true they use mobiles a lot more than us their mobiles are often older and will not support a BTC client.


A smart card costs 2$ and the POS using my design would be 15$ and an Android phone.


Given rising metal, fuel, food prices and economic crises I do not see 1 billion Indians all getting a phone in the foreseeable future let alone a even near fancy one.

Yes, cards would be cheaper, the problem is that for the "1 billion Indians" that you speak of, there are no bank branches, no bank accounts, thus no cards in their hands. Why does this matter? It matters b/c most of the merchants they frequent do no have a POS device. The developing world is leap frogging over brick and mortar to mobile. Them's the facts. You are correct in pointing out that that smart phones are not the norm yet. SMS is.  So if one were dedicated to developing a solution for the masses, it would be an SMS based system something that runs on something like "whispernet". Actually this would be easy, but it would require development of a middle office and some investment capital. When you free up a bit, I'd love to discuss further. And yes I have the facts and figures by country on a global basis....somewhere

[Realpra]

Yes text works, but how will you do that with some old old phone?

1. You can't install new programs; they hardly have an "app store".
2. Texting to a site/office that will hold your wallet and send txs for you would work, but introduces hassle for the payer (typing time) and a host of fees and security concerns.

My assumption is that normal folks would get a smartcard, at least in their family/village while merchants would use a handed down android running my imagined POS app and being connected to a card reader cable.

No banks would be involved and anyone could issue cards as it would be open source - for instance "red cross".
The cycle would be all BTC.

[BitcoinAndie]

Yes text works, but how will you do that with some old old phone?

1. You can't install new programs; they hardly have an "app store".
2. Texting to a site/office that will hold your wallet and send txs for you would work, but introduces hassle for the payer (typing time) and a host of fees and security concerns.

Good insights, but remember that when you have to walk miles to move money, SMS is a godsend! It's all relative. Google "Mpesa" The heavy work would have to be done on the delivery side, so that people are sending identifying information and transactions amounts to the middle office. There is also the possibility of using SIM cards (Unlike the US, SIM Cards are the norm in most countries). What do you think of: 

http://gigaom.com/mobile/facebook-sim-card-uses-sms-gemalto/

[Stephen Gornick]

I have no idea if this is applicable here, but I wanted to share this link:
 - http://www.gooze.eu/feitian-pki-free-software-developer-card

They're looking for open source projects and are giving away free cards.  Downside -- only for within the E.U.

[Realpra]

What do you think of: 

http://gigaom.com/mobile/facebook-sim-card-uses-sms-gemalto/

Developing a dedicated BTC sim card had not occurred to me... it would solve all the issues I mentioned.

You would still need to have an office but all they would do would be issuing the cards and taking a small fee for converting the sms into a btc tx.

The card would have inbuilt storage of BTC addresses and aid in sending the "Send BTC" sms and displaying my balance/addresses.

Addresses and keys would be in the phone itself which makes it a lot safer.

You would still have the same cost of a smartcard though as I'm sure they practically are/cost the same.

Still - it avoids some of the smartcard issues (occasional need for an internet bar and "expensive" android POS receiver terminals).

I think both systems could enhance bitcoin together as a SIM user could still pay a smartcard merchant and a smartcard user could with little trouble pay a SIM user.


Perhaps you or someone else should create a new thread dedicated to developing such an "Encapsulated thin BTC client SIM card" as we have arrived at here.

[randomproof]

Ideally, you would want the private key to never leave the card.  Therefore the card would have to be able to generate a transaction and give it to the terminal to upload to the network.  The terminal could then verify the transaction (check address balance and that there are no other transactions pending that would drop the balance) and release the sale.  I think there may be an issue since you would need the code for ECC, SHA256 and RIPE160 (that is a lot of code).  But I don't think storing keys would be to much of a problem.  You would only need a hand full of addresses and each is only about 64 bytes each (I think, someone correct me).  You could always switch out which keys are on the card for anonymity.

Edit:  I just remembered that you could possibly remove one of the hash functions since transactions are a kind of script.  You could change it so that the public key is only hashed with SHA256 or RIPE160 instead of both.  But to do that most nodes would need to be updated to recognize that kind of transaction, since the scripting functions are not complete.

[randomproof]

Did a little search and BasicCard looks promising.  It seems to have ECC and SHA-256 built-in.  Look for version ZC7.5
http://www.basiccard.com/index.html

[Realpra]

Hi guys, I'm DONE at my university so anyone want to design this baby with me?

I am aware of the ellet and its cool, but this is supposed to be cheaper, easier and more open to everyone. More solutions can't hurt.

Project:
1. We design it as described in this thread on standard cheap cards.
2. All is open source.
3. We develop and share together.
4. We create an API for BTC smartcards that all the BTC community can agree on.
5. We try to get the android wallet guys to incorporate card functionality via extension cable OR make our own simple simple receiver.

Profit:
1. We program the cards to send 1/10.000 of amounts to miners and ALSO a similar or LARGER amount to ourselves.
2. Everyone can release cards, it will just push adoption rates... and thus everyone's fame and fortune + BTC/world peace/death to banks agenda.
3. I and others can release free cards that have higher fees on them, though still around 1/1000 max. (with regular use will pay for itself within a year TOPS). Such could be distributed in dense communities or to people doing remittance regularly so as to reach "local 100% penetration".

We need:
1. Programmers!
2. "Cheerleaders"!
3. Business minded folk.
4. Everyone.

All support welcome.

I will start researching etc. in the coming days and post about progress (this is where cheers are crucial). You can join at any time.
I estimate the project will take 1 week to 6 months and after that I expect to get loaded rich with fees that keep coming forever after initial distribution.

[jim618]

Hi Realpra,

Have you seen the OpenPay project here ?:
https://bitcointalk.org/index.php?topic=92055.0

It is being developed at the moment and is an open source software stack to bridge the world of Chip n Pin / magstripe cards and Bitcoin.
If I understand what he is doing correctly, you will be able to use OpenPay cards in regular shops and the money gets converted into bitcoins and comes out your Bitcoin wallet.

I am sure the lead dev (Isis) would welcome any help as it is a pretty ambitious project.

Cheers,

Jim

[Realpra]

I read it now.

I will try to use what I can from their work and also share my work with them of course, however:

I am driven by the desire to see the existing banking sector BURN - I can't do that if I develop cards for them.

On a more rational node, EMV - after re-reading about it briefly - seems ludicrously unsafe and I think BTC can do better and stand on its own.


As for exactly what I will develop, I will describe the payment process below:
0. Card has 5-20 addresses so that even a shopaholic can use addresses with 6-block-verified balances.
1. ONE btc address sent to terminal.
2. If there's a balance on it the terminal requests amount/sends its receive address.
3. Amount multiplied "P" (0-9 nine number that cycles 1 each payment) sent to and displayed in terminal.
4. If the number fits, the user types their PIN (and for high security cards also P).
5A. Card locks itself for 10 seconds* and if everything was correct signs a TX and sends it back.
5B. Card locks itself for 1 minute in case of an incorrect code.

This security model can be further combined with a SMS service that monitors your addresses and warns you if there is too much going on immediately.

With this it would be quite impossible to fraud people without actually robbing them after learning the PIN. Since the merchant does not now P you could also shop just fine at a thief's supermarket every day (even low security cards would be quite safe with a warning SMS service).

All addresses and keys would be known by the owner of the card so that he may recharge it or empty/"block" it.

The card would self-fund by sending half of the just used address to the address just before itself in the cycle. The terminal may request more addresses if one is not enough for a big payment.


*Time here measured as "time while powered by a terminal".

EDIT: Also, I just realized, the connector cable + android would be cheaper for merchants to buy than existing VISA/Mastercard terminals and would not rely on being signed/blackbox security.

[jim618]

Today you make a smartcard that anyone can self issue that works in all shops on the existing EMV systems.
There is a bridge to the Bitcoin network where all the crypto magic occurs.

It is a poor bridge that only works one way.

Tomorrow you create a cheaper, better system that primarily lives in BitcoinLand, but when it has to (for compatibility reasons) it crosses over the Bitcoin -> EMV bridge and talks to the legacy systems.

[Realpra]

Today you make a smartcard that anyone can self issue that works in all shops on the existing EMV systems.
There is a bridge to the Bitcoin network where all the crypto magic occurs.

It is a poor bridge that only works one way.

Tomorrow you create a cheaper, better system that primarily lives in BitcoinLand, but when it has to (for compatibility reasons) it crosses over the Bitcoin -> EMV bridge and talks to the legacy systems.

But doesn't OKPay and similar already exist?

Anyway I'm sure we can cooperate on a bunch of things and that your work is great.

[jim618]

Thanks.

I think the differences between OkPay and OpenPay are:
+ You can self issue in OpenPay ie create your new smartcard directly
+ You can run your own payment generation software ie run your own back office

But yes the offering that the customer sees is similar.

Really you can create whatever combination of services you want !

[Realpra]

Thanks.

I think the differences between OkPay and OpenPay are:
+ You can self issue in OpenPay ie create your new smartcard directly
+ You can run your own payment generation software ie run your own back office

But yes the offering that the customer sees is similar.

What would your fees be compared to OKPay?

Before I read through your entire thread, what smartcard are you using and why?


Progress report:
I have learned the card should be programmed with the C language. Having used it before its not all that bad for simple things.

The reason for this is that the cards for C cost half as much. Sure a dollar or so is not much, but if you want to equip a village with cards 100% that's suddenly twice the village size you could go for.

Also pre-printed cards seem common. I was worried all the first gen cards would be ugly and white, but hopefully they can now be Casasicius-level pretty.

[jim618]

Hi Realpra,

For questions on fees, the actual card used etc on OpenPay the bitcointalk user Isis is the person you want to ask. He is the one actually creating it.

My involvement is mainly that I think it would be incredibly useful if he can get all the parts to work together. He asked if he could fork the MultiBit code for the GUI that does the issue of the smartcards (which is fine by me). I think he plans to clone the multibit.org site and rework it to get that started too. They will both save him a bit of time.

The reference software stack he is producing is open source so I am happy to help.

Programming in C on the cards is the way to go IMO, especially now that there is a cbitcoin code library being written so you do not have to do all the bitcoin/ crypto work from scratch.

[Realpra]

Gah almost all the cards I read about say that "the entire memory can always be read". How can I hide keys then?

Maybe I'm misunderstanding something.

EDIT:
Progress report:
SLE44-55 cards seem to be mag stripe cards in chip form. Security if any as I understand it is that the card and terminal establishes a secure channel.

If ONE terminal is compromised fake terminals could bring down any such system.

ACO3-5 cards seem to be what we are looking for with their own micro processor and signing capabilities. Will research more. 3-4$ lowest price I have seen so far:
http://www.smartcardzone.com/acos3.asp