From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B2AD4C002D for ; Sun, 25 Sep 2022 23:59:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 77A6281CA5 for ; Sun, 25 Sep 2022 23:59:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 77A6281CA5 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=TzNtJP56 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDqZ4d6xmkIt for ; Sun, 25 Sep 2022 23:59:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3635981C58 Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3635981C58 for ; Sun, 25 Sep 2022 23:59:35 +0000 (UTC) Received: by mail-io1-xd36.google.com with SMTP id y141so4015743iof.5 for ; Sun, 25 Sep 2022 16:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=P7dxrSZikY6+taM0fbPzxs74/9i+TOhKKbArNycoal4=; b=TzNtJP56OYE5tlbTNOFN7dqudp0+mIZz0EYhu8ZJRZ92Ebj0axYblzS2KrsBKZrotq rnMV9VgjG8fFuS6+rGL06ZnsExy5XbsBiR3yef8Ll8uZ/5d+yleU45FeJs2HjVNEKJ/Y X4opt0fTKMNCAi2PX6fWvWpjs1dWCCSz6ovUHmiX51pyF9/t7m52oGCUqE8wT/SDwMFb YPf0E4K4uuES+4z1X2e9LITWOAmaXjfjgEPM1xgrL0LVbJnS+KidaWtyUm7+QwEBm+u4 Z04AfCGSQppZ4Mua6RWxpQbCMEriPi8cvBK1ENgbWSjWSo4cwtqBYH7UqesT0YcrLykF g2cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=P7dxrSZikY6+taM0fbPzxs74/9i+TOhKKbArNycoal4=; b=6/EY4kZwbaIblW2tWs68smPjHHMQSv/W6evPd91rp67KPsvbaDGrVgOjJ3lPPTfVru zbzT5J5GhyISFhoUnkzrYiu1ALf2UpsLxQmetcNUF4CrSK/YmJVMmeaS5sSLj36db0ql CPhqZt60CSk7MVc8XHkJEoAYTfG5lS1wqkjmXGG4JjgvU3ro5X6C04aNefHBsu0Chn7/ cl0WB5wxRj4JuPO6cjYaHTXWZ38bOZKUQVbua8VyJj+9pTAcANMkVe9TY9GfNnRrDC9l FtXoy/X84trg7K6jUWV06Rp4+89qyIcIVi3rWAaZ2+QOhBQxGEosv0/kgjupsTwQmoMo G53g== X-Gm-Message-State: ACrzQf08Xrv/e21x5nbROtSnhl3SvNuIBFcS6qArvH62YXd/a/kuFLm3 o1w3qggtQpP5jB0s58QHBNOqAtXNHVy4T/p1mJXveZ/A5Es= X-Google-Smtp-Source: AMsMyM5fjMQMeZeLxjHQu4bdfaFYQiGGmLxTQLHgm8H5GvclZxFcalSGmyhfGALVSb7MXJoZJdc8JGCn/eHqI9GjrQ0= X-Received: by 2002:a05:6602:2a45:b0:6a4:43dc:40ef with SMTP id k5-20020a0566022a4500b006a443dc40efmr4814056iov.64.1664150374073; Sun, 25 Sep 2022 16:59:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sun, 25 Sep 2022 19:59:22 -0400 Message-ID: To: Gloria Zhao , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e6485c05e98933ea" X-Mailman-Approved-At: Mon, 26 Sep 2022 01:22:37 +0000 Subject: Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2022 23:59:37 -0000 --000000000000e6485c05e98933ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gloria, Thanks for the progress on package RBF, few early questions. > 2. Any descendant of an unconfirmed V3 transaction must also be V3. > 3. An unconfirmed V3 transaction cannot have more than 1 descendant. If you're a miner and you receive a non-V3, second descendant of an unconfirmed V3 transaction, if the offered fee is in the top mempool backlog, I think you would have an interest to accept such a transaction. So I'm not sure if those two rules are compatible with miners incentives... > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be > larger than 1000 virtual bytes. If I understand correctly the 1000 vb upper bound rational, it would be to constraint the pinning counterparty to attach a high fee to a child due to the limited size, if they would like this transaction to be stuck in the network mempools. By doing so this child has high odds to confirm. I still wonder if this compatible with miner incentives in period of empty mempools, in the sense that if you've already a V3 transaction of size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement candidate of size 1000 vb offering 10 sat/vb. It could be argued the former should be conserved. (That said, the hard thing with any replacement strategy we might evict a parent transaction *now* to which is attached a high-feerate child *latter* making for a utxo considered the best ancestor set. Maybe in the long-term miners should keep every transaction ever accepted...) > (Lower bound) the smaller this limit, the fewer UTXOs a child may use > to fund this fee-bump. For example, only allowing the V3 child to have > 2 inputs would require L2 protocols to manage a wallet with high-value > UTXOs and make batched fee-bumping impossible. However, as the > fee-bumping child only needs to fund fees (as opposed to payments), > just a few UTXOs should suffice. Reminder for L2 devs, batched fee-bumping of time-sensitive confirmations of commitment transactions is unsafe, as the counterparty could enter in a "cat-and-mouse" game to replace one of the batch element at each block to delay confirmation of the remaining elements in the batch, I think. On the other hand, I wonder if we wouldn't want a higher bound. LN wallets are likely to have one big UTXO in their fee-bumping reserve pool, as the cost of acquiring UTXO is non-null and in the optimistic case, you don't need to do unilateral closure. Let's say you close dozens of channels at the same time, a UTXO pool management strategy might be to fan-out the first spends UTXOs in N fan-out outputs ready to feed the remaining in-flight channels. > 1. The rule around unconfirmed inputs was > originally "A package may include new unconfirmed inputs, but the > ancestor feerate of the child must be at least as high as the ancestor > feerates of every transaction being replaced." Note, I think we would like this new RBF rule to also apply to single transaction package, e.g second-stage HTLC transactions, where a counterparty pins a HTLC-preimage by abusing rule 3. In that case, the honest LN node should be able to broadcast a "at least as high ancestor feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no unconfirmed ancestor to replace, as the commitment transaction, whatever the party it is originating from, should already be confirmed. > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN transactions based on nVersion?" As of today, I think yes you can already fingerprint LN transactions on the spec-defined amount value of the anchor outputs, 330 sats. There is always one of them on post-anchor commitment transactions. And sadly I would say we'll always have tricky fingerprints leaking from unilateral LN closures such as HTLC/PTLC timelocks... > "Can a V2 transaction replace a V3 transaction and vice versa?" IIUC, a V3 package could replace a V2 package, with the benefit of the new package RBF rules applied. I think this would be a significant advantage for LN, as for the current ~85k of opened channels, the old V2 states shouldn't be pinning vectors. Currently, commitment transactions signal replaceability. Le ven. 23 sept. 2022 =C3=A0 11:26, Gloria Zhao via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hi everyone, > > I'm writing to propose a very simple set of mempool/transaction relay > policies intended to aid L2/contract protocols. I realized that > the previously proposed Package Mempool Accept package RBF [1] > had a few remaining problems after digging into the RBF logic more [2]. > This additional set of policies solves them without requiring a huge RBF > overhaul. > > I've written an implementation (and docs) for Bitcoin Core: > https://github.com/bitcoin/bitcoin/pull/25038 > > (You may notice that this proposal incorporates feedback on the PR - > thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns, > and others.) > > If you are interested in using package RBF/relay to bump presigned > transactions, I think you may be interested in reviewing this proposal. > This should solve Rule 3 pinning and perhaps allow us > to get rid of CPFP carve-out (yay!). I'm keen to hear if people find > the 1-anchor-output, 1000vB child limit too restrictive. Also, if you fin= d > a > pinning attack or something that makes it unusable for you, I would > really really like to know. > > Note that transactions with nVersion=3D3 ("V3 transactions") are > currently non-standard in Bitcoin Core. That means **anything that was > standard before this policy change would still be standard > afterwards.** If you don't want your transactions to be subject to > these rules, just continue whatever you're doing and don't use > nVersion=3D3. AFAICT this shouldn't break anything, but let me know if > this would be disruptive for you? > > **New Policies:** > > This includes: > - a set of additional policy rules applying to V3 transactions > - modifications to package RBF rules > > **V3 transactions:** > > Existing standardness rules apply to V3 (e.g. min/max tx weight, > standard output types, cleanstack, etc.). The following additional > rules apply to V3: > > 1. A V3 transaction can be replaced, even if it does not signal BIP125 > replaceability. (It must also meet the other RBF rules around fees, > etc. for replacement to happen). > > 2. Any descendant of an unconfirmed V3 transaction must also be V3. > > *Rationale*: Combined with Rule 1, this gives us the property of > "inherited" replaceability signaling when descendants of unconfirmed > transactions are created. Additionally, checking whether a transaction > signals replaceability this way does not require mempool traversal, > and does not change based on what transactions are mined. It also > makes subsequent rules about descendant limits much easier to check. > > *Note*: The descendant of a *confirmed* V3 transaction does not need to b= e > V3. > > 3. An unconfirmed V3 transaction cannot have more than 1 descendant. > > *Rationale*: (Upper bound) the larger the descendant limit, the more > transactions may need to be replaced. This is a problematic pinning > attack, i.e., a malicious counterparty prevents the transaction from > being replaced by adding many descendant transactions that aren't > fee-bumping. > > (Lower bound) at least 1 descendant is required to allow CPFP of the > presigned transaction. The contract protocol can create presigned > transactions paying 0 fees and 1 output for attaching a CPFP at > broadcast time ("anchor output"). Without package RBF, multiple anchor > outputs would be required to allow each counterparty to fee-bump any > presigned transaction. With package RBF, since the presigned > transactions can replace each other, 1 anchor output is sufficient. > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be > larger than 1000 virtual bytes. > > *Rationale*: (Upper bound) the larger the descendant size limit, the > more vbytes may need to be replaced. With default limits, if the child > is e.g. 100,000vB, that might be an additional 100,000sats (at > 1sat/vbyte) or more, depending on the feerate. > > (Lower bound) the smaller this limit, the fewer UTXOs a child may use > to fund this fee-bump. For example, only allowing the V3 child to have > 2 inputs would require L2 protocols to manage a wallet with high-value > UTXOs and make batched fee-bumping impossible. However, as the > fee-bumping child only needs to fund fees (as opposed to payments), > just a few UTXOs should suffice. > > With a limit of 1000 virtual bytes, depending on the output types, the > child can have 6-15 UTXOs, which should be enough to fund a fee-bump > without requiring a carefully-managed UTXO pool. With 1000 virtual > bytes as the descendant limit, the cost to replace a V3 transaction > has much lower variance. > > *Rationale*: This makes the rule very easily "tacked on" to existing > logic for policy and wallets. A transaction may be up to 100KvB on its > own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants > (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction > in the mempool is 100KvB, its descendant can only be 1000vB, even if > the policy is 10KvB. > > **Package RBF modifications:** > > 1. The rule around unconfirmed inputs was > originally "A package may include new unconfirmed inputs, but the > ancestor feerate of the child must be at least as high as the ancestor > feerates of every transaction being replaced." > > The package may still include new unconfirmed inputs. However, > the new rule is modified to be "The minimum between package feerate > and ancestor feerate of the child is not lower than the individual > feerates of all directly conflicting transactions and the ancestor > feerates of all original transactions." > > *Rationale*: We are attempting to ensure that the replacement > transactions are not less incentive-compatible to mine. However, a > package/transaction's ancestor feerate is not perfectly representative > of its incentive compatibility; it may overestimate (some subset of > the ancestors could be included by itself if it has other high-feerate > descendants or are themselves higher feerate than this > package/transaction). Instead, we use the minimum between the package > feerate and ancestor feerate of the child as a more conservative value > than what was proposed originally. > > 2. A new rule is added, requiring that all package transactions with > mempool conflicts to be V3. This also means the "sponsoring" > child transaction must be V3. > > *Note*: Combined with the V3 rules, this means the package must be > a child-with-parents package. Since package validation is only > attempted if the transactions do not pay sufficient fees to be > accepted on their own, this effectively means that only V3 > transactions can pay to replace their ancestors' conflicts, and only > V3 transactions' replacements may be paid for by a descendant. > > *Rationale*: The fee-related rules are economically rational for > ancestor packages, but not necessarily other types of packages. > A child-with-parents package is a type of ancestor package. It > may be fine to allow any ancestor package, but it's more difficult > to account for all of the possibilities. For example, it gets much > harder to see that we're applying the descendant limits correctly if > the package has a gnarly, many-generation, non-tree shape. I'm also > not sure if this policy is 100% incentive-compatible if the sponsor > is not a direct descendant of the sponsee. > > Please see doc/policy/version3_transactions.md and > doc/policy/packages.md in the PR for the full set of rules. > > **Intended usage for LN:** > > Commitment transactions should be V3 and have 1 anchor output. They > can be signed with 0 fees (or 1sat/vbyte) once package relay is deployed > on a significant portion of the network. If the commitment tx must > be broadcast, determine the desired feerate at broadcast time and > spend the anchor output in a high feerate transaction. I'm going to > call the broadcasted commitment tx "the parent" and the attached > fee-bumping tx "the child." > > - This child must be V3. > - This child must be at most 1000vB. Note this restricts the > number of inputs you can use to fund the fee bump. Depending > on the output types, this is around 6-15. > - One child may fund fees for multiple commitment tx ("batched > fee-bumping"). > - To do a second fee-bump to add more fees, replace the > *child* with a higher-feerate tx. Do not try to attach a grandchild. > > Otherwise, never try to spend from an unconfirmed V3 transaction. The > descendant limits for V3 transactions are very restrictive. > > **Expected Questions:** > > "Does this fix Rule 3 Pinning?" > Yes. The V3 descendant limit restricts both you and your counterparty. > Assuming nodes adopted this policy, you may reasonably assume that you > only need to replace the commitment transaction + up to 1000vB. > > "Only 1 anchor output? What if I need to bump counterparty's commitment t= x > in mempool?" > You won't need to fee-bump a counterparty's commitment tx using CPFP. > You would just package RBF it by attaching a high-feerate child to > your commitment tx. > > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN > transactions based on nVersion?" > Indeed it may be unrealistic to assume V3 transactions will be in > widespread use outside of L2. IIUC, unilateral closes are already > obvious LN transactions because of the HTLC inputs. For e.g. > cooperative closes and opens, I think it makes sense to continue using > V2. So, unless I'm missing something, this shouldn't make it worse. > > "So a V3 transaction that doesn't signal BIP125 replaceability is > replaceable? Is that a backward compatibility issue?" > Yes it's replaceable. It's not an issue AFAICT because, > under previous policy, the V3 transaction wouldn't have been > in the mempool in the first place. > > "Can a V2 transaction replace a V3 transaction and vice versa?" > Yes, otherwise someone can use V3 transactions to censor V2 > transactions spending shared inputs. Note if the > original V3 transaction has an unconfirmed V3 parent, this would > violate the "inherited V3" rule and would be rejected. > > Thanks for reading! Feedback and review would be much appreciated. > > [1]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/01= 9464.html > [2]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= 17.html > > Best, > Gloria > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000e6485c05e98933ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gloria,

