Greg Sanders [ARCHIVE] on Nostr: š Original date posted:2022-09-26 š Original message: > I think this mitigation ...
š
Original date posted:2022-09-26
š Original message:
> I think this mitigation requires reliable access to the UTXO set
In this case, how about just setting nsequence to the value 1? UTXO may not
exist, but maybe that's ok since it means it cannot pin the commitment tx.
> If this concern is correct, I'm not sure we have a current good solution,
the WIP package RBF proposal would be limited to only 2 descendants [1],
and here we might have 3 generations: the splice, a commitment, a CPFP.
I maybe misunderstood the point, but if we're assuming some future V3
transaction update, you could certainly add anchors to the splice and CPFP
it from there. I think the effort was to attempt to avoid waiting for such
an update.
Best,
Greg
On Mon, Sep 26, 2022 at 3:51 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Dustin,
>
> From my understanding, splice pinning is problematic for channel funds
> safety. In the sense once you have a splice floating in network mempools
> and your latest valid commitment transaction pre-signed fees isn't enough
> to replace the splice, lack of confirmation might damage the claim of HTLCs.
>
> I don't know if the current splice proposal discourages pending HTLCs
> during the splice lifetime, this would at least downgrade the pinning
> severity in the splicing case to a simple liquidity timevalue loss.
>
> W.r.t, about the mitigation proposed.
>
> > For āancestor bulkingā, every `tx_add_input` proposed by a peer must be
> > included in the UTXO set. A node MUST verify the presence of a proposed
> > input before adding it to the splicing transaction.
>
> I think this mitigation requires reliable access to the UTXO set, a
> significant constraint for LN mobile clients relying on lightweight
> validation backends. While this requirement already exists in matters of
> routing to authenticate channel announcements, on the LDK-side we have
> alternative infrastructure to offer source-based routing to such a class of
> clients, without them having to care about the UTXO set [0]. I don't
> exclude there would be infrastructure in the future to access a subset of
> the UTXO set (e.g if utreexo is deployed on the p2p network) for
> resource-constraint clients, however as of today this is still pure
> speculation and vaporware.
>
> In the meantime, mobile clients might not be able to partake in splicing
> operations with their LSPs, or without a decrease in trust-minimization
> (e.g assuming your LSP doesn't initiate malicious pinnings against you).
>
> > 1) You cannot CPFP a splice transaction. All splices must be RBFād to be
> > fee-bumped. The interactive tx protocol already provides a protocol for
> > initiating an RBF, which we re-use for splicing.
>
> The issue with RBF, it assumes interactivity with your counterparties. As
> splicing is built on top of the interactive transaction construction
> protocol, from my understanding you could have a high order of participants
> to coordinate with, without knowledge of their signing policies (e.g if
> they're time-constraints) therefore any re-signing operations might have
> odds to fail. Moreover, one of these participants could be malicious and
> refuses straightly to sign, therefore the already splicing transactions
> stay as a pin in the network mempools.
>
> If this concern is correct, I'm not sure we have a current good solution,
> the WIP package RBF proposal would be limited to only 2 descendants [1],
> and here we might have 3 generations: the splice, a commitment, a CPFP.
>
> [0] https://github.com/lightningdevkit/rapid-gossip-sync-server
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>
> Le mar. 9 aoĆ»t 2022 Ć 16:15, Dustin Dettmer <dustin at koinkeep.com> a
> Ć©crit :
>
>> As raised by @crypto-iq and @roasbeef, splices which permit arbitrary
>> script and input inclusion are at risk of being mempool pinned. Here we
>> present a solution to this splice pinning problem.
>>
>>
>> ## Background
>>
>> Pinning can be done by building a very large ājunkā transaction that
>> spends from an important pending one. There are two known pinning vectors:
>> ancestor bulking thru addition of new inputs and junk pinning via the
>> spending of outputs.
>>
>>
>> Pinning pushes transactions to the bottom of the priority list without a
>> practical way of bumping it up. It is in effect a griefing attack, but in
>> the case of lightning can risk funds loss for HTLCs that have timed out for
>> a pinned commitment transaction.
>>
>>
>> Anchor outputs were introduced to lightning to mitigate the junk pinning
>> vector; they work by adding a minimum of `1 CSV` lock to all outputs on
>> the commitment transaction except for two āanchorā outputs, one for each
>> channel peer. (These take advantage of a 1-tx carve-out exception to enable
>> propagation of anchors despite any junk attached to the peerās anchor).
>>
>>
>> ## Mitigation
>>
>> Splice transactions are susceptible to both junk and bulk pinning
>> attacks. Hereās how we propose mitigating these for splice.
>>
>>
>> [
]
>>
>>
>> For āancestor bulkingā, every `tx_add_input` proposed by a peer must be
>> included in the UTXO set. A node MUST verify the presence of a proposed
>> input before adding it to the splicing transaction.
>>
>>
>> For āoutput junkā, every output included directly in a splice transaction
>> MUST be a v0 P2SH witness script which begins with a minimum of `1 CSV`
>> relative timelock. No output on the splice transaction will be spendable
>> until it is included in a block. This prevents junk pinning by removing the
>> ability to propose spends of splice outputs before the transaction is
>> included in a block.
>>
>>
>> There are two side effects here.
>>
>>
>> 1) You cannot CPFP a splice transaction. All splices must be RBFād to be
>> fee-bumped. The interactive tx protocol already provides a protocol for
>> initiating an RBF, which we re-use for splicing.
>>
>> 2) Arbitrary 3rd party scriptPubKeys are not permissible directly into
>> the splice tx.
>>
>>
>> In order for this to work we need to validate that every output has a 1
>> block CSV. There are two output types to consider:
>>
>> 1. New channel outpoints
>> 2. Arbitrary splice out funds
>>
>>
>> For arbitrary splice out, funds can be included in a āfan-outā
>> transaction. Here standard pay to address etc outputs can live. The output
>> leading to the fan-out transaction will be a P2WSH that also begins with
>> [OP_1, OP_CHECKSEQUENCEVERIFY] (referred to from here on as ā1 CSVā). Each
>> splice party SHOULD build a fan-out transaction for all arbitrary spliced
>> outputs.
>>
>>
>> [
]
>>
>>
>> Splice-in transactions will not require any fan-out children as long as
>> all change goes into the channel outpoint.
>>
>>
>> For new channel outpoints, the v0 witness script should be modified to
>> start with [OP_1, OP_CHECKSEQUENCEVERIFY]. It needs to be the first item in
>> the script to allow easy validation that it is used and not hidden in a
>> false conditional. This would need to be applied to post-splice channel
>> outpoints and probably dual funding channels should add it as well so they
>> can be successfully included in splices.
>>
>>
>> ### interactive tx protocol changes
>>
>> For splices, `tx_add_output` MUST include the `witness_script` in the
>> tlv. Upon receiving outputs, nodes must validate the script matches the
>> script hash in the output and that it begins with a minimum of 1 CSV.
>>
>>
>> ## HTLC Timeouts and Splices
>>
>> Typically when this technique is used, one or two anchor outputs are
>> added to purposely allow for CPFP fee bumping. But, turns out, we already
>> have a usable anchor in the original commitment transaction! Very exciting.
>>
>>
>> The interactive tx protocol mandates that splice txs are RBF-enabled.
>> Broadcast splice proposals can be replaced out for the original commitment
>> transaction at any time. Since the original commitment transaction has
>> existing anchors, these may be used to increase fees on a force close. This
>> combined with every other output in the tree being locked behind a 1 CSV
>> means the force close will always have top mempool priority, mitigating the
>> āoutput junkā style pin.
>>
>>
>> - Nifty & Dusty
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20220926/1df8e3d0/attachment-0001.html>;
š Original message:
> I think this mitigation requires reliable access to the UTXO set
In this case, how about just setting nsequence to the value 1? UTXO may not
exist, but maybe that's ok since it means it cannot pin the commitment tx.
> If this concern is correct, I'm not sure we have a current good solution,
the WIP package RBF proposal would be limited to only 2 descendants [1],
and here we might have 3 generations: the splice, a commitment, a CPFP.
I maybe misunderstood the point, but if we're assuming some future V3
transaction update, you could certainly add anchors to the splice and CPFP
it from there. I think the effort was to attempt to avoid waiting for such
an update.
Best,
Greg
On Mon, Sep 26, 2022 at 3:51 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Dustin,
>
> From my understanding, splice pinning is problematic for channel funds
> safety. In the sense once you have a splice floating in network mempools
> and your latest valid commitment transaction pre-signed fees isn't enough
> to replace the splice, lack of confirmation might damage the claim of HTLCs.
>
> I don't know if the current splice proposal discourages pending HTLCs
> during the splice lifetime, this would at least downgrade the pinning
> severity in the splicing case to a simple liquidity timevalue loss.
>
> W.r.t, about the mitigation proposed.
>
> > For āancestor bulkingā, every `tx_add_input` proposed by a peer must be
> > included in the UTXO set. A node MUST verify the presence of a proposed
> > input before adding it to the splicing transaction.
>
> I think this mitigation requires reliable access to the UTXO set, a
> significant constraint for LN mobile clients relying on lightweight
> validation backends. While this requirement already exists in matters of
> routing to authenticate channel announcements, on the LDK-side we have
> alternative infrastructure to offer source-based routing to such a class of
> clients, without them having to care about the UTXO set [0]. I don't
> exclude there would be infrastructure in the future to access a subset of
> the UTXO set (e.g if utreexo is deployed on the p2p network) for
> resource-constraint clients, however as of today this is still pure
> speculation and vaporware.
>
> In the meantime, mobile clients might not be able to partake in splicing
> operations with their LSPs, or without a decrease in trust-minimization
> (e.g assuming your LSP doesn't initiate malicious pinnings against you).
>
> > 1) You cannot CPFP a splice transaction. All splices must be RBFād to be
> > fee-bumped. The interactive tx protocol already provides a protocol for
> > initiating an RBF, which we re-use for splicing.
>
> The issue with RBF, it assumes interactivity with your counterparties. As
> splicing is built on top of the interactive transaction construction
> protocol, from my understanding you could have a high order of participants
> to coordinate with, without knowledge of their signing policies (e.g if
> they're time-constraints) therefore any re-signing operations might have
> odds to fail. Moreover, one of these participants could be malicious and
> refuses straightly to sign, therefore the already splicing transactions
> stay as a pin in the network mempools.
>
> If this concern is correct, I'm not sure we have a current good solution,
> the WIP package RBF proposal would be limited to only 2 descendants [1],
> and here we might have 3 generations: the splice, a commitment, a CPFP.
>
> [0] https://github.com/lightningdevkit/rapid-gossip-sync-server
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>
> Le mar. 9 aoĆ»t 2022 Ć 16:15, Dustin Dettmer <dustin at koinkeep.com> a
> Ć©crit :
>
>> As raised by @crypto-iq and @roasbeef, splices which permit arbitrary
>> script and input inclusion are at risk of being mempool pinned. Here we
>> present a solution to this splice pinning problem.
>>
>>
>> ## Background
>>
>> Pinning can be done by building a very large ājunkā transaction that
>> spends from an important pending one. There are two known pinning vectors:
>> ancestor bulking thru addition of new inputs and junk pinning via the
>> spending of outputs.
>>
>>
>> Pinning pushes transactions to the bottom of the priority list without a
>> practical way of bumping it up. It is in effect a griefing attack, but in
>> the case of lightning can risk funds loss for HTLCs that have timed out for
>> a pinned commitment transaction.
>>
>>
>> Anchor outputs were introduced to lightning to mitigate the junk pinning
>> vector; they work by adding a minimum of `1 CSV` lock to all outputs on
>> the commitment transaction except for two āanchorā outputs, one for each
>> channel peer. (These take advantage of a 1-tx carve-out exception to enable
>> propagation of anchors despite any junk attached to the peerās anchor).
>>
>>
>> ## Mitigation
>>
>> Splice transactions are susceptible to both junk and bulk pinning
>> attacks. Hereās how we propose mitigating these for splice.
>>
>>
>> [
]>>
>>
>> For āancestor bulkingā, every `tx_add_input` proposed by a peer must be
>> included in the UTXO set. A node MUST verify the presence of a proposed
>> input before adding it to the splicing transaction.
>>
>>
>> For āoutput junkā, every output included directly in a splice transaction
>> MUST be a v0 P2SH witness script which begins with a minimum of `1 CSV`
>> relative timelock. No output on the splice transaction will be spendable
>> until it is included in a block. This prevents junk pinning by removing the
>> ability to propose spends of splice outputs before the transaction is
>> included in a block.
>>
>>
>> There are two side effects here.
>>
>>
>> 1) You cannot CPFP a splice transaction. All splices must be RBFād to be
>> fee-bumped. The interactive tx protocol already provides a protocol for
>> initiating an RBF, which we re-use for splicing.
>>
>> 2) Arbitrary 3rd party scriptPubKeys are not permissible directly into
>> the splice tx.
>>
>>
>> In order for this to work we need to validate that every output has a 1
>> block CSV. There are two output types to consider:
>>
>> 1. New channel outpoints
>> 2. Arbitrary splice out funds
>>
>>
>> For arbitrary splice out, funds can be included in a āfan-outā
>> transaction. Here standard pay to address etc outputs can live. The output
>> leading to the fan-out transaction will be a P2WSH that also begins with
>> [OP_1, OP_CHECKSEQUENCEVERIFY] (referred to from here on as ā1 CSVā). Each
>> splice party SHOULD build a fan-out transaction for all arbitrary spliced
>> outputs.
>>
>>
>> [
]>>
>>
>> Splice-in transactions will not require any fan-out children as long as
>> all change goes into the channel outpoint.
>>
>>
>> For new channel outpoints, the v0 witness script should be modified to
>> start with [OP_1, OP_CHECKSEQUENCEVERIFY]. It needs to be the first item in
>> the script to allow easy validation that it is used and not hidden in a
>> false conditional. This would need to be applied to post-splice channel
>> outpoints and probably dual funding channels should add it as well so they
>> can be successfully included in splices.
>>
>>
>> ### interactive tx protocol changes
>>
>> For splices, `tx_add_output` MUST include the `witness_script` in the
>> tlv. Upon receiving outputs, nodes must validate the script matches the
>> script hash in the output and that it begins with a minimum of 1 CSV.
>>
>>
>> ## HTLC Timeouts and Splices
>>
>> Typically when this technique is used, one or two anchor outputs are
>> added to purposely allow for CPFP fee bumping. But, turns out, we already
>> have a usable anchor in the original commitment transaction! Very exciting.
>>
>>
>> The interactive tx protocol mandates that splice txs are RBF-enabled.
>> Broadcast splice proposals can be replaced out for the original commitment
>> transaction at any time. Since the original commitment transaction has
>> existing anchors, these may be used to increase fees on a force close. This
>> combined with every other output in the tree being locked behind a 1 CSV
>> means the force close will always have top mempool priority, mitigating the
>> āoutput junkā style pin.
>>
>>
>> - Nifty & Dusty
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20220926/1df8e3d0/attachment-0001.html>;