{"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-03\n📝 Original message:\nOn Fri, Nov 02, 2018 at 03:45:58PM +1030, Rusty Russell wrote:\n\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e \u003e On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:\n\u003e \u003e\u003e         There's been some discussion of what the lightning payment flow\n\u003e \u003e\u003e might look like in the future, and I thought I'd try to look forwards so\n\u003e \u003e\u003e we can avoid painting ourselves into a corner now.  I haven't spent time\n\u003e \u003e\u003e on concrete design and implementation to be sure this is correct,\n\u003e \u003e\u003e however.\n\u003e \u003e I think I'd like to see v1.1 of the lightning spec include\n\u003e \u003e experimental/optional support for using secp256k1 public/private keys\n\u003e \u003e for payment hashes/preimages. That assumes using either 2-party ECDSA\n\u003e \u003e magic or script magic until it's viable to do it via Schnorr scriptless\n\u003e \u003e scripts, but that seems like it's not totally infeasible?\n\u003e Not totally infeasible, but since every intermediary needs to support\n\u003e it, I think we'd need considerable buy-in before we commit to it in 1.1.\n\n\"every intermediary\" just means \"you have to find a path where every\nchannel supports it\"; nodes/channels that aren't in the route you choose\naren't a problem, and can still pass on the gossiped announcements,\nI think?\n\n\u003e \u003e I think the\n\u003e \u003e components would need to be:\n\u003e \u003e  - invoices: will the preimage for the hash be a secp256k1 private key\n\u003e \u003e    or a sha256 preimage? (or payer's choice?)\n\u003e From BOLT11:\n\u003e    The `p` field supports the current 256-bit payment hash, but future\n\u003e    specs could add a new variant of different length, in which case\n\u003e    writers could support both old and new, and old readers would ignore\n\u003e    the one not the correct length.\n\u003e So the plan would be you provide two `p` fields in transition.\n\nYeah, that sounds workable.\n\n\u003e \u003e  - channel announcements: do you support secp256k1 for hashes or just\n\u003e \u003e    sha256?\n\u003e Worse, it becomes \"I support secp256k1 with ECDSA\" then a new \"I support\n\u003e secp256k1 with Schnorr\".  You need a continuous path of channels with\n\u003e the same feature.\n\nI don't think that's correct: whether it's 2p-ecdsa, Schnorr or script\nmagic only matters for the two nodes directly involved in the channel\n(who need to be able to understand the commitment transactions they're\nsigning, and extract the private key from the on-chain tx if the channel\ngets unilaterally closed). For everyone else, they just need to know that\nthey can put in a public key based HTLC, and get back the corresponding\nprivate key when the HTLC goes through.\n\nIt's also (theoretically) upgradable afaics: if two nodes have a channel\nthat supports 2p-ecdsa, and eventually both upgrade to support segwit\nv1 scriptless schnorr sigs or whatever, they just need to change the\naddresses they use in new commitment txs, even for existing HTLCs.\n\n\u003e \u003e Even if you calculate r differently, I don't think you can do this\n\u003e \u003e without Bob and Alice interacting to get the nonce R prior to sending\n\u003e \u003e the transaction, which seems effectively the same as having dynamic\n\u003e \u003e invoice hashes, though.\n\u003e I know Andrew Poelstra thought it was possible, so I'm going to leave a\n\u003e response to him :)\n\nAFAICT, in general, if you're going to have n signatures with a public\nkey P, you need to generate the n R=r*G values from n*32B worth of random data,\nthat's previously unknown to the signature recipients. If you've got\nless than that, then you will have calculated each R by doing something\nlike based on \u003cn*32B of data you've been given:\n\n    R = a*R1 + b*R2 + ..\n\nand the n signatures you eventually receive will give you n simultaneous\nlinear equations along the lines of:\n\n    s = (a*r1 + b*r2 + c*r3 + ..) + H(..)*p\n\nwith \u003c= n unknowns (p and less than n r1,r2,.. values). (If you don't\nknown the values a,b,c you won't be able to calculate the R values for\nyour signatures in the first place)\n\nWilling to be surprised by a different approach, but I'm pretty\nskeptical...\n\n\nI think it makes sense to think of proof-of-payment in terms of a\nverification algorithm (that a third party court could use), that takes:\n\n  m - the invoice details, eg\n      \"aj paid $11 for stickers to be delivered to Australia\"\n  P - the pubkey of the vendor\n  sig - some signature\n\nWith the current SHA256 preimages, you can make sig=(R,s,pre)\nwhere the sig is valid if:\n\n  s*G = R + H(P,R,m+SHA256(pre))*P\n\nIf you share R,s,SHA256(pre) beforehand, the payer can tell they'll have\na valid signature if they pay to SHA256(pre). That's a 96B signature,\nand it requires \"pre\" be different for each sale, and needs pre-payment\ninteractivity to agree on m and communicate R,s back to the payer.\n\nWith seckp256k1 preimages, it's easy to reduce that to sig=(R,s),\nand needing to communicate an R to the payer initially, who can then\ncalculate S and send \"m\" along with the payment.\n\n\nMaybe it makes sense to disambiguate the term \"invoice\" -- when you don't\nknow who you might be giving the goods/service to, call it an \"offer\",\nwhich can be a write-once/accept-by-anyone deal that you just leave on\na webpage or your email signature; but an \"invoice\" should be specific\nto each individual payment, with a \"receipt\" provided once an invoice\nis paid.\n\n\nAMP:\n\n\u003e I think a general scheme is: payer creates a random group-marker, sends\n\u003e \u003cgroup-marker\u003e\u003c32-byte-randomness\u003e[encrypted data...] in each payment.\n\u003e Receipient collects payments by \u003cgroup-marker\u003e, xoring the\n\u003e \u003c32-byte-randomness\u003e; if that xor successfully decrypts the data, you've\n\u003e got all the pieces.\n\u003e \n\u003e (For low-AMP, you use payment_hash as \u003cgroup-marker\u003e, and just use\n\u003e SHA256(\u003cxor-of-all-randomness\u003e\u003c32-byte-randomness\u003e) as the per-payment\n\u003e preimage so no [encrypted data] needed).\n\nHmm, right, I've got decorrelation and AMP combined in my head. I'm also\na bit confused about what exactly you mean by \"low-AMP\"...\n\nRereading through the AMP threads, Christian's post makes a lot of sense\nto me:\n\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001023.html\n\nI'm not really seeing the benefits in complicated AMP schemes without\ndecorrelation...\n\nIt seems to me like there are three levels that could be implemented:\n\n - laolu/conner: (\"low AMP\" ?)\n    works with sha256\n    some privacy improvement\n    loses proof-of-payment\n    can't claim unless all payments arrive\n\n - just send multiple payments with the same hash:\n    works with sha256\n    privacy not improved much (some intermediary nodes no longer know\n      full invoice value)\n    can claim partial payments as soon as they arrive\n    accepting any partial payment provides proof-of-payment\n\n - secp256k1: (\"high AMP\" ?)\n    needs secp256k1 preimages\n    works fine with decorrelation improving privacy at every step\n    can set it up so can only claim once all partial payments arrive\n    accepting partial payment provides proof-of-payment\n\nIn theory, both \"just send multiple payments\" and \"secp256k1\" could have\nsplitting and joining at any hop, if we could encode the instructions\non how to do that in the onion message; joining is probably easy, but\nsplitting seems like it might be hard?\n\nCheers,\naj"}