rich1.0Anthony Towns [ARCHIVE] (npub17r…x9l2h)https://yabu.me/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://yabu.me📅 Original date posted:2019-11-07 📝 Original message: On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote: > > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay > > field: it says 14, LLLL." but Alice doesn't know anything other than > > ZZZZ so can't put LLLL in the onion? > Alice created the onion. Alice knows all the preimages, since she > created the chain AAAAA....ZZZZZ. In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating the chain AAAA...ZZZZ -- so I was lost as to what you were proposing... Here's what I now think you're saying, which I think mostly hangs together: Alice sends a HTLC with hash X and value V to Dave via Bob then Carol Alice generates a nonce AAAA, and calculates H^25(AAAA) = ZZZZ. Alice creates an onion, and sends the HTLC to Bob, revealing ZZZZ and 6,TTTT to Bob, along with 2500 msat (25 for the hashing ops between AAAA and ZZZZ, and *100 for round numbers). Bob calculates "6" is a fair price. Bob checks H^6(TTTT)=ZZZZ. If not, Bob refunds the 2500 msat, and fails the HTLC immediately. Otherwise, Bob passes the onion on to Carol, with 1900 msat and TTTT; Carol unwraps the onion revealing 15,EEEE. Carol calcualtes "15" is a fair price. Carol checks H^15(EEEE)=TTTT, and fails the route if not, refunding 1900msat to Bob. Otherwise, Carol passes the onion on to Dave, with 400 msat and EEEE. Dave unwraps the onion, revealing 2,CCCC, so can claim 200 msat as well as the HTLC amount, etc. After the successful route, Dave passes 2,CCCC and 200msat back to Carol, who validates and continues passing things back. If Carol instead passes, say, 3,CCCC back, then she also has to refund 300msat to avoid Bob closing the channel, which would be fine, because Bob can just pass that back too -- Carol's the only one losing money in that case. If Carol wants to close the channel anyway and collect the HTLC on chain, then Bob's situation is: channel with Alice: +2500 msat channel with Carol: -1900 msat , -fees , -HTLC funds If Carol isn't cooperative, Bob only definitely knows TTTT, so to keep the channel open with Alice, has to refund 1900msat, so: channel with Alice: +600 msat , +HTLC funds channel with Carol: -1900 msat , -fees , -HTLC funds (or Bob could keep the 2500 msat at the cost of Alice closing the channel too: channel with Alice: +2500 msat , -fees , +HTLC funds channel with Carol: -1900 msat , -fees , -HTLC funds ) So Bob and either keep the channel open but is out 1300 msat because of Carol, or can gain 600 msat at the cost of closing the channel with Alice? As far as the "fair price" goes, the spitballed formula is "16 - X/4" where X is number of zero bits in some PoW-y thing. The proposal is the thing is SHA256(blockhash|revealedonion) which works, and (I think) means each step is individually grindable. I think an alternative would be to use the prepayment hashes themselves, so you generate the nonce AAAA as the value you'll send to Dave then hash it repeatedly to get BBBB..QQQQ, then check if pow(AAAA,BBBB) has 60 leading zero bits or pow(AAAA,CCCC) has 56 leading zero bits etc. If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd preserve privacy, but also mean you can't meaningfully grind unfairly cheap routing except for very short paths? If you don't grind and just go by luck, the average number of hashes per hop is ~15.93 (if I got my maths right), so you should be able to estimate path length pretty accurate by dividing claimed prepaid funds by 15.93*25msat or whatever. If everyone grinds at each level independently, I think you'd just subtract maybe 6 hops from that, but the maths would mostly stay the same? Though I think you could obfusticate that pretty well by moving some of the value from the HTLC into the prepayment -- you'd risk losing that extra value if the payment made it all the way to the recipient but they declined the HTLC that way though. > >> Does Alice lose everything on any routing failure? > > That was my thought yeah; it seems weird to pay upfront but expect a > > refund on failure -- the HTLC funds are already committed upfront and > > refunded on failure. > AFAICT you have to overpay, since anything else is very revealing of > path length. Which kind of implies a refund, I think. I guess you'd want to pay for a path length of about 20 whether the path is actually 17, 2, 10 or 5. But a path length of 20 is just paying for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of 1 cent, which doesn't seem that worth refunding (except for really tiny micropayments, where paying for payment bandwidth might not be feasible at all). If you're buying a $2 coffee and paying 500ppm in regular fees per hop with 5 hops, then each routing attempt increases your fees by 4%, which seems pretty easy to ignore to me. Cheers, aj