Imagine a way to expand bitcoin payments to millions per second. Now, imagine a clunky, command-line interface.
That’s the extent of the divide between the vision enabled by bitcoin’s best-yet scaling solution, the lightning network, and the current state of its design. But while that’s daunting, developers are moving ahead on designs to make the payment system easier to use, with one recently submitting a proposal for connecting lightning with a payment technology that could make it feel as futuristic as it’s touted.
That payment technology, near-field communication, or NFC, would allow a user to pay for an item just by holding their smartphone an inch away from the device it’s paying.
Not a new idea in bitcoin or the payments world at large, NFC-based payments have caught on throughout Asia and Europe – not only on smartphones, but also through chips embedded in payment cards. And while the U.S. might be lagging behind in NFC adoption, bitcoin’s early adopters might just be the right target audience.
As such, the proposal, submitted by developer Igor Cota, looks to standardize a way to connect lightning with NFC.
Invoking the name of his lightning wallet that uses NFC, Presto, Cota told CoinDesk:
“I want the payments to be instant just like with the contactless cards we have here in Europe. A user would simply tap on the payment terminal and presto!”
Further, Cota imagines turning any computer into a lightning point-of-sale terminal through the use of a $29 USB attachment, a route that has proven successful in his early tests.
Replacing QR codes
Given the success, Cota’s proposal is about standardizing what he’s created, adding it to the many other standard rules that describe how each lightning software implementation should operate.
Many bitcoin payments implementations tend to use QR codes – those pixelated-looking black-and-white squares that encode data that can then be scanned and consumed by smartphones. And while Presto supports QR codes alongside NFC, he believes the latter provides a much better experience.
QR codes not only can be a bit finicky, but they also can become “unwieldy,” Cota said, especially when more information is added to them. In this way, merchants won’t be able to add much information such as itemized receipts and coupons to QR codes, he said.
NFC, though, doesn’t have this hurdle.
“I’d like to see a system where the payment terminal sends a nice HTML receipt for the customer – that receipt has, say, a table list of your grocery shopping with subtotal, taxes, grand-total, perhaps a shop logo, some loyalty code or a coupon for future use,” he said.
In Cota’s mind, this would give consumers a more detailed record of their spending habits, empowering them to take even more control of their finances.
“Imagine a wallet that can tell you how much you’ve spent on broccoli last month?” Cota said, adding:
“With crypto you’re always in control, but with these digital receipts you are even more so.”
A bolt of lightning
But first, Cota is trying to get his NFC implementation added to the standards that lightning network developers have established in an effort to make sure all implementations are compatible with each other.
These standards are called “BOLTS,” and Cota believes NFC should be added to BOLT 11, which explains how “invoices” – describing how much a person owes – should be encoded and presented to a user. It’s a similar process to that of the credit card reader at Starbucks showing you that you owe $4.50 for a mocha latte.
For now, BOLT 11 only describes a standard for QR codes.
Already, Cota has come up with a rough standard, putting together a Multipurpose Internet Mail Extensions (MIME) type, which is a format for sending data; an NFC application ID, which indicates the payment method is lightning; and a “very simple protocol to forward socket data.”
Though these pieces weren’t so hard to come up with, Cota said he thinks it’s important to write up a standard, whereby all NFC-enabled point-of-sale devices can accept any NFC-based lightning payment, now to be ahead of the game should NFC-based lightning payments take off.
“For the sake of interoperability, it would be great if we agreed on some standards,” he explained.
And already, most of the public technical feedback has been positive, with Lightning developers ZmnSCPxj and Corné Plooy responding favorably to the proposal on the mailing list.
However, Bitrefill lightning developer Justin Camarena was a bit wishy-washy, telling CoinDesk:
“It’s an obvious way to pay in the future but it seems we’re a bit too early as there are no hardware point-of-sales offering lightning support.”
Still, Cota is plugging away on the next steps to move the project forward.
“As you can see the [Presto user-interface] is not really there yet but I’m working on it,” he said, adding, “What I’m working on at the moment is a protocol that makes sure the NFC payment goes through even in case the paying device is offline.”
Cota plans to submit another pull request for developers to review once this mechanism is finished.
from: https://www.coindesk.com/lightning-nfc-new-plan-bring-bitcoin-retail/
Igor Cota igor at codexapertus.com
Thu Apr 5 09:46:32 UTC 2018
- Previous message: [Lightning-dev] De geschiedenis van Lightning
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello all,
I feel that one of the biggest promises of lightning lies in it being used for everyday retail payments.
I’d like to see a system that’s:
1) instantaneous like the contactless bank cards of today
2) encodes a fancy HTML receipt in bolt11 for the payers future reference
QR codes are a bit unwieldy and even more so if you want a nice HTML table description of your grocery shopping with hundreds of items – this relatively large amount of data makes them impractical to scan.
To this end I’ve been running an instance of c-lightning on Android [1][2][3] and experimenting with payments via NFC. I set up a machine with an NFC USB dongle that acts as an point-of-sale terminal [4]. So far so good!
There are two basic ways you can use NFC enabled phones today – as passive tag readers or in card emulation mode (not sure if the latter is available on iOS).
Passive tags are really simple and encoding bolt11 to them works as expected. If you set the right MIME type Android will open whatever app is registered to handle lightning and you can either pay instantaneously or after user confirmation. Works great provided both the phone and terminal are connected to the network and have a route to each other.
Card emulation mode is more interesting because it enables us to have two way communication and therefore an ad hoc connection to the lightning network. After some handshaking, phone can tell the terminal that it wants to connect to lightning via NFC. All communication between these two lightning nodes can be done over NFC or even bluetooth [5]. This might be useful as fallback in situations where mobile data is not available.
I settled on a MIME type (application/lightning) and an NFC application id (LIGHTNING). There is also a very simple protocol to forward socket data. For the sake of interoperability it would be great if we agreed on some standards but I’m not sure how to proceed with this. Should these be part of a future BOLT or is mailing list banter enough?
I look forward to your views!
Cheers, Igor
[1] https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[2] https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
[3] https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[4] https://github.com/icota/presto
[5] https://github.com/ElementsProject/lightning/pull/1323
from: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001132.html