Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
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 > intervening milliseconds)." Note that if B cannot forward an HTLC to C later, then C cannot have a failed payment and thus cannot earn any money from the upfront payment scheme; thus, at least that part of the incentive is impossible. On the other hand, there is still a positive incentive for continuing the lie --- later, maybe the capacity becomes OK and C could earn both the upfront fee and the success fee. > So C decides it's in his interest to keep the lie going. D, the payee, > can't tell that it's a lie when it reaches her. > > If C did want to tattle, it's important that he be able to do so in a > way that blames B instead of himself, otherwise payers will assume > (incorrectly, and to C's detriment) that the liquidity deficit is with C > rather than B. That is certainly quite possible to do. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
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 > > lie? > > Suppose the next hop is alive but the forwarding node has > > insufficient capacity towards the next hop. > > Then the forwarding node can lie and claim it can still resolve the > > HTLC, in the hope that a few milliseconds later, when the actual > > HTLC arrives, the capacity towards the next hop has changed. > > Thus, even if the capacity now is insufficient, the forwarding node > > has an incentive to lie and claim sufficient capacity. Under Joost's proposal, there's even more of an incentive to lie: sats to be had. > > Against the above, we can mitigate this by accepting "no" from *any* > > node along the path, but only accepting "yes" from the actual payee. This doesn't really help if all the routers along the way are lying and saying 'yes'. Only the payee's 'yes' is meaningful, and she doesn't have enough information to know if the routers were lying or not. I think the actual enforcement mechanism is (also from your proposal Zmn): > > Presumably, when a node receives a question, it checks if the asking > > node has sufficient capacity towards it first, and if not, fails the > > channel between them, since obviously the asking node is not > > behaving according to protocol and is buggy. But I'm not sure the incentives align for this tattling on your neighbor. Let's take an example A -> B -> C -> D A sends a probe towards D. B doesn't have sufficient liquidity to send to C. But B is a liar. B says 'yes'. 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 intervening milliseconds)." So C decides it's in his interest to keep the lie going. D, the payee, can't tell that it's a lie when it reaches her. If C did want to tattle, it's important that he be able to do so in a way that blames B instead of himself, otherwise payers will assume (incorrectly, and to C's detriment) that the liquidity deficit is with C rather than B. Maybe Joost's suggestion of using a simple reputation scheme would work. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Issue assets on lightning
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 well. We can argue that the above problem is really just the "failed HTLCs are free and HODL invoices are free" problem, magnified by the fact that as an exchange, and with most cryptocurrency assets being very volatile, exchange rate changes can be exploited to leak economic power from exchange nodes. So, fixing the "free HOLD invoices" problem, such as creating a ***palatable*** upfront payment scheme, should also fix the American Call Option problem. On the other hand, if we cannot create an upfront payment scheme and are forced to solve the "free HODL invoices" problem by other means, then we may need to solve the American Call Option problem separately. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Issue assets on lightning
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. Example: If we had two ways to issue assets LA1 and LA2, the user can issue asset using a command: lightning-cli -named issueassets -type=LA1 -number=1000 > Blockstream I believe has plans to include support for Liquid-issued assets > in C-Lightning somehow; C-Lightning already supports running on top of Liquid > instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin > for the channel asset type) This is interesting. > 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 well. -- Prayank A3B1 E430 2298 178F Oct 13, 2021, 09:29 by zmnsc...@protonmail.com: > Good morning Prayank, > >> Hello everyone, >> >> I wanted to know few things related to asset issuance on lightning: >> >> 1.Is it possible to issue assets on LN right now? If yes, what's the process >> and is it as easy as few commands in liquid: >> https://help.blockstream.com/hc/en-us/articles/95127583-How-do-I-issue-an-asset-on-Liquid- >> >> 2.If no, is anyone working or planning to work on it? >> >> 3.I had read few things about Omni BOLT which could solve this problem but >> not sure about status of project and development: >> https://github.com/omnilaboratory/OmniBOLT-spec >> >> Few use cases for tokens on lightning: >> >> 1.DEX >> 2.Stablecoins >> 3.Liquidity: If projects could incentivize users with native tokens that are >> associated with the project on every LN channel opened it would improve >> liquidity. >> > > 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. > > Most plans for colored coins on Lightning generally assume that each channel > has just a single asset, as that seems to be simpler, at least as a start. > However, this complicates the use of such channels for forwarding, as we > would like to restrict channel gossip to channels that *any* node can easily > prove actually exist as a UTXO onchain. > Thus, colored coins would need to somehow be provable as existing to *any* > node (or at least those that support colored coins somehow) on the LN. > > Blockstream I believe has plans to include support for Liquid-issued assets > in C-Lightning somehow; C-Lightning already supports running on top of Liquid > instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin > for the channel asset type). > > Generally, the assumption is that there would be a Lightning Network where > channels have different asset types, and you can forward via any channel, > suffering some kind of asset conversion fee if you have a hop where the > incoming asset is different from the outgoing asset. > > > However, do note that some years ago I pointed out that swaps between two > *different* assets are a form of very lousy American Call Option: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html > > Due to this, issued assets may not be usable on Lightning after all, even if > someone makes the work to make non-Bitcoin assets on Lightning channels. > > I am unaware of any actual decent solutions to the American Call Option > problem, but it has been a few years since then and someone might have come > up with a solution by now (we hope, maybe). > I believe CJP had a trust-requiring solution: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html > and https://bitonic.nl/public/slowdown_prevention.pdf > Here is a paper which requires Ethereum (I have not read it because it > required Ethereum): https://eprint.iacr.org/2019/896.pdf > > It may be possible to use Barrier Escrows: > https://suredbits.com/payment-points-implementing-barrier-escrows/ > Barrier Escrows are still trusted (and I think they can serve as the RM role > in the CJP paper?) to operate correctly, but the exact use of their service > is blinded to them. > Of course, any single participant of a multi-participant protocol can > probably unblind the Barrier Escrow, so still not a perfectly trustless > solution. > > > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
> > > 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 too. Failed payment attempts after a > > > successful probe should be extremely rate, so doesn't this fix the ux > > > issue with upfront fees? > > > > Why couldn't a malicious routing node (or group of colluding routing > > nodes) succeed the probe and then fail the payment in order to collect > > the failed payment fee? > > Good observation! > > I propose substantially the same thing here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html I totally missed that thread, but it is indeed the same thing including the notion that it may make upfront payments palatable! Contains some great additional ideas too. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
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 > > failed payment attempts too. Failed payment attempts after a > > successful probe should be extremely rate, so doesn't this fix the ux > > issue with upfront fees? > > Why couldn't a malicious routing node (or group of colluding routing > nodes) succeed the probe and then fail the payment in order to collect > the failed payment fee? Good observation! 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 lie? > Suppose the next hop is alive but the forwarding node has insufficient > capacity towards the next hop. > Then the forwarding node can lie and claim it can still resolve the HTLC, in > the hope that a few milliseconds later, when the actual HTLC arrives, the > capacity towards the next hop has changed. > Thus, even if the capacity now is insufficient, the forwarding node has an > incentive to lie and claim sufficient capacity. > > Against the above, we can mitigate this by accepting "no" from *any* node > along the path, but only accepting "yes" from the actual payee. We already have a mechanism to send an onion and get back an "error" reply; the reply can be identified by the sender as arising from any node along the path, or at the destination. Basically, we simply reuse this mechanism: * Do not need an HTLC with this onion. * Only accept a "everything is OK" result from the destination. * Accept a "sorry cannot forward" from *any* node along the path. Thus, a malicious node cannot succeed the probe --- the probe has to reach the destination. Now the malicious forwarding node could be colluding with the destination, but presumably the destination wants to *actually* get paid, so we expect that, economically, it has no incentive to cooperate with the malicious node to *fail* the actual payment later just to extract a tiny failure fee. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
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 we'll require senders to pay for > > failed payment attempts too. Failed payment attempts after a > > successful probe should be extremely rate, so doesn't this fix the ux > > issue with upfront fees? > > Why couldn't a malicious routing node (or group of colluding routing > nodes) succeed the probe and then fail the payment in order to collect > the failed payment fee? > Yes they could, but senders should be really suspicious when this happens. It could happen occasionally because balances may have shifted in between probe and payment. But if it keeps happening they may want to ban this routing node for a long time. This may disincentivize the routing node enough to respond honestly to probes. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
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 too. Failed payment attempts after a > successful probe should be extremely rate, so doesn't this fix the ux > issue with upfront fees? Why couldn't a malicious routing node (or group of colluding routing nodes) succeed the probe and then fail the payment in order to collect the failed payment fee? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository
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 you're referring to c-lightning it was the first lightning implementation, and the only one for a while, so in a way it was a "reference" at the time ? Or it could have been a reference to their policy of "implementing the spec, all the spec and nothing but the spec" ? > I think it's worth briefly revisiting a bit of history here w.r.t the github > org in question. In the beginning, the lightningnetwork github org was > created by Joseph, and the lightningnetwork/paper repo was added, the > manuscript that kicked off this entire thing. Later lightningnetwork/lnd was > created where we started to work on an initial implementation (before the > BOLTs in their current form existed), and we were added as owners. > Eventually we (devs of current impls) all met up in Milan and decided to > converge on a single specification, thus we added the BOLTs to the same > repo, despite it being used for lnd and knowingly so. Yes, work on c-lightning then eclair then lnd all began a long time before the BOLTs process was implemented, and we all set up repos, accounts... I agree that we all inherited things from the "pre-BOLTS" era and changing them will create some friction but I still believe it should be done. You also mentioned potential admin rights issues on the current specs repos which would be solved by moving them to a new clean repo. > As it seems the primary grievance here is collocating an implementation of > Lightning along with the _specification_ of the protocol, and given that the > spec was added last, how about we move the spec to an independent repo owned > by the community? I currently have github.com/lightning, and would be happy > to donate it to the community, or we could create a new org like > "lightning-specs" or something similar. Sounds great! github.com/lightning is nice (and I like Damian's idea of using github.com/lightning/bolts) and seems to please everyone so it looks that we have a plan! Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
