rich1.0Anthony Towns [ARCHIVE] (npub17r…x9l2h)https://yabu.me/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://yabu.me📅 Original date posted:2019-11-05 📝 Original message: On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote: > Sure: for simplicity I'm sending a 0-value HTLC. > ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat > in the channel with YAIjbOJa. Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty... > Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ. > ZmnSCPxj prepares the onion, but adds extra fields (see below). It would have made more sense to me for Alice (Zmn) to generate the nonce, hash it, and prepare the onion, so that the nonce is revealed to Dave (Rusty) if/when the message ever actually reaches its destination. Otherwise Rusty has to send AAAAA to Zmn already so that Zmn can prepare the onion? > He then > sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those > fields are in the update_add_htlc msg). His balance with Rusty is now > 8750msat (ie. 25x50 to Rusty). > > Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL. > Rusty checks: the hash of the onion & block (or something) does indeed > have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He > then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it > should be. I'm not sure why lucky hashing should result in a discount? You're giving a linear discount for exponentially more luck in hashing which also seems odd. You've only got two nonce choices -- the initial AAAA and the depth that you tell Bob and Carol to hash to as steps in the route; so the incentive there seems to be to do a large depth, so you might hash AAAA 1000 times, and figure that you'll find a leading eight 0's once in the first 256 entries, then another by the time you get up to 512, and another by the time you get to 768, which gets you discounts on three intermediaries. But the cost there is that your intermediaries collectively have to do the same amount of hashing you did, so it's not proof-of-work, because it's as hard to verify as it is to generate. I think you could just make the scheme be: Alice sends HTLC(k,v) + 1250 msat to Bob Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol Carol redeems the HTLC and refunds 200 msat to Bob Bob redeems the HTLC and refunds 200 msat to Alice If there's a failure, Alice loses the 1250 msat, and someone in the path steals the funds. You could make the accountable by having Alice also provide "Hash(AAAA, refund=200)" to everyone, encoding AAAA in the onion to Dave, and then each hop reveals AAAA and refunds 200msat to demonstrate their honesty. Does that miss anything that all the hashing achieves? I think the idea here is that you're paying tiny amounts for the bandwidth, which when it's successful does in fact pay for the bandwidth; and when it's unsuccessful results in a channel closure, which makes it unprofitable to cheat the system, but doesn't change the economics of lightning much overall because channel closures can happen anytime anyway. I think that approach makes sense. Cheers, aj