Bitcoin Forum

Hey everyone,

I'm proud to be making this post today and announcing another pioneering tech solution within the eMunie project, but first, a bit of blurb to set the scene....

From the outset, one of our (many) goals was that eMunie would be accessible to the masses and easy to use, a key requirement of meeting that goal being integration into existing merchant infrastructures.
More specifically, we wanted merchants to be able to accept EMU (or other system asset token) payments without needing any additional or new Point of Sale (PoS) hardware as this is not cost effective, nor a good use of valuable counter space.

Additionally, we wanted a convenient primary payment method that non-technical users would already be familiar with, debit cards, yet they should not be reliant on 3rd party payment networks, nor on middlemen services in order to fund and use it. Thus it and had to be a "native" system.

To clarify, native in this context means that users should be able to spend EMU directly from the card, to the merchant, using existing hardware the merchant already possesses which has been updated with a simple software patch, allowing that PoS hardware to push transactions directly to the main eMunie network.....*whew*

Achieving this level of native integration is not possible with current crypto-currency technology, as the architecture of the ledgers (more specifically block chains) do not lend themselves to this kind of operation. There is always a requirement for 3rd party services of some kind, that the merchant and/or users are reliant upon so incurring inconvenience and additional costs (fees).

The eMunie ledger has been designed from the outset with this goal and associated use cases in mind throughout development, and recently we were finally able to perform the first transactions using simulators and hardware that support the same EMV protocols as hardware found in merchant stores.

Presented below is a first look video of this technology in action, I'll then explain in more detail what is going on, as the demonstration has a number of moving parts and it's difficult to represent efficiently in a video.

https://www.youtube.com/watch?v=yZFscCpiSkM

In the demonstration we have 2 machines, 1 in the UK the other in Denmark being viewed over TeamViewer.

The UK machine is acting as the merchant and has a EMV compliant card reader attached to it and is executing a basic PoS terminal device simulator.

The machine in Denmark has the imported card wallet open and the card has been loaded with funds simply by sending EMU to the card wallet address.

Card creation is a simple process and users can either obtain them from an trusted issuer, or if they have access to (or purchase) a cheap EMV compatible card reader and the correct card type, they can install the cardlet application and create their own. Readers can be obtained for between $20-40 depending on any addition features desired and the blank cards themselves costing a few $.

Once created, card wallets can then be imported into the users client/s, and can be loaded/unloaded with funds as they see fit.

In the video there are 2 demonstrations, the first is a payment from the card for 1000 EMU with the card's wallet open in Denmark, and the second is another payment of 1000 EMU with the card's wallet in Denmark closed.

These 2 demonstrations are performed to prevent any confusion that card wallets need to be open somewhere when spending, they do not. Subsequently if the user should open the card's wallet in their client at a later date, the transactions they made with the physical card will be displayed as that client synchronizes.

As you can see in the demonstrations, payments from the card show almost immediately in the user's card wallet (when open), and have cleared and confirmed in the merchant's wallet within around 10 seconds. The system is still in heavy development and unoptimized at present so transaction times are a little longer than optimal.

In the first release candidate post-optimizations and tuning, these durations will be 5 seconds or less, and of course payments will be tightly integrated with the software on the PoS terminal via the update plugin, and will not need the actual eMunie client.

Due to our PoS technology being EMV compliant, contact-less support is also available within future eMunie mobile clients and can use existing merchant contact-less payment terminals in the same manner. A demonstration of contact-less payments will be made and posted in due course.

I hope you enjoyed this short initial demonstration of our native PoS technology. Watch this space for more demonstrations as development progresses, and I welcome any questions or comments.

Very cool.

Does this mean you'll need to write firmware/software updates for every different type of card reader software a merchant might have? Are the manufacturers of the point of sale systems happy to have merchants updating their firmware?

Oh waw really nice to see this. Nice info btw.

Is there a reason a consumer would want to buy emunies first to do the purchase with instead of just using his/her visa card?

The only answer I could give to this question is rhetorical: Is there any reason a consumer would use any cryptocurrency rather than a visa card?
The initial users would be people who have already bought into the idea of a decentralized, P2P currency and network as an alternative to the existing financial systems monopolized by the large banks and financial institutions.

