Topic: Bitcoin smartcard Point of Sale terminal - page 2. (Read 26856 times)

Hi Realpra,

Have you seen the OpenPay project here ?:
https://bitcointalksearch.org/topic/announce-openpay-entering-burn-in-shake-down-alpha-test-phase-92055

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

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.

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

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.

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.

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.

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/

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.

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

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.

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.

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://bitcointalksearch.org/topic/multibitshell-hp50g-hack-76004
(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.

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.

Loading is simple just send funds to an address the card has.

Making the card aware of its current balance is a different thing obviously that requires (indirect) access to the blockchain.  One option would be to keep the number of private keys relatively small and have that performed as part of every transaction.  Each tx the card says "here is a list of my keys", and the POS machine says "here is your list back w/ your balances".  Users could do the same thing at home with smartcard reader.


PIN would be internal to the card.  I would imagine a system as simple as connect card to computer, enter old pin, hit change pin, enter new pin.  There would be no registry of PINs because each card would be smart enough to validate its own PIN.

The simplest solution which provides minimal privacy would be to have deterministic key generation.
All funds are held in one address (value address), all tx send balance to change address which becomes the value address, and the card "forgets" the old value address.

Address A (100 BTC).
Tx1: A (100 BTC) -> M1 (10 BTC)  & B (90BTC)
Tx2: B (90 BTC) -> M2 (15 BTC) & C (75BTC)
Tx3: C (75 BTC) -> M3 (5 BTC) & D (70BTC)

The idea behind the square devices are exactly what I envision; a small card adapter plugged into your phone and installing an app.

I think however that a simple cable/smart card reader would be cheaper than a licensed square device.

Further if they are based entirely on magstripes I don't its safe enough for BTC use.

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.

Hasn't Paypal launched a private label version of Square or perhaps Square's competitor Isis? It'll be interesting to see if Square can carve out a portion of the market place beyond their utility function.  My bet is that they'll be acquired before they can.

Square is the "merchant" in the traditional sense of how a card swipe transaction transaction occurs.  Square can do whatever they want with the proceeds.   They just happen to, today, sweep those proceeds (less 2.75%) to the Square dongle account-holder's bank account.  If they instead wanted to let their account-holder's accumulate a balance for all card-swipe payments received, they could do that.


Today, that's all they are.  But they aren't making much money because they charge just a 2.75% swipe fee and are in-turn paying most of that out in fees as well.

But once Square adds the concept of a wallet, then if a Square user (Alice) does a $100 sale she gets $97.25 but she lets it sit in her Square wallet.  Then when she uses it to send money to another Square user (Bob) , Square gives Bob just $94.57 ($97.25 less 2.75%) and keeps the $2.68 difference.   That' how PayPal has been functioning since 2001.  There's nothing tricky about it.

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

Stephen Gornick interesting in theory, but I think it's a bit trickier to move from mag strip (which triggers the debit or credit card networks) to ACH like Dwolla. When a card is swiped the "merchant acquirer's" bank/card processor is contacted to effect clearing settlement.  It is possible that Square could put in a middle office that takes all mag strip "calls" and routes them according to "on us" vs "off-us" transactions where "on us" are transactions where both parties have Square "wallets" and thus like Dwolla would be a cheap ACH transfer.  So, while I can see the utility developing a large user base, I cannot yet imagine how Square is not just another interface into the Visa/MC networks.

Or a "wallet", if that is a better term for it.  These are simply accounts that carry a balance, just like what PayPal, Venmo, Dwolla, American Express' Serve, etc. all have.


I think you are confusing what I am saying with the old "merchant"-centric models.  Square is P2P, except one side doesn't necessarily need to have a square account -- just a magstripe card.

Every person running the Square app can be a merchant though.  So there really isn't the concept of "customer" and "merchant" anymore -- at least not to Square (and Dwolla, and Venmo, and PayPal, and Serve, and ... ).

And just to clarify, that person who just swipes a magstripe card doesn't have an "account" with Square.


Same ways as with PayPal, Dwolla, Serve, Venmo, etc.  One way is to receive a payment from someone else and just hold onto it rather than having it simply pass through and funds withdrawn to a bank account.  Or the funds can be add using an ACH pull, just like how PayPal, Dwolla, VenMo, Serve, etc. do it.

It's the natural next step for Square to add a wallet once they have enough people using their app.   I'm not sure why they haven't done it already.  Probably because it adds complexity and is expensive to administer.  But eventually they will, I would bet.

Starting out Square Register by having it be the simplest it could be (a free app for iPad + a $10 dongle) and making the design super simple yet be a fully functional point-of-sale system is a very smart and unprecedented approach.