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] Issue assets on lightning

2021-10-15 Thread ZmnSCPxj via Lightning-dev
Good morning Prayank, > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html > > Still trying to understand this problem and possible solutions. Interesting > email though (TIL), thanks for sharing the link. Found related things > explained Suredbits blog as

Re: [Lightning-dev] Issue assets on lightning

2021-10-15 Thread Prayank via Lightning-dev
Good morning ZmnSCPxj, > I heard before that the RGB colored coin project had plans to be compatible > with Lightning so that channels could be denominated in an issued asset. RGB will address lot of things but I was wondering if such things should exist in LN implementations by default.

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

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-10-15 Thread Fabrice Drouin
On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun wrote: > Also note that lnd has _never_ referred to itself as the "reference" > implementation. A few years ago some other implementations adopted that > title themselves, but have since adopted softer language. I don't remember that but if