Bitcoin smartcard Point of Sale terminal

[Vasili Sviridov]

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:

• 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?

[1715190321]

1715190321

[1715190321]

1715190321

[1715190321]

1715190321

[1715190321]

1715190321

[1715190321]

1715190321

[lfm]

I dont see what this has to do with bitcoin, in fact it looks nothing like bitcoin.

[Vasili Sviridov]

Which specific points are you disagreeing about?

[Garrett Burgwardt]

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.

[Vasili Sviridov]

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...

[Matt Corallo]

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.

[Vasili Sviridov]

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.

[Matt Corallo]

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.

[Vasili Sviridov]

How can you sign a lot of transactions without having the private key?

[Matt Corallo]

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.

[Vasili Sviridov]

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.

[benjamindees]

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?

[Vasili Sviridov]

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

[Matt Corallo]

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.

Have fun stopping the hackers .  In any case I suppose the problem isn't unsolvable, just impossible on a huge scale.  In any case, getting merchants on board (or at least interested before starting would be cool as AFAIK, there are no where near enough IRL bitcoin merchants for this to be reasonable).  

[Vasili Sviridov]

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>

[caveden]

The idea is good, but the price quoting you mentioned seems high. $1 per card, not to mention the $50k initial investment?

It would particularly awesome if somehow you made it work in existent machines that accept Visa and Mastercard, but I don't think it's possible... is it? Can new software be installed in these machines?

[Vasili Sviridov]

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.

[casascius]

I have a significant amount of experience programming for VeriFone point-of-sale terminals... they tend to be programmed in C/C++ and have a proprietary OS that mimics POSIX compliance.  These also have smart card readers, though I have never programmed the smart card portion.  PM me if you'd like to discuss.  Programming Bitcoin on POS terminals is absolutely possible.

[Vasili Sviridov]

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...

[casascius]

It would particularly awesome if somehow you made it work in existent machines that accept Visa and Mastercard, but I don't think it's possible... is it? Can new software be installed in these machines?

I can run the following on a VeriFone Vx570 POS terminal


#include <string.h>
#include <svc.h>
char Greeting[] = "Hello World";
void main (void)
{
   int display = open(DEV_CONSOLE, O_WRONLY);
   write(display, Greeting, strlen(Greeting));
   normal_tone();
}

[casascius]

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...

