Re: [Lightning-dev] A proposal for up-front payments.
Anthony Towns writes: > On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote: >> >> Rusty prepares a nonce, A and hashes it 25 times = Z. >> >> 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 A to Zmn already so that >> > Zmn can prepare the onion? >> The entire point is to pay *up-front*, though, to prevent spam. > > Hmm, I'm not sure I see the point of paying upfront but not > unconditionally -- you already commit the funds as part of the HTLC, > and if you're refunding some of them, you kind-of have to keep them > reserved or you risk finalising the HTLC causing a failure because you > don't have enough msats spare to do the refund? ? These are upfront an unconditional. I'm confused. You pay per HTLC added (or, in future, to send a message). What part was unclear here? Alice pays X to Bob. Bob gives X- back to Alice. Bob gets preimages from the onion, and from Carol etc. This happens independent of HTLC success or failure. >> Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the >> last hash directly: Alice is saying "I'll pay you 50msat for each >> preimage you can give me leading to this hash". > > So my example was Alice paying Dave via Bob and Carol (so Alice/Bob, > Bob/Carol, Carol/Dave being the individual channels). > > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay > field: it says 14, ." but Alice doesn't know anything other than > so can't put in the onion? Alice created the onion. Alice knows all the preimages, since she created the chain AZ. >> > I'm not sure why lucky hashing should result in a discount? >> Because the PoW adds noise to the amounts, otherwise the path length is >> trivially exposed, esp in the failure case. It's weak protection >> though. > > With a linear/exponential relationship you just get "half the time it's > 1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units", so > I don't think that's adding much noise? It depends how much people are prepared to grind, doesn't it? >> > You've only got two nonce choices -- the initial and the depth >> > that you tell Bob and Carol to hash to as steps in the route; >> No, the sphinx construction allows for grinding, that was my intent >> here. The prepay hashes are independent. > > Oh, because you're also xoring with the onion packet, right, I see. > >> > 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 > > The math here doesn't add up. Let's assume I meant: > > Bob keeps 500 sat, forwards 750 sat > Carol keeps 250 sat, forwards 500 sat > Dave keeps 300 sat, refunds 200 sat > >> > 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. >> This example confuses me. > > Well, that makes us even at least? :) > >> So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol >> now know Dave is the last hop? > > No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and > Dave respectively, as part of setting up the onion, and picks those > numbers via some magic algo trading off privacy and cost. OK. >> 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. >> If so, that is strong incentive for Alice to reduce path-length privacy >> by keeping payments minimal, which I was really trying to avoid. > > Assuming v is much larger than 1250msat, and 1250 msat is much lower than > the cost to Bob of losing the channel with Alice, I don't think that's > a problem. 1250msat pays for 125kB of bandwdith under your assumptions > I think? That's irrelevant? Since retries are common, it's natural for Alice to want to minimize losses. If she's going to lose everything on any failure, she'll pay the minimum amount, which exposes her path length trivially. Thus my attempt to try to reduce the lossage. I think. >> > Does that miss anything that all the hashing achieves? >> It does nothing if Carol is the one who can't route. > > If Carol can't route, then ideally she just refunds all the money and >
Re: [Lightning-dev] A proposal for up-front payments.
Joost Jager writes: > In my opinion, the prepayment should be a last resort. It does take away > some of the attractiveness of the Lightning Network. Especially if you need > to make many payment attempts over long routes, the tiny prepays do add up. > For a $10 payment, it's probably nothing to worry about. But for > micro-payments this can become prohibitively expensive. And it is exactly > the micro-payment use case where Lightning outshines other payment systems. > A not yet imagined micro-payment based service could even be the launchpad > to world domination. So I think we should be very careful with interfering > with that potential. I completely agree, yeah. And maybe we'll never need it, but it's one of my main concerns for the network. > Isn't spam something that can also be addressed by using rate limits for > failures? If all relevant nodes on the network employ rate limits, they can > isolate the spammer and diminish their disruptive abilities. Sure, once the spammer has jammed up the network, he'll be stopped. So will everyone else. Conner had a proposal like this which didn't work, IIRC. > If a node sees that its outgoing htlc packets stack up, it can reduce > the incoming flow on the channels where the htlcs originate > from. Large routing nodes could agree with their peers on service > levels that define these rate limits. Unfortunately, if we *don't* address this, then the network will defend itself with the simple tactic of deanonymizing payments. And every other solution I've seen ends up the same way :( Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A proposal for up-front payments.
On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote: > >> Rusty prepares a nonce, A and hashes it 25 times = Z. > >> 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 A to Zmn already so that > > Zmn can prepare the onion? > The entire point is to pay *up-front*, though, to prevent spam. Hmm, I'm not sure I see the point of paying upfront but not unconditionally -- you already commit the funds as part of the HTLC, and if you're refunding some of them, you kind-of have to keep them reserved or you risk finalising the HTLC causing a failure because you don't have enough msats spare to do the refund? If you refund on routing failure, why wouldn't a spammer just add a fake "Ezekiel" at the end of the route after Dave, so that the HTLCs always fail and all the fees are returned? > Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the > last hash directly: Alice is saying "I'll pay you 50msat for each > preimage you can give me leading to this hash". So my example was Alice paying Dave via Bob and Carol (so Alice/Bob, Bob/Carol, Carol/Dave being the individual channels). What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay field: it says 14, ." but Alice doesn't know anything other than so can't put in the onion? Are you using Hornet so that every intermediary can communicate a nonce back to the source of the route? If not, "Rusty" generating the nonce seems like you're informing Rusty that you're actually the origin of the HTLC, and not just innocently forwarding it along; if so, it seems like you have independent nonces at each step, rather than /// in a direct chain. > > I'm not sure why lucky hashing should result in a discount? > Because the PoW adds noise to the amounts, otherwise the path length is > trivially exposed, esp in the failure case. It's weak protection > though. With a linear/exponential relationship you just get "half the time it's 1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units", so I don't think that's adding much noise? > > You've only got two nonce choices -- the initial and the depth > > that you tell Bob and Carol to hash to as steps in the route; > No, the sphinx construction allows for grinding, that was my intent > here. The prepay hashes are independent. Oh, because you're also xoring with the onion packet, right, I see. > > 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 The math here doesn't add up. Let's assume I meant: Bob keeps 500 sat, forwards 750 sat Carol keeps 250 sat, forwards 500 sat Dave keeps 300 sat, refunds 200 sat > > 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. > This example confuses me. Well, that makes us even at least? :) > So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol > now know Dave is the last hop? No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and Dave respectively, as part of setting up the onion, and picks those numbers via some magic algo trading off privacy and cost. > 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. > If so, that is strong incentive for Alice to reduce path-length privacy > by keeping payments minimal, which I was really trying to avoid. Assuming v is much larger than 1250msat, and 1250 msat is much lower than the cost to Bob of losing the channel with Alice, I don't think that's a problem. 1250msat pays for 125kB of bandwdith under your assumptions I think? > > Does that miss anything that all the hashing achieves? > It does nothing if Carol is the one who can't route. If Carol can't route, then ideally she just refunds all the money and everyone's happy. If Carol tries to steal, then she can keep 750 msat instead of 250 msat. This doesn't give any way for Bob to prove Carol cheated on him though; but Bob could just refund the 1250 msat and write the 750 msat off as a loss of dealing with cheaters like Carol. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org
Re: [Lightning-dev] A proposal for up-front payments.
In my opinion, the prepayment should be a last resort. It does take away some of the attractiveness of the Lightning Network. Especially if you need to make many payment attempts over long routes, the tiny prepays do add up. For a $10 payment, it's probably nothing to worry about. But for micro-payments this can become prohibitively expensive. And it is exactly the micro-payment use case where Lightning outshines other payment systems. A not yet imagined micro-payment based service could even be the launchpad to world domination. So I think we should be very careful with interfering with that potential. Isn't spam something that can also be addressed by using rate limits for failures? If all relevant nodes on the network employ rate limits, they can isolate the spammer and diminish their disruptive abilities. If a node sees that its outgoing htlc packets stack up, it can reduce the incoming flow on the channels where the htlcs originate from. Large routing nodes could agree with their peers on service levels that define these rate limits. Joost On Tue, Nov 5, 2019 at 3:25 AM Rusty Russell wrote: > 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
