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.

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.

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

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.

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.

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.


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.

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.

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.

discussion cont'd here : http://bt.irlbtc.com/view/7872.0

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