### 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!

#### Exceprt

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.