When these guys build these terminals, they are nice enough to use quality 3rd party hardware for which documentation is independently available.  And these terminals run "monolithic" code: you interface with the hardware ALMOST on a direct level... there is a layer of abstraction (its API library makes syscalls into the firmware to get things done) but it's all blocking calls, there's no pre-emptive multitasking and no kernel doing anything in the background.  (Multiple threads and processes are supported but it's purely cooperative, when one thread/process blocks, control goes to another).

The interface they provide to the smart card reader IIRC is so low level that it's probably possible to get it to do anything the hardware supports.

One notable thing about the platform is they will only run signed code.  A bank can lock down a terminal with a public key and then the terminal will only run binaries signed by the bank.  But if you acquire an unlocked terminal (it says "DEFAULT CERTIFICATE" on the home screen) then their SDK comes with the private key to sign binaries for development purposes.

[Vasili Sviridov]

I can run the following on a VeriFone Vx570 POS terminal

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

When these guys build these terminals, they are nice enough to use quality 3rd party hardware for which documentation is independently available.  And these terminals run "monolithic" code: you interface with the hardware ALMOST on a direct level.  The interface they provide to the smart card reader IIRC is so low level that it's probably possible to get it to do anything the hardware supports.

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

[casascius]

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...

YES, the VeriFone terminals I'm familiar with are designed to support up to 13 isolated apps.  Each has its own file system partition so they can't steal data from one another, and they're targeted to not just do credit cards, but other things like EBT (food stamps/electronic benefits), time and attendance (punch in and out), etc...  I made a simple video poker app for one just to prove I could do it.

Although they don't have huge amounts of resources (4-8 MB of memory), they are physically designed so they can execute code directly out of flash memory (saves RAM) and the executables tend to be very small...in short...this should be no problem.  Notably, they are also physically designed to protect encryption keys - with specially caged memory that automatically forgets encryption keys if you try to physically tamper with the unit.  Pretty robust.

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank (if the default certificate were overridden) but acquiring new terminals with the default certificate is pretty cheap.

[Vasili Sviridov]

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?

[casascius]

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?

I can get them for $100 to $200 for a basic refurbished model with dialup or Ethernet, as can anyone seriously in the business of buying in bulk.  The refurb market is lively because businesses close their doors all the time. Refurb companies replace the exterior facing parts and they work good as new for a low price.

No dedicated crypto chip, just ARM CPU, but for signing transactions it is plenty.  The only dedicated crypto related components are tamper resistant memory and smart card readers.

Oh I forgot, they also have spots where smart cards can be permanently installed like by the bank, these are so you can add your own TPM etc. So 3 semi permanent slots (sized like gsm sim cards) and one full size slot for customer cards.

[benjamindees]

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank

In my opinion the biggest hurdle is that the transaction processing business is a total racket.  There are theoretically several different tiers of processors but they are all owned by the same company so they dictate everything from hardware and software to banks to fees.  And then there's the fact that I've never actually seen a POS terminal in the US with a smartcard reader.  They can't be that common.  Instead of messing with existing POS terminals you would be better off making a small ethernet-ready box that runs the necessary software and interacts with your Bitcoin cards or smartphones directly.  I'm not joking when I say it would end up being cheaper to go this route.

[ByteCoin]

custom ECDSA implementation for JavaCard is really slow
http://amadousarr.free.fr/crypto/ECDSAJAVACARD.pdf

I've been reading that paper. They seem to be using a slow modular inversion routine that runs 150 times slower than multiplication and also a point multiplication routine that involves many inversions. From this, it looks like they're using affine coordinates rather than projective for the point multiplication. This is a serious shortcoming.

I would hesitate to use that paper to support an argument.

ByteCoin

[casascius]

Because of the code signing requirement you wouldn't be able to add apps to terminals provided by a bank

In my opinion the biggest hurdle is that the transaction processing business is a total racket.  There are theoretically several different tiers of processors but they are all owned by the same company so they dictate everything from hardware and software to banks to fees.  And then there's the fact that I've never actually seen a POS terminal in the US with a smartcard reader.  They can't be that common.  Instead of messing with existing POS terminals you would be better off making a small ethernet-ready box that runs the necessary software and interacts with your Bitcoin cards or smartphones directly.  I'm not joking when I say it would end up being cheaper to go this route.

How much cheaper?  Those terminals are exactly what you describe, with hardening to keep cryptographic keys safe. They are perfect.  What more do you want?

I write time and attendance software for a living. I have written time and attendance both for POS terminals as well as little boxes running Linux just like you describe. POS terminals with smart card are easy to acquire, I have one sitting right here, it is just an option that adds a few bucks to each unit. And I appreciate the fact that I can lock the hardware down with signed binaries if I choose to, so I can sell a trusted product. The point of it is to secure the contents right?

Anybody can buy their SDK, take their course, and start compiling apps. I am not a banker and I was able to do it.  

[casascius]

Their SDK I should mention costs $10k to $20k. So one who wants to develop apps has to be serious, but that is chump change for someone building a payment processing network.

Also I wrote my own server side code. They hold no monopoly on that either.

[benjamindees]

Well, there are really two separate issues.

In my experience banks and credit card processors tend to have conniption fits when presented with non-standard hardware or software.  Telling them you want to install a competing processing service on hardware that they have any control over is just an excuse to raise your fees or cause you problems.  I don't know the usual arrangement, but if it's common for the POS terminals to be subsidized or locked-down then you can say "adios" to the dream of running Bitcoin on them.

As for smartcard readers, I was referring to currently-installed hardware.  If it's really just an easy and cheap (<$400) upgrade, then great.  But if a substantial portion of older POS hardware in use isn't capable of easy upgrade, then at a certain point dedicated hardware becomes the better choice.

[Vasili Sviridov]

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.

[ChrisRich]

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.

What I don't get is why anyone would make effort to go backwards in the tech tree? Smart cards are just another point of failure and expense when we already carry smart phones?

I've been doing work with point of sale (professionally) for over 9 years now, and you can trust me when I say that I've got no love for the existing infrastructure.

I'd push for a in-store product registry with Aztec(public domain) or similar 2d barcoding on the items for information and purchasing. Scanning one of these items will bring up the entire history of the item which can in many cases add value to the store/products.

When you spot something you wish to own, you'd scan it (take a picture) with a mobile app that would handle the purchase and authenticate. You can place the item in your cart and at the checkout the cashier scans the items a second time to confirm which ones are paid and which need to be paid to continue.

This would allow the retailer to do promotions on items and track those sales, while still allowing everything else to be purchased normally. Retailers LOVE solutions that they can ease into slowly without shutting down the store for a few days.

[casascius]

In my experience banks and credit card processors tend to have conniption fits when presented with non-standard hardware or software.  Telling them you want to install a competing processing service on hardware that they have any control over is just an excuse to raise your fees or cause you problems.  I don't know the usual arrangement, but if it's common for the POS terminals to be subsidized or locked-down then you can say "adios" to the dream of running Bitcoin on them.

Seems to me this would be for good cause.  If you administered these things, why would you go to the effort of acquiring a secured payment platform only to let people run whatever they choose on them?  The bank card industry suffers ingenious data thefts left and right, so you'd be hard pressed to blame them for this.  That said, if their customers are demanding it in droves, and there is a revenue stream to be shared, and their engineers can inspect and sign the code, that's what will get them on board.  They are fairly receptive to my time and attendance app for those reasons.

As for smartcard readers, I was referring to currently-installed hardware.  If it's really just an easy and cheap (<$400) upgrade, then great.  But if a substantial portion of older POS hardware in use isn't capable of easy upgrade, then at a certain point dedicated hardware becomes the better choice.

Look here, a Vx570 with smartcard reader for $299: http://www.terminaldepot.net/products/VeriFone-VX570-6mb-w%7B47%7D-Smartcard.html

Despite it only having 6 MB of memory, that goes a LONG way on this platform as compared to an app for a PC.  My time and attendance app, complete with a statically linked TCP/IP stack with SSL, is only about 0.5 MB.  This device isn't going to be able to hold the whole block chain by any means.  But it would be perfect for kicking off transactions from a MYBITCOIN or equivalent, or talking to a participating bitcoind when needed.

The real travesty, the way I see it, is how valuable retail merchants consider the surface area of their countertop.  You can easily put another terminal in there for less than $400, they're more likely to balk at having to have one more gadget.  That said, at this early stage, if they really want to deal in Bitcoins, they're not going to mind.

[Vasili Sviridov]

What I don't get is why anyone would make effort to go backwards in the tech tree? Smart cards are just another point of failure and expense when we already carry smart phones?

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.

[casascius]

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.

A terminal that can consult with a well-connected instance of bitcoind can validate against a casual double spend, a topic that has been well discussed in the past.  The tl;dr of it was that, even without confirmations, once a transaction has been well broadcast amongst lots of nodes, and no other competing double spends have been received (regardless of confirmation status), it's pretty difficult to reverse a typical retail transaction with less resources than the transaction is probably worth.  And also, knowing that scalability of Bitcoin depends on the formation of bitcoin "banks" like MYBITCOIN, these "banks" when trusted by the merchant may also be able to guarantee availability of funds on their own balance sheets without  waiting for confirmations in the block chain.

[casascius]

A terminal that can consult with a well-connected instance of bitcoind can validate against a casual double spend

The ten-minute blocks are not a fundamental limitation for point-of-sale. I can imagine a few mining pool operators collaborating to offer a service to merchants where the pool operators are prepared to validate any transaction within a few seconds on the basis that "if any of the pool operators mines a block, that transaction will be in the block because no earlier spend has been seen".

With the mining pools accounting for about half of generating capacity, that ought to provide enough reassurance for point-of-sale transactions.

Yes, great idea, those mining pool operators, after "validating" any such transaction, could also automatically work to fight any block that happens to contain a double spend against their validated transactions as part of their services.

[Vasili Sviridov]

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.

[oillio]

The confirmation issue can probably be overcome.  But there is another issue that cannot be solved with smart-cards.

A smart-card does not have an independent display.  You must trust the POS system that you plug your card into.
The POS can claim that it is debiting $1 from your card, while it is really transferring $100.  You won't notice this until you try to use your card again, which is probably much too late.  There is no way to overcome this issue, except for using a device with its own display (like a smartphone).

This is not an issue for credit cards because the bank can do a charge back.  If this happens to you (and it does happen) you just call up your bank and they give you your money back.  But Bitcoin is different...

[Vasili Sviridov]

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

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

[ChrisRich]

The confirmation issue can probably be overcome.  But there is another issue that cannot be solved with smart-cards.

A smart-card does not have an independent display.  You must trust the POS system that you plug your card into.
The POS can claim that it is debiting $1 from your card, while it is really transferring $100.  You won't notice this until you try to use your card again, which is probably much too late.  There is no way to overcome this issue, except for using a device with its own display (like a smartphone).

This is not an issue for credit cards because the bank can do a charge back.  If this happens to you (and it does happen) you just call up your bank and they give you your money back.  But Bitcoin is different...

Yes and the lack of a display on the smart card nixes any added information value of the effort which is why I suggested 2D Barcoding as a win-win. The retail perks of having more information given to the customer and the retailer is going to offset any concerns of cost to implement.

Plus the interface on the phone would have the option to challenge the bitcoin account holder for validation, meaning the amount paid will be verified, and it can't be stolen and abused by simply physically having the phone.

[sebastian]

I think a better idea here is:

You have one CARD keypair.
And one ACCOUNT keypair.

The ACCOUNT keypair is not available on the card, only on computer, and the CARD keypair is available on BOTH card and computer, BUT the private portion is saved in a way that does not allow it to be extracted (only used).

When you do a purchase, you insert the card into the POS terminal, and the POS terminal searches for some of your coins (The card could also save some transactions for faster search), uses them as sender, sends the coins you wants to purchase for to merchant and receives change.

Since the private key is "locked" into the card (so it can only be used, not copied), any crook merchant cannot copy the private key and use it later when your'e not around.

A crook merchant COULD debit your card more than agreed purchase amount like debiting 100$ but showing 1$ on display, but thats true for cash too.

If you give a 50 $ bill to a merchant for a 30 $ item, he could simply refuse to give a 20 $ bill back. Its the same problem. You need to trust the people you are doing affairs with. And in case its a crook merchant, you simply police report him and the police does it's work.

Thats why you should never carry more on your card than you are prepared to lose. So you can carry lets say 3 cards with you, one card with 10BTC, one with 50BTC and one with 100BTC. This will be like bills in a wallet. You give the smallest possible bill to merchant, in case he is a crook.



But the big bonus is that you can PIN protect the card, AND if you lose your card, you can "ban" the card in this way:
Simply move ALL coins currently saved under CARD key to ACCOUNT key. Now the card is empty, so even if someone figures out the pin or physically hack the card, theres no coins on card.

[Realpra]

How are things going with this project?

I think its instrumental to the widespread success of BitCoin and its why I joined this forum.


I think I "solved" the "no-display" problem:
1. POS displays debit amount 1$
2. POS sends this amount to the smartcard.
3. Smartcard multiplies this amount with a number only you now, say "5".
4. The result is sent back to the terminal.
5. Terminal displays "checksum" "5" - only you can know whether this number is correct or not. The number may even increment once each time making logging results impossible, you just have to remember slightly correctly to check the checksum.
6. You punch the pin code. If the terminal attempts to post a NEW amount before a pin is given the card locks itself for 10 minutes.
7. Card sends signed transaction to the terminal.
8. Merchant is happy. If there is double-spend, unlikely as it is, he has seen you in person and can call the cops.

I imagine that both card and POS software should be public with checksums for the trusted versions.

New smartcards could be made by anyone with a smartcard programmer so though you would trust that party you would not be bound at all.
It would be as ubiquitous as BTC itself.

Next, the card would be sent in the mail along with the address, private key and pins so that you could back up your card or refill it on your own.
Naturally the card should not be your main storage medium despite all the safety.

Such terminals would cost very little and the cards would be affordable even in third world countries - UNLIKE android wallets!

Merchants would simply link their terminal to their mtgox address and post an immediate and large sell order. At the end of the day fiat currency could be withdrawn from mtgox.

Casascius coins are very cool, but I believe the market has found smartcards to be the most easy to use and we should act on that.

[benjamindees]

I've done a little research on this, and I think the way to go is to use a smartcard with an integral LCD display and at least one button.  These are on the market already.



http://www.nidsecurity.com/

Basically, the POS terminal just sends the balance due to your card, which displays it for you.  You then press the button to verify, and the card creates the transaction and signs it.  No need to trust anything.  The card can keep track of your balance, and you can verify it via some other trusted channel just like you do with debit cards now.

[BitcoinAndie]

1. Smart cards are expensive to produce, so cardholder adoption rates will be disappoint.
2. The "S" curve for Merchant acceptance in the US is nil. Europe is a possibility. 
3. Better solutions are simpler and will leverage existing infrastructure with an eye towards smart phones.
4. Your current design will attract US regulatory oversight, resulting in need for money transmitter licensing.

[benjamindees]

4. Your current design will attract US regulatory oversight, resulting in need for money transmitter licensing.

Whose design?

[nedbert9]

@OP:  Smartcard that's lost = lost money = non starter.

The populous would hate this and ultimately reflect poorly on Bitcoin in public perception.

[cbeast]

@OP:  Smartcard that's lost = lost money = non starter.

The populous would hate this and ultimately reflect poorly on Bitcoin in public perception.

Not if it has multisig protection. Just activate your backup card. The lost card is worthless.

[Realpra]

I've done a little research on this, and I think the way to go is to use a smartcard with an integral LCD display and at least one button.  These are on the market already.

Yes, but my checksum solution achieves the same with only normal super cheap smart cards.

What are the price of these display cards, I couldn't find it?

Smart cards are expensive to produce, so cardholder adoption rates will be disappoint.

Actually normal smartcards cost less than 2$ a piece; buy in bulk and it comes down from even that.

(http://www.smartcardsupply.com/Content/Cards/ISO7816.htm)

An innovator/BTC promoter could send them to everyone in a city as a stunt for the price of a normal small ad campaign.

From there, usage can spread like a wildfire.

POS terminals are rented out to the largest merchants in town as part of the campaign.

@OP:  Smartcard that's lost = lost money = non starter.

This depends entirely on design - I know my pin code, why wouldn't I just know my private key too?

With my BTC smartcard/wallet and my BTC client I am my own bank and card provider.


I can help develop stuff after the 30. of June and I'm an educated programmer.
I will do it for free, but with a small payment I could do it full time.

I don't see this as something that would take long to create a development kit for.

[Haplo]

@OP:  Smartcard that's lost = lost money = non starter.

This depends entirely on design - I know my pin code, why wouldn't I just know my private key too?

With my BTC smartcard/wallet and my BTC client I am my own bank and card provider.


I can help develop stuff after the 30. of June and I'm an educated programmer.
I will do it for free, but with a small payment I could do it full time.

I don't see this as something that would take long to create a development kit for.

I can see really two problems with the smart card proposal.

With a smartphone, you can have your home desktop computer act as a server for your phone's app and then it's easy to limit the liability of how much money you can lose if someone steals your phone.

With a smartcard you could do basically the same thing, store the private/public keypairs for some pre-made accounts that you want to spend from along with the reference txOuts, and some software for negotiating/signing tx.

However, in order to make this work, you have to have your own smartcard reader to load it with money, which may or may not be expensive for your average user (or maybe not?).

The other thing is the sneaky merchant problem. Most smart cards are designed to be used with a tap of your wallet, so a screen would basically defeat the point, and a button on the card would be too easy to accidentally activate (or too easy for a thief to use). The only way to completely circumvent that problem is to have something with basically the capabilities (and independent power source) like a smartphone, where the merchant has no direct control over what is sent. Or else a card with a screen, a pinpad, a cancel button and a "lock price" button, which wouldn't be so easy to use one way or the other and isn't available since most banks can just do a chargeback instead.

[benjamindees]

However, in order to make this work, you have to have your own smartcard reader to load it with money, which may or may not be expensive for your average user (or maybe not?).

With a display, at least, there's no reason you couldn't add Bitcoins the same way you spend them.  Even multi-sig backups could probably be made to work without a reader as well.

The other thing is the sneaky merchant problem. Most smart cards are designed to be used with a tap of your wallet, so a screen would basically defeat the point, and a button on the card would be too easy to accidentally activate (or too easy for a thief to use).

Personally I lean towards the contact smartcards rather than RF.  They are more reliable, and less subject to tampering.  It's less convenient, but not really any less convenient than credit cards currently.

[Haplo]

With a display, at least, there's no reason you couldn't add Bitcoins the same way you spend them.  Even multi-sig backups could probably be made to work without a reader as well.

I don't really get it. If you don't have a smart card interface to your computer, how do you load any coins onto them? By going to some centralized bank? Certainly the grocery store isn't going to offer deposit services for bitcoin cards. If you do have a card interface for your computer, you could set up your pin securely from there and load whatever coins you wanted from your online or offline wallets.

Personally I lean towards the contact smartcards rather than RF.  They are more reliable, and less subject to tampering.  It's less convenient, but not really any less convenient than credit cards currently.

I don't see how a contact based smart card would be any better than an RF card security wise. Neither has a large enough range to allow someone to steal your money remotely, and in both cases you're trusting that the manufacturer of the card reader has made it so that the merchant can't charge more than they said they would without retyping your pin.

AFAIK (from the few RF smartcard readers I've seen, and McDonald's is about the only place I've seen them) most RF card readers don't even require even so much as a pin input, which would be a disadvantage vs contact cards, but the card itself could require a pin to mitigate that problem. On the other hand, requiring a pin would be a disadvantage for small token purchases, like the original usage of smart cards as subway tickets.

Although the price tag of a smart card is way more affordable than a smart phone, I don't think they're well suited to the technology and usage of BTC.

[ThomasV]

shameless plug: https://en.bitcoin.it/wiki/Smart_card_wallet

[Realpra]

With a display, at least, there's no reason you couldn't add Bitcoins the same way you spend them.  Even multi-sig backups could probably be made to work without a reader as well.

1. You load simply by sending BTC to the address of the card - you don't need a smartcard programmer to load it.

2. The card receives a transaction request and if you see the right checksum returned from the card, you give your pin.

3. Provided the pin, the card now signs the earlier transaction with a unreadable private key on the card and sends this signed message to the terminal.

4. The terminal publishes the signed message to the network.

ANYONE see any holes in this?

shameless plug: https://en.bitcoin.it/wiki/Smart_card_wallet

Yeah seen it; already added my proposal with checksums instead of LCD screens (not that those aren't cool! I had no idea that could be done)

Anyway we can create a complete BitCoin economy system here:
1. Bitcoin client is your bank and online payment device.
2. Smart card is your wallet and credit card.
3. Simple terminals accept payments.

That's it! And its physically impossible for a merchant to hack your card.

Lets do a mailing list or facebook group with people who support this and have programming skills.

I'm busy now, but in the summer I can program for this project.

Since ?Cascious? has done this sort of thing before he should probably be the lead dev and we just help where we can and with promotion.

[Realpra]

I had another idea:

Step 1: Create smart card reader that can be connected to an android phone via the standard plug.

Step 2: Create app using said cable connector to turn the phone into a POS terminal.


Now anyone with a sub 200$ android phone could become a merchant!

[cbeast]

I don't see any point in developing new hardware. Bitcoin is the most adaptable currency invented (I consider it the ninja currency) and should use whatever is already ubiquitous. Magstrip readers are plethera, barcode scanners too. I don't see many smart card scanners in America, though it's probably because I live in a rural area. I'm sure there are a lot of magstrip haters here, so I probably shouldn't have mentioned it. I'm sure many other countries are technologically way ahead on the smartcard trend to buy their bullet train tickets. I hate to be a pessimist, but I see the way most average Joes behave and they won't be using iPhones, smart cards, or any other new gadget any time soon in the retail environment. They will be using magstrips and paper. If Bitcoin cannot adapt to magstrips, paper, and sms, then it will require bucking the system. It's too expensive to try to educate the masses about new gadgets.

tl;dr  Bitcoin is the most adaptable currency and should use what is already ubiquitous, because it's too expensive to educate a market.

[Realpra]

daptable currency and should use what is already ubiquitous, because it's too expensive to educate a market.

I agree totally. However to expand BTC beyond computer-to-computer use we need a POS-system.

Given this, the nature of BTC and your argument the technology that exists IS smart cards.


I don't think a swipe card can be programmed unless it has the same chip as a smart card anyway - otherwise I would be with you there.

Paper BTC won't work as you would have to trust a million different printers who could have saved the private key they put on the coin.
(Even Casasciuos has admitted this flaw)


Smart cards work very much like swipe cards though; the ONLY exception is that you insert it instead of swiping - PIN, terminal etc. all looks and acts the same.

You ignore the returned checksum unless merchants start scamming people.


The cards cost 2$ a piece so you could practically hand them out.

The terminal could be a 10$ cable, a free app and your already-owned android phone. A total cost of maybe 110$ that even grandmas could pay to with their card.


All WE have to do is to order the cards, cable (I'm sure it exists), develop the chip program and the android terminal client.

Then we release all our code, suppliers, data and guides and anyone can sell programmed cards in their region and anyone can download the app/buy the cable.

EDIT:
EXACT supplies needed to turn my Android into a POS terminal:
http://www.amazon.com/USB-Type-Female-Adapter/dp/B000GHXTA0
(1.1$)

http://www.athena-scs.com/products-solutions/readers/contact
(Approx. pricing of above: 14$ - source: http://www.kinapriser.dk/konig-smart-card-reader-p-4695.html)

So... lets start programming?

[BitcoinAndie]

Guys the adoption rates on new merchant POS devices is an S curve. As for adapting existing hardware, merchants tend to be VERY reluctant as the POS device typically links into inventory management or at a minimum the G/L.  Incidentally, the Europeans have been trying to get the Americans to adopt Smart Cards for almost a decade. They've kind of given up on the retail payments side, but it's my understanding that they are now pitching it as a medical records management solution.  Doubt it'll work there either, as the developing world is leapfrogging over smart cards to mobile (Smart cards are too expensive for both consumer and doctors/pharmacies/clinics/hospitals to implement.) As for working through the card processor, not very likely as you have to have a BIN to join the network. The big banks, Paypal, and new retail payments entrants like Google are using competing protocols to fight over share of wallet, and they typically look to devise solutions that erect barriers to entry (friction and fees)

Personally, I think a card based solution that leverages tradition POS technology is a mistake, as the entire systems is in flux; (thus crappy dongle technology like Isis and Square) and the merchants seem to be waiting on a dominant design to emerge before yet another upgrade to their POS hardware. As you know the banks are trying to shove NFT down the merchants' throats, haven't heard of any positive news un uptake rates beyond markets serving the top 1%.

I think solutions should be forward looking and with an eye toward creating some sort of universal adaptor should demand support the need for backwards integration.  My early sketches suggest that the cost structure of a "universal adaptor" would not be competitive, so how do you get the merchants to accept a more expense system with increased settlement risk (yes it's non reversible, but 10 mins is 9 min 50 seconds too long meaning you've got to build a middle office to hedge that risk) So to whom does one pass on costs in excess of the industry average 2.8%.

Don't mean to sound like a nay sayer, I think about this problem rather frequently, and I too find myself frustrated by the timing differences between the evolution of BTC, the lagging implementation of mobile money (the US is woefully behind, search "M-Pesa" 9MM users in 3 years), and the lack of vision and defensive genuflecting by the big banks when it comes to next generation retail payments solutions. 

[Realpra]

Guys the adoption rates on new merchant POS devices is an S curve. As for adapting existing hardware, merchants tend to be VERY reluctant as the POS device typically links into inventory management or at a minimum the G/L.....

Well there is no reason we can't develop the software for real terminals first, but where do you think our chances are best? Immigrant shops that would prefer using their Android or big supermarket chains?

Whatever the shape of the curve it can't begin before we create this tech - we could be the creators of a new world spanning standard here.

My early sketches suggest that the cost structure of a "universal adaptor" would not be competitive

The components would cost in total 15$ as I wrote last post - that is at LEAST 10x cheaper than a normal POS system in my country.

If you go full terminal the cost largely remains the same, but you don't get a nice smartphone in the package to use after work.

, so how do you get the merchants to accept a more expense system with increased settlement risk (yes it's non reversible, but 10 mins is 9 min 50 seconds too long meaning you've got to build a middle office to hedge that risk)

The system would be cheaper actually, both in implementation and use:

You just go by unconfirmed transactions.

If somebody pulls a double spend they get arrested as they are on your store camera or witnesses saw them.

Heck even pulling off a double spend is pretty hard to do, especially considering that we could program the POS to check for it (lots of transactions suddenly coming from the address after purchase).

You would wait max. 10s. - the time it takes to pack your groceries anyway.

[BitcoinAndie]

4. Your current design will attract US regulatory oversight, resulting in need for money transmitter licensing.

Whose design?

Sorry about the delayed response.  Any design leveraging the card processing network. Any network that registers debit or credits in USD. It you co-locate a private BTC only network that doesn't talk to the merchant's cash register then you may as well move straight to mobile as the merchant will then have to reconcile by hand all BTC trade, since they well need some sort of paper trail for the accountants/ auditors.

[Realpra]

Sorry about the delayed response.  Any design leveraging the card processing network. Any network that registers debit or credits in USD.

I agree that is unacceptable, I am talking about a pure BTC system - client = bank, BTC card = USD credit card and BTC POS = Visa terminal.

A complete replacement, beautiful, simple, cheap and pure like BTC itself.

It you co-locate a private BTC only network that doesn't talk to the merchant's cash register then you may as well move straight to mobile as the merchant will then have to reconcile by hand all BTC trade, since they well need some sort of paper trail for the accountants/ auditors.

Well lets say we develop a POS terminal accepting BTC (cards) directly.

It should not be much of a stretch to wire a USB cable from that into the corp computer that merges it with the normal POS data.

We would provide an API for communicating with the BTC terminal of course.

Otherwise all transactions and their times going into the corp address would be in the blockchain for later auditors.


Anyway big businesses will not be the first adopters, lets focus on the small guys - and thus, I think, the Android + 15$ cable connector.

[BitcoinAndie]

Universal adaptor, sorry mate, not really in scope for the way you are envisioning your system. I was thinking about a virtual wallet that enables BTC to link seamlessly into debit or credit card networks.  Okay back to your design. It's likely best to work with whatever hardware is currently in place. Selling into small mom & pop shops will be easier than selling into a national chain (but still time consuming) b/c they are more likely to accept some manual processes.

Sure you could depend on someone else to handle exchange risk, but hedging exchange risk might give you the opportunity to offset the cost of deploying your solution. (Most smaller merchants are not that tech savvy and rather risk adverse)  In my experience changing Merchant behavior to achieve meaningful scale will involve some sort of incentive meaning accepting BTCs is cheaper and/or brings new Biz.

If you want a recent analog, take a look at GreenDot. (Since they are publicly traded you should be able to get their Annual Report for the past few years from the SEC's website for free. In it you'll see a bit more about the cost of floating their system.  It ain't cheap) Sure the hardware relative cheap but the time and labor to implement, not so much.

Sure you could design an opt in Smart Card system, but it'll be more like a novelty/alpha test than a prototype/beta test.

Payment systems are hard b/c they are highly regulated, little is published, and they touch both Merchant-- Inventory Mgmt and the G/L of the business on the front end, and cash management, accounting and audit in the back office. Realize that one way the regulators and IRS are able to "encouraged" the Merchants to follow best practices is to link compliance to bank--loans, cash management services, and even merchant acquiring accounts.

[BitcoinAndie]

It should not be much of a stretch to wire a USB cable from that into the corp computer that merges it with the normal POS data.

True. You'll need to factor in Merchants reluctance. They tend to be afraid of voiding their warrantee, and that an untested systems might write errors to their G/L. So doable, but time to sell and implement and merchant value proposition must be compelling.


Otherwise all transactions and their times going into the corp address would be in the blockchain for later auditors.

So we're talking BTC converts like ourselves....

[Realpra]

Universal adaptor, sorry mate, not really in scope for the way you are envisioning your system. I was thinking about a virtual wallet that enables BTC to link seamlessly into debit or credit card networks.

Yeah that seems quite impossible as the card would need to access mtgox, sell the BTC, send it back from mtgox... not happening via terminal!

Selling into small mom & pop shops will be easier than selling into a national chain (but still time consuming) b/c they are more likely to accept some manual processes.

I am imagining the first markets as something like Greece where no one wants to pay tax to the bankers or young innovators starting out with minimum cash for terminals etc..

As for manual processes its pretty clear you know more than me about exactly what a cash register needs to do.

Still I am sure we could do more advanced functions; a spreadsheet with transaction records should be doable in an Android POS app from V.1 though - just save it to the SD card.

Since the Android has camera it could scan QR codes and add to an order too!


As for a complete automatic system that a supermarket would use that can wait a little.

Sure you could depend on someone else to handle exchange risk, but hedging exchange risk might give you the opportunity to offset the cost of deploying your solution.

Well BTC are more stable these days and probably going up, that said you could set your address in the app to your mtgox address - that way your coins can be sold immediately for regular cash.

(Most smaller merchants are not that tech savvy and rather risk adverse)  In my experience changing Merchant behavior to achieve meaningful scale will involve some sort of incentive meaning accepting BTCs is cheaper and/or brings new Biz.

I'm pretty sure our Android system would be simpler to start with than any Visa terminal I have heard of!

Old businesses might stay the same, but new businesses may see BTC and BTC POS as a godsend of simplicity to get started.

Yeah wouldn't need to rely on market penetration of BTC either as they could gift regular customers with BTC cards and load them with cash or something.

Hell for all the customers need to know they could be told it was a reusable gift card!

If you want a recent analog, take a look at GreenDot. (Since they are publicly traded you should be able to get their Annual Report for the past few years from the SEC's website for free. In it you'll see a bit more about the cost of floating their system.

Sure you could design an opt in Smart Card system, but it'll be more like a novelty/alpha test than a prototype/beta test.

I have seen quite a few debit cards and they all seem like an expensive overlay to mastercard - whats the point?

Lets go full BTC and ALL that trouble, cost and those 2-3% fees disappear.

There must be a million BTC users by now, if 10% of them gave friends and relatives a smartcard loaded with 2 BTC as birthday presents that's an instant mega market.

Payment systems are hard b/c they are highly regulated

Well in Scandinavia and Germany I think you can trade BTC all you like - as long as you pay your taxes as normal and a yearly budget - nothing new there.

True. You'll need to factor in Merchants reluctance. They tend to be afraid of voiding their warrantee, and that an untested systems might write errors to their G/L. So doable, but time to sell and implement and merchant value proposition must be compelling.

The same could be said for BTC, why did it ever take off?

Well however we debate that part of the reason was because it was THERE and it was USEFUL. If we focus on just that we can't mess up.

As for advanced merchants as you describe, for now, I would ignore them completely.

So we're talking BTC converts like ourselves....

Well isn't it pretty sad that WE can't use our own damn currency even if we all lived in one town?

Lets fix that and see what happens.

[BitcoinAndie]

There are a few paper-based analogs. I seem to remember reading of a handful of towns that created there own voucher (currency) that could be used in all the shops in that town.  Maybe Ithaca NY (Cornell) was one?

Yes agree, the US markets are highly regulated and the FATF is driving KYC rules thru the entire global payments systems via SWIFT. Remember that anyone using the VISA or MC networks must have a BIN to even apply for access. 

I think your system will work and if you work 100% in BTC you may not even need a money transmittal license until such time BTCs are formally defined. Having said that, there is a elephant in the room that simply cannot be ignored. For everyday mom and pop shops, they would really have to be BTC enthusiasts b/c at present the # of potential customers, likely sales and the costs and risks of running a separate offline payments system that has to be marked to market and cashed out on an exchange is likely to be a very hard sell given the dollar amount in tax savings. 

Or to put it another way, can you think of actual products or specific types of stores that would benefit from adding a BTC capability and have you constructed a simple spreadsheet showing the # of such goods or services they would have to sell to break even on their startup costs (meaning lower cost per transaction + interest on deferred taxes)?

As some point all of us early adopters and innovators will need to level up quite a bit in terms of infrastructure/support (hardware+ software, txt & video manuals = ease of use) if we expect to see the growth in BTCs acceptance and usage that gets us to some sort of tipping point in the brick & mortar world. Strategically, I am developing a pretty clear vision of how BTCs can interact with the current global payment systems, and to me that's exciting. As for network and app development, I am a total noob, all I can offer is a list of must have functionality.

[Haplo]

There are a few paper-based analogs. I seem to remember reading of a handful of towns that created there own voucher (currency) that could be used in all the shops in that town.  Maybe Ithaca NY (Cornell) was one?

I believe ithaca uses a time-currency worth about ~$10 an hour. There's also Berkshares and a few others. All of said currencies come with a socialist hook, however.

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it? Seems to me it'd be up to memory and luck to make sure you didn't overdraft, which would end up sending an invalid tx anyway. More importantly, how do you set your pin without a central authority doing it for you? I think it's also worth noting that if a card continuously re-uses a single address, then it kinda kills your privacy too.

On the merchant end, assuming physical sales, there's still the problem of integrating a bitcoind backend for register and accounting software, and exchange risk. It seems to me CAO/ICS systems would be less affected, if at all except for the inherent exchange risk involved.

Protecting against double spends = easy
Protecting against exchange risk = not so much
Protecting against arbitrary government confiscation and dealing with accounting conversions = jungle gym

In Greece I think all the disadvantages are moot. Greek business owners currently can't get loans, greek people have no money to spend, and the value of the Eur is evaporating out from under them both in government debt and inflation. Anything that would allow them to easily manage their business or even do business at all would be nothing short of deus ex machina for them, and it's not like they give a damn about complying with government tax regulations or anything. They would like nothing better than for the EUR, the ECB, the IMF, the unelected European Commission, and their own unelected government to hurry up and die so they can get on with their lives.

[BitcoinAndie]

Okay, If I understand you now. If you'd like to build a prototype geared to the Greek market? Because if that's the case, I'd recommend a mobile solution rather than a card based solution. Matters not what kind of phone they have, old flip fone, smartphone... The key to making it work is a middle office. You'd have to build that. Where would customers get their BTCs? From storefronts or online via the exchanges? If I am hearing you about your target market we can work out more details...

[benjamindees]

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it?

Obviously it doesn't in that case.  What I'm proposing is that you stick your card into a machine and deposit your $5, the machine sends a +1 BTC transaction, it gets displayed on the card, and you okay it.  The card keeps track of your balance.

For the cards I posted at least, if you browse the site you can see they have cards with keypads as well.  It would be possible to manually set your balance with those.

More importantly, how do you set your pin without a central authority doing it for you?

Same solution, cards with keypads.  But a pin is not necessarily a requirement, especially when using multisig keys as mentioned.  Ultimately a reader is only like $15 anyways so I think your minimum outlay is going to be around $20 regardless of which type of card you use.

I think it's also worth noting that if a card continuously re-uses a single address, then it kinda kills your privacy too.

The high end cards can store several keys, several hundred even.

[grue]

assuming you can even implement a protocol that doesn't allow the private keys to be leaked, you'll also need some sort of way to prevent unscrupulous merchants from skimming the card using a tampered terminal.

related vid:
http://www.youtube.com/watch?v=JABJlvrZWbY

[Haplo]

Okay, If I understand you now. If you'd like to build a prototype geared to the Greek market? Because if that's the case, I'd recommend a mobile solution rather than a card based solution. Matters not what kind of phone they have, old flip fone, smartphone... The key to making it work is a middle office. You'd have to build that. Where would customers get their BTCs? From storefronts or online via the exchanges? If I am hearing you about your target market we can work out more details...

Well, I wouldn't exactly call them "my market". I don't have the resources to launch a huge BTC promotion in Greece (nor do I have greek contacts), although I am curious; how could you use BTC with an old flip phone?

Also, that would depend on what technology is commonly affordable/available in Greece. Since "not EUR/ECB" is the most appealing feature of BTC for Greeks, delivering the currency to them requires putting it in whatever form is most available to them. I don't even have the slightest clue what greeks commonly use or have.

I'm only interested in that point because it would be nice to see the people of a country outsmart their multi-hierarchal dictators for once, not particularly because I want to profit from the venture.

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it?

Obviously it doesn't in that case.  What I'm proposing is that you stick your card into a machine and deposit your $1, the machine sends a +5 BTC transaction, it gets displayed on the card, and you okay it.  The card keeps track of your balance.

For the cards I posted at least, if you browse the site you can see they have cards with keypads as well.  It would be possible to manually set your balance with those.

More importantly, how do you set your pin without a central authority doing it for you?

Same solution, cards with keypads.  But a pin is not necessarily a requirement, especially when using multisig keys as mentioned.  Ultimately a reader is only like $15 anyways so I think your minimum outlay is going to be around $20 regardless of which type of card you use.

Well if the initial outlay for a USB card reader isn't so bad, and you can get a card with a numpad, then you could just input the price they display to you on your card, enter your pin, then hit send. The card signs a tx with only that exact value so they can't change the price after you begin entering your pin. It could be doable but it seems a bit complicated imo. That and, what's the price difference between a USB card reader + supercard with screen and such vs the cost of the cheapest BTC runnable smartphone?

[BitcoinAndie]

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it?

The essential usefulness of SmartCards was that it allowed for the writing to and reading of data (account balances) from the smart chip even when the merchant didn't have access to the card payment networks i.e., when the phone lines fail.

[benjamindees]

That and, what's the price difference between a USB card reader + supercard with screen and such vs the cost of the cheapest BTC runnable smartphone?

I imagine the "supercards" are less than $20.  The point is that once you have a display and keypad, you don't need a reader.  So the cost is similar.

you could just input the price they display to you on your card, enter your pin, then hit send. The card signs a tx with only that exact value so they can't change the price after you begin entering your pin. It could be doable but it seems a bit complicated imo.

No, there's no need to manually enter the transaction amount.  Transactions can be sent over the wire.  This is irrelevant.

assuming you can even implement a protocol that doesn't allow the private keys to be leaked

A lot of smartcard apps are poorly designed.  But it isn't black magic or anything.  It's definitely doable.  Look at the satellite TV access cards.  They can be reverse engineered, if you have access to the card itself and a scanning electron microscope.

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it?

The essential usefulness of SmartCards was that it allowed for the writing to and reading of data (account balances) from the smart chip even when the merchant didn't have access to the card payment networks i.e., when the phone lines fail.

Why are you mis-quoting me?

[BitcoinAndie]

Oops my bad, didn't mean to misquote you. Sloppy on my part. I was merely giving the context for why the card providers developed the smart card technology to make it a little easier for people to understand its limitations.

[BitcoinAndie]

Okay, If I understand you now. If you'd like to build a prototype geared to the Greek market? Because if that's the case, I'd recommend a mobile solution rather than a card based solution. Matters not what kind of phone they have, old flip fone, smartphone... The key to making it work is a middle office. You'd have to build that. Where would customers get their BTCs? From storefronts or online via the exchanges? If I am hearing you about your target market we can work out more details...

Well, I wouldn't exactly call them "my market". I don't have the resources to launch a huge BTC promotion in Greece (nor do I have greek contacts), although I am curious; how could you use BTC with an old flip phone?

Also, that would depend on what technology is commonly affordable/available in Greece. Since "not EUR/ECB" is the most appealing feature of BTC for Greeks, delivering the currency to them requires putting it in whatever form is most available to them. I don't even have the slightest clue what greeks commonly use or have.

I'm only interested in that point because it would be nice to see the people of a country outsmart their multi-hierarchal dictators for once, not particularly because I want to profit from the venture.

I agree, it would be helpful, but you'll have to seed the market for it to be meaningful.  Incidentally, markets can be big or small as in mass marketing or niche market. They can be high margin or they can generate losses. Markets in the strategic design sense is separate from profits.  People can seek profitable markets or narrow their definition to make the market more profitable (i.e., exclude poorer people) A market is just a collection of people who you believe will benefit from your good or service.  For programmers it's like a collection of objects, where objects are always people.

When defining a market segment for the purposes of developing new payment systems I look for what is the most accessible, low-cost technology at the POS for both customer and merchant. Avoiding the whole hardware sell, install, train headache. So in the case of Greece solutions may well look more like M-Pesa (9 million people in 3 years. B/c it is a top down authoritarian model. They're being studied at all the top B-schools now) or the mobile solution in Ghana (open source with equal rights to participation for all consumers and all telcos)

Don't assume that b/c those economies are lesser developed that they haven't found a way to exchange value without using the debit and credit card networks, b/c they have and in that sense they are years ahead of the US (ironic isn't it?) Mass market access to mobile payment, elite only access to Visa/MC. The very opposite of the US. In our case we'd replace bank ACH clearing and settlement with BTC clearing and settlement.

[Haplo]

That and, what's the price difference between a USB card reader + supercard with screen and such vs the cost of the cheapest BTC runnable smartphone?

I imagine the "supercards" are less than $20.  The point is that once you have a display and keypad, you don't need a reader.  So the cost is similar.

you could just input the price they display to you on your card, enter your pin, then hit send. The card signs a tx with only that exact value so they can't change the price after you begin entering your pin. It could be doable but it seems a bit complicated imo.

No, there's no need to manually enter the transaction amount.  Transactions can be sent over the wire.  This is irrelevant.

I was talking more about security from merchant overcharging, and for that matter, since BTC is spent by referring to previous txOuts, you'd have to load all the txOuts onto your card, or trust the merchant to construct a tx with the proper amounts that pays you the proper change. If the merchant is using a USB smart-card reader, they would have even more room for messing with clients since there are no software restrictions on a general computer as opposed to a specialized card payment unit.

I agree, it would be nice, but you'll have to seed the market.  Markets can be big or small as in mass marketing or niche market. They can be high margin or they can generate losses. Markets in the strategic design sense is separate from profits.  People can seek profitable markets are narrow their definition to make the market more profitable (i.e., exclude poorer people) A market is just a collection of people who you believe will benefit from your good or service.  For programmers it's like a collection of objects, where objects are always human being.

It is important to be able to visualize the participants you are looking to serve. It is difficult to design a system for a foreign market w/out understanding their infrastructure. In one design I had to go back to flip phones (SMS) and a middle office because that was the only reliable technology people in that market had access to on a consistent basis. When defining a market segment I look for what is the most accessible, low-cost technology at the POS for both customer and merchant. So in the case of Greece solutions may well look more like M-Pesa (9 million people in 3 years! A top down authoritarian model. They're being studied at all the top B-schools now) or the mobile solution in Ghana (open source with equal rights to participation for all consumers and all telcos) Don't assume that b/c those economies are lesser developed that they haven't found a way to exchange value without using the debit and credit card networks, b/c they have an in that sense they are years ahead of the US (ironic isn't it?) Mass market access to mobile payment, elite only access to Visa/MC.

Can these solutions be fully automated? Yes. As for the cost of service, you are essentially getting the Telcos to dump data into a middle office for processing and then you need to be able to send replies to both the merchant and their customer. These Telcos modules are now a commodity product (See BOKU) I can find out how much it costs here in the US if you'd like that reference point. But I don't see why you can't build your own, I mean it's just bits and bytes across a wire like all e-payments. Can't you grab the data from an email client and process it? Yes the run rate could be higher than that of a cobbled together smart card system, (# of SMS messages per month) on the other hand once you write the customer/merchant facing app and automate the middle office (just a big data base with a few rules) you don't have to spend a whole lot of time installing hardware and the merchants won't have to buy any new systems or devices. Oh and for BTCs system users would also need cloud-based wallet services.

Well, I can see that M-Pesa works. Theoretically BTC should work under similar conditions. However, I don't know anything about cloud-based services, and I don't even own a smart phone =\. Where possible, QR codes printed on a receipt are probably the easiest route, requiring only an internet connection to validate, but again that depends on what hardware is available for clients as well as what is typically available for merchants. The only way to find that out is to visit Greece and see what it's like. If smart phones are common and merchants can easily get an internet connected computer, then a flip phone service would only be needed to make it available to the stragglers. If the best anyone can afford is a flip phone, then you're pretty much stuck with centralization, which is a Very Bad Thing in a confiscation-sensitive environment. Also possibly relevant are the fees incurred by said service, although really it shouldn't be more than current banking fees.

Security is another big question, I think. What happens if someone steals your phone? How do you enter a pin or something without your phone recording it? Etc etc.

[benjamindees]

I was talking more about security from merchant overcharging, and for that matter, since BTC is spent by referring to previous txOuts, you'd have to load all the txOuts onto your card, or trust the merchant to construct a tx with the proper amounts that pays you the proper change. If the merchant is using a USB smart-card reader, they would have even more room for messing with clients since there are no software restrictions on a general computer as opposed to a specialized card payment unit.

That's exactly the point.  You can put multiple addresses on a smart card, verify the transaction amounts with a display, and create all the transactions right on the card.  There's absolutely zero need to trust merchants.

[Haplo]

I was talking more about security from merchant overcharging, and for that matter, since BTC is spent by referring to previous txOuts, you'd have to load all the txOuts onto your card, or trust the merchant to construct a tx with the proper amounts that pays you the proper change. If the merchant is using a USB smart-card reader, they would have even more room for messing with clients since there are no software restrictions on a general computer as opposed to a specialized card payment unit.

That's exactly the point.  You can put multiple addresses on a smart card, verify the transaction amounts with a display, and create all the transactions right on the card.  There's absolutely zero need to trust merchants.

How do you get them on there? In order for a card to create tx it would have to have the relevant txIns, in which case it could also know its own balance, and could use a simple interface for "locking in" the settling price for a tx prior to pin input. Again, though, that requires having a computer and a card reader for loading and managing it, or else a bank which can do it for you.

[BitcoinAndie]

Security is another big question, I think. What happens if someone steals your phone? How do you enter a pin or something without your phone recording it? Etc etc.
[/quote]

Right, don't know what the Telecom infrastructure looks like or the cost of service. But that's pretty straight forward market research.

Would need to consult/work with with a BTC expert on the security side, there are plenty of folks here. Yes, security would be PIN based. Realize that each phone has a unique number like a POS device.  But using dual PINs may also make a lot of sense, for example requiring a second PIN to send money to a new merchant not in the system or on the customers call list.  Also when sending money to another individual, that person would need a know the the special Receiver PIN as designated by the Sender (I believe that's how its done in Ghana) As you can see, mobile does solve a lot of problems but it also requires design/build, a server (hardware or space in the cloud) and a caretaker.  Meaning linking in folks who with an interest in helping to pull this together for the Greek market.  Let me know if you'd like to discuss further you can PM me.

[benjamindees]

That's exactly the point.  You can put multiple addresses on a smart card, verify the transaction amounts with a display, and create all the transactions right on the card.  There's absolutely zero need to trust merchants.

How do you get them on there? In order for a card to create tx it would have to have the relevant txIns, in which case it could also know its own balance, and could use a simple interface for "locking in" the settling price for a tx prior to pin input. Again, though, that requires having a computer and a card reader for loading and managing it, or else a bank which can do it for you.

Hmm, I see your point.  If the card is your only device, you do have to trust whomever you purchase Bitcoins from.  That's not entirely different from most Bitcoin users today, though, who have to trust the exchanges they send money to.

But perhaps it could be solved by setting up some sort of centralized service that would just send you a signed verification of your balance.  That way, the card itself could query the service through a 3rd party terminal, and would only have to trust the service, but not the terminal.  The card would have the public key for the service, and can verify that the balance was not tampered with.

[Realpra]

Okay replying loosely to posts above and questions from Haplo:

1. The card does not know the balance -> The terminal will check if the address the card returns along with the tx has sufficient funds.
If so the terminal sends the tx to the network otherwise it says "overcharge" on the screen.

2. The card would be programmed by a third party that you would have to trust, however:
* The program loaded would be the same for ALL card manufacturers.
* The program would be open source and standardized.
* Anyone with a with a cable could program cards - for the paranoid.
* Using web-of-trust you would choose a trusted card programmer.

-> The cost for the individual remains 2$ for the card.
-> 15$ for the Android Phone + Cable Terminal (APCT) for the merchants.

3. PIN, address and keys would be sent to you along with the card or you would know if you programmed it yourself.

4. Maintaining anonymity:
* The card would contain multiple addresses and keys (~50).
* This allows spending with it again within 60 mins. after use.
* It also allows maintaining anonymity by only sending the address to the terminal that will be used to pay with.

5. Overcharge prevention:
* The card will have a number only you know.
* This number will be multiplied by the charge amount from the terminal and sent back.
* If the wrong result is shown you know you have been tricked and can just leave.
* If a new charge is sent before giving the PIN the card locks itself for 10 minutes.

6. Backend:
* We can add two features to the APCT app.
* A QR code scanner to scan price and item type from the wares. (QR code formats are standardized)
* The app will create a file with a column with QR results and a column with charged price.
* The auto-file/spreadsheet can later be merged with corporate databases automatically with a small parsing program.
* If the auto-spreadsheet is saved as XLS (Excel) it could also be used as-is.

7. "Needing a reader" - only merchants will need a reader (15$) (+Android and APCT app).

8. Hackability:
* Locked memory: Casascious (who seems knowledgeable about this field) said there is locked memory ONLY the card can see.
* Force: You would need access to the physical card and a microscope to FORCE the chip.
* Hack: If you hack the APCT app, save all used customer addresses and pins THEN you MAY one day be able to overcharge a multi-return customer for the small amount he keeps on his spending card.

So YES you CAN hack the smartcard, but it requires the physical card and collecting a lot of card information.
Merchants will have little incentive to do this anyway as their shops would be raided shortly after.
I'm sure Visa is no better really.

To BitCoinAndie about early markets:
1. First market:
Market:
* Bitcoin promoters and bitcoin physical exchanges.
Motive:
* This could be used by people trying to replace Western Union and such.
Users:
* It would be used by early adopters or rarely by normal people as a novel means of easy money moving.

2. Second market:
Market:
* Greece and other oppressed economies.
Motive:
* Cash is good and WILL be used, but it is not always practical - hiding your pension as devaluing bills inside your couch is hardly optimal.
* With a BTC client you have a safe savings account.
* All the users need is access to internet bars and a smartcard.
* The shop owners can more easily hide BTCs than cash in case of a raid.
* Transferring cash over larger distance (pay, relatives and investors) is a complete pain.
Users:
* Savers, businessmen, drug dealers and at times shops.

3. Third market?

[kjj]

I've tried to follow this thread, but it meanders a bit.

Is the basic idea under discussion having a wallet-only client running in a small hardware device that can interact with POS terminals?

Most of the smartcards that I've seen are just (tiny) general purpose CPUs embedded in a card, usually with a small ROM containing a secret key.  This is not a useful model for bitcoin.  For bitcoin, you need the secrets in RAM (flash, etc) because you need to be able to add new secrets.  You also need to make sure that you don't ever let the device communicate with a hostile device using the same physical pins that can be used to reprogram or dump it.

Think more along the lines of a small custom device with a screen, a couple of buttons, and a serial port (or serial over USB, or serial over bluetooth, or serial over NFC, etc).  The programming interface, if it has one, must be internal, or it must load software from a memory card (like SD).

[grue]

assuming you can even implement a protocol that doesn't allow the private keys to be leaked

A lot of smartcard apps are poorly designed.  But it isn't black magic or anything.  It's definitely doable.  Look at the satellite TV access cards.  They can be reverse engineered, if you have access to the card itself and a scanning electron microscope.

if you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack.

a much better way is to have a portable wallet that "pays" a merchant by transferring a signed tx, which the merchant can verify and broadcast.

[Realpra]

If you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack.

Well... can't the card be locked immediately after a purchase (say 30-90 s).

That way the merchant would have to wait for you to come back AND remember who you were?

(he only gets 3 PIN attempts)


As for special override PINs I did not know about that? Is it real does that exist?
It seems to defeat the point of even making a smartcard...

If it does what stops anyone from hacking any VISA card in the world?

[benjamindees]

if you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack.

a much better way is to have a portable wallet that "pays" a merchant by transferring a signed tx, which the merchant can verify and broadcast.

I'm not even going to ask what you thought it was we were discussing.  Some of you need to do some basic research before posting in this thread.  Or at the very least, read what others post.

I've tried to follow this thread, but it meanders a bit.

Is the basic idea under discussion having a wallet-only client running in a small hardware device that can interact with POS terminals?

Most of the smartcards that I've seen are just (tiny) general purpose CPUs embedded in a card, usually with a small ROM containing a secret key.  This is not a useful model for bitcoin.  For bitcoin, you need the secrets in RAM (flash, etc) because you need to be able to add new secrets.  You also need to make sure that you don't ever let the device communicate with a hostile device using the same physical pins that can be used to reprogram or dump it.

You, for instance, don't have a clue.

[Realpra]

You [EDIT: grue], for instance, don't have a clue.

So smartcards are still saf-ish?

EDIT:
Looked it up a bit:
http://en.wikipedia.org/wiki/Smart_card_security
http://en.wikipedia.org/wiki/Smart_card
http://en.wikipedia.org/wiki/Mifare
http://people.cs.uchicago.edu/~dinoj/smartcard/security.html

So okay hacking the card is totally possible in a few ways:
1. Physical abuse.
2. Storing PINs and waiting for the customer to return.
3. Advanced hacking after stealing card.

HOWEVER: Special access pin connectors do NOT exists. Once the private keys are loaded to the card and programmed as NEVER-access level you have no practical way of getting them.

To summarize as I see it:
* If you only store what you spend in a week on your card the cost to the attacker would be MUCH MUCH higher than the return.
* If your card is stolen it can NOT be forced (by common thieves).
* Over-/double-charge using either my checksum scheme or "super cards" would be impossible.
* Even if no police will help you most merchants would not take the extreme risk of robbing a return customer for very little gain - it would loose him his customers rather quickly.
* Even storing the PIN and later overcharging would require a good deal of programming + being a merchant + getting a victim to come by minimum twice.

If people use BTC cards with a bit of care (like all else, including normal BTC) smard cards will be completely safe (safe as VISA or more anyway).

[benjamindees]

For some inexplicable reason people want to discuss the mangled, incompetent bullshit put out by credit card companies as though it has anything to do with either 1) smart cards or 2) Bitcoin.  Here's a reality check:  credit card companies aren't interested in smart cards.  It destroys their entire business model, which is based on trust, and which therefore requires fraud to be possible.

That video someone posted earlier is completely irrelevant.  They're talking about glorified credit cards.

PIN numbers are completely irrelevant.  Why would typing a static pin number into a hostile terminal gain me any security at all?

Skimming is completely irrelevant.  Smart cards have protected memory.  If they don't, then they aren't smart cards.

Dumping memory is completely irrelevant.  Like "oh shit" we left a major glaring design flaw and just allow the memory to be dumped, through the exact same pins no less?

There are some realistic hacks (power analysis) against older smart cards.  But you're not going to be able to sign Bitcoin transactions on those anyways.

And ANY APPLICATION THAT DOESN'T INVOLVE SIGNING TRANSACTIONS ON THE CARD ITSELF ISN'T EVEN A SMART CARD APP SO WHY THE HELL IS IT BEING DISCUSSED IN THIS THREAD?

[Realpra]

PIN numbers are completely irrelevant.  Why would typing a static pin number into a hostile terminal gain me any security at all?

Alright first; GREAT post. Cleared things up - nice to see my research was correct.

I disagree with the PIN thing though: It offers some safety:

1. PIN is used and the card is locked 30-90 sec.
2. User removes card and leaves.
3. Merchant secretly stored the PIN.
4. Merchant does not have the card - how will he use his stolen PIN?
5. He has to either A rob the guy or B get the person to come back another time.
6. He can then destroy ALL reputation he had to make 5. happen for maybe 40-200$!

WITHOUT a PIN:
1. Send money request of "ALL YOUR BASE... PLZ".
2. Done.
3. His reputation is still ruined, but it was a lot easier to do the stealing.

(90% of the times you use your card a new place, you will never use it there again - hence you're safe)

[benjamindees]

You're right I glossed over the one benefit of a PIN.  A PIN protects against someone stealing your card and using it.  That's all.  It doesn't protect against hostile merchants.  That's what transaction signing is for.

[BitcoinAndie]

Think more along the lines of a small custom device with a screen, a couple of buttons, and a serial port (or serial over USB, or serial over bluetooth, or serial over NFC, etc).  The programming interface, if it has one, must be internal, or it must load software from a memory card (like SD).

What about SIM cards?

[kjj]

Think more along the lines of a small custom device with a screen, a couple of buttons, and a serial port (or serial over USB, or serial over bluetooth, or serial over NFC, etc).  The programming interface, if it has one, must be internal, or it must load software from a memory card (like SD).

What about SIM cards?

I wouldn't trust a device without a display and keypad (or at least a pair of buttons!) built-in.

I also dislike the idea of a device just signing a transaction presented to it, rather than generating the entire transaction internally.  But, this can be overcome.

Also, in my opinion, the device must generate all keys after it enters my exclusive possession, and it must include a genuine entropy source.  This may be extra paranoid on my part, but I'm not sure I even like the idea of importing keys into the device.

[BitcoinAndie]

3. Third market?

Well if the intent is to enable payments with less friction (expense) and fewer middlemen, for people under duress, then the next markets should be strategic in terms of assisting people with the means of survival (food, shelter, clothing) Using Greece as an example, food and beverage distributors who can link into their regional supply chains (Europe) as well as local retail distribution would probably make a lot of sense.  

But still noodling on the central role of smart cards. I totally get why smart cards could provide access and anonymity on a distributed basis, and that the plastic and its chip has little inherent value until loaded with BTCs. But introducing a new product into a system, a product that requires additional hardware no matter how pocket sized, by its very definition attracts attention. If a citizen is stopped and searched will the mere possession of a branded smart card become probably cause?  

If only we could start a new healthy vitamin enriched beverage line sold via vending machines that has free mini smart cards attached to the bottles, and folks have to take those BTC cards into their local stores to be read so that they can see if they won the "BIG PRIZE" which of course is the act of buying and reading the cards.... now that would be a clever trick.

[grue]

If you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack.

Well... can't the card be locked immediately after a purchase (say 30-90 s).

but then the smart card will need an internal power source, which will definitely not fit in a card.

If it does what stops anyone from hacking any VISA card in the world?

visa/mastercard is supposedly secure because POS terminals that can process EMV transactions have to be tamper evident (sealed with sticker), and can't have removable faceplates, which should remove the risk of physical keylogging attacks.

maximum rage

1. get yourself a bitcoin POS terminal
2. open it up, and place a circuit that monitors keypad input (remember, this is inside the unit, so 99.9% of the users won't notice)
3. get yourself an arduino and program it so it can do everything a normal POS terminal can do
4. hook the keylogging circuit to the arduino
5. close the entire unit, and make everything look legit
6. place it in your store
7. wait for a customer to buy something
8. the payment gets processed as usual, but now the merchant can charge the customer again, because the card is still inside, and the pin has been logged.

[benjamindees]

grue, it's obvious that you want to argue with me about other people's proposals.  So here, watch a video about the hardware I'm suggesting:

http://www.building43.com/videos/2011/02/22/nagraid-creating-the-credit-card-of-the-future/

[grue]

grue, it's obvious that you want to argue with me about other people's proposals.  So here, watch a video about the hardware I'm suggesting:

http://www.building43.com/videos/2011/02/22/nagraid-creating-the-credit-card-of-the-future/

no, i'm arguing about how secure a smartcard system (in general) can be. it's very hard to keep your keys secure if the terminal that you're using can't be trusted. as long as the interface between the card and the user isn't protected, there will always be a risk of a man-in-the-middle attack. if you have a solution to prevent the attack i mentioned earlier, i will be glad to hear it.

One of these measures is to house your security information on a computer chip within the card as opposed to displaying it on the card. Another is a unique display window that reveals a security code necessary to complete a transaction. Each code can only be used once, so even if your card information were stolen, a thief would be unable to effect a transaction without having physical possession of the card and its security code. This window can also display account information such as your last transaction, your balance, how much you have spent this month, even messages from your bank.

too bad i got both

[BitcoinAndie]

grue, it's obvious that you want to argue with me about other people's proposals.  So here, watch a video about the hardware I'm suggesting:

http://www.building43.com/videos/2011/02/22/nagraid-creating-the-credit-card-of-the-future/

Thanks for link. Excellent Technology!

benjamindees here's a question for you. Could we issue these cards here in the US, buy the hardware and use the chip as form of Cold Storage? With an eye toward make these cards dual wallets (USD & BTCs)?

[benjamindees]

grue, do you understand that the entire point of a smart card is that the private key never leaves the card?

Basically, the POS terminal just sends the balance due to your card, which displays it for you.  You then press the button to verify, and the card creates the transaction and signs it.  No need to trust anything.

This is what I have proposed.  If you'd like to discuss any flaws you see in what I have proposed, I'd love to hear them.

benjamindees here's a question for you. Could we issue these cards here in the US, buy the hardware and use the chip as form of Cold Storage? With an eye toward make these cards dual wallets (USD & BTCs)?

No idea.  I haven't had a chance to speak with the manufacturer.  Obviously that would depend on particulars such as being able to source cards with the features you'd need, including memory and cryptographic requirements.  For long-term storage, you'd probably also want to know what happens when the battery runs out.

As for dual-usage, I can fairly confidently predict that no credit card company would consent to this.  I'm guessing that you mean for some type of proprietary payment network?  Which, sounds like an interesting idea and I'm sure would work in theory.

[kjj]

grue, do you understand that the entire point of a smart card is that the private key never leaves the card?

Basically, the POS terminal just sends the balance due to your card, which displays it for you.  You then press the button to verify, and the card creates the transaction and signs it.  No need to trust anything.

This is what I have proposed.  If you'd like to discuss any flaws you see in what I have proposed, I'd love to hear them.

This is exactly right.  The card must sign the transaction itself, and it must do so only after showing the transaction to the user and getting confirmation.

But the details are tricky.

[Realpra]

but then the smart card will need an internal power source, which will definitely not fit in a card.

Timing mechanisms:
1. Capacitor:
* Not a full power supply, could keep it running for those 30-90sec or at least enough for you to pull the card out.
* Just before it runs out it unlocks the card.

2. Clock:
* While the card has power from the terminal it counts chip cycles.
* The time from giving PIN and pulling the card will only be half the necessary waiting time.
* The other half will be counted down in the next terminal used at another merchant.
* This adds maybe 10s of waiting time when you start to use your card.
* This waiting can be mitigated by slotting in the card while the cashier is scanning your wares.

I believe that solves things?

BitCoinAndie:
1. I don't think new supercards are the way, at least right now - as it has been said we don't want to have to train people in new tech + they may be expensive hindering BTC market penetration.
2. For the paranoid super users it may be an option though - our protocol should just allow for communication with both types of card.
3. One-time codes are safe, but I don't think it is practical without super cards - which I again do not see as an option.

Using Greece as an example, food and beverage distributors who can link into their regional supply chains (Europe) as well as local retail distribution would probably make a lot of sense [EDIT: As a third market].

I think I kinda mentioned it in my second market ("businessmen"), but yes definitely a good way to go.

I think a "third generation" market would be something like my grandma using it.

First market would be "converts" and BTC dependent business start-ups (run by converts).

[grue]

grue, do you understand that the entire point of a smart card is that the private key never leaves the card?

and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.

[BitcoinAndie]

BitCoinAndie:
1. I don't think new supercards are the way, at least right now - as it has been said we don't want to have to train people in new tech + they may be expensive hindering BTC market penetration.

Well, I may have been a bit hasty in writing that opinion.  Since then I've taken a look at the vid that benjamindees has posted, and the technology is indeed impressive. If these cards and readers are adopted in the broader marketplace then repurposing them will indeed have been a great insight.  The logic behind decisioning in this matter is simple. The S curves for  the merchant and consumer adoption rates are not uniform. In this case we would be somewhat dependent upon merchant adoption rates as you'd want merchants in "closed" or "protected" markets to blend in with the "norm."  More importantly, for distributed or open systems, it is far better to have a symbiotic relationship with the dominant design. I am a huge proponent of commensalism, (a class of relationship between two organisms where one organism benefits but the other is neutral-- with no ill effects or benefit) when designing alternative payment systems.

Best practice would suggest that the next step is to get a sense of the reaction to this technology. Is MC going to push it across their installed base? Do the biggest card issuers see an advantage in adopting this new technology, and if so, will they push the cycle time (meaning faster than the normal replacement rate of the cards already in the hands of their customers) What are the odds makers predicting (Gartner Group, Sullivan and Frost, etc.) in terms of adoption rates?

The above notwithstanding, I continue to believe that we must crack the code on mobile devices, as card usage will likely NEVER take root on most of this planet. Indeed, the average person throughout the Pacific Rim, Central and South America and Africa are already embracing "mobile banking." (The top 10 telcos are making a big push, Verizon is # 18 globally and the Gates Foundation has mounted a major offensive.)  It can be difficult for most of us to appreciate just how large this market is (people not petro dollars) b/c we tend to travel the Epcot Center route when doing business within but particularly outside our western democracies. Of equally important consideration, since a good deal of the world's supply chains originate in these markets, overlooking them would be a fatal error over the long run.

Using Greece as an example, food and beverage distributors who can link into their regional supply chains (Europe) as well as local retail distribution would probably make a lot of sense [EDIT: As a third market].
I think I kinda mentioned it in my second market ("businessmen"), but yes definitely a good way to go.

I think a "third generation" market would be something like my grandma using it.

Guess I misunderstood, and assumed that the "businesses" in your outline are elements of markets by "Geography."  I'd suggest that we separate Businesses from Geographies, making "Grandma" 4th generation.

Yes, there will be significant overlap between these two markets, (like a Rubix cube) however, both categories are sufficiently large and complex that breaking them into two will make them easier to understand and our work less prone to error. I would further argue that one tends to think of countries from the bottom up (conditions on the ground) and Industries regionally and ultimately Globally, or top down.  Of course, all change resides in the individual and thus is local by definition. So designs derived in think tanks, no matter how diverse and multicultural, will be best customized and disseminated by actual users under their actual market conditions.

[benjamindees]

and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.

grue, I understand that your attack has relevance to standard smart cards.  How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless.

But I want you to look again at the hardware I'm proposing be used, and to think about the process flow:

• The terminal sends the transaction amount to the smart card.
• The transaction amount is displayed on the smart card.
• The user presses the button on the smart card to verify the amount.
• The smart card creates and signs the transaction.

There is no way to create multiple transactions without consent.  There is no way to create transactions with the wrong amount without consent.  No sensitive information is transferred to the terminal.  All transactions are created on the card itself using Bitcoin keys that never leave the card.

[grue]

and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.

grue, I understand that your attack has relevance to standard smart cards.  How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless.

But I want you to look again at the hardware I'm proposing be used, and to think about the process flow:

• The terminal sends the transaction amount to the smart card.
• The transaction amount is displayed on the smart card.
• The user presses the button on the smart card to verify the amount.
• The smart card creates and signs the transaction.

http://www.nidsecurity.com/products/106-details.jpg

There is no way to create multiple transactions without consent.  There is no way to create transactions with the wrong amount without consent.  No sensitive information is transferred to the terminal.  All transactions are created on the card itself using Bitcoin keys that never leave the card.

I see your point now, thanks for clarifying it.

[kjj]

and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.

grue, I understand that your attack has relevance to standard smart cards.  How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless.

But I want you to look again at the hardware I'm proposing be used, and to think about the process flow:

• The terminal sends the transaction amount to the smart card.
• The transaction amount is displayed on the smart card.
• The user presses the button on the smart card to verify the amount.
• The smart card creates and signs the transaction.

There is no way to create multiple transactions without consent.  There is no way to create transactions with the wrong amount without consent.  No sensitive information is transferred to the terminal.  All transactions are created on the card itself using Bitcoin keys that never leave the card.

This is a good model for a hardware wallet.  It is essentially the same model as the "box with serial port" model that has been discussed in many other threads.

My only objection is that I think that smartcards are a lousy choice for this model.  But, in parts of the world where smart card terminals are common, the network effect may very well be more important.

[Realpra]

Yes I think there's no debate that those cards would be safe, but what do they cost?

5$ range is fine, but I think above 15$ will hurt us a lot.

Anyway there is no reason our protocol cannot include both smart cards and super cards at the same time:
* Same form, shape and chip connectors.
* With normal cards the amount is sent and then you punch a PIN - tx sent.
* With super cards the amount is sent then button pressed - tx sent.

-> The terminal won't really need to know the difference, just send the amount and wait for tx (relaying the PIN with smart cards of course).

[benjamindees]

I imagine the "super" cards will be in the range of $20+.  That's probably fine for elite users and the security-conscious.  It will be competing as a more secure alternative to smart phones.  So it's in a niche market anyways.

For regular smart cards, maybe they could be paired with some type of online service that keeps an eye on merchants and perhaps validates transactions based on buying patterns.  At the very least, it would be nice to receive some type of statement at the end of the month to be able to detect fraud.  Otherwise, with nothing but the blockchain to go by, it would be basically impossible to know whether your grocer has a hacked POS terminal that is ripping you off.

So, just from what we've come up with so far, our universal POS terminal is looking at supporting:

• Smart phones via QR code / NFC
• Super cards via contact (/ contactless?)
• Smart cards via contact
• Online balance service
• Online transaction verification service
• Online "lite client" service?

Then on top of that add interfacing with the merchant's accounting system.  And besides magstripe and contact/contactless credit cards, you're competing with Paypal and Dwolla and that new Canadian Mint thing.  It's likely that none of those will cooperate to share hardware.

[finway]

This will be much more convenient!

[Haplo]

For regular smart cards, maybe they could be paired with some type of online service that keeps an eye on merchants and perhaps validates transactions based on buying patterns.  At the very least, it would be nice to receive some type of statement at the end of the month to be able to detect fraud.  Otherwise, with nothing but the blockchain to go by, it would be basically impossible to know whether your grocer has a hacked POS terminal that is ripping you off.

If you have access to a desktop running bitcoind or other client, it should be trivial to get said client to track tx to/from your card address. Remembering which tx went where is another story, but at least you could have some idea.

Then on top of that add interfacing with the merchant's accounting system.  And besides magstripe and contact/contactless credit cards, you're competing with Paypal and Dwolla and that new Canadian Mint thing.  It's likely that none of those will cooperate to share hardware.

Do paypal and dwolla have physical POS methods that don't rely on VISA or mastercard? Maybe I'm missing something. That canadian mint thing sounds like a citizen tracking collar to me. It'll be a disaster of human rights and a disaster of identity theft. I don't think Canada is really the ideal market for bitcoin anyway.

[BitcoinAndie]

Then on top of that add interfacing with the merchant's accounting system.  And besides magstripe and contact/contactless credit cards, you're competing with Paypal and Dwolla and that new Canadian Mint thing.  It's likely that none of those will cooperate to share hardware.

Do paypal and dwolla have physical POS methods that don't rely on VISA or mastercard? Maybe I'm missing something. That canadian mint thing sounds like a citizen tracking collar to me. It'll be a disaster of human rights and a disaster of identity theft. I don't think Canada is really the ideal market for bitcoin anyway.

Dwolla is a takeover target once they reach scale, it may even be after they go public if the I-Bankers can circle a deal.  Paypal senior management is being poached by the big banks and Google as they look to take back share in non US markets via their SWIFT relationships under the guise (gun) of FAFT's KYC rules.  So neither are good analogies nor reliable partners.  The banks don't like VISA/MC since they went public as the objective of the associations are no longer aligned with those of the banks. Meaning as public cos they now have to show increasing profits on a quarterly basis, prior to going public they were a utility function operating on behalf of "all" participating banks.  

The banks will look to alternate clearing and settlement systems as these opportunities present themselves. This effort will be lead by the Cash Management/Treasury guys (think checking and payment services for businesses). So for example, KRAFT's snack food distributors in Indonesia, will use a handheld internet device to collect e-payments from the retail stores on their route. The store owners may have a cell phone, or even just a simple pin number linked to a bar code that identifies them and their account at the bank.  The point is that where there hasn't been any installed infrastructure the one being developed is based on mobile technology. These direct connects to the bank use ACH (like Dwolla) or the local market equivalent and not VISA/MC.  Thus in may ways, the US market is an anomaly, we have little economic reason to move beyond card-based systems.... at least for the moment. Thus the craze over flimsy dongle technology like Square and ISIS.

I still think that mobile payments is the way to go, and that all of you gents with mad skills ought to working on making a mobile app that uses tokenization and secure data transmission to effect payments via an automated BTC clearing house.

[grue]

I imagine the "super" cards will be in the range of $20+.  That's probably fine for elite users and the security-conscious.  It will be competing as a more secure alternative to smart phones.  So it's in a niche market anyways.

For regular smart cards, maybe they could be paired with some type of online service that keeps an eye on merchants and perhaps validates transactions based on buying patterns.  At the very least, it would be nice to receive some type of statement at the end of the month to be able to detect fraud.  Otherwise, with nothing but the blockchain to go by, it would be basically impossible to know whether your grocer has a hacked POS terminal that is ripping you off.

So, just from what we've come up with so far, our universal POS terminal is looking at supporting:

• Smart phones via QR code / NFC
• Super cards via contact (/ contactless?)
• Smart cards via contact
• Online balance service
• Online transaction verification service
• Online "lite client" service?

Then on top of that add interfacing with the merchant's accounting system.  And besides magstripe and contact/contactless credit cards, you're competing with Paypal and Dwolla and that new Canadian Mint thing.  It's likely that none of those will cooperate to share hardware.

the cheapest & easiest to implement would be an android/ios client. nearly everyone has a cell phone, and if you're just signing transactions, you don't even need a data plan. however, this will require some way to transfer the signed transaction back to the POS terminal (maybe camera to scan QR code?), so you're looking at additional costs for the merchant.

[BitcoinAndie]

the cheapest & easiest to implement would be an android/ios client. nearly everyone has a cell phone, and if you're just signing transactions, you don't even need a data plan. however, this will require some way to transfer the signed transaction back to the POS terminal (maybe camera to scan QR code?), so you're looking at additional costs for the merchant.

So, what do you think of the P2P upstart BUMP?

[benjamindees]

Do paypal and dwolla have physical POS methods that don't rely on VISA or mastercard? Maybe I'm missing something. That canadian mint thing sounds like a citizen tracking collar to me. It'll be a disaster of human rights and a disaster of identity theft. I don't think Canada is really the ideal market for bitcoin anyway.

Dwolla basically has mobile web payments, so I guess there isn't any hardware involved.  And Paypal apparently uses standard mag stripe cards.  So perhaps not.

[BitcoinAndie]

Do paypal and dwolla have physical POS methods that don't rely on VISA or mastercard? Maybe I'm missing something. That canadian mint thing sounds like a citizen tracking collar to me. It'll be a disaster of human rights and a disaster of identity theft. I don't think Canada is really the ideal market for bitcoin anyway.

Dwolla basically has mobile web payments, so I guess there isn't any hardware involved.  And Paypal apparently uses standard mag stripe cards.  So perhaps not.

At present, all physical POS methods rely on the Visa/MC networks.

Dwolla uses the ACH to move money among bank accounts. Eventually they could move into prepaid/debit cards. If they do they would run their payments on the existing VISA/MC payments networks.

Paypal also uses ACH as its base. Their payment cards run on the VISA/MC networks.  For vendors wishing to accept card payments, Paypal offers a private label version of ISIS or Square (not sure which) hardware.  You know--those portable plastic mag strip readers that attach to cell phones enabling mobile VISA/MC payments.

One might be able to repurpose those ISIS or Square devices. They read the mag strip and send that data along with the merchant # and courtesy amount to a previously established phone number... ultimately Paypal's third party card processor's data center.

[Stephen Gornick]

They will be using magstrips and paper. If Bitcoin cannot adapt to magstrips, paper, and sms, then it will require bucking the system. It's too expensive to try to educate the masses about new gadgets.

If you notice, that's how Square is proceeding.  Step 1 is to get merchants onboard using new software, but the payment methods are the same yet (magstripe swipe or cash).  Added to that is the optional mobile data (where the customer's presence is shared with the merchant ... "pay using your name").

Once there are enough users doing that, Square can switch to having accounts the app also function as a wallet so that transactions for mobile users don't go through their credit card anymore.    Square can do this because the fraud rates are lower when GPS data + security at the merchant's point of purchase (e.g. video cameras, face-to-face transaction with a cashier) makes fraud harder to get away with.

Here's how Bitcoin can piggyback onto Square's progress though:
 - https://bitcointalk.org/index.php?topic=2732.msg843575#msg843575

[BitcoinAndie]

Square can switch to having accounts so that transactions for mobile users don't go through their credit card anymore.

How would Square switch to having accounts? Whose accounts? The customer's or the merchants? How would funds get into those accounts? 

[Stephen Gornick]

How would Square switch to having accounts?

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.

Whose accounts? The customer's or the merchants?

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.

How would funds get into those accounts?

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.

[BitcoinAndie]

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.

[2_Thumbs_Up]

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

[Stephen Gornick]

When a card is swiped the "merchant acquirer's" bank/card processor is contacted to effect clearing settlement.

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.

I cannot yet imagine how Square is not just another interface into the Visa/MC networks.

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.

[BitcoinAndie]

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.

[Realpra]

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.

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.

[DeathAndTaxes]

My question is, even if you load BTC to your smartcard's address without connecting it to your computer somehow, how does the card know how much is on it? Seems to me it'd be up to memory and luck to make sure you didn't overdraft, which would end up sending an invalid tx anyway.

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.

More importantly, how do you set your pin without a central authority doing it for you? I think it's also worth noting that if a card continuously re-uses a single address, then it kinda kills your privacy too.

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)

[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.

[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

[Realpra]

Progress report:
Okay learned some stuff.

Brands:
BasicCard SmartCards (SCs) - Brand by German Zeit Control company. Uses the Basic programming language (DOS like).
JavaCard/JCOP SmartCards - Produced by multiple producers (expensive).
ACS cards - Brand by Advanced Card Systems, runs AC-OS (hence ACOS name).

ACOS cards are developed using their software. ACS sells an SDK.

Basiccards seem more open, though buying an SDK from the company will likely speed your development time. At ~59 EUR I can do this easily. That includes hardware such as test cards/reader, books and manual.


I have tried basic about 10 years ago and I remember it as an easy and simple language. Further the implementation on those cards are done in hardware so it's more efficient than the java cards - hence the price difference.

Basiccards will cost 1.5-5$ I think, it depends a bit on how demanding the BTC app turns out to be.

I have found no "C/C++ cards" though there may well be more card companies.


When communicating with the cards via reader/writers various frameworks exist such as OpenCardSC and as I understand one included in the basiccard SDK mentioned above.


Most card companies can print your cards (including ZC) or you can buy your own card printer at a reasonable price. Some of those printers also have programming modules, though I don't know if they will work with the basic cards.

I consider it very likely that given a little time and quite little start-up capital (5-20K$) you could set up a very serious BTC card manufacturing plant and churn out your first thousand cards or so.
Given the demand we could totally supply the world with BTC cards.


So; I am strongly considering buying the ZC basiccards/SDK, does anyone have any reasons this is a bad choice?
(if the corp dies the same BTC card standard/app developed here can be deployed on a new card, so no worries there)

Does anyone want to join the project or help out anyhow? I estimate I would develop this maybe 5 times faster with a second guy on board - not including his contributions.
(two men dig more than one man in twice the timespan)

[Realpra]

Progress report:
Okay so I have been reading the technical datasheet/manual on the basiccard website.

I have found the following:
- Communication standard should be T1 - faster, newer and less error prone than T0.
- 200-400 lines of basic code will be able to run on a 2kb basiccard (0.9-1EUR).
- Files/directories can be locked completely or assigned a pub key you must communicate by.
- The card may be locked into a RUN state in which it can no longer be read or re-programmed. This would be the product the users get,
   so that a corrupted/thief terminal does not wipe/re-program the card or steal your keys.

Additionally ZeitControl, the company behind the cards, is a member of the ISO 7816 committee since 1996? so they are quite big, proven and respected.

In light of this I am buying the SDK and going forward with these cards.

Hopefully the basiccard "enhanced basiccard ZC3.12" card with 2kb EEPROM will prove adequate as they are very cheap - I think the cheapest on the WORLD market.

[unclescrooge]

Thanks Realpra 

[JustThinking]

Progress report:
Okay so I have been reading the technical datasheet/manual on the basiccard website.

I have found the following:
- Communication standard should be T1 - faster, newer and less error prone than T0.
- 200-400 lines of basic code will be able to run on a 2kb basiccard (0.9-1EUR).
- Files/directories can be locked completely or assigned a pub key you must communicate by.
- The card may be locked into a RUN state in which it can no longer be read or re-programmed. This would be the product the users get,
   so that a corrupted/thief terminal does not wipe/re-program the card or steal your keys.

Additionally ZeitControl, the company behind the cards, is a member of the ISO 7816 committee since 1996? so they are quite big, proven and respected.

In light of this I am buying the SDK and going forward with these cards.

Hopefully the basiccard "enhanced basiccard ZC3.12" card with 2kb EEPROM will prove adequate as they are very cheap - I think the cheapest on the WORLD market.

Hello,

I have not fully understand the scope of what you are trying to do (and too much to read as well), but you seem to be mostly on the starting into the smart card world.

I don't know if this relates to what you do or not: https://bitcointalk.org/index.php?topic=94119.0

Current status: integrating it with Electrum for a sensible GUI. The card itself works for what I believe is sufficient functionality to keep a wallet.

[Bitcoin Oz]

Progress report:
Okay learned some stuff.

Brands:
BasicCard SmartCards (SCs) - Brand by German Zeit Control company. Uses the Basic programming language (DOS like).
JavaCard/JCOP SmartCards - Produced by multiple producers (expensive).
ACS cards - Brand by Advanced Card Systems, runs AC-OS (hence ACOS name).

ACOS cards are developed using their software. ACS sells an SDK.

Basiccards seem more open, though buying an SDK from the company will likely speed your development time. At ~59 EUR I can do this easily. That includes hardware such as test cards/reader, books and manual.


I have tried basic about 10 years ago and I remember it as an easy and simple language. Further the implementation on those cards are done in hardware so it's more efficient than the java cards - hence the price difference.

Basiccards will cost 1.5-5$ I think, it depends a bit on how demanding the BTC app turns out to be.

I have found no "C/C++ cards" though there may well be more card companies.


When communicating with the cards via reader/writers various frameworks exist such as OpenCardSC and as I understand one included in the basiccard SDK mentioned above.


Most card companies can print your cards (including ZC) or you can buy your own card printer at a reasonable price. Some of those printers also have programming modules, though I don't know if they will work with the basic cards.

I consider it very likely that given a little time and quite little start-up capital (5-20K$) you could set up a very serious BTC card manufacturing plant and churn out your first thousand cards or so.
Given the demand we could totally supply the world with BTC cards.


So; I am strongly considering buying the ZC basiccards/SDK, does anyone have any reasons this is a bad choice?
(if the corp dies the same BTC card standard/app developed here can be deployed on a new card, so no worries there)

Does anyone want to join the project or help out anyhow? I estimate I would develop this maybe 5 times faster with a second guy on board - not including his contributions.
(two men dig more than one man in twice the timespan)

Perhaps a glbse IPO ? I suspect you would get a lot of interest.

[Realpra]

Thanks Realpra 

And thanks for the interest.

Hello,

I have not fully understand the scope of what you are trying to do (and too much to read as well), but you seem to be mostly on the starting into the smart card world.

I don't know if this relates to what you do or not: https://bitcointalk.org/index.php?topic=94119.0

Current status: integrating it with Electrum for a sensible GUI. The card itself works for what I believe is sufficient functionality to keep a wallet.

Yeah I'm just starting out alright, still I can see the path ahead.

What you are doing seems very similar though focused on securing the computer wallet.
I can see you chose the JavaCard; with dropping hardware prices that's probably a good choice too.

I would love to share notes, that you have come so far already is impressive - I myself usually work slower.

Do you sign transactions on the card or do you only store information on the card?

If its the second, how do you prevent keys leaving the card and getting used by someone else?

Perhaps a glbse IPO ? I suspect you would get a lot of interest.

I will keep it in mind. Currently I mostly need help to develop, which money won't help a great deal with.

Also I am still not entirely sure what I am trying to do is possible so I don't want to owe people money yet!


Progress report:
I have looked into Bitcoin a bit more and what my cards need to do.
It seems ECDSA is used to sign and what is signed is a SHA256 hash of the transaction data/tx.

Both of these algorithms are unfortunately a bit heavy computationally for a smartcard - simply programming them could use up a lot of/all EEPROM.
Hence some co-processing will likely be needed - I still have to research more on what my exact options are there.

Further I have found that the card needs to store a reference to any transaction it wants to spend as this is required info in a tx.
This will not be a major problem as most of these txs will be generated from the card itself and only a few will be "refills" that may be relayed to the card by a merchants terminal.

Fraudulent data from a terminal to the card can at worst only lead to having to pay twice and some unintentional doublespends by the user - security is still fine.

It will still be a no-trust security model.

I have also received the SDK which is very slick and all, I will share it with you guys when/if possible.

Next is finding out the exact card specifications needed (16EEPROM? ECDSA/sha coprocessor?) and what to program. If an algorithm is not supported I can program it, but this is CPU? expensive and a bit time consuming.

ZeitControl sells many different cards, some with different coprocessors and some with lots of EEPROM for custom implementations of unsupported things.

[JustThinking]

What you are doing seems very similar though focused on securing the computer wallet.
I can see you chose the JavaCard; with dropping hardware prices that's probably a good choice too.

JavaCard is the natural choice for such things, in this sector, in 2012.

I would love to share notes, that you have come so far already is impressive - I myself usually work slower.

Apparently you have not worked in this field before. I don't have much notes, but I expect to make pre-release kits (a card and a reader) available for sale ASAP, maybe as early as next week. Anyone interested in getting a rev 1.0 (with BitcoinJ library for using it) at an early bird rate (meaning slightly higher price than eventually) please let me know.

Do you sign transactions on the card or do you only store information on the card?
If its the second, how do you prevent keys leaving the card and getting used by someone else?

Yes, transactions are signed on the card, that's the usual purpose of smart cards. Keys *can* leave the card, if allowed by policy or for example for backing up to a backup smart card wallet. Again, if allowed by card policy profile *and* card owner. It is a split responsibility of the card platform and application.

Progress report:
I have looked into Bitcoin a bit more and what my cards need to do.
It seems ECDSA is used to sign and what is signed is a SHA256 hash of the transaction data/tx.

Both of these algorithms are unfortunately a bit heavy computationally for a smartcard - simply programming them could use up a lot of/all EEPROM.
Hence some co-processing will likely be needed - I still have to research more on what my exact options are there.

Further I have found that the card needs to store a reference to any transaction it wants to spend as this is required info in a tx.
This will not be a major problem as most of these txs will be generated from the card itself and only a few will be "refills" that may be relayed to the card by a merchants terminal.

Fraudulent data from a terminal to the card can at worst only lead to having to pay twice and some unintentional doublespends by the user - security is still fine.

It will still be a no-trust security model.

I have also received the SDK which is very slick and all, I will share it with you guys when/if possible.

Next is finding out the exact card specifications needed (16EEPROM? ECDSA/sha coprocessor?) and what to program. If an algorithm is not supported I can program it, but this is CPU? expensive and a bit time consuming.

ZeitControl sells many different cards, some with different coprocessors and some with lots of EEPROM for custom implementations of unsupported things.

On the contrary, EC crypto is much lighter/faster on a smart card than for example RSA (one of the main purposes of ECC is improved efficiency on constrained hardware) and the amount of data needed to be hashed for a transaction is really minimal (compared to a PDF contract, for example). Also, technically you can hash part of the stuff on the host and only part of it on the card.

The cards I've chosen for Smart Card Wallet all have 64K or more of EEPROM available, which means that a bunch of addresses can be made on the card (but for now I've limited the amount of addresses to 64, to keep it maintainable for the user).

One more suggestion: unless you are *sure* (like... 80% or more sure) about what you are doing, I don't suggest to try to create any crypto or algorithms yourself, unless you *have to* (gunpoint) or *want to* (for learning purposes). The chances of messing something up are really high.

If the cards you have are BasicCard-s, then I'd be "professionally interested" in learning more about them.

[Realpra]

JavaCard is the natural choice for such things, in this sector, in 2012.

How much do you pay for your cards?

I think I will have to pay 3.8$/piece in order to get the crypto functions I need. (ZC5.4 card - 16 kbyte, SHA256 and EC-211 on co-proc).

The EC I could probably do, but the SHA seems to take a lot of code to implement and the price-step lower is a card with 16kbyte to implement both algos + BTC program. (16kb basiccard = 2400 code lines)

Apparently you have not worked in this field before. I don't have much notes, but I expect to make pre-release kits (a card and a reader) available for sale ASAP, maybe as early as next week. Anyone interested in getting a rev 1.0 (with BitcoinJ library for using it) at an early bird rate (meaning slightly higher price than eventually) please let me know.

Nope completely new to this. I might be interested in your package - I will just look through what I already bought first though.

Would your package include your card code so I can steal/port it XD? I am planning to make mine open source.

On the contrary, EC crypto is much lighter/faster on a smart card than for example RSA (one of the main purposes of ECC is improved efficiency on constrained hardware)

Yeah, but the cheaper cards allow quite few lines of code and SHA256 is the problem. ZC 5.4 is the one I think.

One more suggestion: unless you are *sure* (like... 80% or more sure) about what you are doing, I don't suggest to try to create any crypto or algorithms yourself, unless you *have to* (gunpoint) or *want to* (for learning purposes). The chances of messing something up are really high.

I was probably going to port algos from some example project if I did that, but yeah I hope it can be avoided.

If the cards you have are BasicCard-s, then I'd be "professionally interested" in learning more about them.

They are.

According to the producer they cost 1/3 of javacards/multiOS cards.

They use a version the Basic language which is DOS like.

The cards run near-byte code at the hardware level which supposedly means they require less EEPROM than javacards etc. (hence the price difference).
I don't know to what extent this is all true, but they SEEM cheap when I compare them to other cards on the net.

A comprehensive manual/datasheet/Basic language tutorial is free for download on their site - the SDK just lets you have a cybermouse and some cards on top of all that otherwise free stuff.

They also provide you with a free IDE that lets you test/step-debug smart card programs and program your cards - example programs are included.

Anything else just ask.

[JustThinking]

How much do you pay for your cards?

Look around in smartcardfocus.com, cryptoshop.com, smartcardsource.com etc. For cards in quantities the prices are of course cheaper.

I think I will have to pay 3.8$/piece in order to get the crypto functions I need. (ZC5.4 card - 16 kbyte, SHA256 and EC-211 on co-proc).

EC-211? Bitcoin uses secp256k1 curve ...

Would your package include your card code so I can steal/port it XD? I am planning to make mine open source.

Eventually. I must first figure out if/how I want to monetize it. The deal being that "whoever pays, also gets the source", but I might postpone opening the on-card software in the beginning and only distribute pre-made cards. I don't know yet.

If the cards you have are BasicCard-s, then I'd be "professionally interested" in learning more about them.

They are.

According to the producer they cost 1/3 of javacards/multiOS cards.

They use a version the Basic language which is DOS like.

The cards run near-byte code at the hardware level which supposedly means they require less EEPROM than javacards etc. (hence the price difference).
I don't know to what extent this is all true, but they SEEM cheap when I compare them to other cards on the net.

I've never seen a software stack for basiccards, thus I'd like to see how a) the source code of an application looks like b) building and loading looks like c) capabilities of the ecosystem feel like. Thus if you have things like sample code or hello world package, I'd like to have a look at it, if possible.

Regarding JavaCard vs MultOS (mostly dead these days, IMHO) vs bare cards vs basiccards...

I don't know if the chip they use is CC verified, it certainly does not exist in FIPS 140-2 list etc. Even though CC/FIPS somewhat contradicts bitcoin spirit, it actually has *some* meaning.

Regarding EEPROM: this is for user data, thus the execution environment should not matter that much.

"You get what you pay for" applies very often, very harshly.

A comprehensive manual/datasheet/Basic language tutorial is free for download on their site - the SDK just lets you have a cybermouse and some cards on top of all that otherwise free stuff.
Anything else just ask.

I tried surfing their site but did not find the language reference or datasheet in 2 minutes, except for the short example on http://www.zeitcontrol.de/basiccard_gen.htm

Nevertheless, it might be an interesting option for people who require ease of use or cheap prices, but I have more confidence and experience in JavaCard-s.

And regarding BASIC: I think the last time I used it was when I was in early teens or so Would be strange to go back in time...

[Realpra]

Right guys sorry I dropped off the map for a while. I became a dad and pursued some other projects (waste of time mostly), I also got a job as a real software developer. Nifty stuff.

Anyway I do have some progress to report and this is still my main and only hobby project.

Not caught up on everything in this thread yet, very interesting project though. Can these cards be programmed with assembly and if so would it help much with memory constraints?

Not really, the basic language is one the first languages and probably C like in performance. Further the whole basic card has been built around it so the instructions are almost hardware level from the get go.

.. and of course assembly is horrible to code, I don't think anyone uses it.

EDIT:
Another thought, recently in Ireland there has been a boom in some universal readers to pay for tolls, issue mobile phone credit etc. Don't know what they are or who runs them but it may be an opening for a bitcoin card reader to get in if other countries use them too.

My main focus right now is a card talking to an android phone - even that is very advanced and android phones are more universal than the universal readers of one company.

EC-211? Bitcoin uses secp256k1 curve ...

Yeah I found out.

The EC-211 is just Elliptic Curve crypto over a integer field 211 bits large. It COULD likely have done secp256k1, which itself is just a variation of normal EC, but unfortunately their EC-211 does not use the normal EC curve.

y^2 + XY = x^3 + ax + b instead of y^2= x^3 + ax + b
secp256k1 is just specific values for "a" and "b"

This means the EC-k1 must be ported/implemented from some library - SHA256 is on-card. I still need to read more about pure BTC as I have been mostly reading about the cards and just EC.

I tried surfing their site but did not find the language reference or datasheet in 2 minutes, except for the short example on http://www.zeitcontrol.de/basiccard_gen.htm

I can't link to it directly, but is under "free download" on their english site: http://www.basiccard.com/.


Right now I'm looking into the T1 protocol, the basiccard terminal program from ZC will do it for you automatically, BUT it runs on a PC, not Android. After a quick look I doubt I could do T1 from the bottom, but other options such as reverse engineering the ZC terminal, contacting the company or finding a T1/DS1 library exist.

Thats all for now.

[Realpra]

A month huh.. yeah I'm not moving along so fast I admit it. However:

1. I have a game plan right now that says:
   A. Program smard card with a simple pub address and make it send it to a win-PC terminal program (ZeitControl software, only runs on
       win-PC )
   B. Program full card program.
   C. Get it to work and all/maybe an open source protocol for this stuff.
   D. People could at this step accept my BTC credit cards using say a laptop or do their own terminals/cards based on protocol
   E. Get it to work on Android - not easy, but vital more long term.

2. I have now researched Bitcoin itself a bit and I believe I am ready to do this. I was confused about the scripting system and thought my
    card would need RipeMD160 (a pain in the butt) - however since the card does no validation it will NOT be necessary.

3. If I didn't mention it the ZC5 something cards will be necessary for their SHA256 on-card functionality. EC-koblitz1 I still have to do
    myself, but it is actually kinda simple. (Think of it as an equation with two unknowns and the correct solution being a signature )

So yeah, next time I post here I might have a little source code with me!

[Realpra]

Another month, but I have meaty progress and good news to report!

The link at the end I ask you to download and share, it contains the source code, my research and progress so far. It has everything you need to get started etc etc..
(You wouldn't want the FBI to shut this down now would you!?)

What I have done so far is familiarize myself with the ZeitControl IDE and I have programmed some key commands and key/address pairs into the card-program. I still have to work out some kinks with correct command definition as their book has a really crappy way of showing syntax (no examples!  ).

I have started to program every day on my commute so I think step 1 of my plan could be done in a week or two. (Step 1 was making the terminal and card exchange addresses).

Quick guide to ZC IDE:
1. To add a file you first create and save it. Then you include it and rebuild. Only then its will show up as part of your project.
2. Under "help" and then Example projects->"Calc" you can easily access examples of basiccard code.


Now as for the good news: It seems ZeitControl does in fact have a Java library. As you may know Android is mostly straight normal Java and so this could mean putting the terminal program on Android phones could be very easy. The only major problem left is to figure out USB standards. (Android expects an out-going USB connection but the smart card reader is in-going, USB is a one way host->child standard as far as I can tell. Basically both reader and Android are normally "child")

Link:
http://www.4shared.com/zip/HdI942A-/BitcoinCardProject.html

[Realpra]

The project is now completed.

Yes that is right, you can buy a Bitcoin Card NOW at my web site: www.Blochstech.com

No pre-orders, no waiting, no nothing. Buy and use.

This is a userfriendly Bitcoin wallet card for only 20 EUR.
Anyone with a NFC enabled Android smartphone can accept it which should mean a good amount of existing physical Bitcoin merchants.