Dustin Dettmer [ARCHIVE] on Nostr: š Original date posted:2022-08-09 š Original message: As raised by @crypto-iq ...
š
Original date posted:2022-08-09
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220809/d79c4ee0/attachment.html>;
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220809/d79c4ee0/attachment.html>;