Re: [Lightning-dev] A proposal for up-front payments.

On Thu, Feb 20, 2020 at 4:22 AM Anthony Towns wrote: > On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: > > A different way of mitigating this is to reverse the direction in which > the > > bond is paid. So instead of paying to offer an htlc, nodes need to pay to > > receive an htlc.

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > Aside from those philosophical complaints, seems to me the simplest > attack would be: > > * route 1000s of HTLCs from your node A1 to your node A2 via different, > long paths, using up the total channel capacity of your A1/A2 nodes, > with long timeouts > * hav

Re: [Lightning-dev] A proposal for up-front payments.

On Mon, Feb 24, 2020 at 01:29:36PM +1030, Rusty Russell wrote: > Anthony Towns writes: > > On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: > >> And if there is a grace period, I can just gum up the network with lots > >> of slow-but-not-slow-enough HTLCs. > > Well, it reduces the "g

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: >> And if there is a grace period, I can just gum up the network with lots >> of slow-but-not-slow-enough HTLCs. > > Well, it reduces the "gum up the network for blocks" to "gum > up the network for seconds",

Re: [Lightning-dev] A proposal for up-front payments.

On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: > > I think the way it would end up working > > is that the further the route extends, the greater the payments are, so: > > A -> B : B sends A 1msat per minute > > A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: >> A different way of mitigating this is to reverse the direction in which the >> bond is paid. So instead of paying to offer an htlc, nodes need to pay to >> receive an htlc. This sounds counterintuitive, but for

Re: [Lightning-dev] A proposal for up-front payments.

On Thu, Feb 20, 2020 at 03:42:39AM +, ZmnSCPxj wrote: > A thought that arises here is, what happens if I have forwarded a payment, > then the outgoing channel is dropped onchain and that peer disconnects from > me? > > Since the onchain HTLC might have a timelock of, say, a few hundred block

Re: [Lightning-dev] A proposal for up-front payments.

Good morning Joost and aj, A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me? Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim

Re: [Lightning-dev] A proposal for up-front payments.

On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: > A different way of mitigating this is to reverse the direction in which the > bond is paid. So instead of paying to offer an htlc, nodes need to pay to > receive an htlc. This sounds counterintuitive, but for the described jamming > att

Re: [Lightning-dev] A proposal for up-front payments.

Hi all, Within our team, we've been discussing the subject of preventing liquidity-consuming spam (aka channel jamming) further. One idea came up that I think is worth sharing. Previous prepay ideas were based on the sender paying something up-front in case the htlc causes grief on the network. T

Re: [Lightning-dev] A proposal for up-front payments.

Hello ZmnSCPxj, > This can be made "the same" by any of the following methods: > > * Burning the up-front fees. This would impose a hard maximum of 21 * 10^6 * 10^8 global lifetime hops, and a much lower practical one. PoW OTOH doesn't impose such limits. Hence different dynamics. > * Locking

Re: [Lightning-dev] A proposal for up-front payments.

Good morning Orfeas, > Hi ZmnSCPxj, > > > > > requiring a fee is equivalent to requiring proof-of-work, > > > > incentive-wise. > > > > > > Not necessarily, given that > > > > > > 1. there is a finite bitcoin supply but an eventually infinite PoW > > > supply (relevant in the unlikely case f

Re: [Lightning-dev] A proposal for up-front payments.

Hi ZmnSCPxj, >>> requiring a fee is equivalent to requiring proof-of-work, incentive-wise. >> >> Not necessarily, given that >> 1) there is a finite bitcoin supply but an eventually infinite PoW >> supply (relevant in the unlikely case fees are burned) >> 2) sats are transferrable, whereas PoW isn

Re: [Lightning-dev] A proposal for up-front payments.

Good morning Bastien, > While I agree with most of your points, I think there are subtleties to > explore before > completely rejecting the idea. > > > every use of proof-of-work today (other than to power Bitcoin itself, as > > Bitcoin cannot support itself) can instead be done by using Bitcoin

Re: [Lightning-dev] A proposal for up-front payments.

Bastien TEINTURIER writes: > I think there's another alternative than upfront payments to prevent spam, > which is maybe less > controversial (but potentially less effective as well - to be investigated). > > Why not adapt what has been done with email spam and PoW/merkle puzzles? If we can't com

Re: [Lightning-dev] A proposal for up-front payments.

Good morning ZmnSCPxj, > requiring a fee is equivalent to requiring proof-of-work, incentive-wise. Not necessarily, given that 1) there is a finite bitcoin supply but an eventually infinite PoW supply (relevant in the unlikely case fees are burned) 2) sats are transferrable, whereas PoW isn't (re

Re: [Lightning-dev] A proposal for up-front payments.

