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