{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-11-02\n📝 Original message:\nOn Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:\n\u003e         There's been some discussion of what the lightning payment flow\n\u003e might look like in the future, and I thought I'd try to look forwards so\n\u003e we can avoid painting ourselves into a corner now.  I haven't spent time\n\u003e on concrete design and implementation to be sure this is correct,\n\u003e however.\n\nI think I'd like to see v1.1 of the lightning spec include\nexperimental/optional support for using secp256k1 public/private keys\nfor payment hashes/preimages. That assumes using either 2-party ECDSA\nmagic or script magic until it's viable to do it via Schnorr scriptless\nscripts, but that seems like it's not totally infeasible? I think the\ncomponents would need to be:\n\n - invoices: will the preimage for the hash be a secp256k1 private key\n   or a sha256 preimage? (or payer's choice?)\n - channel announcements: do you support secp256k1 for hashes or just\n   sha256?\n - node features: how do you support secp256k1? not at all (default),\n   via 2p-ecdsa, via script magic, (eventually) via schnorr, ...?\n\nI think this is (close to) a necessary precondition for payment\ndecorrelation, AMP, and third-party verifiable proof-of-payment.\n\n\u003e Desired Status\n\u003e --------------\n\u003e Ideally, you could create one invoice which could be paid arbitrary many\n\u003e times, by different individuals.  eg. \"My donation invoice is on my web\n\u003e page\", or \"I've printed out the invoice for a widget and stuck it to the\n\u003e widget\", or \"Pay this invoice once a month please\".\n\u003e \n\u003e Also, you should be able to prove you've paid, in a way I can't just\n\u003e copy the proof and claim I paid, too, even if I'm the merchant, and that\n\u003e you agreed to my terms, eg. \"I'm paying for 500 widgets to be shipped to\n\u003e Rusty in Australia\".\n\nSo, I think at a high level the logic here goes:\n\n  1. Alice: \"Buy a t-shirt from me for $5!\"\n  2. Bob: \"Alice, I want to buy a t-shirt from you, here's $5\"\n  3. Alice: \"Receipt: Bob bought a t-shirt from me\"\n  4. Bob: \"Your Honour, here's my receipt from Alice for a t-shirt, please\n     make her deliver on it!\"\n\nGoing backwards; for the last step to be useful, the receipt has to be\na signature with the Alice's public key -- if it were anything short of\nthat, Alice will claim Bob could have just made up all the numbers. For a\nSchnorr sig, that means (R,s) with the vendor choosing R and not revealing\nR's preimage as that would reveal their private key.\n\nIf both vendor and customer know R, then to get the signature, you need\nthe private key holder to reveal s which is just revealing the secp256k1\nprivate key corresponding to S, calculated as:\n\n    S = R + H(P,R,\"Bob bought a $5 t-shirt from me\")*P\n\nwhere P is Alice's public key. If R is calculated via the Schnorr BIP's\nrecommendation, then r = H(p, \"Bob bought a $5 t-shirt from me\") -- ie,\nbased on the private key and the message being signed.\n\nEven if you calculate r differently, I don't think you can do this\nwithout Bob and Alice interacting to get the nonce R prior to sending\nthe transaction, which seems effectively the same as having dynamic\ninvoice hashes, though.\n\nMaybe querying for a nonce through the lightning network would make\nsense though, which would allow the \"invoice\" to be static, and all the\ndynamic things would be via lightning p2p? That step could perhaps be\ncombined with the 0 satoshi payment probes that Fabrice proposes in\n\n https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html\n\nbut I think replying with a public nonce value would need a new message\ntype of some sort?\n\n\n\nI think AMP is independent, other than also using secp256k1 preimages\nrather than SHA256. I think AMP splits and joins are just:\n\n - if you're joining incoming payments, don't forward until you've\n   got all the HTLCs, and ensure you can generate the secret for each\n   incoming payment from the single outgoing payment\n\n - if you're splitting an incoming payment into many outgoing payments,\n   ensure you can claim the incoming payment from *any* outgoing\n   payments' secret\n\nWhich I think in practice just means knowing x_i for each input, and\ny_j for each output other than the first, and verifying:\n\n    I_i = O_1 + x_i*G\n    O_j = O_1 + y_j*G\n\n(this gives I_i = O_j + (x_i-y_j)*G and the corresponding secret being\ni_i = o_j + x_i - y_j) allowing you to claim all incoming HTLCs given\nthe secret from any outgoing HTLC)\n\nCheers,\naj"}