Good morning Igor,

This is quite an interesting use-case for Lightning.

However it seems to me that the payer will need a direct channel to the payee, 
or at least the payment terminal (of the payee...?).

In addition the payer will need to somehow get blockchain information from the 
payee if the payer itself has no Internet.  The payee may have an incentive to 
prevent the payer from knowing that timeouts have been reached, for example, 
and may withhold new blocks (although all censorship attacks I know of that 
could be used on LN target the payee and not the payer).

Is my understanding correct?

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On April 5, 2018 5:46 PM, Igor Cota <i...@codexapertus.com> wrote:

> 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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to