[Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Dec 20 10:05:10 UTC 2018


Good morning Jose,



> 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.

This is badly undesirable.
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.

>
> 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.

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?

Each product sold is one invoice claimed.
Thus, replenishing of products, is same operation as replenishing of invoices.
You have to open the vending machine anyway to replenish its stock of products for sale.
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.
Even tiny EEPROM chip can hold enough data to support thousands of invoices.
And it is unlikely you would fill a vending machine with thousands of product.

>
> 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.

Why would you sell products with widely fluctuating BTC value?
We sell products with a fixed BTC value!
And because BTC is deflationary, BTC value of product will never change.
We can see very readily that BTC price relative to dollar does not change except for dollar inflation rate and there is no such thing as massive bear market.

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.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001602.html

>
> 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.


>
> 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.

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.


(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.)

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list