{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-07\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote:\n\u003e\u003e \u003e\u003e Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.\n\u003e\u003e \u003e\u003e ZmnSCPxj prepares the onion, but adds extra fields (see below).  \n\u003e\u003e \u003e It would have made more sense to me for Alice (Zmn) to generate\n\u003e\u003e \u003e the nonce, hash it, and prepare the onion, so that the nonce is\n\u003e\u003e \u003e revealed to Dave (Rusty) if/when the message ever actually reaches its\n\u003e\u003e \u003e destination. Otherwise Rusty has to send AAAAA to Zmn already so that\n\u003e\u003e \u003e Zmn can prepare the onion?\n\u003e\u003e The entire point is to pay *up-front*, though, to prevent spam.\n\u003e\n\u003e Hmm, I'm not sure I see the point of paying upfront but not\n\u003e unconditionally -- you already commit the funds as part of the HTLC,\n\u003e and if you're refunding some of them, you kind-of have to keep them\n\u003e reserved or you risk finalising the HTLC causing a failure because you\n\u003e don't have enough msats spare to do the refund?\n\n?  These are upfront an unconditional.  I'm confused.  You pay per\nHTLC added (or, in future, to send a message).\n\nWhat part was unclear here?\n\nAlice pays X to Bob.  Bob gives X-\u003cnum-preimages\u003e back to Alice.  Bob\ngets preimages from the onion, and from Carol etc.\n\nThis happens independent of HTLC success or failure.\n\n\u003e\u003e Bob/ZmnSCPxj doesn't prepare anything in the onion.  They get handed the\n\u003e\u003e last hash directly: Alice is saying \"I'll pay you 50msat for each\n\u003e\u003e preimage you can give me leading to this hash\".\n\u003e\n\u003e So my example was Alice paying Dave via Bob and Carol (so Alice/Bob,\n\u003e Bob/Carol, Carol/Dave being the individual channels).\n\u003e\n\u003e What you wrote to Zmn says \"Rusty decrypts the onion, reads the prepay\n\u003e field: it says 14, LLLL.\" but Alice doesn't know anything other than\n\u003e ZZZZ so can't put LLLL in the onion?\n\nAlice created the onion.  Alice knows all the preimages, since she\ncreated the chain AAAAA....ZZZZZ.\n\n\u003e\u003e \u003e I'm not sure why lucky hashing should result in a discount?\n\u003e\u003e Because the PoW adds noise to the amounts, otherwise the path length is\n\u003e\u003e trivially exposed, esp in the failure case.  It's weak protection\n\u003e\u003e though.\n\u003e\n\u003e With a linear/exponential relationship you just get \"half the time it's\n\u003e 1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units\", so\n\u003e I don't think that's adding much noise?\n\nIt depends how much people are prepared to grind, doesn't it?\n\n\u003e\u003e \u003e You've only got two nonce choices -- the initial AAAA and the depth\n\u003e\u003e \u003e that you tell Bob and Carol to hash to as steps in the route;\n\u003e\u003e No, the sphinx construction allows for grinding, that was my intent\n\u003e\u003e here.  The prepay hashes are independent.\n\u003e\n\u003e Oh, because you're also xoring with the onion packet, right, I see.\n\u003e\n\u003e\u003e \u003e I think you could just make the scheme be:\n\u003e\u003e \u003e   Alice sends HTLC(k,v) + 1250 msat to Bob\n\u003e\u003e \u003e   Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol\n\u003e\u003e \u003e   Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave\n\u003e\u003e \u003e   Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol\n\u003e\n\u003e The math here doesn't add up. Let's assume I meant:\n\u003e\n\u003e   Bob keeps 500 sat, forwards 750 sat\n\u003e   Carol keeps 250 sat, forwards 500 sat\n\u003e   Dave keeps 300 sat, refunds 200 sat\n\u003e\n\u003e\u003e \u003e   Carol redeems the HTLC and refunds 200 msat to Bob\n\u003e\u003e \u003e   Bob redeems the HTLC and refunds 200 msat to Alice\n\u003e\u003e \u003e\n\u003e\u003e \u003e If there's a failure, Alice loses the 1250 msat, and someone in the\n\u003e\u003e \u003e path steals the funds.\n\u003e\u003e This example confuses me.\n\u003e\n\u003e Well, that makes us even at least? :)\n\u003e\n\u003e\u003e So, you're charging 250msat per hop?  Why is Bob taking 750?  Does Carol\n\u003e\u003e now know Dave is the last hop?\n\u003e\n\u003e No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and\n\u003e Dave respectively, as part of setting up the onion, and picks those\n\u003e numbers via some magic algo trading off privacy and cost.\n\nOK.\n\n\u003e\u003e Does Alice lose everything on any routing failure?\n\u003e\n\u003e That was my thought yeah; it seems weird to pay upfront but expect a\n\u003e refund on failure -- the HTLC funds are already committed upfront and\n\u003e refunded on failure.\n\nAFAICT you have to overpay, since anything else is very revealing of\npath length.  Which kind of implies a refund, I think.\n\n\u003e\u003e If so, that is strong incentive for Alice to reduce path-length privacy\n\u003e\u003e by keeping payments minimal, which I was really trying to avoid.\n\u003e\n\u003e Assuming v is much larger than 1250msat, and 1250 msat is much lower than\n\u003e the cost to Bob of losing the channel with Alice, I don't think that's\n\u003e a problem. 1250msat pays for 125kB of bandwdith under your assumptions\n\u003e I think?\n\nThat's irrelevant?  Since retries are common, it's natural for Alice to\nwant to minimize losses.  If she's going to lose everything on any\nfailure, she'll pay the minimum amount, which exposes her path length\ntrivially.\n\nThus my attempt to try to reduce the lossage. I think.\n\n\u003e\u003e \u003e Does that miss anything that all the hashing achieves?\n\u003e\u003e It does nothing if Carol is the one who can't route.\n\u003e\n\u003e If Carol can't route, then ideally she just refunds all the money and\n\u003e everyone's happy.\n\nThat tells Bob clearly that Carol failed.  If Carol claims a variable\namount, it's less obvious (though still pretty bad).\n\n\u003e If Carol tries to steal, then she can keep 750 msat instead of 250 msat.\n\u003e This doesn't give any way for Bob to prove Carol cheated on him though;\n\u003e but Bob could just refund the 1250 msat and write the 750 msat off as a\n\u003e loss of dealing with cheaters like Carol.\n\nWhat actually happens is that Carol sends a signature on a commitment\nwhich Bob does't agree with (since he expected his money back).  They go\nonchain.\n\nNow Bob is out the total he fwd to Carol, but he's probably more annoyed\nat losing the channel.\n\nCheers,\nRusty."}