rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 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.