Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko wrote: > Hi Lloyd, > > > I agree with Z that this proposal is missing a strong argument as to why > this is a better “proof-of-stake” than channel balances themselves. > > I think Z’s consideration is about the alternative Stake Certificates > proposed by t-bast, where every link in the route proves something to the > next hop. > For the context see this post, specifically “point-to-point property”: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html > Thanks for the correction. > > I think you managed to apply the same argument to our original proposal as > well :) > > > In order to send a jamming HTLC you have to have to lock up funds to do > it (they need outgoing balance for the sender and incoming balance for the > receiver). > > I think the issue here is with loop attacks ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)? > This restriction with locking funds doesn’t really work… > After getting past their intermediate hop, an attacker can make arbitrary > loops and lock 100 BTC channels even by just having 1 BTC locked in the > initial hop. > > Stake Certificates allow for a node in the middle of the route to > distinguish where the payment is coming from (in a privacy-preserving > manner of course), to distinguish heavy channel users from normal. > They also allow to force an attacker to distribute jamming in time and > across many channels. > That's a very interesting point. If we were to be able to prevent loop attacks by the sender proving the path is well formed (without revealing who they are or any of the other hops) would this be an alternative solution? It seems to me that disabling loop attacks might be much easier than stake certificates. > Perhaps, alternative restrictions may take place by restricting based on > from which immediate channel/node they are coming (one-hop). But that > sounds like a mess, as a payment sender doesn’t have any control, and > gossiping that would probably be a privacy leak, also it still allows free > jamming I think (just a bit different). > The big deal here is to distinguish the flows, to better control them. > We can discuss this separately. > > It’s true that any token might achieve the same goal here, but how to make > it Sybil-resistant and prevent generating new tokens? Stake Certificates, I > don’t know what else we can commit to. > > > If we are talking about non-economic adversaries who simply wish to > destroy LN then that’s another game altogether. > > I was thinking about this scenario all the way, but maybe I should think > about the other one as well. > > But if we are talking about large holders of Bitcoin that just want to destory LN this seems like a very weak mitigation since they will be able to produce stake certificates galore and lock up channels anyway. I don't see much of a way around this other than reputation systems. LL > > – gleb > On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier , > wrote: > > Hi Gleb et al, > > I really appreciate the out-of-the-box thinking of this proposal. > I will put to the side the very difficult task of creating a cryptosystem > that efficiently achieves what's necessary for this to work because that > seems not to be the main concern. > > I agree with Z that this proposal is missing a strong argument as to why > this is a better "proof-of-stake" than channel balances themselves. > In order to send a jamming HTLC you have to have to lock up funds to do it > (they need outgoing balance for the sender and incoming balance for the > receiver). > Why would stake certificates be more powerful than this? I get that you > decrement the UTXO's credit even if they fail. This increases the cost of > sending spam (but it also increases the cost of sending normal payments > since you now may be honest but have all your UTXOs run out of credit.) > Does this increased cost (it was not zero before) actually prevent the > attack without inhibiting normal usage? > > In general there seems to be an open question about whether these channel > jamming attacks are actually economic. > If I want to get more payments routed through me would it really be > optimal to do channel jamming? > Suppose that the nodes react to the jamming by adding extra capacity by > splicing out from somewhere else. Then I have jammed up my own coins and > got nothing for it. > What if instead of attacking I allocated the coins instead to creating > more valuable channels. Couldn't this be more profitable? > I just posed this question in [1]. > > If we are talking about non-economic adversaries who simply wish to > destroy LN then that's another game altogether. > For example if the CCP with its 1% of all Bitcoin it seized from the > plustoken scam were to try and attack lightning they would likely succeed > even if we had this system in place simply because they have a lot of > "stake". > As David points out I don't think y
Re: [Lightning-dev] Lightning Distributed Routing
Hello Bastien! Firstly I'd like to thank you for the time you took to read the paper, it's been hard to get some quality reviews. Your feedback made me think and reach the following conclusions: Let's assume node A is sending information to its peer, node B, with the goal of attracting more business (increasing the number of payments that are routed through it). In LDR this would mean A would want to announce to B that it belongs to larger volume routes than the ones it actually does. Let's say A and B shared channel state is (A: 1, B: 4). A shares a channel with C, state (A: 2, C: 3). B also shares a channel with C, state (B: 3, C: 6). A could dishonestly share with B knowing a path to C with capacity 4 BTC although it only has 2 currently available. By doing this A would effectively change B's routing preferences for payments to C, making B's routing table go from: Destination | Next Hop | Capacity CA 2 CC 3 ...to: Destination | Next Hop | Capacity CA 4 CC 3 Meaning B now thinks payments to C with volume in the [3, 4] BTC range can only be routed through A and payments to C in the [0, 3] BTC range can be routed to A or directly to C. What does this information change and how does it affect honest nodes? Larger [3, 4] BTC payments are not within the capacity provided by the path that goes directly to C and would immediately fail when the payment is made in the LN layer using the path that goes through A. This breaks the incentive to, at least for payments in this volume range, share the invalid information. The cheating nodes would not be putting honest nodes out of business nor increasing the number of payments that go through them. The problem starts when the cheating node fakes directly competing for routes within the capacity range provided by honest nodes and not by them ([2, 3] BTC range for the example). Although this could not be used to collect more fees because payments would eventually fail in the LN layer and the fees wouldn't be able to be collected, it could certainly be used to "put honest nodes out of work", stealing routing paths that would otherwise belong to them. I think the solution lies in the way in which a node chooses the next best hop for a certain destination. I started by proposing the following (section 3.1.2): >The ”best next hop” for a certain payment destination is defined as being the hop with the lowest fee from the group of next hops for that destination where the maximum volume allowed is bigger than the payment’s volume. I propose changing it to: >The ”best next hop” for a certain payment destination is defined as being a random hop taken from the group of next hops for that destination where the maximum volume allowed is higher than the payment’s volume. Which would diminish the incentive attacking nodes have to share fake gossip by not allowing them to set themselves as first in line to be chosen as next hop. A maximum fee that a node is willing to pay would also need to be set, Also, keep in mind that the capacity the maximum path capacity can lie about is limited by the capacity of his biggest channel, available in the blockchain. PS: I adapted Figure 5 from your trampoline routing presentation, hope that's ok! Kind regards, João Valente On Mon, 30 Nov 2020 at 08:36, Bastien TEINTURIER wrote: > Hi Joao, > > Thanks for the time you spent on this, the paper is clear on the > trade-offs (sacrificing some privacy for > efficiency). > > My main negative feedback here is that you seem to assume that nodes will > honestly cooperate. > It feels to me that nodes can cheat and gossip biased or invalid > information to their peers in order to > attract more payments through their nodes (and collect more fees or put > honest routing nodes out of > business). > > Is that something you've thought about? > > Cheers, > Bastien > > Le dim. 29 nov. 2020 à 00:46, João Valente a > écrit : > >> Hey! >> >> I've been working on this new concept for routing in the lightning >> network. It leverages the use of the information nodes have on the >> distribution of funds in their channels to try and maximize the probability >> of success for a payment. >> Each node shares with his neighbours the information it has about the >> distribution of funds in its own neighbourhood through the form of a >> routing table. As nodes receive new tables they'll be updating their own >> locally maintained tables with the new information, periodically sharing >> them with their neighbours. >> Routing tables associate destination addresses (representing nodes in the >> network) to the next hop in the maximum capacity path to these nodes. >> If a new payment is to be made a payment probe is forwarded by the payer >> and through every node in the path, collects the path information along the >> way, and reaches the payee who returns it to the
Re: [Lightning-dev] Lightning Distributed Routing
Hi Joao, Thanks for the time you spent on this, the paper is clear on the trade-offs (sacrificing some privacy for efficiency). My main negative feedback here is that you seem to assume that nodes will honestly cooperate. It feels to me that nodes can cheat and gossip biased or invalid information to their peers in order to attract more payments through their nodes (and collect more fees or put honest routing nodes out of business). Is that something you've thought about? Cheers, Bastien Le dim. 29 nov. 2020 à 00:46, João Valente a écrit : > Hey! > > I've been working on this new concept for routing in the lightning > network. It leverages the use of the information nodes have on the > distribution of funds in their channels to try and maximize the probability > of success for a payment. > Each node shares with his neighbours the information it has about the > distribution of funds in its own neighbourhood through the form of a > routing table. As nodes receive new tables they'll be updating their own > locally maintained tables with the new information, periodically sharing > them with their neighbours. > Routing tables associate destination addresses (representing nodes in the > network) to the next hop in the maximum capacity path to these nodes. > If a new payment is to be made a payment probe is forwarded by the payer > and through every node in the path, collects the path information along the > way, and reaches the payee who returns it to the payer. The payer can then > use this knowledge and confidently use the discovered path to route LN > payments through. > > I wrote a 10 page paper about the subject and would love to get some > feedback: > > https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing > > Cheers, > João Valente > ___ > 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
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Hi Lloyd, > I agree with Z that this proposal is missing a strong argument as to why this > is a better “proof-of-stake” than channel balances themselves. I think Z’s consideration is about the alternative Stake Certificates proposed by t-bast, where every link in the route proves something to the next hop. For the context see this post, specifically “point-to-point property”: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html I think you managed to apply the same argument to our original proposal as well :) > In order to send a jamming HTLC you have to have to lock up funds to do it > (they need outgoing balance for the sender and incoming balance for the > receiver). I think the issue here is with loop attacks (https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)? This restriction with locking funds doesn’t really work… After getting past their intermediate hop, an attacker can make arbitrary loops and lock 100 BTC channels even by just having 1 BTC locked in the initial hop. Stake Certificates allow for a node in the middle of the route to distinguish where the payment is coming from (in a privacy-preserving manner of course), to distinguish heavy channel users from normal. They also allow to force an attacker to distribute jamming in time and across many channels. Perhaps, alternative restrictions may take place by restricting based on from which immediate channel/node they are coming (one-hop). But that sounds like a mess, as a payment sender doesn’t have any control, and gossiping that would probably be a privacy leak, also it still allows free jamming I think (just a bit different). The big deal here is to distinguish the flows, to better control them. We can discuss this separately. It’s true that any token might achieve the same goal here, but how to make it Sybil-resistant and prevent generating new tokens? Stake Certificates, I don’t know what else we can commit to. > If we are talking about non-economic adversaries who simply wish to destroy > LN then that’s another game altogether. I was thinking about this scenario all the way, but maybe I should think about the other one as well. > As David points out I don’t think you can make a distinction between real LN > outputs and fake ones. Responding here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002894.html – gleb On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier , wrote: > Hi Gleb et al, > > I really appreciate the out-of-the-box thinking of this proposal. > I will put to the side the very difficult task of creating a cryptosystem > that efficiently achieves what's necessary for this to work because that > seems not to be the main concern. > > I agree with Z that this proposal is missing a strong argument as to why this > is a better "proof-of-stake" than channel balances themselves. > In order to send a jamming HTLC you have to have to lock up funds to do it > (they need outgoing balance for the sender and incoming balance for the > receiver). > Why would stake certificates be more powerful than this? I get that you > decrement the UTXO's credit even if they fail. This increases the cost of > sending spam (but it also increases the cost of sending normal payments since > you now may be honest but have all your UTXOs run out of credit.) > Does this increased cost (it was not zero before) actually prevent the attack > without inhibiting normal usage? > > In general there seems to be an open question about whether these channel > jamming attacks are actually economic. > If I want to get more payments routed through me would it really be optimal > to do channel jamming? > Suppose that the nodes react to the jamming by adding extra capacity by > splicing out from somewhere else. Then I have jammed up my own coins and got > nothing for it. > What if instead of attacking I allocated the coins instead to creating more > valuable channels. Couldn't this be more profitable? > I just posed this question in [1]. > > If we are talking about non-economic adversaries who simply wish to destroy > LN then that's another game altogether. > For example if the CCP with its 1% of all Bitcoin it seized from the > plustoken scam were to try and attack lightning they would likely succeed > even if we had this system in place simply because they have a lot of "stake". > As David points out I don't think you can make a distinction between real LN > outputs and fake ones. > It seems unavoidable that any coins you own could be used to produce a > certificate to give you spam bandwidth (especially if you actually manage to > guarantee privacy through ZKPs). > > [1] https://github.com/t-bast/lightning-docs/issues/7 > > Cheers, > > LL > > > > On Sun, Nov 29, 2020 at 5:25 AM David A. Harding wrote: > > > On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote: > > > > > > > > Hello list, > > > > > > Gleb and Antoine, > > > > > >
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Hi Dave, Thanks for the hard questions. >Can’t a malicious user get around this restriction by opening channels with themself? You are right, preventing this kind of Sybil attack is challenging, but I don’t think it’s a no-go. Three separate observations which make me positive about are: 1. This still requires locking funds by an attacker 2. We might start with a low credit for just random valid Stake Certificates, but increase if they showed good activity: e.g., they we route through them a lot, or they paid us a lot of fees previously. Both ideas would require some extra work of linking Stake Certificates to these activities in a private matter. The paid-fees one should be easier. 3. We might give more credit if they or their channel counterparty is just a known good actor. This can be achieved by a routing node have this second list of trustworthy UTXOs payment sender may prove inclusion for. (2) and (3) may be just a part of routing node Stake Certificate acceptance policy, I think if we like the ideas, new can make them work in a desirable private/scalable way. We might also have senders proving that they paid fees to *other* (real) non-Sybil routing nodes, although it adds even more complexity. Also, now that I’m thinking, maybe payment receiver could also contribute to the Stake Certificate… >How would a stake certificate prove that the UTXO was generated for LN rather >than just belonging to a user with a 2-of-2 multisig wallet or any >key-path-spendable taproot wallet?) You are right, we can only get so close to proving that it’s indeed a payment channel. I think the problem of channels-with-themselves (see a beginning of this response) includes this one, so if we solve that, this won’t be a big deal. >That cost doesn’t seem high enough to me to effectively prevent attacks. Perhaps having 1000 BTC staked should not allow them to send 1000 BTC over Lightning, but maybe, with Stake Certificates, this could be restricted to say 100 BTC per 0.1 hour? This, of course, requires hypothesizing about honest economic activity in the Lightning Network. The exact economics of Stake Certificates still has to be worked out, I’m just suggesting that we probably have a lot flexibility with restrictions, since we’re very permissive towards users to begin with. – gleb On Nov 28, 2020, 8:25 PM +0200, David A. Harding , wrote: > On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote: > > > > Hello list, > > Gleb and Antoine, > > This is an interesting idea! Thank you for working on it. > > I had difficulty with one part of the proposal: > > > Should we allow holding *any* Bitcoins (not just LN channels) for > > Stake Certificates? > > > > [...] we believe that allowing any UTXO would give an attacker more > > opportunities to use their cold funds for this attack, or even have a > > secondary market where holders sell their proofs (they have nothing to > > loose). > > Can't a malicious user get around this restriction by opening channels > with themself? (Also, aren't current channel open outputs just P2WSH > 2-of-2 multisigs, and in the future won't they be generic P2TR outputs? > How would a stake certificate prove that the UTXO was generated for LN > rather than just belonging to a user with a 2-of-2 multisig wallet or > any key-path-spendable taproot wallet?) > > According to some random website, the current total channel balance of > the public LN is about 1,000 BTC. Although I'm sure this will grow with > time, it seems to me that an attacker who can rent access to stake > certificates for a one-week attack at, say, a 5% annual interest rate > would only need to pay 1 BTC to acquire stake certificates equal to all > honest users at present. That cost doesn't seem high enough to me to > effectively prevent attacks. Am I missing something? > > Thanks, > > -Dave ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
