[Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets
ZmnSCPxj at protonmail.com
Sat Dec 22 14:38:21 UTC 2018
Good morning Jose,
> 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.
I imagine even a cheap EEPROM can contain several hundred thousand invoices.
And you will want to regularly do checkups on your machines anyway, so you might as well replenish invoices at each checkup.
> > 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.
Whatever you may call them.
They open the machine, they put things in it.
Adding an instruction "remove this thing from the slot, then replace with this thing, press this internal button to see if it got inserted properly" is not so hard.
> > 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?
Yes, in A Few Years (hint: longer than you think).
Moving to points and scalars would let us use hierarchical derivation, where the offline machine would contain only the root pubkey (point), while the online Lightning node would contain the root privkey (scalar).
This would not require any storage of invoices in the offline machine.
More information about the Lightning-dev