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