[EMUNIE] Decentralized debit cards and integrated PoS systems - *first look*

[tokeweed]

I guess this Ignecio is the one to talk to?

Point-of-Sale Giant Ingenico Rolls Out Worldwide Bitcoin Payments

BitPay has partnered with payments giant Ingenico to allow brick and mortar stores to accept bitcoin via its point-of-sale (POS) terminals.

The payment solution, unveiled today as part of Blockchain Week, was developed by BitPay and installed on an Ingenico Terminal ICT250.
ADVERTISEMENT

According to the company, it will be compatible with the majority of Ingenico terminals as they run its operating system, Tellium.

http://www.coindesk.com/point-of-sale-giant-ingenico-rolls-out-worldwide-bitcoin-payments/

[1713893230]

1713893230

[1713893230]

1713893230

[Fuserleer]

I guess this Ignecio is the one to talk to?

Point-of-Sale Giant Ingenico Rolls Out Worldwide Bitcoin Payments

BitPay has partnered with payments giant Ingenico to allow brick and mortar stores to accept bitcoin via its point-of-sale (POS) terminals.

The payment solution, unveiled today as part of Blockchain Week, was developed by BitPay and installed on an Ingenico Terminal ICT250.
ADVERTISEMENT

According to the company, it will be compatible with the majority of Ingenico terminals as they run its operating system, Tellium.

http://www.coindesk.com/point-of-sale-giant-ingenico-rolls-out-worldwide-bitcoin-payments/

I saw that earlier and its about as good as you'll ever get with Bitcoin and other cryptos derived from its architecture, you always need a 3rd party or middle man of some kind.

The solution that Bitpay are offering won't be much different that those Paypal debit cards you can get and it certainly wont be a decentralized native BTC payment solution similar to what we present here.  You load BTC to your Bitpay account, Bitpay will fire off some fiat to the merchant from their account, and debit the equivalent amount of BTC required to honor the sale from your account then throw up a sell to settle it.

It'll likely operate over the Visa/Mastercard network, but Bitpay could have set up their own end point where the terminal connects to them directly, doubtful but possible (if anyone knows I'd love to know!).

Just like Paypal or your bank though, they will be the authority on whether the payment goes through or not.  Someone at Bitpay doesn't like what you are spending your BTC on, payment denied/card blocked, government/NSA duly informed!

All they have likely done with the terminals (save for implementing their own network) is provide a user interface so that it displays "Paying with BTC" when you insert that card and the associated options to do so.  The terminal then just instructs whoever the payment network operator is (Visa/MC) that Bitpay is the authorization for that payment and routes the information accordingly.  The merchant probably doesn't even know you've paid with BTC.

Will it work and allow you to pay with BTC?  Sure it will, but there are solutions already available that do the same thing except they don't have the marginally improved PoS integration and experience.

Already had the dev kits and terminal devices for some time now, Ive worked in the payments sector of FinTech in the past pre-eMunie (NFC solution development) so still got access to a lot of stuff.

Ingenico and Verisign are the 2 major players globally so we're planning to roll out on those initially, but ultimately I'd like to have the eMunie payment protocol installed by the OEM on the devices.  Thankfully I'm still in contact with some very nice folks at Atos from those NFC days, so I'm hoping they can help to oil the gears a little

[Fuserleer]

I'm really digging your project Fuserleer.

Thanks!

Lots to come yet, so stay tuned 

[monsterer]

I saw that earlier and its about as good as you'll ever get with Bitcoin and other cryptos derived from its architecture, you always need a 3rd party or middle man of some kind.

This feature of Emunie completely relies on it the supposed impossibility of a fork developing in the chain(s), resulting in a double spend?

[Peachy]

I saw that earlier and its about as good as you'll ever get with Bitcoin and other cryptos derived from its architecture, you always need a 3rd party or middle man of some kind.

This feature of Emunie completely relies on it the supposed impossibility of a fork developing in the chain(s), resulting in a double spend?

There are no forks.  There are no blocks.  Get out of the blockchain mindset. 

[monsterer]

There are no forks.  There are no blocks.  Get out of the blockchain mindset. 