While I agree with most of your points, I think there are subtleties to explore before completely rejecting the idea. every use of proof-of-work today (other than to power Bitcoin itself, as > Bitcoin cannot support itself) can instead be done by using Bitcoins to > impose this economic cost. > T

Re: [Lightning-dev] A proposal for up-front payments.

Good morning Bastien, > I think there's another alternative than upfront payments to prevent spam, > which is maybe less  > controversial (but potentially less effective as well - to be investigated). > > Why not adapt what has been done with email spam and PoW/merkle puzzles? > The high-level id

Re: [Lightning-dev] A proposal for up-front payments.

> The high-level idea would be that the sender must solve a small PoW puzzle ___ 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.

I think there's another alternative than upfront payments to prevent spam, which is maybe less controversial (but potentially less effective as well - to be investigated). Why not adapt what has been done with email spam and PoW/merkle puzzles? The high-level idea would be that the sender must sol

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote: >> Anthony Towns writes: >> [ Snip summary, which is correct ] > > Huzzah! > > This correlates all the hops in a payment when the route reaches its end > (due to the final preimage getting propogated back for e

Re: [Lightning-dev] A proposal for up-front payments.

[Sorry: re-sending again in plain text] On 08/11/2019 16:15, Joost Jager wrote: > > >     The goal of this pre-payment proposal is to remove the need for > >     trusted parties > > > > Trust isn't the right word. It is a level of service that you > provide > > to your peer

Re: [Lightning-dev] A proposal for up-front payments.

On 08/11/2019 16:15, Joost Jager wrote: >     The goal of this pre-payment proposal is to remove the need for >     trusted parties > > Trust isn't the right word. It is a level of service

Re: [Lightning-dev] A proposal for up-front payments.

> > >> > 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 networ

Re: [Lightning-dev] A proposal for up-front payments.

> > > The goal of this pre-payment proposal is to remove the need for > > trusted parties > > > > Trust isn't the right word. It is a level of service that you provide > > to your peers. If nodes are cognizant of the fact that the level of > > service they receive goes down if they forward

Re: [Lightning-dev] A proposal for up-front payments.

On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote: > Anthony Towns writes: > [ Snip summary, which is correct ] Huzzah! This correlates all the hops in a payment when the route reaches its end (due to the final preimage getting propogated back for everyone to justify the funds they c

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote: >> > 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 th

Re: [Lightning-dev] A proposal for up-front payments.

Joost Jager writes: >> >> > 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

Re: [Lightning-dev] A proposal for up-front payments.

On 07/11/2019 16:43, Joost Jager wrote: On Thu, Nov 7, 2019 at 3:36 PM lisa neigut > wrote: > Imagine the following setup: a network of nodes that trust each other The goal of this pre-payment proposal is to remove the need for trusted parties Trust

Re: [Lightning-dev] A proposal for up-front payments.

On Thu, Nov 7, 2019 at 3:36 PM lisa neigut wrote: > > Imagine the following setup: a network of nodes that trust each other > > The goal of this pre-payment proposal is to remove the need for trusted > parties > Trust isn't the right word. It is a level of service that you provide to your peers.

Re: [Lightning-dev] A proposal for up-front payments.

> Imagine the following setup: a network of nodes that trust each other The goal of this pre-payment proposal is to remove the need for trusted parties. On Thu, Nov 7, 2019 at 07:38 Joost Jager wrote: > > Isn't spam something that can also be addressed by using rate limits for >> > failures? If

Re: [Lightning-dev] A proposal for up-front payments.

> > > 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.

Re: [Lightning-dev] A proposal for up-front payments.

On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote: > > 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

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 >>

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 w

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 pr

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-pay

Re: [Lightning-dev] A proposal for up-front payments.

Olaoluwa Osuntokun writes: > Hi Rusty, > > Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other > alternatives for a few years now, and none of them seems to resolve the > series of routing related incentive issues that prepaid HTLCs would. > >> Since both Offers and Joost's WhatS

Re: [Lightning-dev] A proposal for up-front payments.

Anthony Towns writes: > 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 1msat in channel with Rusty, who has 1000msat >> in the channel with YAIjbOJa. > > Alice, Bob and Carol sure seem simpler than Zmn

Re: [Lightning-dev] A proposal for up-front payments.

Hi Rusty, Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other alternatives for a few years now, and none of them seems to resolve the series of routing related incentive issues that prepaid HTLCs would. > Since both Offers and Joost's WhatSat are looking at sending messages, > i

Re: [Lightning-dev] A proposal for up-front payments.

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 1msat 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 prepa

Re: [Lightning-dev] A proposal for up-front payments.

ZmnSCPxj 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

Re: [Lightning-dev] A proposal for up-front payments.

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 e