{"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-04\n📝 Original message:\nOn Sun, Nov 04, 2018 at 01:30:48PM +1030, Rusty Russell wrote:\n\u003e I'm not sure.  Jonas Nick proposed a scheme, which very much assumes\n\u003e Schnorr AFAICT:\n\u003e Jonas Nick wrote:\n\u003e \u003e How I thought it would work is that the invoice would contain a\n\u003e \u003e Schnorr nonce R.\n\n(Note this means the \"invoice\" must be unique for each payment)\n\n\u003e \u003e Then the payer would construct s*G = R +\n\u003e \u003e H(payee_pubkey,R,\"I've bought 5 shirts shipped to Germany\")*G. Then\n\u003e \u003e the payer builds the scriptless script payment path such that when the\n\u003e \u003e payee claims, the payer learns s and thus has a complete\n\u003e \u003e signature. However, that doesn’t work with recurrent payments because\n\u003e \u003e the payee can use the nonce only once.\n\nSo that's totally fine to do however you receive the \"s\" value -- the\nmessage that's getting the Schnorr signature isn't a valid bitcoin\ntransaction, so it's something that only needs to be validated by\nBOLT-aware courts.\n\n\nI also think you can get recurrent payments easily by extending the\nverification algorithm. Basically instead of Verify(m,P,sig) have\nVerify(m,P,n,sig) to verify you've made n payments of the invoice \"m\".\n\nConstruct \"m\" to include the postimage X = H(pre,1000) which indicates\n\"pre\" has been hashed 1000 times, so X = H(H(pre,1000-n),n).\n\nCalculate the original signature as:\n\n   s = r + H(P,R,m+X)*p\n\nand verify that n payments have been made by checking:\n\n   Verify(m,P,n,(s,R,rcpt)) :: s*G = R + H(P,R,m+H(rcpt,n))*P\n\nYou'd provide s,R,X when setting up the subscription, then reveal the\npreimage to X, the preimage to the preimage of X etc on each payment.\n(Maybe shachain would work here?)\n\nI think that approach is independent of using sha256/secp256k1 for\npreimages over lightning too.\n\n\u003e I would probably enhance this to include a nonce, which allows for AMP\n\u003e (you have to xor the AMP payments to get the nonce):\n\u003e R + H(payee_pubkey,R,\"I've bought 5 shirts shipped to Germany\",NONCE)*G\n\nR is already a unique nonce under the hash here, so I don't think a\nsecond one adds any value fwiw.\n\n\u003e \u003e I think it makes sense to think of proof-of-payment in terms of a\n\u003e \u003e verification algorithm (that a third party court could use), that takes:\n\u003e \u003e\n\u003e \u003e   m - the invoice details, eg\n\u003e \u003e       \"aj paid $11 for stickers to be delivered to Australia\"\n\u003e \u003e   P - the pubkey of the vendor\n\u003e \u003e   sig - some signature\n\u003e \u003e\n\u003e \u003e With the current SHA256 preimages, you can make sig=(R,s,pre)\n\u003e \u003e where the sig is valid if:\n\u003e \u003e\n\u003e \u003e   s*G = R + H(P,R,m+SHA256(pre))*P\n\u003e \u003e\n\u003e \u003e If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have\n\u003e \u003e a valid signature if they pay to SHA256(pre). That's a 96B signature,\n\u003e \u003e and it requires \"pre\" be different for each sale, and needs pre-payment\n\u003e \u003e interactivity to agree on m and communicate R,s back to the payer.\n\u003e For current-style invoices (no payer-supplied data), the payee knows\n\u003e 'm', so no interactivity needed, which is nice.\n\nI'm looking at it as needing interactivity to determine m prior to\nthe payment going through -- the payer needs to send through \"aj\" and\n\"Australia\" in the example above, before the payee can generate s,R to\nsend back, at which point the payer can make the payment knowing they'll\neither get a cryptographic proof of payment or a refund.\n\n\u003e In the payer-supplied data case, I think 'm' should include a signature\n\u003e for a key only the payer knows: this lets them prove *they* made the\n\u003e payment.\n\nI don't object to that, but I think it's unnecessary; as long as there\nwas a payment for delivery of the widget to \"aj\" in \"Australia\" does it\nmatter if the payment was technically made by \"aj\" by \"Visa on behalf\nof aj\" or by \"Bank of America on behalf of Mastercard on behalf of aj's\nfriend who owed him some money\" ?\n\n\u003e How does this interact with AMP, however?\n\nThe way I see it is they're separate: you have a way of getting the\npreimage back over lightning (which is affected by AMP), and you have a\nway of turning a preimage into a third-party-verifiable PoP (with\nSchnorr or whatever).\n\n(That might not be true if there's a clever way of safely feeding the\nnonce R back, so that you can go straight from a generic offer to an\naccepted payment with proof of payment)\n\n\u003e \u003e With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),\n\u003e \u003e and needing to communicate an R to the payer initially, who can then\n\u003e \u003e calculate S and send \"m\" along with the payment.\n\u003e OK, I buy that.\n\nCrap, do I need to give you proof of payment for it now? :)\n\n\u003e \u003e Maybe it makes sense to disambiguate the term \"invoice\" -- when you don't\n\u003e \u003e know who you might be giving the goods/service to, call it an \"offer\",\n\u003e \u003e which can be a write-once/accept-by-anyone deal that you just leave on\n\u003e \u003e a webpage or your email signature; but an \"invoice\" should be specific\n\u003e \u003e to each individual payment, with a \"receipt\" provided once an invoice\n\u003e \u003e is paid.\n\u003e \"offer\" is a good name, since I landed on the same one while thinking\n\u003e about this too :)\n\nYay!\n\n\u003e \u003e It seems to me like there are three levels that could be implemented:\n\u003e \u003e\n\u003e \u003e  - laolu/conner: (\"low AMP\" ?)\n\u003e \u003e     works with sha256\n\u003e \u003e     some privacy improvement\n\u003e \u003e     loses proof-of-payment\n\u003e \u003e     can't claim unless all payments arrive\n\u003e \n\u003e Yep.\n\u003e \n\u003e \u003e  - just send multiple payments with the same hash:\n\u003e \u003e     works with sha256\n\u003e \u003e     privacy not improved much (some intermediary nodes no longer know\n\u003e \u003e       full invoice value)\n\u003e \u003e     can claim partial payments as soon as they arrive\n\u003e \u003e     accepting any partial payment provides proof-of-payment\n\u003e \n\u003e Interestingly, if vendor takes part payment, rest can be stolen by\n\u003e intermediaries.\n\nOr you could just see a $5 bill, send $0.50 through, and wait to see\nif the take the partial payment immediately before even trying the\nremaining $4.50.\n\n\u003e \u003e  - secp256k1: (\"high AMP\" ?)\n\u003e \u003e     needs secp256k1 preimages\n\u003e \u003e     works fine with decorrelation improving privacy at every step\n\u003e \u003e     can set it up so can only claim once all partial payments arrive\n\u003e \u003e     accepting partial payment provides proof-of-payment\n\u003e Yes.  Though I'm not sure exactly how this works with your scheme\n\u003e above...\n\n Vendor -\u003e *:        \"I sell widgets for 0.01 BTC, my pubkey is P\"\n Customer -\u003e Vendor: \"I want to buy a widget\"\n Vendor -\u003e Customer: \"Here's an R value\"\n Customer: calculates S = R + H(P,R,\"send $me a widget at $address\")*P\n Customer -\u003e Vendor: \"here's 0.01 BTC for s corresponding to S, my\n                      details are R, $me, $address\"\n Vendor: looks up r for R=r*G, calculates s = r + H(P,R,\"send $me a\n         widget at $address\")*p, checks S=s*G\n Vendor -\u003e Customer: \u003caccepts payment, revealing s\u003e\n\n Customer -\u003e Court: reveals the invoice (\"send $me a widget...\") and the\n                    signature by Vendor's pubkey P, (s,R)\n\nI think the way to do secp256k1 AMP with that is that when sending\nthrough the payment is for the customer to send three payments to the\nVendor conditional on preimages for A,B,C calculated as:\n\n   A = S + H(1,secret)*G\n   B = S + H(2,secret)*G\n   C = S + H(3,secret)*G\n\nwhere \"secret\" is your xor of info from each of the three message hashes.\n\n\u003e \u003e In theory, both \"just send multiple payments\" and \"secp256k1\" could have\n\u003e \u003e splitting and joining at any hop, if we could encode the instructions\n\u003e \u003e on how to do that in the onion message; joining is probably easy, but\n\u003e \u003e splitting seems like it might be hard?\n\u003e I don't think so.  If you can join two payments, it wasn't private?\n\nSorry, I mean \"source-directed splits and joins\", so rather than\nyour source routing being a linear \"me -\u003e A -\u003e B -\u003e C -\u003e D -\u003e you\",\nyou specify a graph: \"me -\u003e A -\u003e B,E ; B -\u003e C ; E -\u003e F -\u003e G ; C,G -\u003e\nD -\u003e you\" so you tell \"A\" how to split the payment into two new routes,\nand tell \"D\" to join two payments and continue it on. The ECC part works\nfine for that, but the onion routed messages seem difficult and probably\nnot worth considering for spec v1.1.\n\n\u003e Note: if we need an interaction message for BOLT11 features we want in\n\u003e future[1], then it has the advantage that it decouples the bolt11\n\u003e features from changing preimages to secp256k1.  That makes this question\n\u003e *critical* for the Summit next week.\n\u003e \n\u003e Thanks!\n\u003e Rusty.\n\u003e \n\u003e [1] If we're not careful we're going to implement HORNET so we can pass\n\u003e arbitrary messages around, which means we want to start charging for\n\u003e them to prevent spam, which means we reopen the pre-payment debate, and\n\u003e need reliable error messages...\n\nCould leave the interactivity to the \"web store\" layer, eg have a BOLT\n11 v1.1 \"offer\" include a url for the website where you go an enter your\nname and address and whatever other info they need, and get a personalised\nBOLT 11 v1.1 \"invoice\" back with payment-hash/nonce/signature/whatever?\n\nCheers,\naj"}