Good morning Rusty,
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. 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)? Regards, ZmnSCPxj > 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