Regarding 'why eMunie', the eMunie network is explained in a series of videos on Youtube, although things have moved on since the older ones were made so they are not 100% correct but they do show the general overall system. An eMunie user wouldn't have to 'buy' eMunie, although this is an option, they could simply earn eMunie by providing a service to the eMunie community. Additionally, due to the ease of use of eMunie - no special hardware needed, no special technical expertise needed, straightforward GUI, 'familiar use' debit card, and more - compared to other existing cryptocurrency networks, eMunie would be a more viable currency compared to another crypto coin.

Given the care and expertise that has gone into creating eMunie, with the same diligence the rollout and marketing should produce wide spread adoption of the system.

Well, that's my take on it!

Yes. eMu is the currency and eMunie the platform is an automated decentralised elastic money supply where your not robbed through inflation.

This means they wouldn't buy the eMu for that specific transaction but would have their entire income earned in (or converted to) eMu making financial transactions as effortless and practical as it is with the local fiat currency.

No there isn't. That's why I asked if they had perhaps came up with a new idea to take crypto to mainstream.



i.e. yet another way for early BTC holders to dump (indirectly) for FIAT.



Most consumers don't have to worry about inflation as they don't have massive FIAT savings. They spend their salary in a month. Not much time for inflation to really affect anything. Store of value could be a valid use case though.

We have quite a few ideas to take crypto from the state it is now to main street. Exact details are not given since they will be stolen by others - we've experienced that before. There will be plenty incentives to go for the emunie route instead of regular VISA cards.

We will "spill the beans" when the time is right.  :)

I recommend you use a different acronym for Point Of Sale, otherwise you will confuse people on here :)

Sorry, I must have overlooked your question about plans to take crypto mainstream!

For most of the payment terminals (where you insert your card) it should be "write once run anywhere".  Its EMV compatible so you simply use the same protocol to communicate with the card as a debit card from your bank would, and the ISO API to push the information you need to display on the screen.  The basic EMV compliant cardlet will be enough to work on most, if not all of the major hardware providers.

If we want to do a more exotic implementation (some eMunie branding on the screen, more complicated payment options etc), then providing you are a registered developer, and you obtain the correct certification for your card application, then there is no issue to push updates to the readers to do this task.

On the front end cash desk screen that the merchant sees, most of these run some form of embedded Windows or Linux kernel, so its trivial to have an eMunie daemon running in the background to have that direct connection to the network and provide any interfacing required.

Indeed, those videos are very out of date for the most part now and we're doing updated ones as we go along.  Nice to keep them around though for nostalgia and to see how far its come :)

We have some novel roll out plans which compliment the balance interest and earnings for providing work to the system incentives to assist adoption further, but we're keeping those under wraps for now.


Thanks for that, means a lot :)

Not only that, the merchant doesn't get busted with 1-3% fees, but a flat 1 cent (in equivalent EMU) fee, so some could actually offer the product cheaper if purchased with EMU, another incentive :)

True, most consumers would just opt to buy the cards from a trusted provider, or maybe ask a friend who is "computery" to make one for them (everyone has a `computery` friend :) )...but, for the paranoid amongst us, the cost of making your own for you and your family is low enough to be viable, and its simply 2 commands in the client to do it.

It would be hard to implement this, merchants are thousands - who will cover costs ? Even through supermarkets chains  ;)

Not as hard as you might think.

Much like installing an updated driver for a printer, but with the new driver you save 2~3% in printer ink for every page printed.

1. Download driver
2. Install driver on POS terminal
3. Start accepting eMunie and begin saving 2~3% vs. Visa/MC.

Exactly!

Should take a few minutes to be up and running :)

I disagree. In the world outside of current crypto no merchant would associate POS with Proof of Stake.

Any plans on having BTC and LTC doing off chain transactions in your network?  I think LTC will benefit more with this if your system takes off.  So I guess you guys could get together with Charlie Lee or whoever and form an informal partnership of sorts.

Yes, but the outside world does not use this forum, that's what I meant.

I'm really digging your project Fuserleer.

I guess this Ignecio is the one to talk to?


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 :)

Thanks! :)

Lots to come yet, so stay tuned  8)

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

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.

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 :(

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 :)

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?

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.

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?

Ok i want some....

Any rewards for early adopters?