Hi Zeeman, I think it is correct to say that if any mechanism to protect against channel jamming succeeds, the remaining instance of apparent channel jamming might be accidental. This rate of accident might be still high due to spontaneous congestion (i.e more HTLC senders than slots/liquidity available for the core links of the network). With the present credential tokens scheme the rate of spontaneous failure should still have to be encumbered by some entity. By default it would be the HTLC sender, as is the one attaching the tokens, and this sounds to be aligned with incentive as is the one building a payment path of _reliable_ routing hop.
On the second issue, namely a node B who is a competitor of node A and accepting node A credentials to provoke a jamming attack against A, I don't think this is plausible. As long as node A is requesting its _own_ tokens to accept HTLC forward, there is a compensation for the risk. The behavior of node B accepting node A to drain traffic through node A, in an attempt to jam it, would in the present situation benefit node A due to the credentials acquisition cost. There is a different idea, I think you're describing, the trust-minimized exchange of credentials tokens between receivers. Effectively here we can imagine a Chaumian bank-style construction where the tokens are transferred in a privacy-fashion, and double-spend flagged out by the bank. However, this wouldn't prevent a token double-spend against another bank. So it sounds to me you need some kind of underlying reputation or enforcement mechanism to make the economics of the bank work ? I.e the bank being a LSP and force-closing channels in case of double-spend. It should be noted, even if we assume federation of Chaumian banks leading to a global secondary market for token transfers, the routing hops should be still economically safe against jamming attacks, as long as the token acquisition cost is paid at issuance. Best, Antoine Le jeu. 1 déc. 2022 à 07:28, ZmnSCPxj <zmnsc...@protonmail.com> a écrit : > > Good morning Antoine, > > > About secondary-markets, the credentials themselves are subject to the > classic double-spend problem. E.g, Alice can transfer her "Ned" credentials > both to Bob and Caroll, without any of them getting knowledge of the > duplication. So it could be expected secondary markets to only happen > between LSP and their spokes (where "trust" relationships already exist), > as such harder to formalize. > > If this is a problem, would the use of the WabiSabi technique help? > If my understanding was correct, the WabiSabi paper described a Chaumian > bank that issues coins of variable amount, with clients able to merge and > split coins without revealing the amount to the bank/issuer, while allowing > for non-double-spendable transfer of coins by having the bank sign off on > all transfers between clients (without the bank becoming aware of the value > being transferred or the pseudonyms of either client). > > > If transfer of tokens can be made non-double-spendable, then it may be > feasible for a forwarding node to accept tokens issued by a different > forwarding node, if the sender also transfers control of those tokens to > the forwarding node. > i.e. if a sender has credentials for node A but needs to forward via node > B, then node B may be willing to accept credentials issued by node A. > This is similar to the situation where "free banks", in the absence of a > central bank, are willing to accept paper bearer bonds issued by another > bank, as this lets them attack the other bank by withdrawing the value > backing the bond and attempt to trigger a bank run on that other bank (and > thus remove them from competition). > Similarly, node B who is a competitor of node A may be willing to accept > credentials issued by node A, in a forward that goes through node B, as the > transferred credentials would allow node B to perform a jamming attack on > node A (and thus remove them from competition). > Both node A and B can then peacefully resolve the difference without > attacking via a "clearing house" where they reveal how much of the > credential issued by the other they have, in much the same way as free > banks would resolve paper bearer bonds. > > Regards, > ZmnSCPxj >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
