<div dir="ltr">Morning all,<div><br><br>&gt; 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...?).<br><br>Yes, for the lightning NFC connection I had the local coffe shop use case in mind.<br><br><br>&gt; The trusted server can, for instance, be a full Lightning node running at the payer&#39;s home.<br><br>This is my current setup and I feel the only feasible one for the privacy minded. For the time being at least.<br><br><br>&gt; 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.<br><br>This is a great idea!<br><br><br>&gt; But what the payment terminal would provide, would not be a connection to the payment terminal node, but a connection to the Internet-in-general.<br><br>¿Por qué no los dos? <div>I&#39;m thinking of a protocol where (after initial BOLT-11 transfer) the terminal and device agree on the means of connection depending on what they respectively support or makes sense at that moment. There is a standard way for NFC to handover to bluetooth or wifi, I&#39;ll look into that. Basically whatever works as long as it seems seamless to the user and is relatively quick.<br><br>I&#39;m not so fussed about potential abuse for these types of payments. In my experience people are less likely to scam you if you are physically there. :)<br><br>Thanks for your input! I made a pull request for the BOLT-11 MIME type and I&#39;ll have a think-over bout the connection-handover business.<br><br>Cheers,<br>Igor<br><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><span style="color:rgb(84,84,84);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><span style="color:rgb(84,84,84);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 April 2018 at 18:53, ZmnSCPxj via Lightning-dev <span dir="ltr">&lt;<a href="mailto:lightning-dev@lists.linuxfoundation.org" target="_blank">lightning-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning Corne,<br>
<br>
My understanding, of the setup of Igor, is that, there is a Lightning-protocol connection between the mobile device and the base station/payment terminal device.<br>
<br>
Initiating a payment to anyone on the network requires that you have direct communication with whoever you have a direct channel to.<br>
<br>
If the mobile device can communicate only with the payment terminal, then it can only pay using channels with the only node it has a connection to.<br>
<br>
The mobile device could pay anyone else on the network via that channel, but presumably the purpose of the payment terminal is to be the node that receives the payment.<br>
<br>
If the payment terminal itself connects to anyone else, on behalf of the mobile device, then that is beyond the current Lightning protocol.  Perhaps Igor has added more messages that allow such a setup?<br>
<br>
Communicating over a secure channel to a trusted server is how I imagine most practical mobile devices would work.  But what the payment terminal would provide, would not be a connection to the payment terminal node, but a connection to the Internet-in-general.<br>
<br>
Regards,<br>
ZmnSCPxj.<br>
<br>
<br>
​Sent with ProtonMail Secure Email.​<br>
<br>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
<div><div class="h5"><br>
On April 5, 2018 11:52 PM, Corné Plooy via Lightning-dev &lt;<a href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; If there are censorship concerns, you could opt for a set-up where payer<br>
&gt;<br>
&gt; has an authenticated connection to a trusted server, through the<br>
&gt;<br>
&gt; Internet connection provided by payee. The trusted server can, for<br>
&gt;<br>
&gt; instance, be a full Lightning node running at the payer&#39;s home.<br>
&gt;<br>
&gt; The payer then only has to take a very light piece of electronics with<br>
&gt;<br>
&gt; him/her. It will still be larger than a credit card (since<br>
&gt;<br>
&gt; authentication should be done payer-side, e.g. with a PIN code), but it<br>
&gt;<br>
&gt; can be smaller than a smart phone. Personally, I like this kind of<br>
&gt;<br>
&gt; set-up, because I see cell phones as a huge privacy issue (you&#39;re<br>
&gt;<br>
&gt; continuously transmitting your rough location to the network).<br>
&gt;<br>
&gt; Why would there need to be a direct channel between payer and payee? We<br>
&gt;<br>
&gt; have the Lightning network to avoid needing direct channels, right?<br>
&gt;<br>
&gt; CJP<br>
&gt;<br>
&gt; Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:<br>
&gt;<br>
&gt; &gt; Good morning Igor,<br>
&gt; &gt;<br>
&gt; &gt; This is quite an interesting use-case for Lightning.<br>
&gt; &gt;<br>
&gt; &gt; However it seems to me that the payer will need a direct channel to<br>
&gt; &gt;<br>
&gt; &gt; the payee, or at least the payment terminal (of the payee...?).<br>
&gt; &gt;<br>
&gt; &gt; In addition the payer will need to somehow get blockchain information<br>
&gt; &gt;<br>
&gt; &gt; from the payee if the payer itself has no Internet.  The payee may<br>
&gt; &gt;<br>
&gt; &gt; have an incentive to prevent the payer from knowing that timeouts have<br>
&gt; &gt;<br>
&gt; &gt; been reached, for example, and may withhold new blocks (although all<br>
&gt; &gt;<br>
&gt; &gt; censorship attacks I know of that could be used on LN target the payee<br>
&gt; &gt;<br>
&gt; &gt; and not the payer).<br>
&gt; &gt;<br>
&gt; &gt; Is my understanding correct?<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt;<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt;<br>
&gt; &gt; Sent with ProtonMail <a href="https://protonmail.com" rel="noreferrer" target="_blank">https://protonmail.com</a> Secure Email.<br>
&gt; &gt;<br>
&gt; &gt; ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
&gt; &gt;<br>
&gt; &gt; On April 5, 2018 5:46 PM, Igor Cota <a href="mailto:igor@codexapertus.com">igor@codexapertus.com</a> wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hello all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I feel that one of the biggest promises of lightning lies in it being<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; used for everyday retail payments.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;d like to see a system that&#39;s:<br>
&gt; &gt; &gt;<br>
</div></div>&gt; &gt; &gt; 1.  instantaneous like the contactless bank cards of today<br>
&gt; &gt; &gt; 2.  encodes a fancy HTML receipt in bolt11 for the payers future reference<br>
<div class="HOEnZb"><div class="h5">&gt; &gt; &gt;<br>
&gt; &gt; &gt; QR codes are a bit unwieldy and even more so if you want a nice HTML<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; table description of your grocery shopping with hundreds of items -<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; this relatively large amount of data makes them impractical to scan.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; To this end I&#39;ve been running an instance of c-lightning on Android<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [1][2][3] and experimenting with payments via NFC. I set up a machine<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; with an NFC USB dongle that acts as an point-of-sale terminal [4]. So<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; far so good!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; There are two basic ways you can use NFC enabled phones today - as<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; passive tag readers or in card emulation mode (not sure if the latter<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; is available on iOS).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Passive tags are really simple and encoding bolt11 to them works as<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; expected. If you set the right MIME type Android will open whatever<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; app is registered to handle lightning and you can either pay<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; instantaneously or after user confirmation. Works great provided both<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; the phone and terminal are connected to the network and have a route<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; to each other.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Card emulation mode is more interesting because it enables us to have<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; two way communication and therefore an ad hoc connection to the<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; lightning network. After some handshaking, phone can tell the<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; terminal that it wants to connect to lightning via NFC. All<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; communication between these two lightning nodes can be done over NFC<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; or even bluetooth [5]. This might be useful as fallback in situations<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; where mobile data is not available.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I settled on a MIME type (application/lightning) and an NFC<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; application id (LIGHTNING). There is also a very simple protocol to<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; forward socket data. For the sake of interoperability it would be<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; great if we agreed on some standards but I&#39;m not sure how to proceed<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; with this. Should these be part of a future BOLT or is mailing list<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; banter enough?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I look forward to your views!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Igor<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [1]<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; <a href="https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af" rel="noreferrer" target="_blank">https://github.com/<wbr>ElementsProject/lightning/<wbr>commit/<wbr>bd95aba7a5f9bad8f447bf3de8f7e8<wbr>cfe83751af</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [2]<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; <a href="https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7" rel="noreferrer" target="_blank">https://github.com/<wbr>ElementsProject/lightning/<wbr>commit/<wbr>d4d1c4acb08efb6be4f491cdee5cb6<wbr>dd4b84ddf7</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [3]<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; <a href="https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af" rel="noreferrer" target="_blank">https://github.com/<wbr>ElementsProject/lightning/<wbr>commit/<wbr>bd95aba7a5f9bad8f447bf3de8f7e8<wbr>cfe83751af</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [4] <a href="https://github.com/icota/presto" rel="noreferrer" target="_blank">https://github.com/icota/<wbr>presto</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; [5] <a href="https://github.com/ElementsProject/lightning/pull/1323" rel="noreferrer" target="_blank">https://github.com/<wbr>ElementsProject/lightning/<wbr>pull/1323</a><br>
&gt; &gt;<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; &gt; Lightning-dev mailing list<br>
&gt; &gt;<br>
&gt; &gt; <a href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt; &gt;<br>
&gt; &gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/<wbr>lightning-dev</a><br>
&gt;<br>
&gt; Lightning-dev mailing list<br>
&gt;<br>
&gt; <a href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;<br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/<wbr>lightning-dev</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/<wbr>lightning-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><b>Igor Cota</b><div>Codex Apertus Ltd<br></div></div></div></div></div>
</div>