{"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-04\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e\u003e \u003e  - channel announcements: do you support secp256k1 for hashes or just\n\u003e\u003e \u003e    sha256?\n\u003e\u003e Worse, it becomes \"I support secp256k1 with ECDSA\" then a new \"I support\n\u003e\u003e secp256k1 with Schnorr\".  You need a continuous path of channels with\n\u003e\u003e the same feature.\n\u003e\n\u003e I don't think that's correct: whether it's 2p-ecdsa, Schnorr or script\n\u003e magic only matters for the two nodes directly involved in the channel\n\u003e (who need to be able to understand the commitment transactions they're\n\u003e signing, and extract the private key from the on-chain tx if the channel\n\u003e gets unilaterally closed). For everyone else, they just need to know that\n\u003e they can put in a public key based HTLC, and get back the corresponding\n\u003e private key when the HTLC goes through.\n\nI'm not sure.  Jonas Nick proposed a scheme, which very much assumes\nSchnorr AFAICT:\n\nJonas Nick wrote:\n\u003e How I thought it would work is that the invoice would contain a\n\u003e Schnorr nonce R. Then the payer would construct s*G = R +\n\u003e H(payee_pubkey,R,\"I've bought 5 shirts shipped to Germany\")*G. Then\n\u003e the payer builds the scriptless script payment path such that when the\n\u003e payee claims, the payer learns s and thus has a complete\n\u003e signature. However, that doesn’t work with recurrent payments because\n\u003e the payee can use the nonce only once.\n\nI would probably enhance this to include a nonce, which allows for AMP\n(you have to xor the AMP payments to get the nonce):\n\nR + H(payee_pubkey,R,\"I've bought 5 shirts shipped to Germany\",NONCE)*G\n\n\u003e I think it makes sense to think of proof-of-payment in terms of a\n\u003e verification algorithm (that a third party court could use), that takes:\n\u003e\n\u003e   m - the invoice details, eg\n\u003e       \"aj paid $11 for stickers to be delivered to Australia\"\n\u003e   P - the pubkey of the vendor\n\u003e   sig - some signature\n\u003e\n\u003e With the current SHA256 preimages, you can make sig=(R,s,pre)\n\u003e where the sig is valid if:\n\u003e\n\u003e   s*G = R + H(P,R,m+SHA256(pre))*P\n\u003e\n\u003e If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have\n\u003e a valid signature if they pay to SHA256(pre). That's a 96B signature,\n\u003e and it requires \"pre\" be different for each sale, and needs pre-payment\n\u003e interactivity to agree on m and communicate R,s back to the payer.\n\nFor current-style invoices (no payer-supplied data), the payee knows\n'm', so no interactivity needed, which is nice.\n\nIn the payer-supplied data case, I think 'm' should include a signature\nfor a key only the payer knows: this lets them prove *they* made the\npayment.\n\nHow does this interact with AMP, however?\n\n\u003e With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),\n\u003e and needing to communicate an R to the payer initially, who can then\n\u003e calculate S and send \"m\" along with the payment.\n\nOK, I buy that.\n\n\u003e Maybe it makes sense to disambiguate the term \"invoice\" -- when you don't\n\u003e know who you might be giving the goods/service to, call it an \"offer\",\n\u003e which can be a write-once/accept-by-anyone deal that you just leave on\n\u003e a webpage or your email signature; but an \"invoice\" should be specific\n\u003e to each individual payment, with a \"receipt\" provided once an invoice\n\u003e is paid.\n\n\"offer\" is a good name, since I landed on the same one while thinking\nabout this too :)\n\nFor an \"offer\" you would need a (lightning-network-carried) req/resp to\nget the per-payment invoice.  An offer could use a 128-bit 'p': smaller\nwould do, but this is too large to brute-force iterate through (hey, I\nwonder if they sell other stuff?).\n\n\u003e Rereading through the AMP threads, Christian's post makes a lot of sense\n\u003e to me:\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001023.html\n\u003e\n\u003e I'm not really seeing the benefits in complicated AMP schemes without\n\u003e decorrelation...\n\nIn practice it should increase reliability of payments through capacity\nbottlenecks.  But don't underestimate the benefits of PoP: we're so used\nto intermediates we take it for granted, but once the middleman is\nremoved the ability to prove the invoice/payment cycles is vital for\nusability.\n\n\u003e It seems to me like there are three levels that could be implemented:\n\u003e\n\u003e  - laolu/conner: (\"low AMP\" ?)\n\u003e     works with sha256\n\u003e     some privacy improvement\n\u003e     loses proof-of-payment\n\u003e     can't claim unless all payments arrive\n\nYep.\n\n\u003e  - just send multiple payments with the same hash:\n\u003e     works with sha256\n\u003e     privacy not improved much (some intermediary nodes no longer know\n\u003e       full invoice value)\n\u003e     can claim partial payments as soon as they arrive\n\u003e     accepting any partial payment provides proof-of-payment\n\nInterestingly, if vendor takes part payment, rest can be stolen by\nintermediaries.  This puts pressure on vendor to treat them atomically.\nI haven't thought about this before, but it has desirable attributes.\n(If the contract is \"you will only release preimage once you've got the\npayment\", all this requires is a single bit to say \"I know this is\npartial, more are coming, please wait\").\n\n\u003e  - secp256k1: (\"high AMP\" ?)\n\u003e     needs secp256k1 preimages\n\u003e     works fine with decorrelation improving privacy at every step\n\u003e     can set it up so can only claim once all partial payments arrive\n\u003e     accepting partial payment provides proof-of-payment\n\nYes.  Though I'm not sure exactly how this works with your scheme\nabove...\n\n\u003e In theory, both \"just send multiple payments\" and \"secp256k1\" could have\n\u003e splitting and joining at any hop, if we could encode the instructions\n\u003e on how to do that in the onion message; joining is probably easy, but\n\u003e splitting seems like it might be hard?\n\nI don't think so.  If you can join two payments, it wasn't private?  For\nsplitting, in the specific case of having two channels between the same\nnodes, you might be able to do something, but that's a pretty narrow\ncase.  And as TCP discovered, you're better off failing back to sender\nthan trying to add fragmentation to the protocol.\n\nNote: if we need an interaction message for BOLT11 features we want in\nfuture[1], then it has the advantage that it decouples the bolt11\nfeatures from changing preimages to secp256k1.  That makes this question\n*critical* for the Summit next week.\n\nThanks!\nRusty.\n\n[1] If we're not careful we're going to implement HORNET so we can pass\narbitrary messages around, which means we want to start charging for\nthem to prevent spam, which means we reopen the pre-payment debate, and\nneed reliable error messages..."}