[Lightning-dev] Lightning over NFC
corne at bitonic.nl
Thu Apr 5 15:52:27 UTC 2018
If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.
The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since
authentication should be done payer-side, e.g. with a PIN code), but it
can be smaller than a smart phone. Personally, I like this kind of
set-up, because I see cell phones as a huge privacy issue (you're
continuously transmitting your rough location to the network).
Why would there need to be a direct channel between payer and payee? We
have the Lightning network to avoid needing direct channels, right?
Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> 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?
> Sent with ProtonMail <https://protonmail.com> Secure Email.
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 5, 2018 5:46 PM, Igor Cota <igor at 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
>>  and experimenting with payments via NFC. I set up a machine
>> with an NFC USB dongle that acts as an point-of-sale terminal . 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 . 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!
>>  https://github.com/icota/presto
>>  https://github.com/ElementsProject/lightning/pull/1323
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
More information about the Lightning-dev