Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-01 📝 Original message: Hi all, There's been some ...
📅 Original date posted:2018-11-01
📝 Original message:
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.
📝 Original message:
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.