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