{"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-02\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:\n\u003e\u003e         There's been some discussion of what the lightning payment flow\n\u003e\u003e might look like in the future, and I thought I'd try to look forwards so\n\u003e\u003e we can avoid painting ourselves into a corner now.  I haven't spent time\n\u003e\u003e on concrete design and implementation to be sure this is correct,\n\u003e\u003e however.\n\u003e\n\u003e I think I'd like to see v1.1 of the lightning spec include\n\u003e experimental/optional support for using secp256k1 public/private keys\n\u003e for payment hashes/preimages. That assumes using either 2-party ECDSA\n\u003e magic or script magic until it's viable to do it via Schnorr scriptless\n\u003e scripts, but that seems like it's not totally infeasible?\n\nNot totally infeasible, but since every intermediary needs to support\nit, I think we'd need considerable buy-in before we commit to it in 1.1.\n\n\u003e I think the\n\u003e components would need to be:\n\u003e\n\u003e  - invoices: will the preimage for the hash be a secp256k1 private key\n\u003e    or a sha256 preimage? (or payer's choice?)\n\n\u003eFrom BOLT11:\n\n   The `p` field supports the current 256-bit payment hash, but future\n   specs could add a new variant of different length, in which case\n   writers could support both old and new, and old readers would ignore\n   the one not the correct length.\n\nSo the plan would be you provide two `p` fields in transition.\n\n\u003e  - channel announcements: do you support secp256k1 for hashes or just\n\u003e    sha256?\n\nWorse, it becomes \"I support secp256k1 with ECDSA\" then a new \"I support\nsecp256k1 with Schnorr\".  You need a continuous path of channels with\nthe same feature.\n\n\u003e  - node features: how do you support secp256k1? not at all (default),\n\u003e    via 2p-ecdsa, via script magic, (eventually) via schnorr, ...?\n\nWe could make these global feature bits, if you want to preferentually\nestablish channels with nodes who support a specific feature.\n\n\u003e I think this is (close to) a necessary precondition for payment\n\u003e decorrelation, AMP, and third-party verifiable proof-of-payment.\n\nYes, that's the easy part :)\n\n...\n\u003e Even if you calculate r differently, I don't think you can do this\n\u003e without Bob and Alice interacting to get the nonce R prior to sending\n\u003e the transaction, which seems effectively the same as having dynamic\n\u003e invoice hashes, though.\n\nI know Andrew Poelstra thought it was possible, so I'm going to leave a\nresponse to him :)\n\n\u003e Maybe querying for a nonce through the lightning network would make\n\u003e sense though, which would allow the \"invoice\" to be static, and all the\n\u003e dynamic things would be via lightning p2p? That step could perhaps be\n\u003e combined with the 0 satoshi payment probes that Fabrice proposes in\n\u003e\n\u003e  https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html\n\u003e\n\u003e but I think replying with a public nonce value would need a new message\n\u003e type of some sort?\n\nWe might eventually end up going full HORNET, for other reasons.  But it\nplaces demands on the network which need careful consideration, and the\nmore traffic you send the more chances for analysis.  A single pass is\nenough.\n\n\u003e I think AMP is independent, other than also using secp256k1 preimages\n\u003e rather than SHA256. I think AMP splits and joins are just:\n\u003e\n\u003e  - if you're joining incoming payments, don't forward until you've\n\u003e    got all the HTLCs, and ensure you can generate the secret for each\n\u003e    incoming payment from the single outgoing payment\n\u003e\n\u003e  - if you're splitting an incoming payment into many outgoing payments,\n\u003e    ensure you can claim the incoming payment from *any* outgoing\n\u003e    payments' secret\n\u003e\n\u003e Which I think in practice just means knowing x_i for each input, and\n\u003e y_j for each output other than the first, and verifying:\n\u003e\n\u003e     I_i = O_1 + x_i*G\n\u003e     O_j = O_1 + y_j*G\n\u003e\n\u003e (this gives I_i = O_j + (x_i-y_j)*G and the corresponding secret being\n\u003e i_i = o_j + x_i - y_j) allowing you to claim all incoming HTLCs given\n\u003e the secret from any outgoing HTLC)\n\nI think a general scheme is: payer creates a random group-marker, sends\n\u003cgroup-marker\u003e\u003c32-byte-randomness\u003e[encrypted data...] in each payment.\nReceipient collects payments by \u003cgroup-marker\u003e, xoring the\n\u003c32-byte-randomness\u003e; if that xor successfully decrypts the data, you've\ngot all the pieces.\n\n(For low-AMP, you use payment_hash as \u003cgroup-marker\u003e, and just use\nSHA256(\u003cxor-of-all-randomness\u003e\u003c32-byte-randomness\u003e) as the per-payment\npreimage so no [encrypted data] needed).\n\nCheers,\nRusty."}