{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-11-01\n📝 Original message:\nHi all,\n\n        There's been some discussion of what the lightning payment flow\nmight look like in the future, and I thought I'd try to look forwards so\nwe can avoid painting ourselves into a corner now.  I haven't spent time\non concrete design and implementation to be sure this is correct,\nhowever.\n\nCurrent Status\n--------------\nCurrently, one invoice can be paid 0 or 1 times.  There is no safe\ninvoice reuse.  The payer can prove the node offered the invoice (it is\nsigned), and that someone paid the invoice, but not that they\nspecifically did: the lightning nodes along the path and the merchant\nthemselves also have the preimage.  This implies that the invoice itself\nshould have enough information to make that link, eg. with a description\nof \"1 T-shirt to Rusty in Australia\", otherwise the payer can say \"here,\nI paid for 1 T-shirt\" and the merchant says \"no, that invoice was for a\nT-shirt we shipped to Austria\".\n\nDesired Status\n--------------\nIdeally, you could create one invoice which could be paid arbitrary many\ntimes, by different individuals.  eg. \"My donation invoice is on my web\npage\", or \"I've printed out the invoice for a widget and stuck it to the\nwidget\", or \"Pay this invoice once a month please\".\n\nAlso, you should be able to prove you've paid, in a way I can't just\ncopy the proof and claim I paid, too, even if I'm the merchant, and that\nyou agreed to my terms, eg. \"I'm paying for 500 widgets to be shipped to\nRusty in Australia\".\n\nRequired Magic\n--------------\nIt seems that scriptless scripts will allow this: an HTLC signature\nwould commit to the invoice/\"payment_hash\" as well as \"something I sent\nto you in the payment onion\".  That \"something\" has to be well-defined\nin the protocol, of course, since the merchant will have to parse it and\nunderstand the conditions it presents before accepting the payment.  I\nhave an idea that we could merkelize the information to allow you to\npartially reveal it if you wanted to.\n\nThis also enables full AMP (I think), where you receive the payment\nproof despite using AMP.  I call this \"High AMP\" vs the current proposal\n(\"Low AMP\") which trusts the merchant to deliver.\n\nThis is a subtle change in semantics: currently the lightning layer only\nprovides assistance metadata (eg. routing), and the entire protocol can\nbe played out onchain.  This is no longer true: the onchain data is not\nsufficient for you to accept a payment.  However, this was practically\nuntrue anyway.\n\nLesser Magic\n------------\nIt's possible to do spontaneous donations *without* proof of payment\ntoday (I simply give you the preimage in the onion).  Low-AMP relies on a\nsimilar trick.\n\nIt's even possible to do recurring payments, if each preimage you get is\nthe payment_hash for the next payment.\n\nNone of this is supported in the 1.0 protocol, but I'm sure we'll have\nvigorous debate over how much of this gets into 1.1 at the Summit next\nweek.\n\nCheers,\nRusty."}