ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-17 📝 Original message: Good morning JOSE, > An ...
📅 Original date posted:2018-12-17
📝 Original message:
Good morning JOSE,
> An offline device (say a vending machine) shares a secret S1 with an online LN Node.
Is this the same problem that is solved by: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html ?
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
📝 Original message:
Good morning JOSE,
> An offline device (say a vending machine) shares a secret S1 with an online LN Node.
Is this the same problem that is solved by: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001579.html ?
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