Thanks for the progress on package RBF, = few early questions.

> 2. Any descendant of an unconfirmed V3 tra= nsaction must also be V3.

> 3. An unconfirmed V3 transaction cann= ot have more than 1 descendant.

If you're a miner and you receiv= e a non-V3, second descendant of an unconfirmed V3 transaction, if the offe= red fee is in the top mempool backlog, I think you would have an interest t= o accept such a transaction.

So I'm not sure if those two rules = are compatible with miners incentives...

> 4. A V3 transaction th= at has an unconfirmed V3 ancestor cannot be
> =C2=A0 =C2=A0larger tha= n 1000 virtual bytes.

If I understand correctly the 1000 vb upper bo= und rational, it would be to constraint the pinning counterparty to attach = a high fee to a child due to the limited size, if they would like this tran= saction to be stuck in the network mempools. By doing so=C2=A0 this child h= as high odds to confirm.

I still wonder if this compatible with mine= r incentives in period of empty mempools, in the sense that if you've a= lready a V3 transaction of size 100Kvb offering 2 sat/vb, it's more int= eresting than a V3 replacement candidate of size 1000 vb offering 10 sat/vb= . It could be argued the former should be conserved.

(That said, the= hard thing with any replacement strategy we might evict a parent transacti= on *now* to which is attached a high-feerate child *latter* making for a ut= xo considered the best ancestor set. Maybe in the long-term miners should k= eep every transaction ever accepted...)

