Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote: > > > Good morning Joost, > > > > > A potential downside of a dedicated probe message is that it could be > > > used for free messaging on lightning by including additional data in the > > > payload for the recipient. Free

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread Joost Jager
On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote: > Good morning Joost, > > > A potential downside of a dedicated probe message is that it could be > used for free messaging on lightning by including additional data in the > payload for the recipient. Free messaging is already possible today via

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > A potential downside of a dedicated probe message is that it could be used > for free messaging on lightning by including additional data in the payload > for the recipient. Free messaging is already possible today via htlcs, but a > probe message would lower the cost to

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-21 Thread Joost Jager
A potential downside of a dedicated probe message is that it could be used for free messaging on lightning by including additional data in the payload for the recipient. Free messaging is already possible today via htlcs, but a probe message would lower the cost to do so because the sender doesn't

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-19 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > There could be some corners where the incentives may not work out 100%, but I > doubt that any routing node would bother exploiting this. Especially because > there could always be that reputation scheme at the sender side which may > cost the routing node a lot more in

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-19 Thread Joost Jager
There could be some corners where the incentives may not work out 100%, but I doubt that any routing node would bother exploiting this. Especially because there could always be that reputation scheme at the sender side which may cost the routing node a lot more in lost routing fees than the

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Owen, > C now notes that B is lying, but is faced with the dilemma: > > "I could either say 'no' because I can plainly see that B is lying, or > I could say 'yes' and get some free sats from the failed payment (or > via the hope of a successful payment from a capacity increase in the

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread Owen Gunden
On Fri, Oct 15, 2021 at 02:29:15PM +, ZmnSCPxj wrote: > I propose substantially the same thing here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html > > In that proposal, I wrote: > > > Another thought is: Does the forwarding node have an incentive to > >

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread Joost Jager
> > > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > > > > So how would things work out with a combination of both of the > > > proposals described in this mail? First we make probing free (free as > > > in no liquidity locked up) and then we'll require senders to pay for > > >

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Owen, > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > > So how would things work out with a combination of both of the > > proposals described in this mail? First we make probing free (free as > > in no liquidity locked up) and then we'll require senders to pay for

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread Joost Jager
On Fri, Oct 15, 2021 at 4:21 PM Owen Gunden wrote: > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > So how would things work out with a combination of both of the > > proposals described in this mail? First we make probing free (free as > > in no liquidity locked up) and then

Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-15 Thread Owen Gunden
On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > So how would things work out with a combination of both of the > proposals described in this mail? First we make probing free (free as > in no liquidity locked up) and then we'll require senders to pay for > failed payment attempts

[Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

2021-10-14 Thread Joost Jager
A practice that is widely applied by lightning wallets is to probe routes with an unknown payment hash before making the actual payment. Probing yields an accurate routing fee that can be shown to the user before execution of the payment. The downside of this style of probing is that for a short