path: root/5f/4d55a584a51900a652e32f75f216ac128439e4

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B2AD4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Sep 2022 23:59:35 +0000 (UTC)
Received: by mail-io1-xd36.google.com with SMTP id y141so4015743iof.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAFXO6=KDys2_dsrdxE9_q_MVZJOFMbg-MctxiokcicP=wd4Lkw@mail.gmail.com>
In-Reply-To: <CAFXO6=KDys2_dsrdxE9_q_MVZJOFMbg-MctxiokcicP=wd4Lkw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 25 Sep 2022 19:59:22 -0400
Message-ID: <CALZpt+HYUti=foo+d5ER7Wj=PxsfgaU2CEqqG4_KRxmsWoaSxw@mail.gmail.com>
To: Gloria Zhao <gloriajzhao@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">Hi Gloria,<br><br>Thanks for the progress on package RBF, =
few early questions.<br><br>&gt; 2. Any descendant of an unconfirmed V3 tra=
nsaction must also be V3.<br><br>&gt; 3. An unconfirmed V3 transaction cann=
ot have more than 1 descendant.<br><br>If you&#39;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.<br><br>So I&#39;m not sure if those two rules =
are compatible with miners incentives...<br><br>&gt; 4. A V3 transaction th=
at has an unconfirmed V3 ancestor cannot be<br>&gt; =C2=A0 =C2=A0larger tha=
n 1000 virtual bytes.<br><br>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.<br><br>I still wonder if this compatible with mine=
r incentives in period of empty mempools, in the sense that if you&#39;ve a=
lready a V3 transaction of size 100Kvb offering 2 sat/vb, it&#39;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.<br><br>(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...)<br><br>&gt; (Lower bound) the small=
er this limit, the fewer UTXOs a child may use<br>&gt; to fund this fee-bum=
p. For example, only allowing the V3 child to have<br>&gt; 2 inputs would r=
equire L2 protocols to manage a wallet with high-value<br>&gt; UTXOs and ma=
ke batched fee-bumping impossible. However, as the<br>&gt; fee-bumping chil=
d only needs to fund fees (as opposed to payments),<br>&gt; just a few UTXO=
s should suffice.<br><br>Reminder for L2 devs, batched fee-bumping of time-=
sensitive confirmations of commitment transactions is unsafe, as the counte=
rparty could enter in a &quot;cat-and-mouse&quot; 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.<br><br>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&#39;t need to do unilateral closure. Let&#3=
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.<br><br>&gt; 1. The rule ar=
ound unconfirmed inputs was<br>&gt; originally &quot;A package may include =
new unconfirmed inputs, but the<br>&gt; ancestor feerate of the child must =
be at least as high as the ancestor<br>&gt; feerates of every transaction b=
eing replaced.&quot;<br><br>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 &quot;at least as hig=
h ancestor feerate&quot; HTLC-timeout transaction. With `option_anchor_outp=
uts&quot; there is no unconfirmed ancestor to replace, as the commitment tr=
ansaction, whatever the party it is originating from, should already be con=
firmed.<br><br>&gt; &quot;Is this a privacy issue, i.e. doesn&#39;t it allo=
w fingerprinting LN<br>transactions based on nVersion?&quot;<br><br>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&#39;ll always have tricky fingerprints leaking from unilateral LN closure=
s such as HTLC/PTLC timelocks...<br><br>&gt; &quot;Can a V2 transaction rep=
lace a V3 transaction and vice versa?&quot;<br><br>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&#39;t be pinning vector=
s. Currently, commitment transactions signal replaceability.<br></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven=
. 23 sept. 2022 =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">Hi everyone,<br><br>I&#39;m writi=
ng to propose a very simple set of mempool/transaction relay<br>policies in=
tended to aid L2/contract protocols. I realized that<br>the previously prop=
osed Package Mempool Accept package RBF [1]<br><div>had a few remaining pro=
blems after digging into the RBF logic more [2].</div><div>This additional =
set of policies solves them without requiring a huge RBF overhaul.<br></div=
><br>I&#39;ve written an implementation (and docs) for Bitcoin Core:<br><a =
href=3D"https://github.com/bitcoin/bitcoin/pull/25038" target=3D"_blank">ht=
tps://github.com/bitcoin/bitcoin/pull/25038</a><br><br>(You may notice that=
 this proposal incorporates feedback on the PR - thanks Suhas Daftuar, Greg=
ory Sanders, Bastien Teinturier, Anthony Towns, and others.)<br><br>If you =
are interested in using package RBF/relay to bump presigned<br>transactions=
, I think you may be interested in reviewing this proposal.<br>This should =
solve Rule 3 pinning and perhaps allow us<br>to get rid of CPFP carve-out (=
yay!). I&#39;m keen to hear if people find<br>the 1-anchor-output, 1000vB c=
hild limit too restrictive. Also, if you find a<br>pinning attack or someth=
ing that makes it unusable for you, I would<br>really really like to know.<=
br><br>Note that transactions with nVersion=3D3 (&quot;V3 transactions&quot=
;) are<br>currently non-standard in Bitcoin Core. That means **anything tha=
t was<br>standard before this policy change would still be standard<br>afte=
rwards.** If you don&#39;t want your transactions to be subject to<br>these=
 rules, just continue whatever you&#39;re doing and don&#39;t use<br>nVersi=
on=3D3. AFAICT this shouldn&#39;t break anything, but let me know if<br>thi=
s would be disruptive for you?<br><br>**New Policies:**<br><br>This include=
s:<br>- a set of additional policy rules applying to V3 transactions<br>- m=
odifications to package RBF rules<br><br>**V3 transactions:**<br><br>Existi=
ng standardness rules apply to V3 (e.g. min/max tx weight,<br>standard outp=
ut types, cleanstack, etc.). The following additional<br>rules apply to V3:=
<br><br>1. A V3 transaction can be replaced, even if it does not signal BIP=
125<br>=C2=A0 =C2=A0replaceability. (It must also meet the other RBF rules =
around fees,<br>etc. for replacement to happen).<br><br>2. Any descendant o=
f an unconfirmed V3 transaction must also be V3.<br><br>*Rationale*: Combin=
ed with Rule 1, this gives us the property of<br>&quot;inherited&quot; repl=
aceability signaling when descendants of unconfirmed<br>transactions are cr=
eated. Additionally, checking whether a transaction<br>signals replaceabili=
ty this way does not require mempool traversal,<br>and does not change base=
d on what transactions are mined. It also<br>makes subsequent rules about d=
escendant limits much easier to check.<br><br>*Note*: The descendant of a *=
confirmed* V3 transaction does not need to be V3.<br><br>3. An unconfirmed =
V3 transaction cannot have more than 1 descendant.<br><br>*Rationale*: (Upp=
er bound) the larger the descendant limit, the more<br>transactions may nee=
d to be replaced. This is a problematic pinning<br>attack, i.e., a maliciou=
s counterparty prevents the transaction from<br>being replaced by adding ma=
ny descendant transactions that aren&#39;t<br>fee-bumping.<br><br>(Lower bo=
und) at least 1 descendant is required to allow CPFP of the<br>presigned tr=
ansaction. The contract protocol can create presigned<br>transactions payin=
g 0 fees and 1 output for attaching a CPFP at<br>broadcast time (&quot;anch=
or output&quot;). Without package RBF, multiple anchor<br>outputs would be =
required to allow each counterparty to fee-bump any<br>presigned transactio=
n. With package RBF, since the presigned<br>transactions can replace each o=
ther, 1 anchor output is sufficient.<br><br>4. A V3 transaction that has an=
 unconfirmed V3 ancestor cannot be<br>=C2=A0 =C2=A0larger than 1000 virtual=
 bytes.<br><br>*Rationale*: (Upper bound) the larger the descendant size li=
mit, the<br>more vbytes may need to be replaced. With default limits, if th=
e child<br>is e.g. 100,000vB, that might be an additional 100,000sats (at<b=
r>1sat/vbyte) or more, depending on the feerate.<br><br>(Lower bound) the s=
maller this limit, the fewer UTXOs a child may use<br>to fund this fee-bump=
. For example, only allowing the V3 child to have<br>2 inputs would require=
 L2 protocols to manage a wallet with high-value<br>UTXOs and make batched =
fee-bumping impossible. However, as the<br>fee-bumping child only needs to =
fund fees (as opposed to payments),<br>just a few UTXOs should suffice.<br>=
<br>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<br>=
without requiring a carefully-managed UTXO pool. With 1000 virtual<br>bytes=
 as the descendant limit, the cost to replace a V3 transaction<br>has much =
lower variance.<br><br>*Rationale*: This makes the rule very easily &quot;t=
acked on&quot; to existing<br>logic for policy and wallets. A transaction m=
ay be up to 100KvB on its<br>own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with=
 descendants<br>(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 tr=
ansaction<br>in the mempool is 100KvB, its descendant can only be 1000vB, e=
ven if<br>the policy is 10KvB.<br><br>**Package RBF modifications:**<br><br=
>1. The rule around unconfirmed inputs was<br>originally &quot;A package ma=
y include new unconfirmed inputs, but the<br>ancestor feerate of the child =
must be at least as high as the ancestor<br>feerates of every transaction b=
eing replaced.&quot;<br><br>The package may still include new unconfirmed i=
nputs. However,<br>the new rule is modified to be &quot;The minimum between=
 package feerate<br>and ancestor feerate of the child is not lower than the=
 individual<br>feerates of all directly conflicting transactions and the an=
cestor<br>feerates of all original transactions.&quot;<br><br>*Rationale*: =
We are attempting to ensure that the replacement<br>transactions are not le=
ss incentive-compatible to mine. However, a<br>package/transaction&#39;s an=
cestor feerate is not perfectly representative<br>of its incentive compatib=
ility; it may overestimate (some subset of<br>the ancestors could be includ=
ed by itself if it has other high-feerate<br>descendants or are themselves =
higher feerate than this<br>package/transaction). Instead, we use the minim=
um between the package<br>feerate and ancestor feerate of the child as a mo=
re conservative value<br>than what was proposed originally.<br><br>2. A new=
 rule is added, requiring that all package transactions with<br>mempool con=
flicts to be V3. This also means the &quot;sponsoring&quot;<br>child transa=
ction must be V3.<br><br>*Note*: Combined with the V3 rules, this means the=
 package must be<br>a child-with-parents package. Since package validation =
is only<br>attempted if the transactions do not pay sufficient fees to be<b=
r>accepted on their own, this effectively means that only V3<br>transaction=
s can pay to replace their ancestors&#39; conflicts, and only<br>V3 transac=
tions&#39; replacements may be paid for by a descendant.<br><br>*Rationale*=
: The fee-related rules are economically rational for<br>ancestor packages,=
 but not necessarily other types of packages.<br>A child-with-parents packa=
ge is a type of ancestor package. It<br>may be fine to allow any ancestor p=
ackage, but it&#39;s more difficult<br>to account for all of the possibilit=
ies. For example, it gets much<br>harder to see that we&#39;re applying the=
 descendant limits correctly if<br>the package has a gnarly, many-generatio=
n, non-tree shape. I&#39;m also<br>not sure if this policy is 100% incentiv=
e-compatible if the sponsor<br>is not a direct descendant of the sponsee.<b=
r><br>Please see doc/policy/version3_transactions.md and<br>doc/policy/pack=
ages.md in the PR for the full set of rules.<br><br>**Intended usage for LN=
:**<br><br>Commitment transactions should be V3 and have 1 anchor output. T=
hey<br>can be signed with 0 fees (or 1sat/vbyte) once package relay is depl=
oyed<br>on a significant portion of the network. If the commitment tx must<=
br>be broadcast, determine the desired feerate at broadcast time and<br>spe=
nd the anchor output in a high feerate transaction. I&#39;m going to<br>cal=
l the broadcasted commitment tx &quot;the parent&quot; and the attached<br>=
fee-bumping tx &quot;the child.&quot;<br><br>- This child must be V3.<br>- =
This child must be at most 1000vB. Note this restricts the<br>=C2=A0 number=
 of inputs you can use to fund the fee bump. Depending<br>on the output typ=
es, this is around 6-15.<br>- One child may fund fees for multiple commitme=
nt tx (&quot;batched<br>=C2=A0 fee-bumping&quot;).<br>- To do a second fee-=
bump to add more fees, replace the<br>=C2=A0 *child* with a higher-feerate =
tx. Do not try to attach a grandchild.<br><br>Otherwise, never try to spend=
 from an unconfirmed V3 transaction. The<br>descendant limits for V3 transa=
ctions are very restrictive.<br><br>**Expected Questions:**<br><br>&quot;Do=
es this fix Rule 3 Pinning?&quot;<br>Yes. The V3 descendant limit restricts=
 both you and your counterparty.<br>Assuming nodes adopted this policy, you=
 may reasonably assume that you<br>only need to replace the commitment tran=
saction + up to 1000vB.<br><br>&quot;Only 1 anchor output? What if I need t=
o bump counterparty&#39;s commitment tx in mempool?&quot;<br><div>You won&#=
39;t need to fee-bump a counterparty&#39;s commitment tx using CPFP.</div><=
div>You would just package RBF it by attaching a high-feerate child to</div=
>your commitment tx.<br><br>&quot;Is this a privacy issue, i.e. doesn&#39;t=
 it allow fingerprinting LN<br>transactions based on nVersion?&quot;<br>Ind=
eed it may be unrealistic to assume V3 transactions will be in<br>widesprea=
d use outside of L2. IIUC, unilateral closes are already<br>obvious LN tran=
sactions because of the HTLC inputs. For e.g.<br>cooperative closes and ope=
ns, I think it makes sense to continue using<br>V2. So, unless I&#39;m miss=
ing something, this shouldn&#39;t make it worse.<br><br>&quot;So a V3 trans=
action that doesn&#39;t signal BIP125 replaceability is<br>replaceable? Is =
that a backward compatibility issue?&quot;<br>Yes it&#39;s replaceable. It&=
#39;s not an issue AFAICT because,<br>under previous policy, the V3 transac=
tion wouldn&#39;t have been<br>in the mempool in the first place.<br><br>&q=
uot;Can a V2 transaction replace a V3 transaction and vice versa?&quot;<br>=
Yes, otherwise someone can use V3 transactions to censor V2<br>transactions=
 spending shared inputs. Note if the<br>original V3 transaction has an unco=
nfirmed V3 parent, this would<br>violate the &quot;inherited V3&quot; rule =
and would be rejected.<br><br>Thanks for reading! Feedback and review would=
 be much appreciated.<br><br>[1]: <a href=3D"https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2021-September/019464.html" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.=
html</a><br><div>[2]: <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2022-January/019817.html" target=3D"_blank">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html</a></div><d=
iv><br></div>Best,<br>Gloria</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000e6485c05e98933ea--