Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Good morning LL, > Back to the general topic. Perhaps a way of refining the proposal is the > following: > > 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of > design. > 2. The owner (owners?) of leach LN UTXO can go to any node in the network and > request a kind of token for their UTXO (i.e. channel id). Not all forwarding nodes have a directly-contactable address published, and many publish only an .onion address; many payers do not bother to run Tor and cannot directly contact .onion addresses. On the other hand, it would be possible to use an onion routing (without an attached HTLC) to remotely contact such forwarding nodes, and presumably other nodes will be willing to provide this almost for free since they would not need to lock up funds. > 3. When making a payment you present a randomized version of the token to > each node (it is not linkable to the UTXO) and prove that the UTXO it > represents is large enough to support the payment (the token and proof > protocol can hopefully be non-interactive so it can fit in the onion). > 4. If your HTLC fails your token is deleted (and have to wait some period > before requesting a new one). > 5. If your payment succeeds your token is renewed on the spot (and maybe > forwarded back along the path covertly). I think it should not be success or failure that matters. I can still mount the same attack by forwarding a payment to another node I control, with the last hop having a large timeout, waiting out the entire timeout, and then *succeeding* the payment just before the payment times out. The funds are still locked for nearly the entire timeout period, during which my competitors (whether as merchant or as forwarder node --- forwarder nodes are really just merchants of liquidity) are unable to use the liquidity during this timeout period. I end up paying fees, but the fees on Lightning are ridiculously tiny and may very well remain so for a good amount of time. Instead, a particular UTXO size provides so many msat-seconds of lockup credit. As a forwarding node, if I have issued a credential for a UTXO of particular size, offering so many msat-seconds of lockup, if I receive the unblinded credential, after I send out the outgoing HTLC, I measure its size and how long before it gets resolved (in either success or failure), multiply those together, and debit that particular credential. (it might be plausible for failure for me to add a little more extra surcharge to the msat-seconds credit of that credential, but nevertheless --- I must still treat a *slow* success as something as bad, or almost as bad, as a *slow* failure) If that credential later reappears on an incoming HTLC and it has been debited to 0 or negative, I just fail it without risking sending out my funds in an outgoing HTLC. This prevents the above trivial variation of the loop attack. However, this exacerbates the effects of accidental incompetence-based failures of other forwarding nodes. Otherwise I largely agree that anonymous credentials seems a better way to build stake certificates. 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
> Loop attacks are not about loops, it only requires that the start and end of a payment are controlled by the same entity Thanks for clearing that up. I was referring to cycles in the payment paths where you get honest parties to forward your HTLC between themselves over and over again as part of a single paryment. I have just realized that it's easy to prevent by just looking for duplicate payment hashes. This will be a problem for randomized PTLCs though. > * There are two griefing attacks: > * Loop attacks, which are deliberate malicious attacks to lock up funds of competitors in order to redirect forwarding towards the attacker. > * Accidental "attacks", which are accidental due to incompetence, where a forwarding node accidentally goes offline and causes payments to be locked up for long periods and making everyone on the network cry when HTLCs time out and things have to be dropped onchain Another one recently pointed out in [1] is to jam a channels towards a competing merchant. Users who are trying to buy from the merchant will give up because of technical failure and instead come to your site where you will sell successfully for a higher price. This seems more plausible to me than completing for fees. Back to the general topic. Perhaps a way of refining the proposal is the following: 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of design. 2. The owner (owners?) of leach LN UTXO can go to any node in the network and request a kind of token for their UTXO (i.e. channel id). 3. When making a payment you present a randomized version of the token to each node (it is not linkable to the UTXO) and prove that the UTXO it represents is large enough to support the payment (the token and proof protocol can hopefully be non-interactive so it can fit in the onion). 4. If your HTLC fails your token is deleted (and have to wait some period before requesting a new one). 5. If your payment succeeds your token is renewed on the spot (and maybe forwarded back along the path covertly). Not saying this will be easy (or even totally coherent) but I feel the direction is a bit more plausible. The benefit here is that you avoid the complicated ZKPs about UTXOs and are treading on a more well worn path of anonymous credentials and ecash. [1]: https://github.com/t-bast/lightning-docs/issues/7#issuecomment-736713076 LL On Tue, Dec 1, 2020 at 11:11 PM ZmnSCPxj wrote: > Good morning LL, and list, > > > > 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. > > Loop attacks are not about loops, it only requires that the start and end > of a payment are controlled by the same entity. > > Multiple nodes on the LN may be owned by the same entity. > Nodes, individually as nodes, are trivially cheap and just need 32 bytes > of entropy from a `/dev/random` near you. > It is the channels themselves, requiring actual funds, high uptime, and > not being a dick to your counterparty, that are fairly expensive. > > Thus, a "loop attack" need not involve a loop per se --- a single entity > can run any number of nodes with small numbers of channels each, and > thereby grief the network. > > Stake certificates make the node itself expensive, so a single entity > running a number of nodes cannot perform such loop attacks, since it would > require entities expensively allocating funds for each node. > > > > > On the other hand, if channels are expensive, then a node with channels is > expensive. > > In > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html > , which contains the "Z consideration" you were alluding to, I note that > the "point-to-point property" is already proven by the ***existing*** > Lightning network without an additional ZK cryptographic proof. > > So let me invert that logic and present an even more extreme position: > > * There are two griefing attacks: > * Loop attacks, which are deliberate malicious attacks to lock up funds > of competitors in order to redirect forwarding towards the attacker. > * Accidental "attacks", which are accidental due to incompetence, where > a forwarding node accidentally goes offline and causes payments to be > locked up for long periods and making everyone on the network cry when > HTLCs time out and things have to be dropped onchain. > * The point-to-point property, which is already proven by the > ***existing*** Lightning network, is already sufficient to prevent loop > attacks, leaving only accidental incompetence-based "attacks". > * Or: the ***existing*** Lightning Network ***already*** proves the > point-to-point property presented by t-bast, and that property is > ***already*** sufficient to prevent the loop attacks. > > So, maybe we should i
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Hello Zeeman, If I understand well the "point-to-point property" is the following : you can authenticate an incoming HTLC traffic from your neighbors owing to their expensive channels. My concern with this approach relies on the fact that a routing node isn't decisionary of the HTLC traffic going through itself. Thus its outgoing traffic might be far superior to its locked channel utxos and it will have to compensate HTLC receiver for the difference. You're back to some fees mechanism for everyone to do its account. The interesting property with stake certificates is to overlay the liquidity effective user with the HTLC sender. This last one should care about using liquidity resources reasonably, not the routing nodes. IMO, the more interesting point you're underscoring is that we shouldn't bind a HTLC traffic volume to a channel size. E.g you have a small channel but a high HTLC traffic spread through the day and that's lawful. What we may consider is a stake certificate/point-to-point control only relying on utxo uniqueness, and not the amount locked. If a utxo-authenticated HTLC-traffic is far beyond the median, just blacklist the utxo, thus forcing a utxo spend (and bearing onchain fees) by any liquidity abuser. Cheers, Antoine Le mar. 1 déc. 2020 à 07:11, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > Good morning LL, and list, > > > > 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. > > Loop attacks are not about loops, it only requires that the start and end > of a payment are controlled by the same entity. > > Multiple nodes on the LN may be owned by the same entity. > Nodes, individually as nodes, are trivially cheap and just need 32 bytes > of entropy from a `/dev/random` near you. > It is the channels themselves, requiring actual funds, high uptime, and > not being a dick to your counterparty, that are fairly expensive. > > Thus, a "loop attack" need not involve a loop per se --- a single entity > can run any number of nodes with small numbers of channels each, and > thereby grief the network. > > Stake certificates make the node itself expensive, so a single entity > running a number of nodes cannot perform such loop attacks, since it would > require entities expensively allocating funds for each node. > > > > > On the other hand, if channels are expensive, then a node with channels is > expensive. > > In > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html > , which contains the "Z consideration" you were alluding to, I note that > the "point-to-point property" is already proven by the ***existing*** > Lightning network without an additional ZK cryptographic proof. > > So let me invert that logic and present an even more extreme position: > > * There are two griefing attacks: > * Loop attacks, which are deliberate malicious attacks to lock up funds > of competitors in order to redirect forwarding towards the attacker. > * Accidental "attacks", which are accidental due to incompetence, where > a forwarding node accidentally goes offline and causes payments to be > locked up for long periods and making everyone on the network cry when > HTLCs time out and things have to be dropped onchain. > * The point-to-point property, which is already proven by the > ***existing*** Lightning network, is already sufficient to prevent loop > attacks, leaving only accidental incompetence-based "attacks". > * Or: the ***existing*** Lightning Network ***already*** proves the > point-to-point property presented by t-bast, and that property is > ***already*** sufficient to prevent the loop attacks. > > So, maybe we should instead focus on mitigating the effects of the > incompetence-based non-attacks [such as this proposal]( > https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980), > instead of attempting to defend against the mirage of loop attacks. > > > I could be utterly wrong here though. > > > Regards, > ZmnSCPxj > ___ > 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 LL, and list, > 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. Loop attacks are not about loops, it only requires that the start and end of a payment are controlled by the same entity. Multiple nodes on the LN may be owned by the same entity. Nodes, individually as nodes, are trivially cheap and just need 32 bytes of entropy from a `/dev/random` near you. It is the channels themselves, requiring actual funds, high uptime, and not being a dick to your counterparty, that are fairly expensive. Thus, a "loop attack" need not involve a loop per se --- a single entity can run any number of nodes with small numbers of channels each, and thereby grief the network. Stake certificates make the node itself expensive, so a single entity running a number of nodes cannot perform such loop attacks, since it would require entities expensively allocating funds for each node. On the other hand, if channels are expensive, then a node with channels is expensive. In https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html , which contains the "Z consideration" you were alluding to, I note that the "point-to-point property" is already proven by the ***existing*** Lightning network without an additional ZK cryptographic proof. So let me invert that logic and present an even more extreme position: * There are two griefing attacks: * Loop attacks, which are deliberate malicious attacks to lock up funds of competitors in order to redirect forwarding towards the attacker. * Accidental "attacks", which are accidental due to incompetence, where a forwarding node accidentally goes offline and causes payments to be locked up for long periods and making everyone on the network cry when HTLCs time out and things have to be dropped onchain. * The point-to-point property, which is already proven by the ***existing*** Lightning network, is already sufficient to prevent loop attacks, leaving only accidental incompetence-based "attacks". * Or: the ***existing*** Lightning Network ***already*** proves the point-to-point property presented by t-bast, and that property is ***already*** sufficient to prevent the loop attacks. So, maybe we should instead focus on mitigating the effects of the incompetence-based non-attacks [such as this proposal](https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980), instead of attempting to defend against the mirage of loop attacks. I could be utterly wrong here though. 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
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] 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
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
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 signature.asc Description: PGP signature ___ 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
Hey, On Fri, 27 Nov 2020 at 19:18, Bastien TEINTURIER wrote: > 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). > If the above paragraph is confirmed, then does this mean StakeCertificates with privacy are possible without ZK proofs? Or did I miss something? > > 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.
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 payme
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
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 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 c
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
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
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 amount of the corresponding UTXO or a ballpark > this amount provably belongs to. > - Credit balance. When Alice provides a routing node Bob with a Stake > Certificate, Bob should increase Alice’s routing credit balance. Alice is > then limited in her payments by this balance, and this rule is enforced by > routing nodes to prevent free channel jamming in the network. Note that > ideally “Alice’s credit balance“ should be virtual and only known to Alice, > while routing nodes should only observe per-UTXO credit balance. We currently > assume that each routing node keeps track of per-UTXO credit balance > separately, see “Design decisions” for more details. > - Stake-to-credit function defin
