Open arcbtc opened 2 years ago
Bleskomat is very different. It's not using encrypted anything, it is using an HMAC to ensure the amount can be safely withdrawn. See https://github.com/fiatjaf/lnurl-rfc/pull/91.
Yes, Bleskomat works using HMAC signature for the withdrawRequest
but the workflow described here can be used to integrate payRequest
with the offline device.
I think it would be a great improvement in the way LNURLPoS works right now and for similar workflow projects if there would be something like successMessage
sent from the LN Service
to the LN WALLET
after point 9 described in LUD06 - Wallet to service interaction flow
So when LN Service
verifies the invoice has been paid it responds to the LN WALLET
with the decrypted pin (or potentially other data), and then the LN WALLET
displays it to the user. Making not necessary to have a web page that will show the decrypted pin once the payment is done.
The Bleskomat concept is similar, in that it uses a secret to prove the LNURL was generated from a legitimate source. I'm sure these projects can find a common workflow so a generic standard can be added to LNURL.
I'm looking forward to using the improved successaction workflow once it has greater support across wallets
One problem I see with the idea of displaying arbitrary data is it's an attack vector for phishing. ("Upgrade the wallet to receive the token") A pretty good solution would be to just enforce that the wallet displays it either as hex or decimal number. Thus any text would be scrambled and unreadable for common user.
There's another problem which I disclosed to @arcbtc privately. Since he said the code is not used in the wild, I'm thinking of publishing it.
Please do, although can you wait until we have patched. If creating a standard Bleskomat and LNURLPoS/LNURLVend can share involves a change to how we encrypt the pin, the benefit will far outweigh any inconvenience
OK, I'll wait. Please ping me once it's patched.
I'm not seeing these benefits. What are the benefits? If OpenNode wants to support LNURLPoS why can't it just implement the LNURLPoS backend? Bleskomat is completely unrelated.
I'm not seeing these benefits. What are the benefits? If OpenNode wants to support LNURLPoS why can't it just implement the LNURLPoS backend? Bleskomat is completely unrelated.
There is benefit to creating a standard for a common and useful design pattern - especially one involving cryptographic functions. It's better than having a bunch of slightly different implementations floating around each with their own potential vulnerabilities. One standard that has been well tested and vetted by many eyes - that's desirable.
And the current iteration of Bleskomat uses only an HMAC to secure the signed lnurl-withdraw flow. But we could implement a similar flow as the LnurlPOS or LnurlVend using a signed lnurl-pay with encrypted PIN. This can make all kinds of offline hardware possible using Lightning.
Exactly, cryptography can be very subtle and very dangerous to implement without review and experience.
LNURLPoS and LNURLVend encrypt a pin on each payment, which is passed to server through an LNURL-pay, then decrypted and sent back in the receipt upon completion of payment. The crypto was elegantly written by @stepansnigirev and using readily available bitcoin crypto.
On LNURLPoS the encrypted pin is added to LNURL here: https://github.com/arcbtc/LNURLPoS/blob/40cb199c4599d9f6c64b7e372a5c7938b75a83f0/LNURLPoS/LNURLPoS.ino#L232
On LNbits server side, it is decrypted and sent back as a receipt here: https://github.com/lnbits/lnbits-legend/blob/a2bb34060102d049e07766436359e9526e3d8aab/lnbits/extensions/lnurlpos/lnurl.py#L37
Bleskomat uses practically the same method, but for LNURL-withdraws and their offline ATM.
If we made encrypting a confirmation pin and passing through LNURL, then sending back decrypted pin in the receipt, part of the LNURL protocol, then a service like OpenNode could support it directly and LNURLPoS, LNURLVend, Bleskomat, etc would be compatible native with their platform.