> 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.ri...@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 <dus...@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. >> >> >> [https://i.imgur.com/ayiO1Qt.png] >> >> >> 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. >> >> >> [https://i.imgur.com/40Dy3oq.png] >> >> >> 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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
