📅 Original date posted:2023-06-07
🗒️ Summary of this message: The use of v3 transactions for channel funding and splicing could be a mid-term solution to mempool pinning issues. In the longer term, an anti-DoS token may be needed. Disabling inbound payments or using longer `cltv_expiry_delta` can also be implemented as a policy.
📝 Original message:
Hey Antoine,
Sure, I agree with you, the usual mempool pinning issues still apply
regardless of whether we use 0-conf or not. And we must solve them
all at some point!
I think a reasonable mid-term solution is to use v3 transactions for
channel funding and splicing, with the obvious caveat that it makes
them identifiable on-chain (unless in the longer term, everyone moves
to v3 transactions for everything, which doesn't seem crazy to me?).
In the longer term, we know that some kind of anti-DoS token will need
to be exchanged to avoid this whole class of issue, but as we've often
discussed this isn't an easy thing to design and analyze...
> it can still be valuable to disable inbound payments, or requires a
> longer `cltv_expiry_delta` than usual, in case of mempool fee spikes
> delaying the 0-conf chain confirmation.
Sure, that's a policy that nodes can decide to apply if they want to,
and it should be simple enough to implement (no protocol changes are
needed).
Thanks,
Bastien
Le mer. 7 juin 2023 à 02:41, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hi Bastien,
>
> > This can be fixed by using a "soft lock" when selecting utxos for a non
> > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > utxos.
>
> If my understanding of the "soft lock" strategy is correct - Only locking
> UTXO when it's a non 0-conf funding attempt - I think you're still exposed
> to liquidity griefing with dual-funding or splicing.
>
> The vector of griefing you're mentioning is the lack of signature release
> for a shared input by your counterparty. However, in the context of
> dual-funding where the counterparty can add any output with
> `tx_add_output`, the transaction can be pinned in the mempool in a very
> sneaky way e.g abuse of replacement rule 3.
>
> This latter pinning vector is advantageous to the malicious counterparty
> as I think you can batch your pinning against unrelated dual-funding, only
> linked in the mempool by a malicious pinning CPFP.
>
> It is left as an exercise to the reader to find other vectors of pinnings
> that can be played out in the dual-funding flow.
>
> In terms of (quick) solution to prevent liquidity griefing related to
> mempool vectors, the (honest) counterparty can enforce that any contributed
> outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.
> Still, this mitigation can be limited as I think the initial commitment
> transaction must have anchor outputs on each-side, for each party to
> recover its contributed UTXOs in any case.
>
> > Then we immediately send `channel_ready` as well and start using that
> > channel (because we know we won't double spend ourselves). This is nice
> > because it lets us use 0-conf in a way where only one side of the
> > channel needs to trust the other side (instead of both sides trusting
> > each other).
>
> From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it
> can still be valuable to disable inbound payments, or requires a longer
> `cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the
> 0-conf chain confirmation.
>
> Beyond, it sounds liquidity griefing provoked by a lack of signature
> release or mempool funny games will always be there ? Even for the second
> with package relay/nVersion deployment, there is still the duration between
> the pinning happening among network mempools and your replacement broadcast
> kickstarts.
>
> As a more long-term solution, we might reuse solutions worked out to
> mitigate channel jamming, as the abstract problem is the same, namely your
> counterparty can lock up scarce resources without (on-chain/off-chain
> whatever) fees paid.
>
> E.g the Staking Credentials framework could be deployed by dual-funding
> market-makers beyond routing hops [0]. The dual-funding initiator should
> pay to the maker a fee scale up on the amount of UTXOs contributed, and
> some worst-case liquidity griefing scenario. A privacy-preserving
> credential can be introduced between the payment of the fee and the redeem
> of the service to unlink dual-funding initiators (if the maker has enough
> volume to constitute a reasonable anonymity set).
>
> Best,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
>
>
> Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bastien at acinq.fr> a
> écrit :
>
>> Good morning list,
>>
>> One of the challenges created by the introduction of dual funded
>> transactions [1] in lightning is how to protect against liquidity
>> griefing attacks from malicious peers [2].
>>
>> Let's start by reviewing this liquidity griefing issue. The dual funding
>> protocol starts by exchanging data about the utxos each peer adds to the
>> shared transaction, then exchange signatures and broadcast the resulting
>> transaction. If peers lock their utxos as soon as they've decided to add
>> them to the shared transaction, the remote node may go silent. If that
>> happens, the honest node has some liquidity that is locked and unusable.
>>
>> This cannot easily be fixed by simply unlocking utxos *after* detecting
>> that the remote node is fishy, because the remote node would still have
>> succeeded at locking your liquidity for a (small) duration, and could
>> start other instances of that attack with different node_ids.
>>
>> An elegant solution to this issue is to never lock utxos used in dual
>> funded transactions. If a remote node goes silent in the middle of an
>> instance of the protocol, your utxos will automatically be re-used in
>> another instance of the protocol. The only drawback with that approach
>> is that when you have multiple concurrent instances of dual funding with
>> honest peers, some of them may fail because they are double-spent by one
>> of the concurrent instances. This is acceptable, since the protocol
>> should complete fairly quickly when peers are honest, and at worst, it
>> can simply be restarted when failure is detected.
>>
>> But that solution falls short when using 0-conf, because accidentally
>> double-spending a 0-conf channel (because of concurrent instances) can
>> result in loss of funds for one of the peers (if payments were made on
>> that channel before detecting the double-spend). It seems like using
>> 0-conf forces us to lock utxos to avoid this issue, which means that
>> nodes offering 0-conf services expose themselves to liquidity griefing.
>>
>> Another related issue is that nodes that want to offer 0-conf channels
>> must ensure that the utxos they use for 0-conf are isolated from the
>> utxos they use for non 0-conf, otherwise it is not possible to properly
>> lock utxos, because of the following race scenario:
>>
>> - utxoA is selected for a non 0-conf funding attempt and not locked
>> (to protect against liquidity griefing)
>> - utxoA is also selected for a 0-conf funding attempt (because it is
>> found unlocked in the wallet) and then locked
>> - the funding transaction for the 0-conf channel is successfully
>> published first and that channel is instantly used for payments
>> - the funding transaction for the non 0-conf channel is then published
>> and confirms, accidentally double-spending the 0-conf channel
>>
>> This can be fixed by using a "soft lock" when selecting utxos for a non
>> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
>> utxos while non 0-conf funding attempts can (should) reuse soft locked
>> utxos.
>>
>> In eclair, we are currently doing "opportunistic" 0-conf:
>>
>> - if we receive `channel_ready` immediately (which means that our peer
>> trusts us to use 0-conf)
>> - and we're the only contributor to the funding transaction (our peer
>> doesn't have any input that they could use to double-spend)
>> - and the transaction hasn't been RBF-ed yet
>>
>> Then we immediately send `channel_ready` as well and start using that
>> channel (because we know we won't double spend ourselves). This is nice
>> because it lets us use 0-conf in a way where only one side of the
>> channel needs to trust the other side (instead of both sides trusting
>> each other).
>>
>> Unfortunately, we cannot do that anymore when mixing 0-conf and non
>> 0-conf funding attempts, because the utxos may be soft locked,
>> preventing us from "upgrading" to 0-conf.
>>
>> You have successfully reached the end of this quite technical post,
>> congrats! My goal with this post is to gather ideas on how we could
>> improve that situation and offer good enough protections against
>> liquidity griefing for nodes offering 0-conf services. Please share
>> your ideas! And yes, I know, 0-conf is a massive implementation pain
>> point that we would all like to remove from our codebases, but hey,
>> users like it ¯\_(ツ)_/¯
>>
>> Cheers,
>> Bastien
>>
>> [1] https://github.com/lightning/bolts/pull/851
>> [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230607/e913019a/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:13:28
in reply to nevent1q…mfk0
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:13:28Event JSON
{
"id": "528e56e7daa73dfccde6de354fe6193093300d2885c8e32d3d7abfdb0993297c",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686316408,
"kind": 1,
"tags": [
[
"e",
"55d90d46d53f806312150bd67ffa33d492b6eea40ca182665a9909573557c662",
"",
"root"
],
[
"e",
"a76d716036fadb5ced178b4531d7bb0b729df79c52303071dab174d2dbe8fc4f",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-06-07\n🗒️ Summary of this message: The use of v3 transactions for channel funding and splicing could be a mid-term solution to mempool pinning issues. In the longer term, an anti-DoS token may be needed. Disabling inbound payments or using longer `cltv_expiry_delta` can also be implemented as a policy.\n📝 Original message:\nHey Antoine,\n\nSure, I agree with you, the usual mempool pinning issues still apply\nregardless of whether we use 0-conf or not. And we must solve them\nall at some point!\n\nI think a reasonable mid-term solution is to use v3 transactions for\nchannel funding and splicing, with the obvious caveat that it makes\nthem identifiable on-chain (unless in the longer term, everyone moves\nto v3 transactions for everything, which doesn't seem crazy to me?).\n\nIn the longer term, we know that some kind of anti-DoS token will need\nto be exchanged to avoid this whole class of issue, but as we've often\ndiscussed this isn't an easy thing to design and analyze...\n\n\u003e it can still be valuable to disable inbound payments, or requires a\n\u003e longer `cltv_expiry_delta` than usual, in case of mempool fee spikes\n\u003e delaying the 0-conf chain confirmation.\n\nSure, that's a policy that nodes can decide to apply if they want to,\nand it should be simple enough to implement (no protocol changes are\nneeded).\n\nThanks,\nBastien\n\nLe mer. 7 juin 2023 à 02:41, Antoine Riard \u003cantoine.riard at gmail.com\u003e a\nécrit :\n\n\u003e Hi Bastien,\n\u003e\n\u003e \u003e This can be fixed by using a \"soft lock\" when selecting utxos for a non\n\u003e \u003e 0-conf funding attempt. 0-conf funding attempts must ignore soft locked\n\u003e \u003e utxos while non 0-conf funding attempts can (should) reuse soft locked\n\u003e \u003e utxos.\n\u003e\n\u003e If my understanding of the \"soft lock\" strategy is correct - Only locking\n\u003e UTXO when it's a non 0-conf funding attempt - I think you're still exposed\n\u003e to liquidity griefing with dual-funding or splicing.\n\u003e\n\u003e The vector of griefing you're mentioning is the lack of signature release\n\u003e for a shared input by your counterparty. However, in the context of\n\u003e dual-funding where the counterparty can add any output with\n\u003e `tx_add_output`, the transaction can be pinned in the mempool in a very\n\u003e sneaky way e.g abuse of replacement rule 3.\n\u003e\n\u003e This latter pinning vector is advantageous to the malicious counterparty\n\u003e as I think you can batch your pinning against unrelated dual-funding, only\n\u003e linked in the mempool by a malicious pinning CPFP.\n\u003e\n\u003e It is left as an exercise to the reader to find other vectors of pinnings\n\u003e that can be played out in the dual-funding flow.\n\u003e\n\u003e In terms of (quick) solution to prevent liquidity griefing related to\n\u003e mempool vectors, the (honest) counterparty can enforce that any contributed\n\u003e outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.\n\u003e Still, this mitigation can be limited as I think the initial commitment\n\u003e transaction must have anchor outputs on each-side, for each party to\n\u003e recover its contributed UTXOs in any case.\n\u003e\n\u003e \u003e Then we immediately send `channel_ready` as well and start using that\n\u003e \u003e channel (because we know we won't double spend ourselves). This is nice\n\u003e \u003e because it lets us use 0-conf in a way where only one side of the\n\u003e \u003e channel needs to trust the other side (instead of both sides trusting\n\u003e \u003e each other).\n\u003e\n\u003e From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it\n\u003e can still be valuable to disable inbound payments, or requires a longer\n\u003e `cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the\n\u003e 0-conf chain confirmation.\n\u003e\n\u003e Beyond, it sounds liquidity griefing provoked by a lack of signature\n\u003e release or mempool funny games will always be there ? Even for the second\n\u003e with package relay/nVersion deployment, there is still the duration between\n\u003e the pinning happening among network mempools and your replacement broadcast\n\u003e kickstarts.\n\u003e\n\u003e As a more long-term solution, we might reuse solutions worked out to\n\u003e mitigate channel jamming, as the abstract problem is the same, namely your\n\u003e counterparty can lock up scarce resources without (on-chain/off-chain\n\u003e whatever) fees paid.\n\u003e\n\u003e E.g the Staking Credentials framework could be deployed by dual-funding\n\u003e market-makers beyond routing hops [0]. The dual-funding initiator should\n\u003e pay to the maker a fee scale up on the amount of UTXOs contributed, and\n\u003e some worst-case liquidity griefing scenario. A privacy-preserving\n\u003e credential can be introduced between the payment of the fee and the redeem\n\u003e of the service to unlink dual-funding initiators (if the maker has enough\n\u003e volume to constitute a reasonable anonymity set).\n\u003e\n\u003e Best,\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html\n\u003e\n\u003e\n\u003e Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Good morning list,\n\u003e\u003e\n\u003e\u003e One of the challenges created by the introduction of dual funded\n\u003e\u003e transactions [1] in lightning is how to protect against liquidity\n\u003e\u003e griefing attacks from malicious peers [2].\n\u003e\u003e\n\u003e\u003e Let's start by reviewing this liquidity griefing issue. The dual funding\n\u003e\u003e protocol starts by exchanging data about the utxos each peer adds to the\n\u003e\u003e shared transaction, then exchange signatures and broadcast the resulting\n\u003e\u003e transaction. If peers lock their utxos as soon as they've decided to add\n\u003e\u003e them to the shared transaction, the remote node may go silent. If that\n\u003e\u003e happens, the honest node has some liquidity that is locked and unusable.\n\u003e\u003e\n\u003e\u003e This cannot easily be fixed by simply unlocking utxos *after* detecting\n\u003e\u003e that the remote node is fishy, because the remote node would still have\n\u003e\u003e succeeded at locking your liquidity for a (small) duration, and could\n\u003e\u003e start other instances of that attack with different node_ids.\n\u003e\u003e\n\u003e\u003e An elegant solution to this issue is to never lock utxos used in dual\n\u003e\u003e funded transactions. If a remote node goes silent in the middle of an\n\u003e\u003e instance of the protocol, your utxos will automatically be re-used in\n\u003e\u003e another instance of the protocol. The only drawback with that approach\n\u003e\u003e is that when you have multiple concurrent instances of dual funding with\n\u003e\u003e honest peers, some of them may fail because they are double-spent by one\n\u003e\u003e of the concurrent instances. This is acceptable, since the protocol\n\u003e\u003e should complete fairly quickly when peers are honest, and at worst, it\n\u003e\u003e can simply be restarted when failure is detected.\n\u003e\u003e\n\u003e\u003e But that solution falls short when using 0-conf, because accidentally\n\u003e\u003e double-spending a 0-conf channel (because of concurrent instances) can\n\u003e\u003e result in loss of funds for one of the peers (if payments were made on\n\u003e\u003e that channel before detecting the double-spend). It seems like using\n\u003e\u003e 0-conf forces us to lock utxos to avoid this issue, which means that\n\u003e\u003e nodes offering 0-conf services expose themselves to liquidity griefing.\n\u003e\u003e\n\u003e\u003e Another related issue is that nodes that want to offer 0-conf channels\n\u003e\u003e must ensure that the utxos they use for 0-conf are isolated from the\n\u003e\u003e utxos they use for non 0-conf, otherwise it is not possible to properly\n\u003e\u003e lock utxos, because of the following race scenario:\n\u003e\u003e\n\u003e\u003e - utxoA is selected for a non 0-conf funding attempt and not locked\n\u003e\u003e (to protect against liquidity griefing)\n\u003e\u003e - utxoA is also selected for a 0-conf funding attempt (because it is\n\u003e\u003e found unlocked in the wallet) and then locked\n\u003e\u003e - the funding transaction for the 0-conf channel is successfully\n\u003e\u003e published first and that channel is instantly used for payments\n\u003e\u003e - the funding transaction for the non 0-conf channel is then published\n\u003e\u003e and confirms, accidentally double-spending the 0-conf channel\n\u003e\u003e\n\u003e\u003e This can be fixed by using a \"soft lock\" when selecting utxos for a non\n\u003e\u003e 0-conf funding attempt. 0-conf funding attempts must ignore soft locked\n\u003e\u003e utxos while non 0-conf funding attempts can (should) reuse soft locked\n\u003e\u003e utxos.\n\u003e\u003e\n\u003e\u003e In eclair, we are currently doing \"opportunistic\" 0-conf:\n\u003e\u003e\n\u003e\u003e - if we receive `channel_ready` immediately (which means that our peer\n\u003e\u003e trusts us to use 0-conf)\n\u003e\u003e - and we're the only contributor to the funding transaction (our peer\n\u003e\u003e doesn't have any input that they could use to double-spend)\n\u003e\u003e - and the transaction hasn't been RBF-ed yet\n\u003e\u003e\n\u003e\u003e Then we immediately send `channel_ready` as well and start using that\n\u003e\u003e channel (because we know we won't double spend ourselves). This is nice\n\u003e\u003e because it lets us use 0-conf in a way where only one side of the\n\u003e\u003e channel needs to trust the other side (instead of both sides trusting\n\u003e\u003e each other).\n\u003e\u003e\n\u003e\u003e Unfortunately, we cannot do that anymore when mixing 0-conf and non\n\u003e\u003e 0-conf funding attempts, because the utxos may be soft locked,\n\u003e\u003e preventing us from \"upgrading\" to 0-conf.\n\u003e\u003e\n\u003e\u003e You have successfully reached the end of this quite technical post,\n\u003e\u003e congrats! My goal with this post is to gather ideas on how we could\n\u003e\u003e improve that situation and offer good enough protections against\n\u003e\u003e liquidity griefing for nodes offering 0-conf services. Please share\n\u003e\u003e your ideas! And yes, I know, 0-conf is a massive implementation pain\n\u003e\u003e point that we would all like to remove from our codebases, but hey,\n\u003e\u003e users like it ¯\\_(ツ)_/¯\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e [1] https://github.com/lightning/bolts/pull/851\n\u003e\u003e [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230607/e913019a/attachment.html\u003e",
"sig": "885af4b7610f9257044e7c67bdc93f419a775747925d0ce0edbdbf4dec87de4ed8bf8b3b690aa789f20f50028be5ced37b816173160f340552284fac307130fd"
}