Yes, Enumie cheerleaders are very keen to point out that there are no blocks, but the fact remains: there IS a chain, therefore there CAN be forks in it.

[Fuserleer]

I saw that earlier and its about as good as you'll ever get with Bitcoin and other cryptos derived from its architecture, you always need a 3rd party or middle man of some kind.

This feature of Emunie completely relies on it the supposed impossibility of a fork developing in the chain(s), resulting in a double spend?

No it doesn't (nor do I want to get into another forking argument in this thread )

In the case of  BTC and clones for example, the problem is the UTXOs.  The card won't know what inputs it can use within a transaction as it's air gapped from the network 99.9% of the time.  Even if it had the space to store them, it'd be pointless as the UTXOs for that card could have changed since the last time it was connected and would have to query them anyway somehow.

For this to be possible with BTC, you'd need either the merchant to run a full node somewhere, have a daemon running on the PoS terminal that keeps all the UTXOs up to date (might get tricky as it grows on an embedded system its already something like 600MB+) or have some trusted 3rd parties the merchants PoS can contact to get the current set of UTXO for the card.

Then with BTC at least you have the Finney attack to worry about...10 mins is a hell of long time to be able to run off and re-spend.

Other ledger designs have similar limitations that don't allow the simplistic native solution we have developed, but the UTXO problem is by far the worst....sorry Bitcoin

[monsterer]

In the case of  BTC and clones for example, the problem is the UTXOs.  The card won't know what inputs it can use within a transaction as it's air gapped from the network 99.9% of the time.  Even if it had the space to store them, it'd be pointless as the UTXOs for that card could have changed since the last time it was connected and would have to query them anyway somehow.

Interesting... I thought the card was basically just a pin protected private key?

[Fuserleer]

In the case of  BTC and clones for example, the problem is the UTXOs.  The card won't know what inputs it can use within a transaction as it's air gapped from the network 99.9% of the time.  Even if it had the space to store them, it'd be pointless as the UTXOs for that card could have changed since the last time it was connected and would have to query them anyway somehow.

Interesting... I thought the card was basically just a pin protected private key?

Ours is, and that is all we need.  The merchants create the transactions, pass to the card for verification and signing and thats it as no external components are needed from the network.   

The transaction then gets broadcast to the network and the PoS terminal listens for callbacks on whether it validates and confirms or not.  Within a couple of seconds, payment success or failed, easy

[monsterer]

Ours is, and that is all we need.  The merchants create the transactions, pass to the card for verification and signing and thats it as no external components are needed from the network.   

The transaction then gets broadcast to the network and the PoS terminal listens for callbacks on whether it validates and confirms or not.  Within a couple of seconds, payment success or failed, easy

That would work for bitcoin as well - run a lite client on the merchant's terminal building transactions signed using the private key on the card. Ignoring confirmation times, of course.

[Fuserleer]

Ours is, and that is all we need.  The merchants create the transactions, pass to the card for verification and signing and thats it as no external components are needed from the network.   

The transaction then gets broadcast to the network and the PoS terminal listens for callbacks on whether it validates and confirms or not.  Within a couple of seconds, payment success or failed, easy

That would work for bitcoin as well - run a lite client on the merchant's terminal building transactions signed using the private key on the card. Ignoring confirmation times, of course.

Where do you get the inputs from that are required to make the transaction?

[monsterer]

Where do you get the inputs from that are required to make the transaction?

The lite client?

[Fuserleer]

Where do you get the inputs from that are required to make the transaction?

The lite client?

The lite clients don't have the full UTXO...if they did they wouldn't be lite clients as you can only build the full UTXO if you have a full node with all the block chain data.

Merchant needs access to the full UTXO because there is no way to identify which outputs belong to cards, so you need access to them all, at all times whether locally or remotely.

[monsterer]

Merchant needs access to the full UTXO because there is no way to identify which outputs belong to cards, so you need them all, at all times.

Good point. I was thinking about a single user, which isn't entirely scalable!

So how does your system avoid having a full node on the merchant's terminal?

[cryptohunter]

Ok i want some....

Any rewards for early adopters?