<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#333333" bgcolor="#FFFFFF">
    <p><font size="-1"><font face="Trebuchet MS">Hello </font></font>ZmnSCPxj,</p>
    <pre wrap=""><blockquote type="cite"><pre wrap="">Is this the same problem that is solved by: <a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html</a> ?
</pre></blockquote>
It essentially is; but I guess there will be other use cases where it may be interesting to transmit some information encoded within the preimage, so that it is only revealed after payment. 

One use case that comes to mind is what we could call 'pay to pay':

Alice wants to pay Bob some sizable amount, onchain. Bob gives Alice a tiny LN invoice and piggybacks his onchain address for Alice to pay him (160 bits in this case).
Upon payment of the LN invoice, Alice decrypts Bob's address.
This could help preventing Mallory from spamming Bob to get countless payment addresses that won't ever be used (I am thinking Wikileaks for instance). 

<blockquote type="cite"><pre wrap="">I believe the solution presented at the summit is superior technology-wise.
</pre></blockquote>
Regarding what solution is superior, I wouldn't say it is a matter of superiority but rather one of fitness for the purpose, I will elaborate below.

<blockquote type="cite"><pre wrap="">1.  The offline device holds no secrets.  Hacking it (if somehow possible) is thus not incentivized.
2.  The offline device can verify the hashes it holds in memory come from its owner.  Invoices require a signature, and invoices include the payment hash.  A payment hash stored in the offline device is thus committed to in the signature of the invoice, and the invoice signature can be verified
</pre></blockquote>
The risk of hacking will always be there, I believe, although neither proposal stores keys in the vending machine, so hacking it won't be catatrophic.
Anyway, rather than stealing secrets from the vending machine, I believe a hacker would replace the payment hashes and ancillary information with his own.

This way, the future payments would go to the hacker's address instead of the machine's owner. 

This vulnerability applies to both systems, so I don't see a clear winner here. I guess only using an HSM device within the machine could provide a high level of protection against these attacks. In the end, nothing can really beat a hacker that has physical access to a machine (which I guess is the case of many vending machines).

<blockquote type="cite"><pre wrap="">3.  It works as-is without additions to the BOLT spec or to current wallets.</pre></blockquote>
That is a clear plus for your scheme, at least short term, since interested parties would be able to roll out an implementation without having to depend on any external dependencies. Anyway, my point here is that it is actually desirable having both standards and modified wallets, to radically increase usability, which will be needed if we want to have widespread adoption of LN payments.

The biggest drawback to the system you propose is -IMHO- the logistics needed for replenishing the hashes into offline vending machines. The system I propose only requires an initial configuration of the machine with the shared secret for an unlimited series of payments.
 
As for the 'compromise' you suggest, I find it really smart and workable. I think the six digit code is cheap to implement and secure enough for most use cases.

OTHER THOUGHTS
---------------------

I still have a few doubts however on how the scheme you propose would handle these concerns:

a) Price changes: With the piggybacking scheme I propose, the vending machine (or toll both, or whatever) doesn't set the price of the item or service. It only sends the product/service Id to the remote LN Node. This way, prices can be adjusted in real time.

b) Static QR codes: Again, the piggybacking scheme allows for static QR codes to be used by having an implicit transaction Id (the timestamp in 30 seconds  increments).

c) Privacy and security: By sending the six digits code in the clear, within the preimage, intermediate nodes have access to this information. I think that poses both a privacy and a security problem. That's the reason I proposed XORing the piggybacked secret with a one time pad.

All in all, I guess there can be use cases for both schemes. I see yours more fit for devices that have intermittent connectivity, rather than being offline all the time, since that overcomes in a great manner the problem of replenishing hashes, but maybe I am missing something here.

Regards.
</pre>
    <div class="moz-cite-prefix">El 17/12/2018 a las 4:56, ZmnSCPxj via
      Lightning-dev escribió:<br>
    </div>
    <blockquote type="cite"
cite="mid:qqyIVqUlenCitvdl0sLqkrexNh933n_3FPrtILEusQUTcDrpwMHfKtVS58qmj2jac5JPQCRusoHOcr62X-auP59Jl6dJS1YAY3OUT5xfEKQ=@protonmail.com">
      <pre wrap="">Good morning JOSE,

</pre>
      <blockquote type="cite">
        <pre wrap=""> An offline device (say a vending machine) shares a secret S1 with an online LN Node.
</pre>
      </blockquote>
      <pre wrap="">
Is this the same problem that is solved by: <a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html</a> ?

I believe the solution presented at the summit is superior technology-wise.

1.  The offline device holds no secrets.  Hacking it (if somehow possible) is thus not incentivized.
2.  The offline device can verify the hashes it holds in memory come from its owner.  Invoices require a signature, and invoices include the payment hash.  A payment hash stored in the offline device is thus committed to in the signature of the invoice, and the invoice signature can be verified.
3.  It works as-is without additions to the BOLT spec or to current wallets.

The only problem is that the hash preimage is 32 bytes.
But if an invoice can acceptably be sent via QR code, why cannot hash preimages also?
(it may simplify the design of the vending machine, which now needs only present a standard keypad for a PIN)

6-digit decimal codes may be acceptable.
Given about 1 second to enter 6 digits (superhuman speed) it would take about 6 days or so to go through about half the space of 6-digit decimal codes.
Perhaps the vending machine can simply delay if too many failing 6-digit decimal codes are entered.
At the same time, it is easier for meat-based humans to remember and enter a mere 6-digit decimal code.


Perhaps a compromise is possible.

Let me propose this instead, which again *requires no changes to BOLT spec or special changes in wallet implementations*.

1.  The online LN node prepares a set of invoices.
    * The first 6 hexadecimal digits of the preimages are restricted to the set of decimal digits (or just put 6 more keys into your keypad, of course meat-based humans can understand letters too).
    * The succeeding 58 digits of the preimage are a salt.
2.  The offline vending machine stores the payment hash, salt, and invoice signature from the online LN node.
3.  When a customer arrives and indicates desire to purchase, the offline vending machine presents one of the unclaimed invoices.
4.  Upon paying, the vending machine instructs the customer to enter the first 6 digits of the payment preimage.
5.  The vending machine looks through its list of unclaimed invoices to find one where the 6 digits, concatenated with the salt, hash to the given payment hash.
    * If so, it marks that invoice as used and dispenses the product.
    * Otherwise, it is a failure and the vending machine will delay.


Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>