[Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets
Jose Femenías Cañuelo
jose.femenias at gmail.com
Fri Dec 21 16:10:18 UTC 2018
These next two messages come out of order. One was scrubbed by the list (html), the other I sent inadvertently only in private to ZmnSCPxj.
I repost them here for completeness of the thread.
> Is this the same problem that is solved by: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html
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).
> I believe the solution presented at the summit is superior technology-wise.
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.
> 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
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).
> 3. It works as-is without additions to the BOLT spec or to current wallets.
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.
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.
Good morning ZmnSCPxj,
> We should have standard wallets that can talk to other standard-following software well.
> Modifications to wallets are dangerous in many ways, as well as greatly increasing effort overall.
Fully agreed; that is why I said it is vital to have standards.
> Do your vending machines generate product out of quantum foam, like I sometimes do on a boring afternoon?
> Or are they replenished as they run out of product?
I wish they could ;-)
Not all machines sell products. Some sell services: Arcade machines, Toll booths, etc., are examples of machines that provide a service instead of a physical product, where not having to replentish invoices ever is desirable.
> While your technician is replenishing the machine and doing whatever basic checks, your technician also replaces a EEPROM board with a new EEPROM board with fresh invoices.
True, but -in my experience at least- the person that replenishes the machine isn't usually a technician.
> Why would you sell products with widely fluctuating BTC value?
> We sell products with a fixed BTC value!
It isn't really me, I swear, I truly enjoy giving things away, particularly during Christmas... ;-)
However, some evil, greedy people have invented congestion pricing, to match price and demand (https://en.wikipedia.org/wiki/Congestion_pricing).
That is probably more fit for machines that sell services instead of products (say entry to a Zoo, car toll booths, ...) but I wouldn't rule out some evil machine owner linking the price of a Coke to the ambient temperature.
>> 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).
> Same as above.
My point with the static QR codes is not about price optimization (price gouging, one could say...).
It is more about minimizing the hardware requirements a machine needs to have in order to accept offline payments through LN.
While an arcade machine can be 'easily' reprogrammed to show a dynamic QR code with a new invoice for each game with no hardware modifications, there are other cases where the device has no obvious way to do that. I guess that will be much less of a problem in the future though.
> Will be fixed by payment decorrelation when we move to points and scalars.
> This will require either using `OP_CODESEPARATOR`, which is hard to understand, or waiting for Schnorr.
Wasn't aware of that, good to know. Are hash preimages dissapearing then?
> Note that what you want is not an invoice system.
> What you want is a static offer system.
> I suggest to look at Rusty proposal for static offers.
I'll have a look, thanks for the info.
> (incidentally, because I am actually a human being and not a machine superintelligence, in fact I am ***not*** capable of creating product out of quantum foam. by my understanding, this idea is what you humans call a joke.)
Don't sell yourself short! Judging by your work, I wouldn't dare to say that you are not superintelligent, machine or not... (this wasn't a joke)
Regards, again, thanks for your comments.
More information about the Lightning-dev