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
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
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, > > 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 > ___ 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
Good morning Andres, t-bast, Gleb, et al, > > But instead it could be a point-to-point property: each node provides its > > own stake certificate > > to the next node (and only to that node). Alice provides a stake > > certificate to Bob, then Bob > > provides a stake certificate to Carol, and so on. If that's the case, it > > can be in a tlv field in the > > `update_add_htlc` message and doesn't need to be inside the onion. This > > also makes it less > > likely that Alice is exposing herself to remote nodes in the route (payer > > privacy). > > If the above paragraph is confirmed, then does this mean StakeCertificates > with privacy are possible without ZK proofs? > Or did I miss something? Logically speaking, for this model, a proof is unnecessary --- the node offering the HTLC already has a channel that contains funds that is locked. Specifically, it is the channel itself where the HTLC is being instantiated, that contains funds owned by the offerer, and which are locked for use in the Lightning Network. Since the receiver of the HTLC offer is already aware of this channel and its existence, it requires no proof at all. Thus, I have my doubts on this model --- it seems to me that the current Lightning Network is already equivalent to this model, and the current Lightning Network is (supposedly) attackable by these "griefing" attacks. Another example is that, if the offerring node has a number of published channels, that is sufficient proof as well, without requiring any privacy-preserving proofs. This is precisely the current Lightning Network, yet we consider the current Lightning Network attackable by griefing. Instead, payers, or payees (i.e. by providing the proof in an invoice) must set aside separate non-trivial stake, not tied to channels, but provably tied only to this stake certificate mechanism, in order to assuage the fear of forwarding nodes that the HTLCs will not be claimed immediately. Regards, ZmnSCPxj ___ 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
Good morning list, This is an interesting approach to solve this problem, I really like the idea. It definitely deserves digging more into it: the fact that it doesn't add an additional payment makes it largely superior to upfront payment schemes in terms of UX. If we restrict these stake certificates to LN funding txs, which have a very specific format (multisig 2-of-2) there are probably smart ways to achieve this. If for example we're able to do it easily with Schnorr-based funding txs, it may be worth waiting for that to happen. I'm a bit afraid of having to use ZKPs for general statements, I'd prefer something tailored to that specific case (it would likely be more efficient and have less new assumptions - even though you're right to point out that this is a non-critical system, so we're freer to experiment with hot new stuff). I completely agree with Z that it should be added to the requirements that a node cannot reuse a stake certificate from another node for himself. Another constraint is that the proof has to be small, since we have to fit > it all in a small onion... > I'm not sure that's necessary. If I understand correctly, you're saying that because in your model, the sender (Alice) creates one stake certificate for each node in the route (Bob, Carol) and puts them in the onion. But instead it could be a point-to-point property: each node provides its own stake certificate to the next node (and only to that node). Alice provides a stake certificate to Bob, then Bob provides a stake certificate to Carol, and so on. If that's the case, it can be in a tlv field in the `update_add_htlc` message and doesn't need to be inside the onion. This also makes it less likely that Alice is exposing herself to remote nodes in the route (payer privacy). Of course, this depends on the implementation details we choose, but I think it's worth stressing that these two models exist and are quite different. Thanks, Bastien Le ven. 27 nov. 2020 à 07:46, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > Good morning Gleb, > > > Thank you for your interest :) > > > > > Quick question: if I am a routing node and receive a valid stake > certificate, can I reuse this stake certificate on my own outgoing payments? > > > > That probably should be avoided, otherwise a mediocre routing node gets > a lot of jamming opportunities for no good. > > > > You are right, that’s a strong argument for proof “interactivity”: every > Certificate should probably commit to *at least* public key of the routing > node it is generated for. > > Right, it would be better to have the certificate commit to a specific > routing node rather than the payment hash/point as I proposed. > Committing to a payment hash/point allows a random forwarding node to > probe the rest of the network using the same certificate, lowering the > score for that certificate on much of the network. > > Another constraint is that the proof has to be small, since we have to fit > it all in a small onion... > > Presumably we also want the score to eventually "settle to 0" over time. > > Regards, > ZmnSCPxj > > > > > – gleb > > On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj , > wrote: > > > > > Good morning Gleb and Antoine, > > > > > > This is certainly interesting! > > > > > > Quick question: if I am a routing node and receive a valid stake > certificate, can I reuse this stake certificate on my own outgoing payments? > > > > > > It seems to me that the proof-of-stake-certificate should also somehow > integrate a detail of the current payment (such as payment hash/point) so > it cannot be reused by routing nodes for their own outgoing payments. > > > > > > For example, looking only at your naive privacy-broken proposal, the > signature must use a `sign-to-contract` where the `R` in the signature is > actually `R' + h(R' | payment_hash)` with the `R'` also revealed. > > > > > > Regards, > > > ZmnSCPxj > > > > > > > Hello list, > > > > > > > > In this post, we explore a different approach to channel jamming > mitigation. > > > > We won’t talk about the background here, for the problem description > as well as some proposed solutions (mainly upfront payment schemes), see > [1]. > > > > > > > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake > Certificates) to solve this problem. Previously, these proofs were only > used in the Lightning Network at channel announcement time to prevent > malicious actors from announcing channels they don’t control. One can think > of it as a “fidelity bond” (as a scarce resource) as a requirement for > sending HTLCs. > > > > > > > > We start by overviewing issues with other solutions, and then > present a naive, privacy-broken Stake Certificates. Then we examine > designing a privacy-preserving version, evaluating them. At the end, we > talk about non-trivial design decisions and open questions. > > > > > > > > ## Issues with other proposals > > > > > > > > We find unsatisfying that upfront
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Thank you for your interest :) > Quick question: if I am a routing node and receive a valid stake certificate, > can I reuse this stake certificate on my own outgoing payments? That probably should be avoided, otherwise a mediocre routing node gets a lot of jamming opportunities for no good. You are right, that’s a strong argument for proof “interactivity”: every Certificate should probably commit to *at least* public key of the routing node it is generated for. – gleb On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj , wrote: > Good morning Gleb and Antoine, > > This is certainly interesting! > > Quick question: if I am a routing node and receive a valid stake certificate, > can I reuse this stake certificate on my own outgoing payments? > > It seems to me that the proof-of-stake-certificate should also somehow > integrate a detail of the current payment (such as payment hash/point) so it > cannot be reused by routing nodes for their own outgoing payments. > > For example, looking only at your naive privacy-broken proposal, the > signature must use a `sign-to-contract` where the `R` in the signature is > actually `R' + h(R' | payment_hash)` with the `R'` also revealed. > > Regards, > ZmnSCPxj > > > Hello list, > > > > In this post, we explore a different approach to channel jamming mitigation. > > We won’t talk about the background here, for the problem description as > > well as some proposed solutions (mainly upfront payment schemes), see [1]. > > > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to > > solve this problem. Previously, these proofs were only used in the > > Lightning Network at channel announcement time to prevent malicious actors > > from announcing channels they don’t control. One can think of it as a > > “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs. > > > > We start by overviewing issues with other solutions, and then present a > > naive, privacy-broken Stake Certificates. Then we examine designing a > > privacy-preserving version, evaluating them. At the end, we talk about > > non-trivial design decisions and open questions. > > > > ## Issues with other proposals > > > > We find unsatisfying that upfront payment schemes come at a cost of new > > fees (forward and/or backward), thus inflating payment cost for *any* > > payment. > > In the future, the upfront base fee might even make “micropayments” > > economically infeasible by exceeding the value they transfer. Thus, a good > > solution should not inflate payment cost while still requiring “burning” a > > scarce resource (so that the attack is not free). > > > > Another issue with upfront payments is a circular trust dependency. > > Ideally, we shouldn’t introduce anything less trust-minimized than the > > Lightning Network itself. > > Upfront payment schemes are not like that, because they in one way or > > another rely on the honest behavior of route participants. > > > > We believe Stake Certificates we are going to introduce are satisfactory in > > both of these directions: they don’t inflate payment costs for honest users > > and don’t require trust. The main disadvantage of Stake Certificates seems > > to be the novel cryptography required. > > See more details in the “Evaluation” section. > > > > ## Channel Ownership Proofs as Routing Credit Balance > > > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake > > Certificates scheme, she has to commit to a particular channel UTXO by > > embedding an ownership proof in the onion packet while sending an HTLC to > > Bob. > > > > Bob then unwraps the onion and verifies: > > 1) the channel identifier is pointing unambiguously to an on-chain UTXO; > > 2) the ownership proof (e.g., a signature) is valid against the previously > > disclosed UTXO witness script. > > > > If all those checks succeed, Bob should see if Alice hasn’t exceeded her > > credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit > > balance” and relay the HTLC to Carol. > > Decrementing credit balance unconditionally of packet success or failure > > bounds liquidity abuse by malicious HTLC senders. > > Since there is no credit assigned initially, “decrementing the credit > > balance” means just remembering that “Alice spent X out of Y of the credit > > she received for her Stake Certificates”. > > > > Unfortunately, this naive protocol is a privacy nightmare, because routing > > nodes can now easily assign every HTLC they forward to the sender’s UTXO. > > > > Let’s first define the terms here one more time, and then proceed to the > > non-naive, private Stake Certificates. > > > > - Stake Certificate. Either means a solution we’re proposing or the > > primitive it is based on, namely proof of UTXO ownership. As we will argue > > later, it actually makes sense to use proof of LN channel UTXO ownership > > specifically rather than any funds ownership. > > - Stake Certificate value. An
