rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2019-11-05 📝 Original message: ZmnSCPxj <ZmnSCPxj at protonmail.com> writes: > Good morning Rusty, Hi ZmnSCPxj! > Is this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed? > By a vague sense of the description, it seems to me, it would require a complicated SCRIPT (or multiple tiny 50-msatoshi UTXOs) to enforce onchain. No, it's done as a simple subtraction from direct to-local and to-remote payments. Enforcement is by peer closing the channel, which you wouldn't do over a few msat. > Also, it is not exactly clear to me, the mechanism you are proposing in detail. > Can you give a motivating example, for example in a route from > ZmnSCPxj, through Rusty, to my imaginary friend YAIjbOJa (who is not > in fact me)? 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. Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ. ZmnSCPxj prepares the onion, but adds extra fields (see below). 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. So Rusty takes the 14x50 as prepayment, and forwards the HTLC as normal to YAIjbOJa, along with LLLLL and 11x50msat. His balance with YAIjbOJa is now 450msat. YAIjbOJa decrypts the onion. And it says 10,BBBBB. YAIjbOJa checks that hashing BBBBB 10 times does indeed give LLLLL. Now it takes the 11x50 msat, and fulfils the HTLC. It replies to Rusty with 10,BBBBB in the update_fulfill_htlc message, returning the (implicit) 1x50msat; Rusty's balance with YAIjbOJa is now 500msat. Rusty checks that BBBBB hashed 10 times gives LLLLL. Now it returns 24,BBBBB to ZmnSCPxj with the update_fulfill_htlc, demonstrating to ZmnSCPxj that he's entitled to it, and (implicity) returning 1x50msat to ZmnSCPxj, so their balance is now 8800msat. Now let's look at attacks: 1. Rusty steals the funds and doesn't return them. ZmnSCPxj closes channel, having lost 26x50msat. 2, YAIjbOJa steals the funds and doesn't return them. Rusty closes the channel, having lost 11x50msat. 3. ZmnSCPxj doesn't put correct preimages in, or too few, or other malformation. If it's Rusty's onion, he won't forward it and will give an error. If it's YAIjbOJa who rejects it, Rusty returns all but the 14x50msat he has preimages for. Obviously Rusty needs some upper limit on how much he'll pay out, to avoid infinite exposure (say limit the total exposure to 10,000 sats). A reasonable limit for each HTLC would be 20 hops x 16 x 50msat == 16sat. Even with no other limits, with 486 HTLCs in flight each way, that's only 15456 satoshis. You'll probably lament the channel closure more. Hope that helps! Rusty. >> Hi all, >> >> It's been widely known that we're going to have to have up-front >> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1 >> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using >> spam). >> >> Since both Offers and Joost's WhatSat are looking at sending >> messages, it's time to float actual proposals. I've been trying to come >> up with something for several years now, so thought I'd present the best >> I've got in the hope that others can improve on it. >> >> 1. New feature bit, extended messages, etc. >> 2. Adding an HTLC causes a push of a number of msat on >> commitment_signed (new field), and a hash. >> >> 3. Failing/succeeding an HTLC returns some of those msat, and a count >> and preimage (new fields). >> >> How many msat can you take for forwarding? That depends on you >> presenting a series of preimages (which chain into a final hash given in >> the HTLC add), which you get by decoding the onion. You get to keep 50 >> msat[1] per preimage you present[2]. >> >> So, how many preimages does the user have to give to have you forward >> the payment? That depends. The base rate is 16 preimages, but subtract >> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the >> onion. The blockhash is the hash of the block specified in the onion: >> reject if it's not in the last 3 blocks[3]. >> >> This simply adds some payment noise, while allowing a hashcash style >> tradeoff of sats for work. >> >> The final node gets some variable number of preimages, which adds noise. >> It should take all and subtract from the minimum required invoice amount >> on success, or take some random number on failure. >> >> This leaks some forward information, and makes an explicit tradeoff for >> the sender between amount spent and privacy, but it's the best I've been >> able to come up with. >> >> Thoughts? >> Rusty. >> >> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about >> 655msat per message. Flat pricing for simplicity; we're trying to >> prevent spam, not create a spam market. >> [2] Actually, a number and a single preimage; you can check this is >> indeed the n'th preimage. >> [3] This reduces incentive to grind the damn things in advance, though >> maybe that's dumb? We can also use a shorter hash (siphash?), or >> even truncated SHA256 (128 bits). >> >> >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev