BOLT11 In the World of Scriptless Scripts
Last week Rusty Russell started a discussion on LN protocol V1.1, focusing on the new payment models it would bring with it, along with experimental support of new technologies, we discover those technologies with the applications they might bring to Lightning.
Lightning Network payments currently do not accurately model real world payments, some of the problems with the current Lightning payments are the lack of proof and the lack of multiple payments.
An invoice can be paid either 1 or 0 times, with no proof that a distinct node
paid this invoice, the lightning nodes along the path and the receiving node
all have the
preimage, so if there was any dispute between a buyer and a
merchant, the buyer has no proof that the payment came from him and the merchant
can claim that the payment came from another buyer and the product was sent.
Another problem is the lack of multiple payments, an invoice cannot be safely paid multiple times by different people and so the donation model or the recurrent payments model is not really easy, if at all possible, to implement.
The development of V1.1 of Lightning is starting and these payment models are on the list, the usage of scriptless scripts can allow an HTLC signature to commit the invoice as well as something like a signature from the buyer, for example, if Alice is selling something to Bob, Bob pays and Alice refuses to ship the item, but since Bob can now prove that he sent the payment, not anyone else, then a third party judge can make Alice send the product.
There are also discussions on including things like experimental secp256k1 public/private keys support for payment hashes/preimages , Schnorr Scriptless Scripts and other technologies, we’re really excited to see what V1.1 brings with it!
Rusty Russell Fri, 02 Nov 2018 18:31:44 -0700 Hi all, There's been some discussion of what the lightning payment flow might look like in the future, and I thought I'd try to look forwards so we can avoid painting ourselves into a corner now. I haven't spent time on concrete design and implementation to be sure this is correct, however. Current Status -------------- Currently, one invoice can be paid 0 or 1 times. There is no safe invoice reuse. The payer can prove the node offered the invoice (it is signed), and that someone paid the invoice, but not that they specifically did: the lightning nodes along the path and the merchant themselves also have the preimage. This implies that the invoice itself should have enough information to make that link, eg. with a description of "1 T-shirt to Rusty in Australia", otherwise the payer can say "here, I paid for 1 T-shirt" and the merchant says "no, that invoice was for a T-shirt we shipped to Austria". Desired Status -------------- Ideally, you could create one invoice which could be paid arbitrary many times, by different individuals. eg. "My donation invoice is on my web page", or "I've printed out the invoice for a widget and stuck it to the widget", or "Pay this invoice once a month please". Also, you should be able to prove you've paid, in a way I can't just copy the proof and claim I paid, too, even if I'm the merchant, and that you agreed to my terms, eg. "I'm paying for 500 widgets to be shipped to Rusty in Australia". Required Magic -------------- It seems that scriptless scripts will allow this: an HTLC signature would commit to the invoice/"payment_hash" as well as "something I sent to you in the payment onion". That "something" has to be well-defined in the protocol, of course, since the merchant will have to parse it and understand the conditions it presents before accepting the payment. I have an idea that we could merkelize the information to allow you to partially reveal it if you wanted to. This also enables full AMP (I think), where you receive the payment proof despite using AMP. I call this "High AMP" vs the current proposal ("Low AMP") which trusts the merchant to deliver. This is a subtle change in semantics: currently the lightning layer only provides assistance metadata (eg. routing), and the entire protocol can be played out onchain. This is no longer true: the onchain data is not sufficient for you to accept a payment. However, this was practically untrue anyway. Lesser Magic ------------ It's possible to do spontaneous donations *without* proof of payment today (I simply give you the preimage in the onion). Low-AMP relies on a similar trick. It's even possible to do recurring payments, if each preimage you get is the payment_hash for the next payment. None of this is supported in the 1.0 protocol, but I'm sure we'll have vigorous debate over how much of this gets into 1.1 at the Summit next week. Cheers, Rusty. link
Support us and the authors of this article by donating to the following address:3HnqnfNm6yj48WWbJnqLzFj9ruwS1Z7vBc