> (Lower bound) the small= er this limit, the fewer UTXOs a child may use
> to fund this fee-bum= p. For example, only allowing the V3 child to have
> 2 inputs would r= equire L2 protocols to manage a wallet with high-value
> UTXOs and ma= ke batched fee-bumping impossible. However, as the
> fee-bumping chil= d only needs to fund fees (as opposed to payments),
> just a few UTXO= s should suffice.

Reminder for L2 devs, batched fee-bumping of time-= sensitive confirmations of commitment transactions is unsafe, as the counte= rparty could enter in a "cat-and-mouse" game to replace one of th= e batch element at each block to delay confirmation of the remaining elemen= ts in the batch, I think.

On the other hand, I wonder if we wouldn&#= 39;t want a higher bound. LN wallets are likely to have one big UTXO in the= ir fee-bumping reserve pool, as the cost of acquiring UTXO is non-null and = in the optimistic case, you don't need to do unilateral closure. Let= 9;s say you close dozens of channels at the same time, a UTXO pool manageme= nt strategy might be to fan-out the first spends UTXOs in N fan-out outputs= ready to feed the remaining in-flight channels.

> 1. The rule ar= ound unconfirmed inputs was
> originally "A package may include = new unconfirmed inputs, but the
> ancestor feerate of the child must = be at least as high as the ancestor
> feerates of every transaction b= eing replaced."

