Topic: Casascius Bitcoin POS system - page 3. (Read 10024 times)

I write a time and attendance (payroll) app for VeriFone.  Generally, the banks WANT my payroll app on their credit card box.  That's a useful reference point.  It's highly unlikely they'd want bitcoin on it.  They want the payroll app because there's a chance they can scoop up extra revenue via payroll.  They won't add bitcoin just for the karma.

It's not so simple in practice.  You can get those credit card boxes for $200.  Sure perhaps you can unlock the box but will the card processing software play well with the extra app?  It's not like the terminal has "alt-tab", the extra app only plays well if it's loaded and endorsed by the issuing bank and integrated into what's already there.  Without that, much easier to just get a separate box.

Some business owners have a Bitcoin agenda and would be happy to get this going.  They just don't have an easy way to start.  Sure, it's not going to be Target or Wal-Mart, but think Memorydealers.com and Meze Grill.

You tell Walmart that a thousand of their smaller competitors are accepting bitcoin at the POS and they might actually think about accepting it themselves.

You gotta start somewhere.

We have to re-invent the wheel because the current payment systems/companies are not going to cooperate with bitcoin to integrate a free payment system into their infrastructure.

A $200 device that the merchant can stick under the counter, its tough, checkout-chick friendly, simple to power up, and best of all, completely free to use and accept payments with forever. You can even get the backend to convert the btc straight back to whatever currency tickles your fancy.

Personally i'd prefer a mini-pc under the counter with a proper LCD screen that can display the QR code, and show nice graphics etc.. but this POS device will definately be a winner for non techie mom & pop stores to accept bitcoin.

Cheap, Simple, Familiar = Win

Credit and gift cards are not free. Transaction fees are paid ultimately by the consumer. Not so much with bitcoin. It will be awhile before anyone is ready to use bitcoins via POS, but these open source projects show what can be done with bitcoin.

"pay their dues"
Visa and Master Charge fees, money conversion fees, bank fees, money service fees, etc. Merchants are constantly losing profitability and can barely afford to take credit cards anymore. This device is not supposed to be a new idea, it's just a familiar device for a bitcoin based banking system that has very low fees.

Holy shit, how does this not have more attention.  Just seen this on /r/Bitcoin, amazing.

Wow, this is coming along.  Thank you casascius. This is a wonderful contribution.

Wouldn't it just need to do json-rpc calls to bitcoind running somewhere on a LAN (or alternately I suppose that could be an external trusted service)?

This sounds interesting and I'm just touching in here to stay aware of progress.

Questions on the POS protocol outlined on your wiki page.

I imagine there would be some sort of login or authorization step so that the backend knows that it is communicating with an authorized client?

I see the client connects every 15-60 seconds, would a standard web server with HTTPS/SSL be able to communicate with the client? or is the protocol complex enough to require a custom server software to be written?

If you are launching, I am extremely willing to be a volunteer and help in the distributions in the countries I go to.

We're talking a machine designed to exchange transactions that weigh in at between 0.5 and 2 kilobytes.  They do that just fine.


That might be true, but they tend to work fine in practice.  Most of the messages exchanged by these devices fit within a single Ethernet frame.  They are designed to talk to one host (e.g. Visa/Mastercard) over the internet and they clearly do that just fine.  They don't need a gamut of protocols because they don't need to talk to lots of hosts with a wide array of different capabilities like, say, web browsers do.

I believe the WiFi units they sell (Vx610 with a pluggable module) is based on having a third-party radio with its own IP stack on the radio itself, and it is just attached via a serial-like connection.

In short, they do fine.

I think they also have Linux-based products as well.  I've never developed for them.

