Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-01 📝 Original message: Hi Zeeman, I think it is ...
📅 Original date posted:2022-12-01
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221201/57ee379b/attachment.html>;
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221201/57ee379b/attachment.html>;