Note, I think we would like this new RBF rule t= o also apply to single transaction package, e.g second-stage HTLC transacti= ons, where a counterparty pins a HTLC-preimage by abusing rule 3. In that c= ase, the honest LN node should be able to broadcast a "at least as hig= h ancestor feerate" HTLC-timeout transaction. With `option_anchor_outp= uts" there is no unconfirmed ancestor to replace, as the commitment tr= ansaction, whatever the party it is originating from, should already be con= firmed.

> "Is this a privacy issue, i.e. doesn't it allo= w fingerprinting LN
transactions based on nVersion?"

As of t= oday, I think yes you can already fingerprint LN transactions on the=C2=A0 = spec-defined amount value of the anchor outputs, 330 sats. There is always = one of them on post-anchor commitment transactions. And sadly I would say w= e'll always have tricky fingerprints leaking from unilateral LN closure= s such as HTLC/PTLC timelocks...

> "Can a V2 transaction rep= lace a V3 transaction and vice versa?"

IIUC, a V3 package could= replace a V2 package, with the benefit of the new package RBF rules applie= d. I think this would be a significant advantage for LN, as for the current= ~85k of opened channels, the old V2 states shouldn't be pinning vector= s. Currently, commitment transactions signal replaceability.

<= div class=3D"gmail_quote">
Le=C2=A0ven= . 23 sept. 2022 =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> a =C3=A9crit=C2=A0:
Hi everyone,

I'm writi= ng to propose a very simple set of mempool/transaction relay
policies in= tended to aid L2/contract protocols. I realized that
the previously prop= osed Package Mempool Accept package RBF [1]
had a few remaining pro= blems after digging into the RBF logic more [2].
This additional = set of policies solves them without requiring a huge RBF overhaul.

I've written an implementation (and docs) for Bitcoin Core:
ht= tps://github.com/bitcoin/bitcoin/pull/25038

(You may notice that= this proposal incorporates feedback on the PR - thanks Suhas Daftuar, Greg= ory Sanders, Bastien Teinturier, Anthony Towns, and others.)

If you = are interested in using package RBF/relay to bump presigned
transactions= , I think you may be interested in reviewing this proposal.
This should = solve Rule 3 pinning and perhaps allow us
to get rid of CPFP carve-out (= yay!). I'm keen to hear if people find
the 1-anchor-output, 1000vB c= hild limit too restrictive. Also, if you find a
pinning attack or someth= ing that makes it unusable for you, I would
really really like to know.<= br>
Note that transactions with nVersion=3D3 ("V3 transactions"= ;) are
currently non-standard in Bitcoin Core. That means **anything tha= t was
standard before this policy change would still be standard
afte= rwards.** If you don't want your transactions to be subject to
these= rules, just continue whatever you're doing and don't use
nVersi= on=3D3. AFAICT this shouldn't break anything, but let me know if
thi= s would be disruptive for you?

**New Policies:**

This include= s:
- a set of additional policy rules applying to V3 transactions
- m= odifications to package RBF rules

**V3 transactions:**

Existi= ng standardness rules apply to V3 (e.g. min/max tx weight,
standard outp= ut types, cleanstack, etc.). The following additional
rules apply to V3:=

1. A V3 transaction can be replaced, even if it does not signal BIP= 125
=C2=A0 =C2=A0replaceability. (It must also meet the other RBF rules = around fees,
etc. for replacement to happen).

2. Any descendant o= f an unconfirmed V3 transaction must also be V3.

*Rationale*: Combin= ed with Rule 1, this gives us the property of
"inherited" repl= aceability signaling when descendants of unconfirmed
transactions are cr= eated. Additionally, checking whether a transaction
signals replaceabili= ty this way does not require mempool traversal,
and does not change base= d on what transactions are mined. It also
makes subsequent rules about d= escendant limits much easier to check.

*Note*: The descendant of a *= confirmed* V3 transaction does not need to be V3.

3. An unconfirmed = V3 transaction cannot have more than 1 descendant.

*Rationale*: (Upp= er bound) the larger the descendant limit, the more
transactions may nee= d to be replaced. This is a problematic pinning
attack, i.e., a maliciou= s counterparty prevents the transaction from
being replaced by adding ma= ny descendant transactions that aren't
fee-bumping.

(Lower bo= und) at least 1 descendant is required to allow CPFP of the
presigned tr= ansaction. The contract protocol can create presigned
transactions payin= g 0 fees and 1 output for attaching a CPFP at
broadcast time ("anch= or output"). Without package RBF, multiple anchor
outputs would be = required to allow each counterparty to fee-bump any
presigned transactio= n. With package RBF, since the presigned
transactions can replace each o= ther, 1 anchor output is sufficient.

4. A V3 transaction that has an= unconfirmed V3 ancestor cannot be
=C2=A0 =C2=A0larger than 1000 virtual= bytes.

*Rationale*: (Upper bound) the larger the descendant size li= mit, the
more vbytes may need to be replaced. With default limits, if th= e child
is e.g. 100,000vB, that might be an additional 100,000sats (at1sat/vbyte) or more, depending on the feerate.

(Lower bound) the s= maller this limit, the fewer UTXOs a child may use
to fund this fee-bump= . For example, only allowing the V3 child to have
2 inputs would require= L2 protocols to manage a wallet with high-value
UTXOs and make batched = fee-bumping impossible. However, as the
fee-bumping child only needs to = fund fees (as opposed to payments),
just a few UTXOs should suffice.
=
With a limit of 1000 virtual bytes, depending on the output types, the<= br>child can have 6-15 UTXOs, which should be enough to fund a fee-bump
= without requiring a carefully-managed UTXO pool. With 1000 virtual
bytes= as the descendant limit, the cost to replace a V3 transaction
has much = lower variance.

*Rationale*: This makes the rule very easily "t= acked on" to existing
logic for policy and wallets. A transaction m= ay be up to 100KvB on its
own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with= descendants
(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 tr= ansaction
in the mempool is 100KvB, its descendant can only be 1000vB, e= ven if
the policy is 10KvB.

**Package RBF modifications:**
1. The rule around unconfirmed inputs was
originally "A package ma= y include new unconfirmed inputs, but the
ancestor feerate of the child = must be at least as high as the ancestor
feerates of every transaction b= eing replaced."

The package may still include new unconfirmed i= nputs. However,
the new rule is modified to be "The minimum between= package feerate
and ancestor feerate of the child is not lower than the= individual
feerates of all directly conflicting transactions and the an= cestor
feerates of all original transactions."

*Rationale*: = We are attempting to ensure that the replacement
transactions are not le= ss incentive-compatible to mine. However, a
package/transaction's an= cestor feerate is not perfectly representative
of its incentive compatib= ility; it may overestimate (some subset of
the ancestors could be includ= ed by itself if it has other high-feerate
descendants or are themselves = higher feerate than this
package/transaction). Instead, we use the minim= um between the package
feerate and ancestor feerate of the child as a mo= re conservative value
than what was proposed originally.

2. A new= rule is added, requiring that all package transactions with
mempool con= flicts to be V3. This also means the "sponsoring"
child transa= ction must be V3.

*Note*: Combined with the V3 rules, this means the= package must be
a child-with-parents package. Since package validation = is only
attempted if the transactions do not pay sufficient fees to beaccepted on their own, this effectively means that only V3
transaction= s can pay to replace their ancestors' conflicts, and only
V3 transac= tions' replacements may be paid for by a descendant.

*Rationale*= : The fee-related rules are economically rational for
ancestor packages,= but not necessarily other types of packages.
A child-with-parents packa= ge is a type of ancestor package. It
may be fine to allow any ancestor p= ackage, but it's more difficult
to account for all of the possibilit= ies. For example, it gets much
harder to see that we're applying the= descendant limits correctly if
the package has a gnarly, many-generatio= n, non-tree shape. I'm also
not sure if this policy is 100% incentiv= e-compatible if the sponsor
is not a direct descendant of the sponsee.
Please see doc/policy/version3_transactions.md and
doc/policy/pack= ages.md in the PR for the full set of rules.

**Intended usage for LN= :**

Commitment transactions should be V3 and have 1 anchor output. T= hey
can be signed with 0 fees (or 1sat/vbyte) once package relay is depl= oyed
on a significant portion of the network. If the commitment tx must<= br>be broadcast, determine the desired feerate at broadcast time and
spe= nd the anchor output in a high feerate transaction. I'm going to
cal= l the broadcasted commitment tx "the parent" and the attached
= fee-bumping tx "the child."

- This child must be V3.
- = This child must be at most 1000vB. Note this restricts the
=C2=A0 number= of inputs you can use to fund the fee bump. Depending
on the output typ= es, this is around 6-15.
- One child may fund fees for multiple commitme= nt tx ("batched
=C2=A0 fee-bumping").
- To do a second fee-= bump to add more fees, replace the
=C2=A0 *child* with a higher-feerate = tx. Do not try to attach a grandchild.

Otherwise, never try to spend= from an unconfirmed V3 transaction. The
descendant limits for V3 transa= ctions are very restrictive.

**Expected Questions:**

"Do= es this fix Rule 3 Pinning?"
Yes. The V3 descendant limit restricts= both you and your counterparty.
Assuming nodes adopted this policy, you= may reasonably assume that you
only need to replace the commitment tran= saction + up to 1000vB.

"Only 1 anchor output? What if I need t= o bump counterparty's commitment tx in mempool?"
You won&#= 39;t need to fee-bump a counterparty's commitment tx using CPFP.
<= div>You would just package RBF it by attaching a high-feerate child toyour commitment tx.

"Is this a privacy issue, i.e. doesn't= it allow fingerprinting LN
transactions based on nVersion?"
Ind= eed it may be unrealistic to assume V3 transactions will be in
widesprea= d use outside of L2. IIUC, unilateral closes are already
obvious LN tran= sactions because of the HTLC inputs. For e.g.
cooperative closes and ope= ns, I think it makes sense to continue using
V2. So, unless I'm miss= ing something, this shouldn't make it worse.

"So a V3 trans= action that doesn't signal BIP125 replaceability is
replaceable? Is = that a backward compatibility issue?"
Yes it's replaceable. It&= #39;s not an issue AFAICT because,
under previous policy, the V3 transac= tion wouldn't have been
in the mempool in the first place.

&q= uot;Can a V2 transaction replace a V3 transaction and vice versa?"
= Yes, otherwise someone can use V3 transactions to censor V2
transactions= spending shared inputs. Note if the
original V3 transaction has an unco= nfirmed V3 parent, this would
violate the "inherited V3" rule = and would be rejected.

Thanks for reading! Feedback and review would= be much appreciated.

[1]: htt= ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.= html

Best,
Gloria
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e6485c05e98933ea--