You might be aware my experience with these is that I sell payroll timeclock services on them.  We actually have another box with similar characteristics that runs Linux (magstripe reader, 128x64 mono display), and we sell a ton of them as timeclocks.  My timeclock app runs on both VeriFone and these Linux boxes, it's just a different build target.  So if I had an itch for a little more juice, it's just a matter of recompiling for the other hardware.  We sell more Linux timeclocks not because they're Linux, but because they look more like timeclocks and are easier to hang on the wall.  On the other hand, VeriFone boxes would make better Bitcoin POS machines because they have a built-in printer, that's sort of important.

I'm interested in making the Linux timeclock box available to others, because anyone can develop for them.  And if someone can contribute to the Bitcoin codebase that runs on the Linux timeclock, it should have no problem compiling for the bankcard machines as well.


I'm hoping to just give away the code for any progress I make on this.  I believe this is what it'll take for average businesses to care about Bitcoin.


I don't like unresponsive UIs and wouldn't use this platform if that were the expected experience.  My timeclock app is very responsive and I would expect that any sort of bitcoin app would be the same.

I want to belive you and yet my experience tells me that there's something fishy here.

Run-from-flash on a cache-less ARM is definitely possible but also definitely very slow. It may be OK for driving a modem, but most likely it will not be OK for any real crypto application.

As far as I know, the SSL and TCP/IP implementations sold by Verifone (licensed from Windriver?) are seriously crippled by implementing only minimal subsets of the full functionality, suitable to run only on LANs or WLANs with low packet loss.

If the whole project get from the start rearchitectured to dumb-wimpy-client/smart-ruddy-server that would increase the chances of achieving something that is both deliverable and maintainable in case of the future need for modifications.

Admittently I don't have an actual experience with Verifone's hardware, but we had to deal with something very similar. In the end the acceptable and secure solution required about 5-15 seconds wait to respond to the keypresses. And  this was after immense time spent optimizing the C code with hand-crafted assembly.

good work!!

Memory capacity is an option.  The memory goes a long way on these terminals.  I have never run out.  Factors:
* the CPU can execute code directly out of its flash memory filesystem, rather than copying it into RAM, which is actually quite unusual but also saves lots of memory as the code won't occupy any of it
* many of the libs and SDK functions are implemented in the device's firmware, the part you link into your binary merely makes a syscall to get at it
* the device regularly uses thumb (compact ARM encoding) which makes the binaries even smaller

Even my biggest VeriFone project took no more than a few hundred kilobytes, most of that being statically linked support for SSL.  Obviously the machine isn't going to be able to hold the blockchain.  But as the client part of a client/server app, the memory capacity is not an issue.

With respect to a VeriFone Vx terminal, if the device boots up and has the words "DEFAULT CERTIFICATE" on the boot splash screen, it's not locked down and will run binaries signed by the "default certificate" provided in the SDK, assuming the default password to reach the download menu hasn't been changed (it usually is left at the default).

I just downloaded some random pdf book full of blurbage from Verifone Devnet. Here's what I read there:
Is it 3, 4 or 6? And how much of that is left for the application to use?

In light of the above the whole project looks science-fiction-ey to me.

And adding to the POS a rechargable credit card bitcoin wallet let even non tech savy customer to use them even if they don't have a PC at home

I suppose your doubt would ring true for many merchants.  And for many others, the machine would make sense.  A lot of businesses are hurting and don't have $250 to spare.  To others, $250 is negligible.

If you're the boss, you don't want your employees being able to anonymously pocket your cryptocurrency.  A machine like this allows you to delegate receiving bitcoins to your employees - in a drop-dead simple way - so that you don't have to yourself.  Once they've been collected by the machine, only you have access to them, not your employees.

The machine prints paper receipts, which are useful for implementing all sorts of controls, none of this is possible with a smartphone.  And the dedicated machine is always on and ready to go.  If a customer is waiting for a payment to go through, the employee can do something else or work on the next customer while waiting for the machine to beep, rather than fidgeting with the refresh button on the smartphone.

Bottom line - there IS a demand for this.  Many businesses want to accept bitcoin, but can't get past "where do I start".  This machine would be an answer: "buy this and plug it in."