path: root/41/56af34439d650f111b9462b18655f7bf5db237

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DD67EC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Sep 2021 22:59:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CDC6B4062D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Sep 2021 22:59:31 +0000 (UTC)
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
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id S47N5P5BV3co
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Sep 2021 22:59:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [IPv6:2a00:1450:4864:20::436])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3DC5440108
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Sep 2021 22:59:26 +0000 (UTC)
Received: by mail-wr1-x436.google.com with SMTP id d21so952662wra.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Sep 2021 15:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=M+tya7c9q+8egy77HyEa3QRuna5qEg/74xWe9HF0o8w=;
 b=TgRkXDQO2pFb7Zqiurcnw5io37UEbhqcyuQvOAu+Z2bx11H6YtVA1FmC0L9LrobCis
 rsu1hBdP5a9fNhEV9cy7z+A/+pBYIvhCm7SAfpjFZqa+V4QCwxFprCGJ7gAqC9xoo9Y6
 ika0KPJ1xOjyiY2GW37d0BHtdwHX8Kda5JG3bVAYVZyrQ6spFwuwk0Vm6Nca6PIILiJk
 Bg9OKJa9WIkMjtop62X5/YXPkRmwwdOclWYuB1+KT8/fRdRIdDAODTMldDFcxQ8euqd7
 EBsYR0uyjLBxaVHdGzMkviTcVwvk2RpPWsJqnBiLBHx0Uzd/RxvRINaZNKCyPSE12+y/
 LLug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=M+tya7c9q+8egy77HyEa3QRuna5qEg/74xWe9HF0o8w=;
 b=DaUsdew6RToO2sc1rv0UHJOl5hoU6gncVar+qW2BH77FracYyRFds4e6DsjV5fIXXm
 lfhfi7wKMaAXonuznUMAYd2dvHTBRcwCrmSPluOhyYPZvFMNlTJdjSVuaj+kMKJXXQM3
 G3I/iNkjKZI5ePf94fngmCQr4Z9gOjJiLZVekt//nhsBAV40gCnsVEdaddiQW2ux9Rh0
 65ldvlfG3HVS0ueqD1/16SVcgULhSGEemOOvjVZSz+namAXDQLcYU88FVZQCcJA/xId+
 O44qiXrFyfEVOKFHd5QYmTah1l4boc5MKLhygXbI7FYFQvb+qY35zo97i9ebhLZ7ZiAm
 voPA==
X-Gm-Message-State: AOAM532rUDGgzsLqgZL5crQwawK24WSDIqhkMWKclM6nAcxld5lUSjai
 8XnspnJZSS3j0mx65k27lEO+UUm+/mRfeKsqzsY=
X-Google-Smtp-Source: ABdhPJwyGl/QOeaBV/bQpERVzUXEgvQ7yZss7AqGa1oQgyt7UXM58+z0W2oXFp9tg4G6ol4/8zOiW8pt69J0NVmRmn4=
X-Received: by 2002:adf:f782:: with SMTP id q2mr3045803wrp.203.1632869964172; 
 Tue, 28 Sep 2021 15:59:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAFXO6=+cHyQKM2n9yn4EhwLZO+AUB0ZD81qWPxmpN27rjUoU3w@mail.gmail.com>
 <CALZpt+HpvmEHUEOgye34T6pVQ+wnKKn-_8cTJTQXYQb9t1jOTA@mail.gmail.com>
 <CAFXO6=JzsYgiXJE2geSKMpfgPo+GGNX_+Pw0JQx1QQxAfhCdBQ@mail.gmail.com>
 <CALZpt+HQpdrebhWGXv_yLqiSCB5Ur71L1K13bd7w5TZb9DwJEQ@mail.gmail.com>
 <CAFXO6=Lvcr7Pwn_ZD1CZohYUFKY-cC5sGRxdTOiP2MgnTvFnYA@mail.gmail.com>
 <CALZpt+FFSk-+BBxu7SSdjw580UCFfkdo1DTa1Yj9K81M4E1vPg@mail.gmail.com>
 <CACdvm3Pgia5mn60HmZmi4t0U5coc13WBuDkh+QgQBAHZz+Ufow@mail.gmail.com>
In-Reply-To: <CACdvm3Pgia5mn60HmZmi4t0U5coc13WBuDkh+QgQBAHZz+Ufow@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 28 Sep 2021 18:59:11 -0400
Message-ID: <CALZpt+G4Z3PaWDxAAcTi9FUC+CBF-_42iU-aBuarPvPh8Vqmfw@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>
Content-Type: multipart/alternative; boundary="0000000000002dd02d05cd162aa1"
X-Mailman-Approved-At: Wed, 29 Sep 2021 07:39:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF
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: Tue, 28 Sep 2021 22:59:32 -0000

--0000000000002dd02d05cd162aa1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bastien

> In the case of LN, an attacker can game this and heavily restrict
your RBF attempts if you're only allowed to use confirmed inputs
and have many channels (and a limited number of confirmed inputs).
Otherwise you'll need node operators to pre-emptively split their
utxos into many small utxos just for fee bumping, which is inefficient...

I share the concern about splitting utxos into smaller ones.
IIRC, the carve-out tolerance is only 2txn/10_000 vb. If one of your
counterparties attach a junk branch on her own anchor output, are you
allowed to chain your self-owned unconfirmed CPFP ?
I'm thinking about the topology "Chained CPFPs" exposed here :
https://github.com/rust-bitcoin/rust-lightning/issues/989.
Or if you have another L2 broadcast topology which could be safe w.r.t our
current mempool logic :) ?


Le lun. 27 sept. 2021 =C3=A0 03:15, Bastien TEINTURIER <bastien@acinq.fr> a
=C3=A9crit :

> I think we could restrain package acceptance to only confirmed inputs for
>> now and revisit later this point ? For LN-anchor, you can assume that th=
e
>> fee-bumping UTXO feeding the CPFP is already
>> confirmed. Or are there currently-deployed use-cases which would benefit
>> from your proposed Rule #2 ?
>>
>
> I think constraining package acceptance to only confirmed inputs
> is very limiting and quite dangerous for L2 protocols.
>
> In the case of LN, an attacker can game this and heavily restrict
> your RBF attempts if you're only allowed to use confirmed inputs
> and have many channels (and a limited number of confirmed inputs).
> Otherwise you'll need node operators to pre-emptively split their
> utxos into many small utxos just for fee bumping, which is inefficient...
>
> Bastien
>
> Le lun. 27 sept. 2021 =C3=A0 00:27, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> Hi Gloria,
>>
>> Thanks for your answers,
>>
>> > In summary, it seems that the decisions that might still need
>> > attention/input from devs on this mailing list are:
>> > 1. Whether we should start with multiple-parent-1-child or
>> 1-parent-1-child.
>> > 2. Whether it's ok to require that the child not have conflicts with
>> > mempool transactions.
>>
>> Yes 1) it would be good to have inputs of more potential users of packag=
e
>> acceptance . And 2) I think it's more a matter of clearer wording of the
>> proposal.
>>
>> However, see my final point on the relaxation around "unconfirmed inputs=
"
>> which might in fact alter our current block construction strategy.
>>
>> > Right, the fact that we essentially always choose the first-seen
>> witness is
>> > an unfortunate limitation that exists already. Adding package mempool
>> > accept doesn't worsen this, but the procedure in the future is to
>> replace
>> > the witness when it makes sense economically. We can also add logic to
>> > allow package feerate to pay for witness replacements as well. This is
>> > pretty far into the future, though.
>>
>> Yes I agree package mempool doesn't worsen this. And it's not an issue
>> for current LN as you can't significantly inflate a spending witness for
>> the 2-of-2 funding output.
>> However, it might be an issue for multi-party protocol where the spendin=
g
>> script has alternative branches with asymmetric valid witness weights.
>> Taproot should ease that kind of script so hopefully we would deploy
>> wtxid-replacement not too far in the future.
>>
>> > I could be misunderstanding, but an attacker wouldn't be able to
>> > batch-attack like this. Alice's package only conflicts with A' + D',
>> not A'
>> > + B' + C' + D'. She only needs to pay for evicting 2 transactions.
>>
>> Yeah I can be clearer, I think you have 2 pinning attacks scenarios to
>> consider.
>>
>> In LN, if you're trying to confirm a commitment transaction to time-out
>> or claim on-chain a HTLC and the timelock is near-expiration, you should=
 be
>> ready to pay in commitment+2nd-stage HTLC transaction fees as much as th=
e
>> value offered by the HTLC.
>>
>> Following this security assumption, an attacker can exploit it by
>> targeting together commitment transactions from different channels by
>> blocking them under a high-fee child, of which the fee value
>> is equal to the top-value HTLC + 1. Victims's fee-bumping logics won't
>> overbid as it's not worthy to offer fees beyond their competed HTLCs. Ap=
art
>> from observing mempools state, victims can't learn they're targeted by t=
he
>> same attacker.
>>
>> To draw from the aforementioned topology, Mallory broadcasts A' + B' + C=
'
>> + D', where A' conflicts with Alice's P1, B' conflicts with Bob's P2, C'
>> conflicts with Caroll's P3. Let's assume P1 is confirming the top-value
>> HTLC of the set. If D' fees is higher than P1 + 1, it won't be rational =
for
>> Alice or Bob or Caroll to keep offering competing feerates. Mallory will=
 be
>> at loss on stealing P1, as she has paid more in fees but will realize a
>> gain on P2+P3.
>>
>> In this model, Alice is allowed to evict those 2 transactions (A' + D')
>> but as she is economically-bounded she won't succeed.
>>
>> Mallory is maliciously exploiting RBF rule 3 on absolute fee. I think
>> this 1st pinning scenario is correct and "lucractive" when you sum the
>> global gain/loss.
>>
>> There is a 2nd attack scenario where A + B + C + D, where D is the child
>> of A,B,C. All those transactions are honestly issued by Alice. Once A + =
B +
>> C + D are propagated in network mempools, Mallory is able to replace A +=
 D
>> with  A' + D' where D' is paying a higher fee. This package A' + D' will
>> confirm soon if D feerate was compelling but Mallory succeeds in delayin=
g
>> the confirmation
>> of B + C for one or more blocks. As B + C are pre-signed commitments wit=
h
>> a low-fee rate they won't confirm without Alice issuing a new child E.
>> Mallory can repeat the same trick by broadcasting
>> B' + E' and delay again the confirmation of C.
>>
>> If the remaining package pending HTLC has a higher-value than all the
>> malicious fees over-bid, Mallory should realize a gain. With this 2nd
>> pinning attack, the malicious entity buys confirmation delay of your
>> packaged-together commitments.
>>
>> Assuming those attacks are correct, I'm leaning towards being
>> conservative with the LDK broadcast backend. Though once again, other L2
>> devs have likely other use-cases and opinions :)
>>
>> >  B' only needs to pay for itself in this case.
>>
>> Yes I think it's a nice discount when UTXO is single-owned. In the
>> context of shared-owned UTXO (e.g LN), you might not if there is an
>> in-mempool package already spending the UTXO and have to assume the
>> worst-case scenario. I.e have B' committing enough fee to pay for A'
>> replacement bandwidth. I think we can't do that much for this case...
>>
>> > If a package meets feerate requirements as a
>> package, the parents in the transaction are allowed to replace-by-fee
>> mempool transactions. The child cannot replace mempool transactions."
>>
>> I agree with the Mallory-vs-Alice case. Though if Alice broadcasts A+B'
>> to replace A+B because the first broadcast isn't satisfying anymore due =
to
>> mempool spikes ? Assuming B' fees is enough, I think that case as child =
B'
>> replacing in-mempool transaction B. Which I understand going against  "T=
he
>> child cannot replace mempool transactions".
>>
>> Maybe wording could be a bit clearer ?
>>
>> > While it would be nice to have full RBF, malleability of the child won=
't
>> > block RBF here. If we're trying to replace A', we only require that A'
>> > signals replaceability, and don't mind if its child doesn't.
>>
>> Yes, it sounds good.
>>
>> > Yes, A+C+D pays 2500sat more in fees, but it is also 1000vB larger. A
>> miner
>> > should prefer to utilize their block space more effectively.
>>
>> If your mempool is empty and only composed of A+C+D or A+B, I think
>> taking A+C+D is the most efficient block construction you can come up wi=
th
>> as a miner ?
>>
>> > No, because we don't use that model.
>>
>> Can you describe what miner model we are using ? Like the block
>> construction strategy implemented by `addPackagesTxs` or also encompassi=
ng
>> our current mempool acceptance policy, which I think rely on absolute fe=
e
>> over ancestor score in case of replacement ?
>>
>> I think this point is worthy to discuss as otherwise we might downgrade
>> the efficiency of our current block construction strategy in periods of
>> near-empty mempools. A knowledge which could be discreetly leveraged by =
a
>> miner to gain an advantage on the rest of the mining ecosystem.
>>
>> Note, I think we *might* have to go in this direction if we want to
>> replace replace-by-fee by replace-by-feerate or replace-by-ancestor and
>> solve in-depth pinning attacks. Though if we do so,
>> IMO we would need more thoughts.
>>
>> I think we could restrain package acceptance to only confirmed inputs fo=
r
>> now and revisit later this point ? For LN-anchor, you can assume that th=
e
>> fee-bumping UTXO feeding the CPFP is already
>> confirmed. Or are there currently-deployed use-cases which would benefit
>> from your proposed Rule #2 ?
>>
>> Antoine
>>
>> Le jeu. 23 sept. 2021 =C3=A0 11:36, Gloria Zhao <gloriajzhao@gmail.com> =
a
>> =C3=A9crit :
>>
>>> Hi Antoine,
>>>
>>> Thanks as always for your input. I'm glad we agree on so much!
>>>
>>> In summary, it seems that the decisions that might still need
>>> attention/input from devs on this mailing list are:
>>> 1. Whether we should start with multiple-parent-1-child or
>>> 1-parent-1-child.
>>> 2. Whether it's ok to require that the child not have conflicts with
>>> mempool transactions.
>>>
>>> Responding to your comments...
>>>
>>> > IIUC, you have package A+B, during the dedup phase early in
>>> `AcceptMultipleTransactions` if you observe same-txid-different-wtixd A=
'
>>> and A' is higher feerate than A, you trim A and replace by A' ?
>>>
>>> > I think this approach is safe, the one who appears unsafe to me is
>>> when A' has a _lower_ feerate, even if A' is already accepted by our
>>> mempool ? In that case iirc that would be a pinning.
>>>
>>> Right, the fact that we essentially always choose the first-seen witnes=
s
>>> is an unfortunate limitation that exists already. Adding package mempoo=
l
>>> accept doesn't worsen this, but the procedure in the future is to repla=
ce
>>> the witness when it makes sense economically. We can also add logic to
>>> allow package feerate to pay for witness replacements as well. This is
>>> pretty far into the future, though.
>>>
>>> > It sounds uneconomical for an attacker but I think it's not when you
>>> consider than you can "batch" attack against multiple honest
>>> counterparties. E.g, Mallory broadcast A' + B' + C' + D' where A' confl=
icts
>>> with Alice's honest package P1, B' conflicts with Bob's honest package =
P2,
>>> C' conflicts with Caroll's honest package P3. And D' is a high-fee chil=
d of
>>> A' + B' + C'.
>>>
>>> > If D' is higher-fee than P1 or P2 or P3 but inferior to the sum of
>>> HTLCs confirmed by P1+P2+P3, I think it's lucrative for the attacker ?
>>>
>>> I could be misunderstanding, but an attacker wouldn't be able to
>>> batch-attack like this. Alice's package only conflicts with A' + D', no=
t A'
>>> + B' + C' + D'. She only needs to pay for evicting 2 transactions.
>>>
>>> > Do we assume that broadcasted packages are "honest" by default and
>>> that the parent(s) always need the child to pass the fee checks, that w=
ay
>>> saving the processing of individual transactions which are expected to =
fail
>>> in 99% of cases or more ad hoc composition of packages at relay ?
>>> > I think this point is quite dependent on the p2p packages format/logi=
c
>>> we'll end up on and that we should feel free to revisit it later ?
>>>
>>> I think it's the opposite; there's no way for us to assume that p2p
>>> packages will be "honest." I'd like to have two things before we expose=
 on
>>> P2P: (1) ensure that the amount of resources potentially allocated for
>>> package validation isn't disproportionately higher than that of single
>>> transaction validation and (2) only use package validation when we're
>>> unsatisifed with the single validation result, e.g. we might get better
>>> fees.
>>> Yes, let's revisit this later :)
>>>
>>>  > Yes, if you receive A+B, and A is already in-mempoo, I agree you can
>>> discard its feerate as B should pay for all fees checked on its own. Wh=
ere
>>> I'm unclear is when you have in-mempool A+B and receive A+B'. Should B'
>>> have a fee high enough to cover the bandwidth penalty replacement
>>> (`PaysForRBF`, 2nd check) of both A+B' or only B' ?
>>>
>>>  B' only needs to pay for itself in this case.
>>>
>>> > > Do we want the child to be able to replace mempool transactions as
>>> well?
>>>
>>> > If we mean when you have replaceable A+B then A'+B' try to replace
>>> with a higher-feerate ? I think that's exactly the case we need for
>>> Lightning as A+B is coming from Alice and A'+B' is coming from Bob :/
>>>
>>> Let me clarify this because I can see that my wording was ambiguous, an=
d
>>> then please let me know if it fits Lightning's needs?
>>>
>>> In my proposal, I wrote "If a package meets feerate requirements as a
>>> package, the parents in the transaction are allowed to replace-by-fee
>>> mempool transactions. The child cannot replace mempool transactions." W=
hat
>>> I meant was: the package can replace mempool transactions if any of the
>>> parents conflict with mempool transactions. The child cannot not confli=
ct
>>> with any mempool transactions.
>>> The Lightning use case this attempts to address is: Alice and Mallory
>>> are LN counterparties, and have packages A+B and A'+B', respectively. A=
 and
>>> A' are their commitment transactions and conflict with each other; they
>>> have shared inputs and different txids.
>>> B spends Alice's anchor output from A. B' spends Mallory's anchor outpu=
t
>>> from A'. Thus, B and B' do not conflict with each other.
>>> Alice can broadcast her package, A+B, to replace Mallory's package,
>>> A'+B', since B doesn't conflict with the mempool.
>>>
>>> Would this be ok?
>>>
>>> > The second option, a child of A', In the LN case I think the CPFP is
>>> attached on one's anchor output.
>>>
>>> While it would be nice to have full RBF, malleability of the child won'=
t
>>> block RBF here. If we're trying to replace A', we only require that A'
>>> signals replaceability, and don't mind if its child doesn't.
>>>
>>> > > B has an ancestor score of 10sat/vb and D has an
>>> > > ancestor score of ~2.9sat/vb. Since D's ancestor score is lower tha=
n
>>> B's,
>>> > > it fails the proposed package RBF Rule #2, so this package would be
>>> > > rejected. Does this meet your expectations?
>>>
>>> > Well what sounds odd to me, in my example, we fail D even if it has a
>>> higher-fee than B. Like A+B absolute fees are 2000 sats and A+C+D absol=
ute
>>> fees are 4500 sats ?
>>>
>>> Yes, A+C+D pays 2500sat more in fees, but it is also 1000vB larger. A
>>> miner should prefer to utilize their block space more effectively.
>>>
>>> > Is this compatible with a model where a miner prioritizes absolute
>>> fees over ancestor score, in the case that mempools aren't full-enough =
to
>>> fulfill a block ?
>>>
>>> No, because we don't use that model.
>>>
>>> Thanks,
>>> Gloria
>>>
>>> On Thu, Sep 23, 2021 at 5:29 AM Antoine Riard <antoine.riard@gmail.com>
>>> wrote:
>>>
>>>> > Correct, if B+C is too low feerate to be accepted, we will reject it=
.
>>>> I
>>>> > prefer this because it is incentive compatible: A can be mined by
>>>> itself,
>>>> > so there's no reason to prefer A+B+C instead of A.
>>>> > As another way of looking at this, consider the case where we do
>>>> accept
>>>> > A+B+C and it sits at the "bottom" of our mempool. If our mempool
>>>> reaches
>>>> > capacity, we evict the lowest descendant feerate transactions, which
>>>> are
>>>> > B+C in this case. This gives us the same resulting mempool, with A
>>>> and not
>>>> > B+C.
>>>>
>>>> I agree here. Doing otherwise, we might evict other transactions
>>>> mempool in `MempoolAccept::Finalize` with a higher-feerate than B+C wh=
ile
>>>> those evicted transactions are the most compelling for block construct=
ion.
>>>>
>>>> I thought at first missing this acceptance requirement would break a
>>>> fee-bumping scheme like Parent-Pay-For-Child where a high-fee parent i=
s
>>>> attached to a child signed with SIGHASH_ANYONECANPAY but in this case =
the
>>>> child fee is capturing the parent value. I can't think of other fee-bu=
mping
>>>> schemes potentially affected. If they do exist I would say they're wro=
ng in
>>>> their design assumptions.
>>>>
>>>> > If or when we have witness replacement, the logic is: if the
>>>> individual
>>>> > transaction is enough to replace the mempool one, the replacement wi=
ll
>>>> > happen during the preceding individual transaction acceptance, and
>>>> > deduplication logic will work. Otherwise, we will try to deduplicate
>>>> by
>>>> > wtxid, see that we need a package witness replacement, and use the
>>>> package
>>>> > feerate to evaluate whether this is economically rational.
>>>>
>>>> IIUC, you have package A+B, during the dedup phase early in
>>>> `AcceptMultipleTransactions` if you observe same-txid-different-wtixd =
A'
>>>> and A' is higher feerate than A, you trim A and replace by A' ?
>>>>
>>>> I think this approach is safe, the one who appears unsafe to me is whe=
n
>>>> A' has a _lower_ feerate, even if A' is already accepted by our mempoo=
l ?
>>>> In that case iirc that would be a pinning.
>>>>
>>>> Good to see progress on witness replacement before we see usage of
>>>> Taproot tree in the context of multi-party, where a malicious counterp=
arty
>>>> inflates its witness to jam a honest spending.
>>>>
>>>> (Note, the commit linked currently points nowhere :))
>>>>
>>>>
>>>> > Please note that A may replace A' even if A' has higher fees than A
>>>> > individually, because the proposed package RBF utilizes the fees and
>>>> size
>>>> > of the entire package. This just requires E to pay enough fees,
>>>> although
>>>> > this can be pretty high if there are also potential B' and C'
>>>> competing
>>>> > commitment transactions that we don't know about.
>>>>
>>>> Ah right, if the package acceptance waives `PaysMoreThanConflicts` for
>>>> the individual check on A, the honest package should replace the pinni=
ng
>>>> attempt. I've not fully parsed the proposed implementation yet.
>>>>
>>>> Though note, I think it's still unsafe for a Lightning
>>>> multi-commitment-broadcast-as-one-package as a malicious A' might have=
 an
>>>> absolute fee higher than E. It sounds uneconomical for
>>>> an attacker but I think it's not when you consider than you can "batch=
"
>>>> attack against multiple honest counterparties. E.g, Mallory broadcast =
A' +
>>>> B' + C' + D' where A' conflicts with Alice's honest package P1, B'
>>>> conflicts with Bob's honest package P2, C' conflicts with Caroll's hon=
est
>>>> package P3. And D' is a high-fee child of A' + B' + C'.
>>>>
>>>> If D' is higher-fee than P1 or P2 or P3 but inferior to the sum of
>>>> HTLCs confirmed by P1+P2+P3, I think it's lucrative for the attacker ?
>>>>
>>>> > So far, my understanding is that multi-parent-1-child is desired for
>>>> > batched fee-bumping (
>>>> > https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289=
)
>>>> and
>>>> > I've also seen your response which I have less context on (
>>>> > https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202=
).
>>>> That
>>>> > being said, I am happy to create a new proposal for 1 parent + 1 chi=
ld
>>>> > (which would be slightly simpler) and plan for moving to
>>>> > multi-parent-1-child later if that is preferred. I am very intereste=
d
>>>> in
>>>> > hearing feedback on that approach.
>>>>
>>>> I think batched fee-bumping is okay as long as you don't have
>>>> time-sensitive outputs encumbering your commitment transactions. For t=
he
>>>> reasons mentioned above, I think that's unsafe.
>>>>
>>>> What I'm worried about is  L2 developers, potentially not aware about
>>>> all the mempool subtleties blurring the difference and always batching
>>>> their broadcast by default.
>>>>
>>>> IMO, a good thing by restraining to 1-parent + 1 child,  we
>>>> artificially constraint L2 design space for now and minimize risks of
>>>> unsafe usage of the package API :)
>>>>
>>>> I think that's a point where it would be relevant to have the opinion
>>>> of more L2 devs.
>>>>
>>>> > I think there is a misunderstanding here - let me describe what I'm
>>>> > proposing we'd do in this situation: we'll try individual submission
>>>> for A,
>>>> > see that it fails due to "insufficient fees." Then, we'll try packag=
e
>>>> > validation for A+B and use package RBF. If A+B pays enough, it can
>>>> still
>>>> > replace A'. If A fails for a bad signature, we won't look at B or
>>>> A+B. Does
>>>> > this meet your expectations?
>>>>
>>>> Yes there was a misunderstanding, I think this approach is correct,
>>>> it's more a question of performance. Do we assume that broadcasted pac=
kages
>>>> are "honest" by default and that the parent(s) always need the child t=
o
>>>> pass the fee checks, that way saving the processing of individual
>>>> transactions which are expected to fail in 99% of cases or more ad hoc
>>>> composition of packages at relay ?
>>>>
>>>> I think this point is quite dependent on the p2p packages format/logic
>>>> we'll end up on and that we should feel free to revisit it later ?
>>>>
>>>>
>>>> > What problem are you trying to solve by the package feerate *after*
>>>> dedup
>>>> rule ?
>>>> > My understanding is that an in-package transaction might be already =
in
>>>> the mempool. Therefore, to compute a correct RBF penalty replacement,
>>>> the
>>>> vsize of this transaction could be discarded lowering the cost of
>>>> package
>>>> RBF.
>>>>
>>>> > I'm proposing that, when a transaction has already been submitted to
>>>> > mempool, we would ignore both its fees and vsize when calculating
>>>> package
>>>> > feerate.
>>>>
>>>> Yes, if you receive A+B, and A is already in-mempoo, I agree you can
>>>> discard its feerate as B should pay for all fees checked on its own. W=
here
>>>> I'm unclear is when you have in-mempool A+B and receive A+B'. Should B=
'
>>>> have a fee high enough to cover the bandwidth penalty replacement
>>>> (`PaysForRBF`, 2nd check) of both A+B' or only B' ?
>>>>
>>>> If you have a second-layer like current Lightning, you might have a
>>>> counterparty commitment to replace and should always expect to have to=
 pay
>>>> for parent replacement bandwidth.
>>>>
>>>> Where a potential discount sounds interesting is when you have an
>>>> univoque state on the first-stage of transactions. E.g DLC's funding
>>>> transaction which might be CPFP by any participant iirc.
>>>>
>>>> > Note that, if C' conflicts with C, it also conflicts with D, since D
>>>> is a
>>>> > descendant of C and would thus need to be evicted along with it.
>>>>
>>>> Ah once again I think it's a misunderstanding without the code under m=
y
>>>> eyes! If we do C' `PreChecks`, solve the conflicts provoked by it, i.e=
 mark
>>>> for potential eviction D and don't consider it for future conflicts in=
 the
>>>> rest of the package, I think D' `PreChecks` should be good ?
>>>>
>>>> > More generally, this example is surprising to me because I didn't
>>>> think
>>>> > packages would be used to fee-bump replaceable transactions. Do we
>>>> want the
>>>> > child to be able to replace mempool transactions as well?
>>>>
>>>> If we mean when you have replaceable A+B then A'+B' try to replace wit=
h
>>>> a higher-feerate ? I think that's exactly the case we need for Lightni=
ng as
>>>> A+B is coming from Alice and A'+B' is coming from Bob :/
>>>>
>>>> > I'm not sure what you mean? Let's say we have a package of parent A =
+
>>>> child
>>>> > B, where A is supposed to replace a mempool transaction A'. Are you
>>>> saying
>>>> > that counterparties are able to malleate the package child B, or a
>>>> child of
>>>> > A'?
>>>>
>>>> The second option, a child of A', In the LN case I think the CPFP is
>>>> attached on one's anchor output.
>>>>
>>>> I think it's good if we assume the
>>>> solve-conflicts-after-parent's`'PreChecks` mentioned above or fixing
>>>> inherited signaling or full-rbf ?
>>>>
>>>> > Sorry, I don't understand what you mean by "preserve the package
>>>> > integrity?" Could you elaborate?
>>>>
>>>> After thinking the relaxation about the "new" unconfirmed input is not
>>>> linked to trimming but I would say more to the multi-parent support.
>>>>
>>>> Let's say you have A+B trying to replace C+D where B is also spending
>>>> already in-mempool E. To succeed, you need to waive the no-new-unconfi=
rmed
>>>> input as D isn't spending E.
>>>>
>>>> So good, I think we agree on the problem description here.
>>>>
>>>> > I am in agreement with your calculations but unsure if we disagree o=
n
>>>> the
>>>> > expected outcome. Yes, B has an ancestor score of 10sat/vb and D has
>>>> an
>>>> > ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than
>>>> B's,
>>>> > it fails the proposed package RBF Rule #2, so this package would be
>>>> > rejected. Does this meet your expectations?
>>>>
>>>> Well what sounds odd to me, in my example, we fail D even if it has a
>>>> higher-fee than B. Like A+B absolute fees are 2000 sats and A+C+D abso=
lute
>>>> fees are 4500 sats ?
>>>>
>>>> Is this compatible with a model where a miner prioritizes absolute fee=
s
>>>> over ancestor score, in the case that mempools aren't full-enough to
>>>> fulfill a block ?
>>>>
>>>> Let me know if I can clarify a point.
>>>>
>>>> Antoine
>>>>
>>>> Le lun. 20 sept. 2021 =C3=A0 11:10, Gloria Zhao <gloriajzhao@gmail.com=
> a
>>>> =C3=A9crit :
>>>>
>>>>>
>>>>> Hi Antoine,
>>>>>
>>>>> First of all, thank you for the thorough review. I appreciate your
>>>>> insight on LN requirements.
>>>>>
>>>>> > IIUC, you have a package A+B+C submitted for acceptance and A is
>>>>> already in your mempool. You trim out A from the package and then eva=
luate
>>>>> B+C.
>>>>>
>>>>> > I think this might be an issue if A is the higher-fee element of th=
e
>>>>> ABC package. B+C package fees might be under the mempool min fee and =
will
>>>>> be rejected, potentially breaking the acceptance expectations of the
>>>>> package issuer ?
>>>>>
>>>>> Correct, if B+C is too low feerate to be accepted, we will reject it.
>>>>> I prefer this because it is incentive compatible: A can be mined by i=
tself,
>>>>> so there's no reason to prefer A+B+C instead of A.
>>>>> As another way of looking at this, consider the case where we do
>>>>> accept A+B+C and it sits at the "bottom" of our mempool. If our mempo=
ol
>>>>> reaches capacity, we evict the lowest descendant feerate transactions=
,
>>>>> which are B+C in this case. This gives us the same resulting mempool,=
 with
>>>>> A and not B+C.
>>>>>
>>>>>
>>>>> > Further, I think the dedup should be done on wtxid, as you might
>>>>> have multiple valid witnesses. Though with varying vsizes and as such
>>>>> offering different feerates.
>>>>>
>>>>> I agree that variations of the same package with different witnesses
>>>>> is a case that must be handled. I consider witness replacement to be =
a
>>>>> project that can be done in parallel to package mempool acceptance be=
cause
>>>>> being able to accept packages does not worsen the problem of a
>>>>> same-txid-different-witness "pinning" attack.
>>>>>
>>>>> If or when we have witness replacement, the logic is: if the
>>>>> individual transaction is enough to replace the mempool one, the
>>>>> replacement will happen during the preceding individual transaction
>>>>> acceptance, and deduplication logic will work. Otherwise, we will try=
 to
>>>>> deduplicate by wtxid, see that we need a package witness replacement,=
 and
>>>>> use the package feerate to evaluate whether this is economically rati=
onal.
>>>>>
>>>>> See the #22290 "handle package transactions already in mempool" commi=
t
>>>>> (
>>>>> https://github.com/bitcoin/bitcoin/pull/22290/commits/fea75a2237b46cf=
76145242fecad7e274bfcb5ff),
>>>>> which handles the case of same-txid-different-witness by simply using=
 the
>>>>> transaction in the mempool for now, with TODOs for what I just descri=
bed.
>>>>>
>>>>>
>>>>> > I'm not clearly understanding the accepted topologies. By "parent
>>>>> and child to share a parent", do you mean the set of transactions A, =
B, C,
>>>>> where B is spending A and C is spending A and B would be correct ?
>>>>>
>>>>> Yes, that is what I meant. Yes, that would a valid package under thes=
e
>>>>> rules.
>>>>>
>>>>> > If yes, is there a width-limit introduced or we fallback on
>>>>> MAX_PACKAGE_COUNT=3D25 ?
>>>>>
>>>>> No, there is no limit on connectivity other than "child with all
>>>>> unconfirmed parents." We will enforce MAX_PACKAGE_COUNT=3D25 and chil=
d's
>>>>> in-mempool + in-package ancestor limits.
>>>>>
>>>>>
>>>>> > Considering the current Core's mempool acceptance rules, I think
>>>>> CPFP batching is unsafe for LN time-sensitive closure. A malicious tx=
-relay
>>>>> jamming successful on one channel commitment transaction would contam=
ine
>>>>> the remaining commitments sharing the same package.
>>>>>
>>>>> > E.g, you broadcast the package A+B+C+D+E where A,B,C,D are
>>>>> commitment transactions and E a shared CPFP. If a malicious A' transa=
ction
>>>>> has a better feerate than A, the whole package acceptance will fail. =
Even
>>>>> if A' confirms in the following block,
>>>>> the propagation and confirmation of B+C+D have been delayed. This
>>>>> could carry on a loss of funds.
>>>>>
>>>>> Please note that A may replace A' even if A' has higher fees than A
>>>>> individually, because the proposed package RBF utilizes the fees and =
size
>>>>> of the entire package. This just requires E to pay enough fees, altho=
ugh
>>>>> this can be pretty high if there are also potential B' and C' competi=
ng
>>>>> commitment transactions that we don't know about.
>>>>>
>>>>>
>>>>> > IMHO, I'm leaning towards deploying during a first phase
>>>>> 1-parent/1-child. I think it's the most conservative step still impro=
ving
>>>>> second-layer safety.
>>>>>
>>>>> So far, my understanding is that multi-parent-1-child is desired for
>>>>> batched fee-bumping (
>>>>> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289)
>>>>> and I've also seen your response which I have less context on (
>>>>> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202)=
.
>>>>> That being said, I am happy to create a new proposal for 1 parent + 1=
 child
>>>>> (which would be slightly simpler) and plan for moving to
>>>>> multi-parent-1-child later if that is preferred. I am very interested=
 in
>>>>> hearing feedback on that approach.
>>>>>
>>>>>
>>>>> > If A+B is submitted to replace A', where A pays 0 sats, B pays 200
>>>>> sats and A' pays 100 sats. If we apply the individual RBF on A, A+B
>>>>> acceptance fails. For this reason I think the individual RBF should b=
e
>>>>> bypassed and only the package RBF apply ?
>>>>>
>>>>> I think there is a misunderstanding here - let me describe what I'm
>>>>> proposing we'd do in this situation: we'll try individual submission =
for A,
>>>>> see that it fails due to "insufficient fees." Then, we'll try package
>>>>> validation for A+B and use package RBF. If A+B pays enough, it can st=
ill
>>>>> replace A'. If A fails for a bad signature, we won't look at B or A+B=
. Does
>>>>> this meet your expectations?
>>>>>
>>>>>
>>>>> > What problem are you trying to solve by the package feerate *after*
>>>>> dedup rule ?
>>>>> > My understanding is that an in-package transaction might be already
>>>>> in the mempool. Therefore, to compute a correct RBF penalty replaceme=
nt,
>>>>> the vsize of this transaction could be discarded lowering the cost of
>>>>> package RBF.
>>>>>
>>>>> I'm proposing that, when a transaction has already been submitted to
>>>>> mempool, we would ignore both its fees and vsize when calculating pac=
kage
>>>>> feerate. In example G2, we shouldn't count M1 fees after its submissi=
on to
>>>>> mempool, since M1's fees have already been used to pay for its indivi=
dual
>>>>> bandwidth, and it shouldn't be used again to pay for P2 and P3's band=
width.
>>>>> We also shouldn't count its vsize, since it has already been paid for=
.
>>>>>
>>>>>
>>>>> > I think this is a footgunish API, as if a package issuer send the
>>>>> multiple-parent-one-child package A,B,C,D where D is the child of A,B=
,C.
>>>>> Then try to broadcast the higher-feerate C'+D' package, it should be
>>>>> rejected. So it's breaking the naive broadcaster assumption that a
>>>>> higher-feerate/higher-fee package always replaces ?
>>>>>
>>>>> Note that, if C' conflicts with C, it also conflicts with D, since D
>>>>> is a descendant of C and would thus need to be evicted along with it.
>>>>> Implicitly, D' would not be in conflict with D.
>>>>> More generally, this example is surprising to me because I didn't
>>>>> think packages would be used to fee-bump replaceable transactions. Do=
 we
>>>>> want the child to be able to replace mempool transactions as well? Th=
is can
>>>>> be implemented with a bit of additional logic.
>>>>>
>>>>> > I think this is unsafe for L2s if counterparties have malleability
>>>>> of the child transaction. They can block your package replacement by
>>>>> opting-out from RBF signaling. IIRC, LN's "anchor output" presents su=
ch an
>>>>> ability.
>>>>>
>>>>> I'm not sure what you mean? Let's say we have a package of parent A +
>>>>> child B, where A is supposed to replace a mempool transaction A'. Are=
 you
>>>>> saying that counterparties are able to malleate the package child B, =
or a
>>>>> child of A'? If they can malleate a child of A', that shouldn't matte=
r as
>>>>> long as A' is signaling replacement. This would be handled identicall=
y with
>>>>> full RBF and what Core currently implements.
>>>>>
>>>>> > I think this is an issue brought by the trimming during the dedup
>>>>> phase. If we preserve the package integrity, only re-using the tx-lev=
el
>>>>> checks results of already in-mempool transactions to gain in CPU time=
 we
>>>>> won't have this issue. Package childs can add unconfirmed inputs as l=
ong as
>>>>> they're in-package, the bip125 rule2 is only evaluated against parent=
s ?
>>>>>
>>>>> Sorry, I don't understand what you mean by "preserve the package
>>>>> integrity?" Could you elaborate?
>>>>>
>>>>> > Let's say you have in-mempool A, B where A pays 10 sat/vb for 100
>>>>> vbytes and B pays 10 sat/vb for 100 vbytes. You have the candidate
>>>>> replacement D spending both A and C where D pays 15sat/vb for 100 vby=
tes
>>>>> and C pays 1 sat/vb for 1000 vbytes.
>>>>>
>>>>> > Package A + B ancestor score is 10 sat/vb.
>>>>>
>>>>> > D has a higher feerate/absolute fee than B.
>>>>>
>>>>> > Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C'=
s
>>>>> 1000 sats + D's 1500 sats) / A's 100 vb + C's 1000 vb + D's 100 vb)
>>>>>
>>>>> I am in agreement with your calculations but unsure if we disagree on
>>>>> the expected outcome. Yes, B has an ancestor score of 10sat/vb and D =
has an
>>>>> ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than =
B's,
>>>>> it fails the proposed package RBF Rule #2, so this package would be
>>>>> rejected. Does this meet your expectations?
>>>>>
>>>>> Thank you for linking to projects that might be interested in package
>>>>> relay :)
>>>>>
>>>>> Thanks,
>>>>> Gloria
>>>>>
>>>>> On Mon, Sep 20, 2021 at 12:16 AM Antoine Riard <
>>>>> antoine.riard@gmail.com> wrote:
>>>>>
>>>>>> Hi Gloria,
>>>>>>
>>>>>> > A package may contain transactions that are already in the mempool=
.
>>>>>> We
>>>>>> > remove
>>>>>> > ("deduplicate") those transactions from the package for the
>>>>>> purposes of
>>>>>> > package
>>>>>> > mempool acceptance. If a package is empty after deduplication, we =
do
>>>>>> > nothing.
>>>>>>
>>>>>> IIUC, you have a package A+B+C submitted for acceptance and A is
>>>>>> already in your mempool. You trim out A from the package and then ev=
aluate
>>>>>> B+C.
>>>>>>
>>>>>> I think this might be an issue if A is the higher-fee element of the
>>>>>> ABC package. B+C package fees might be under the mempool min fee and=
 will
>>>>>> be rejected, potentially breaking the acceptance expectations of the
>>>>>> package issuer ?
>>>>>>
>>>>>> Further, I think the dedup should be done on wtxid, as you might hav=
e
>>>>>> multiple valid witnesses. Though with varying vsizes and as such off=
ering
>>>>>> different feerates.
>>>>>>
>>>>>> E.g you're going to evaluate the package A+B and A' is already in
>>>>>> your mempool with a bigger valid witness. You trim A based on txid, =
then
>>>>>> you evaluate A'+B, which fails the fee checks. However, evaluating A=
+B
>>>>>> would have been a success.
>>>>>>
>>>>>> AFAICT, the dedup rationale would be to save on CPU time/IO disk, to
>>>>>> avoid repeated signatures verification and parent UTXOs fetches ? Ca=
n we
>>>>>> achieve the same goal by bypassing tx-level checks for already-in tx=
n while
>>>>>> conserving the package integrity for package-level checks ?
>>>>>>
>>>>>> > Note that it's possible for the parents to be
>>>>>> > indirect
>>>>>> > descendants/ancestors of one another, or for parent and child to
>>>>>> share a
>>>>>> > parent,
>>>>>> > so we cannot make any other topology assumptions.
>>>>>>
>>>>>> I'm not clearly understanding the accepted topologies. By "parent an=
d
>>>>>> child to share a parent", do you mean the set of transactions A, B, =
C,
>>>>>> where B is spending A and C is spending A and B would be correct ?
>>>>>>
>>>>>> If yes, is there a width-limit introduced or we fallback on
>>>>>> MAX_PACKAGE_COUNT=3D25 ?
>>>>>>
>>>>>> IIRC, one rationale to come with this topology limitation was to
>>>>>> lower the DoS risks when potentially deploying p2p packages.
>>>>>>
>>>>>> Considering the current Core's mempool acceptance rules, I think CPF=
P
>>>>>> batching is unsafe for LN time-sensitive closure. A malicious tx-rel=
ay
>>>>>> jamming successful on one channel commitment transaction would conta=
mine
>>>>>> the remaining commitments sharing the same package.
>>>>>>
>>>>>> E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitmen=
t
>>>>>> transactions and E a shared CPFP. If a malicious A' transaction has =
a
>>>>>> better feerate than A, the whole package acceptance will fail. Even =
if A'
>>>>>> confirms in the following block,
>>>>>> the propagation and confirmation of B+C+D have been delayed. This
>>>>>> could carry on a loss of funds.
>>>>>>
>>>>>> That said, if you're broadcasting commitment transactions without
>>>>>> time-sensitive HTLC outputs, I think the batching is effectively a f=
ee
>>>>>> saving as you don't have to duplicate the CPFP.
>>>>>>
>>>>>> IMHO, I'm leaning towards deploying during a first phase
>>>>>> 1-parent/1-child. I think it's the most conservative step still impr=
oving
>>>>>> second-layer safety.
>>>>>>
>>>>>> > *Rationale*:  It would be incorrect to use the fees of transaction=
s
>>>>>> that are
>>>>>> > already in the mempool, as we do not want a transaction's fees to =
be
>>>>>> > double-counted for both its individual RBF and package RBF.
>>>>>>
>>>>>> I'm unsure about the logical order of the checks proposed.
>>>>>>
>>>>>> If A+B is submitted to replace A', where A pays 0 sats, B pays 200
>>>>>> sats and A' pays 100 sats. If we apply the individual RBF on A, A+B
>>>>>> acceptance fails. For this reason I think the individual RBF should =
be
>>>>>> bypassed and only the package RBF apply ?
>>>>>>
>>>>>> Note this situation is plausible, with current LN design, your
>>>>>> counterparty can have a commitment transaction with a better fee jus=
t by
>>>>>> selecting a higher `dust_limit_satoshis` than yours.
>>>>>>
>>>>>> > Examples F and G [14] show the same package, but P1 is submitted
>>>>>> > individually before
>>>>>> > the package in example G. In example F, we can see that the 300vB
>>>>>> package
>>>>>> > pays
>>>>>> > an additional 200sat in fees, which is not enough to pay for its o=
wn
>>>>>> > bandwidth
>>>>>> > (BIP125#4). In example G, we can see that P1 pays enough to replac=
e
>>>>>> M1, but
>>>>>> > using P1's fees again during package submission would make it look
>>>>>> like a
>>>>>> > 300sat
>>>>>> > increase for a 200vB package. Even including its fees and size
>>>>>> would not be
>>>>>> > sufficient in this example, since the 300sat looks like enough for
>>>>>> the 300vB
>>>>>> > package. The calculcation after deduplication is 100sat increase
>>>>>> for a
>>>>>> > package
>>>>>> > of size 200vB, which correctly fails BIP125#4. Assume all
>>>>>> transactions have
>>>>>> > a
>>>>>> > size of 100vB.
>>>>>>
>>>>>> What problem are you trying to solve by the package feerate *after*
>>>>>> dedup rule ?
>>>>>>
>>>>>> My understanding is that an in-package transaction might be already
>>>>>> in the mempool. Therefore, to compute a correct RBF penalty replacem=
ent,
>>>>>> the vsize of this transaction could be discarded lowering the cost o=
f
>>>>>> package RBF.
>>>>>>
>>>>>> If we keep a "safe" dedup mechanism (see my point above), I think
>>>>>> this discount is justified, as the validation cost of node operators=
 is
>>>>>> paid for ?
>>>>>>
>>>>>> > The child cannot replace mempool transactions.
>>>>>>
>>>>>> Let's say you issue package A+B, then package C+B', where B' is a
>>>>>> child of both A and C. This rule fails the acceptance of C+B' ?
>>>>>>
>>>>>> I think this is a footgunish API, as if a package issuer send the
>>>>>> multiple-parent-one-child package A,B,C,D where D is the child of A,=
B,C.
>>>>>> Then try to broadcast the higher-feerate C'+D' package, it should be
>>>>>> rejected. So it's breaking the naive broadcaster assumption that a
>>>>>> higher-feerate/higher-fee package always replaces ? And it might be =
unsafe
>>>>>> in protocols where states are symmetric. E.g a malicious counterpart=
y
>>>>>> broadcasts first S+A, then you honestly broadcast S+B, where B pays =
better
>>>>>> fees.
>>>>>>
>>>>>> > All mempool transactions to be replaced must signal replaceability=
.
>>>>>>
>>>>>> I think this is unsafe for L2s if counterparties have malleability o=
f
>>>>>> the child transaction. They can block your package replacement by
>>>>>> opting-out from RBF signaling. IIRC, LN's "anchor output" presents s=
uch an
>>>>>> ability.
>>>>>>
>>>>>> I think it's better to either fix inherited signaling or move toward=
s
>>>>>> full-rbf.
>>>>>>
>>>>>> > if a package parent has already been submitted, it would
>>>>>> > look
>>>>>> >like the child is spending a "new" unconfirmed input.
>>>>>>
>>>>>> I think this is an issue brought by the trimming during the dedup
>>>>>> phase. If we preserve the package integrity, only re-using the tx-le=
vel
>>>>>> checks results of already in-mempool transactions to gain in CPU tim=
e we
>>>>>> won't have this issue. Package childs can add unconfirmed inputs as =
long as
>>>>>> they're in-package, the bip125 rule2 is only evaluated against paren=
ts ?
>>>>>>
>>>>>> > However, we still achieve the same goal of requiring the
>>>>>> > replacement
>>>>>> > transactions to have a ancestor score at least as high as the
>>>>>> original
>>>>>> > ones.
>>>>>>
>>>>>> I'm not sure if this holds...
>>>>>>
>>>>>> Let's say you have in-mempool A, B where A pays 10 sat/vb for 100
>>>>>> vbytes and B pays 10 sat/vb for 100 vbytes. You have the candidate
>>>>>> replacement D spending both A and C where D pays 15sat/vb for 100 vb=
ytes
>>>>>> and C pays 1 sat/vb for 1000 vbytes.
>>>>>>
>>>>>> Package A + B ancestor score is 10 sat/vb.
>>>>>>
>>>>>> D has a higher feerate/absolute fee than B.
>>>>>>
>>>>>> Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's
>>>>>> 1000 sats + D's 1500 sats) /
>>>>>> A's 100 vb + C's 1000 vb + D's 100 vb)
>>>>>>
>>>>>> Overall, this is a review through the lenses of LN requirements. I
>>>>>> think other L2 protocols/applications
>>>>>> could be candidates to using package accept/relay such as:
>>>>>> * https://github.com/lightninglabs/pool
>>>>>> * https://github.com/discreetlogcontracts/dlcspecs
>>>>>> * https://github.com/bitcoin-teleport/teleport-transactions/
>>>>>> * https://github.com/sapio-lang/sapio
>>>>>> *
>>>>>> https://github.com/commerceblock/mercury/blob/master/doc/statechains=
.md
>>>>>> * https://github.com/revault/practical-revault
>>>>>>
>>>>>> Thanks for rolling forward the ball on this subject.
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>> Le jeu. 16 sept. 2021 =C3=A0 03:55, Gloria Zhao via bitcoin-dev <
>>>>>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>>>>>>
>>>>>>> Hi there,
>>>>>>>
>>>>>>> I'm writing to propose a set of mempool policy changes to enable
>>>>>>> package
>>>>>>> validation (in preparation for package relay) in Bitcoin Core. Thes=
e
>>>>>>> would not
>>>>>>> be consensus or P2P protocol changes. However, since mempool policy
>>>>>>> significantly affects transaction propagation, I believe this is
>>>>>>> relevant for
>>>>>>> the mailing list.
>>>>>>>
>>>>>>> My proposal enables packages consisting of multiple parents and 1
>>>>>>> child. If you
>>>>>>> develop software that relies on specific transaction relay
>>>>>>> assumptions and/or
>>>>>>> are interested in using package relay in the future, I'm very
>>>>>>> interested to hear
>>>>>>> your feedback on the utility or restrictiveness of these package
>>>>>>> policies for
>>>>>>> your use cases.
>>>>>>>
>>>>>>> A draft implementation of this proposal can be found in [Bitcoin Co=
re
>>>>>>> PR#22290][1].
>>>>>>>
>>>>>>> An illustrated version of this post can be found at
>>>>>>> https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a.
>>>>>>> I have also linked the images below.
>>>>>>>
>>>>>>> ## Background
>>>>>>>
>>>>>>> Feel free to skip this section if you are already familiar with
>>>>>>> mempool policy
>>>>>>> and package relay terminology.
>>>>>>>
>>>>>>> ### Terminology Clarifications
>>>>>>>
>>>>>>> * Package =3D an ordered list of related transactions, representabl=
e
>>>>>>> by a Directed
>>>>>>>   Acyclic Graph.
>>>>>>> * Package Feerate =3D the total modified fees divided by the total
>>>>>>> virtual size of
>>>>>>>   all transactions in the package.
>>>>>>>     - Modified fees =3D a transaction's base fees + fee delta appli=
ed
>>>>>>> by the user
>>>>>>>       with `prioritisetransaction`. As such, we expect this to vary
>>>>>>> across
>>>>>>> mempools.
>>>>>>>     - Virtual Size =3D the maximum of virtual sizes calculated usin=
g
>>>>>>> [BIP141
>>>>>>>       virtual size][2] and sigop weight. [Implemented here in
>>>>>>> Bitcoin Core][3].
>>>>>>>     - Note that feerate is not necessarily based on the base fees
>>>>>>> and serialized
>>>>>>>       size.
>>>>>>>
>>>>>>> * Fee-Bumping =3D user/wallet actions that take advantage of miner
>>>>>>> incentives to
>>>>>>>   boost a transaction's candidacy for inclusion in a block,
>>>>>>> including Child Pays
>>>>>>> for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our
>>>>>>> intention in
>>>>>>> mempool policy is to recognize when the new transaction is more
>>>>>>> economical to
>>>>>>> mine than the original one(s) but not open DoS vectors, so there ar=
e
>>>>>>> some
>>>>>>> limitations.
>>>>>>>
>>>>>>> ### Policy
>>>>>>>
>>>>>>> The purpose of the mempool is to store the best (to be most
>>>>>>> incentive-compatible
>>>>>>> with miners, highest feerate) candidates for inclusion in a block.
>>>>>>> Miners use
>>>>>>> the mempool to build block templates. The mempool is also useful as
>>>>>>> a cache for
>>>>>>> boosting block relay and validation performance, aiding transaction
>>>>>>> relay, and
>>>>>>> generating feerate estimations.
>>>>>>>
>>>>>>> Ideally, all consensus-valid transactions paying reasonable fees
>>>>>>> should make it
>>>>>>> to miners through normal transaction relay, without any special
>>>>>>> connectivity or
>>>>>>> relationships with miners. On the other hand, nodes do not have
>>>>>>> unlimited
>>>>>>> resources, and a P2P network designed to let any honest node
>>>>>>> broadcast their
>>>>>>> transactions also exposes the transaction validation engine to DoS
>>>>>>> attacks from
>>>>>>> malicious peers.
>>>>>>>
>>>>>>> As such, for unconfirmed transactions we are considering for our
>>>>>>> mempool, we
>>>>>>> apply a set of validation rules in addition to consensus, primarily
>>>>>>> to protect
>>>>>>> us from resource exhaustion and aid our efforts to keep the highest
>>>>>>> fee
>>>>>>> transactions. We call this mempool _policy_: a set of (configurable=
,
>>>>>>> node-specific) rules that transactions must abide by in order to be
>>>>>>> accepted
>>>>>>> into our mempool. Transaction "Standardness" rules and mempool
>>>>>>> restrictions such
>>>>>>> as "too-long-mempool-chain" are both examples of policy.
>>>>>>>
>>>>>>> ### Package Relay and Package Mempool Accept
>>>>>>>
>>>>>>> In transaction relay, we currently consider transactions one at a
>>>>>>> time for
>>>>>>> submission to the mempool. This creates a limitation in the node's
>>>>>>> ability to
>>>>>>> determine which transactions have the highest feerates, since we
>>>>>>> cannot take
>>>>>>> into account descendants (i.e. cannot use CPFP) until all the
>>>>>>> transactions are
>>>>>>> in the mempool. Similarly, we cannot use a transaction's descendant=
s
>>>>>>> when
>>>>>>> considering it for RBF. When an individual transaction does not mee=
t
>>>>>>> the mempool
>>>>>>> minimum feerate and the user isn't able to create a replacement
>>>>>>> transaction
>>>>>>> directly, it will not be accepted by mempools.
>>>>>>>
>>>>>>> This limitation presents a security issue for applications and user=
s
>>>>>>> relying on
>>>>>>> time-sensitive transactions. For example, Lightning and other
>>>>>>> protocols create
>>>>>>> UTXOs with multiple spending paths, where one counterparty's
>>>>>>> spending path opens
>>>>>>> up after a timelock, and users are protected from cheating scenario=
s
>>>>>>> as long as
>>>>>>> they redeem on-chain in time. A key security assumption is that all
>>>>>>> parties'
>>>>>>> transactions will propagate and confirm in a timely manner. This
>>>>>>> assumption can
>>>>>>> be broken if fee-bumping does not work as intended.
>>>>>>>
>>>>>>> The end goal for Package Relay is to consider multiple transactions
>>>>>>> at the same
>>>>>>> time, e.g. a transaction with its high-fee child. This may help us
>>>>>>> better
>>>>>>> determine whether transactions should be accepted to our mempool,
>>>>>>> especially if
>>>>>>> they don't meet fee requirements individually or are better RBF
>>>>>>> candidates as a
>>>>>>> package. A combination of changes to mempool validation logic,
>>>>>>> policy, and
>>>>>>> transaction relay allows us to better propagate the transactions
>>>>>>> with the
>>>>>>> highest package feerates to miners, and makes fee-bumping tools mor=
e
>>>>>>> powerful
>>>>>>> for users.
>>>>>>>
>>>>>>> The "relay" part of Package Relay suggests P2P messaging changes,
>>>>>>> but a large
>>>>>>> part of the changes are in the mempool's package validation logic.
>>>>>>> We call this
>>>>>>> *Package Mempool Accept*.
>>>>>>>
>>>>>>> ### Previous Work
>>>>>>>
>>>>>>> * Given that mempool validation is DoS-sensitive and complex, it
>>>>>>> would be
>>>>>>>   dangerous to haphazardly tack on package validation logic. Many
>>>>>>> efforts have
>>>>>>> been made to make mempool validation less opaque (see [#16400][4],
>>>>>>> [#21062][5],
>>>>>>> [#22675][6], [#22796][7]).
>>>>>>> * [#20833][8] Added basic capabilities for package validation, test
>>>>>>> accepts only
>>>>>>>   (no submission to mempool).
>>>>>>> * [#21800][9] Implemented package ancestor/descendant limit checks
>>>>>>> for arbitrary
>>>>>>>   packages. Still test accepts only.
>>>>>>> * Previous package relay proposals (see [#16401][10], [#19621][11])=
.
>>>>>>>
>>>>>>> ### Existing Package Rules
>>>>>>>
>>>>>>> These are in master as introduced in [#20833][8] and [#21800][9].
>>>>>>> I'll consider
>>>>>>> them as "given" in the rest of this document, though they can be
>>>>>>> changed, since
>>>>>>> package validation is test-accept only right now.
>>>>>>>
>>>>>>> 1. A package cannot exceed `MAX_PACKAGE_COUNT=3D25` count and
>>>>>>> `MAX_PACKAGE_SIZE=3D101KvB` total size [8]
>>>>>>>
>>>>>>>    *Rationale*: This is already enforced as mempool
>>>>>>> ancestor/descendant limits.
>>>>>>> Presumably, transactions in a package are all related, so exceeding
>>>>>>> this limit
>>>>>>> would mean that the package can either be split up or it wouldn't
>>>>>>> pass this
>>>>>>> mempool policy.
>>>>>>>
>>>>>>> 2. Packages must be topologically sorted: if any dependencies exist
>>>>>>> between
>>>>>>> transactions, parents must appear somewhere before children. [8]
>>>>>>>
>>>>>>> 3. A package cannot have conflicting transactions, i.e. none of the=
m
>>>>>>> can spend
>>>>>>> the same inputs. This also means there cannot be duplicate
>>>>>>> transactions. [8]
>>>>>>>
>>>>>>> 4. When packages are evaluated against ancestor/descendant limits i=
n
>>>>>>> a test
>>>>>>> accept, the union of all of their descendants and ancestors is
>>>>>>> considered. This
>>>>>>> is essentially a "worst case" heuristic where every transaction in
>>>>>>> the package
>>>>>>> is treated as each other's ancestor and descendant. [8]
>>>>>>> Packages for which ancestor/descendant limits are accurately
>>>>>>> captured by this
>>>>>>> heuristic: [19]
>>>>>>>
>>>>>>> There are also limitations such as the fact that CPFP carve out is
>>>>>>> not applied
>>>>>>> to package transactions. #20833 also disables RBF in package
>>>>>>> validation; this
>>>>>>> proposal overrides that to allow packages to use RBF.
>>>>>>>
>>>>>>> ## Proposed Changes
>>>>>>>
>>>>>>> The next step in the Package Mempool Accept project is to implement
>>>>>>> submission
>>>>>>> to mempool, initially through RPC only. This allows us to test the
>>>>>>> submission
>>>>>>> logic before exposing it on P2P.
>>>>>>>
>>>>>>> ### Summary
>>>>>>>
>>>>>>> - Packages may contain already-in-mempool transactions.
>>>>>>> - Packages are 2 generations, Multi-Parent-1-Child.
>>>>>>> - Fee-related checks use the package feerate. This means that
>>>>>>> wallets can
>>>>>>> create a package that utilizes CPFP.
>>>>>>> - Parents are allowed to RBF mempool transactions with a set of
>>>>>>> rules similar
>>>>>>>   to BIP125. This enables a combination of CPFP and RBF, where a
>>>>>>> transaction's descendant fees pay for replacing mempool conflicts.
>>>>>>>
>>>>>>> There is a draft implementation in [#22290][1]. It is WIP, but
>>>>>>> feedback is
>>>>>>> always welcome.
>>>>>>>
>>>>>>> ### Details
>>>>>>>
>>>>>>> #### Packages May Contain Already-in-Mempool Transactions
>>>>>>>
>>>>>>> A package may contain transactions that are already in the mempool.
>>>>>>> We remove
>>>>>>> ("deduplicate") those transactions from the package for the purpose=
s
>>>>>>> of package
>>>>>>> mempool acceptance. If a package is empty after deduplication, we d=
o
>>>>>>> nothing.
>>>>>>>
>>>>>>> *Rationale*: Mempools vary across the network. It's possible for a
>>>>>>> parent to be
>>>>>>> accepted to the mempool of a peer on its own due to differences in
>>>>>>> policy and
>>>>>>> fee market fluctuations. We should not reject or penalize the entir=
e
>>>>>>> package for
>>>>>>> an individual transaction as that could be a censorship vector.
>>>>>>>
>>>>>>> #### Packages Are Multi-Parent-1-Child
>>>>>>>
>>>>>>> Only packages of a specific topology are permitted. Namely, a
>>>>>>> package is exactly
>>>>>>> 1 child with all of its unconfirmed parents. After deduplication,
>>>>>>> the package
>>>>>>> may be exactly the same, empty, 1 child, 1 child with just some of
>>>>>>> its
>>>>>>> unconfirmed parents, etc. Note that it's possible for the parents t=
o
>>>>>>> be indirect
>>>>>>> descendants/ancestors of one another, or for parent and child to
>>>>>>> share a parent,
>>>>>>> so we cannot make any other topology assumptions.
>>>>>>>
>>>>>>> *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple
>>>>>>> parents
>>>>>>> makes it possible to fee-bump a batch of transactions. Restricting
>>>>>>> packages to a
>>>>>>> defined topology is also easier to reason about and simplifies the
>>>>>>> validation
>>>>>>> logic greatly. Multi-parent-1-child allows us to think of the
>>>>>>> package as one big
>>>>>>> transaction, where:
>>>>>>>
>>>>>>> - Inputs =3D all the inputs of parents + inputs of the child that c=
ome
>>>>>>> from
>>>>>>>   confirmed UTXOs
>>>>>>> - Outputs =3D all the outputs of the child + all outputs of the
>>>>>>> parents that
>>>>>>>   aren't spent by other transactions in the package
>>>>>>>
>>>>>>> Examples of packages that follow this rule (variations of example A
>>>>>>> show some
>>>>>>> possibilities after deduplication): ![image][15]
>>>>>>>
>>>>>>> #### Fee-Related Checks Use Package Feerate
>>>>>>>
>>>>>>> Package Feerate =3D the total modified fees divided by the total
>>>>>>> virtual size of
>>>>>>> all transactions in the package.
>>>>>>>
>>>>>>> To meet the two feerate requirements of a mempool, i.e., the
>>>>>>> pre-configured
>>>>>>> minimum relay feerate (`minRelayTxFee`) and dynamic mempool minimum
>>>>>>> feerate, the
>>>>>>> total package feerate is used instead of the individual feerate. Th=
e
>>>>>>> individual
>>>>>>> transactions are allowed to be below feerate requirements if the
>>>>>>> package meets
>>>>>>> the feerate requirements. For example, the parent(s) in the package
>>>>>>> can have 0
>>>>>>> fees but be paid for by the child.
>>>>>>>
>>>>>>> *Rationale*: This can be thought of as "CPFP within a package,"
>>>>>>> solving the
>>>>>>> issue of a parent not meeting minimum fees on its own. This allows =
L2
>>>>>>> applications to adjust their fees at broadcast time instead of
>>>>>>> overshooting or
>>>>>>> risking getting stuck/pinned.
>>>>>>>
>>>>>>> We use the package feerate of the package *after deduplication*.
>>>>>>>
>>>>>>> *Rationale*:  It would be incorrect to use the fees of transactions
>>>>>>> that are
>>>>>>> already in the mempool, as we do not want a transaction's fees to b=
e
>>>>>>> double-counted for both its individual RBF and package RBF.
>>>>>>>
>>>>>>> Examples F and G [14] show the same package, but P1 is submitted
>>>>>>> individually before
>>>>>>> the package in example G. In example F, we can see that the 300vB
>>>>>>> package pays
>>>>>>> an additional 200sat in fees, which is not enough to pay for its ow=
n
>>>>>>> bandwidth
>>>>>>> (BIP125#4). In example G, we can see that P1 pays enough to replace
>>>>>>> M1, but
>>>>>>> using P1's fees again during package submission would make it look
>>>>>>> like a 300sat
>>>>>>> increase for a 200vB package. Even including its fees and size woul=
d
>>>>>>> not be
>>>>>>> sufficient in this example, since the 300sat looks like enough for
>>>>>>> the 300vB
>>>>>>> package. The calculcation after deduplication is 100sat increase fo=
r
>>>>>>> a package
>>>>>>> of size 200vB, which correctly fails BIP125#4. Assume all
>>>>>>> transactions have a
>>>>>>> size of 100vB.
>>>>>>>
>>>>>>> #### Package RBF
>>>>>>>
>>>>>>> If a package meets feerate requirements as a package, the parents i=
n
>>>>>>> the
>>>>>>> transaction are allowed to replace-by-fee mempool transactions. The
>>>>>>> child cannot
>>>>>>> replace mempool transactions. Multiple transactions can replace the
>>>>>>> same
>>>>>>> transaction, but in order to be valid, none of the transactions can
>>>>>>> try to
>>>>>>> replace an ancestor of another transaction in the same package
>>>>>>> (which would thus
>>>>>>> make its inputs unavailable).
>>>>>>>
>>>>>>> *Rationale*: Even if we are using package feerate, a package will
>>>>>>> not propagate
>>>>>>> as intended if RBF still requires each individual transaction to
>>>>>>> meet the
>>>>>>> feerate requirements.
>>>>>>>
>>>>>>> We use a set of rules slightly modified from BIP125 as follows:
>>>>>>>
>>>>>>> ##### Signaling (Rule #1)
>>>>>>>
>>>>>>> All mempool transactions to be replaced must signal replaceability.
>>>>>>>
>>>>>>> *Rationale*: Package RBF signaling logic should be the same for
>>>>>>> package RBF and
>>>>>>> single transaction acceptance. This would be updated if single
>>>>>>> transaction
>>>>>>> validation moves to full RBF.
>>>>>>>
>>>>>>> ##### New Unconfirmed Inputs (Rule #2)
>>>>>>>
>>>>>>> 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. This is contrary to BIP125#2, which states "The
>>>>>>> replacement
>>>>>>> transaction may only include an unconfirmed input if that input was
>>>>>>> included in
>>>>>>> one of the original transactions. (An unconfirmed input spends an
>>>>>>> output from a
>>>>>>> currently-unconfirmed transaction.)"
>>>>>>>
>>>>>>> *Rationale*: The purpose of BIP125#2 is to ensure that the
>>>>>>> replacement
>>>>>>> transaction has a higher ancestor score than the original
>>>>>>> transaction(s) (see
>>>>>>> [comment][13]). Example H [16] shows how adding a new unconfirmed
>>>>>>> input can lower the
>>>>>>> ancestor score of the replacement transaction. P1 is trying to
>>>>>>> replace M1, and
>>>>>>> spends an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat,
>>>>>>> and M2 pays
>>>>>>> 100sat. Assume all transactions have a size of 100vB. While, in
>>>>>>> isolation, P1
>>>>>>> looks like a better mining candidate than M1, it must be mined with
>>>>>>> M2, so its
>>>>>>> ancestor feerate is actually 4.5sat/vB.  This is lower than M1's
>>>>>>> ancestor
>>>>>>> feerate, which is 6sat/vB.
>>>>>>>
>>>>>>> In package RBF, the rule analogous to BIP125#2 would be "none of th=
e
>>>>>>> transactions in the package can spend new unconfirmed inputs."
>>>>>>> Example J [17] shows
>>>>>>> why, if any of the package transactions have ancestors, package
>>>>>>> feerate is no
>>>>>>> longer accurate. Even though M2 and M3 are not ancestors of P1
>>>>>>> (which is the
>>>>>>> replacement transaction in an RBF), we're actually interested in th=
e
>>>>>>> entire
>>>>>>> package. A miner should mine M1 which is 5sat/vB instead of M2, M3,
>>>>>>> P1, P2, and
>>>>>>> P3, which is only 4sat/vB. The Package RBF rule cannot be loosened
>>>>>>> to only allow
>>>>>>> the child to have new unconfirmed inputs, either, because it can
>>>>>>> still cause us
>>>>>>> to overestimate the package's ancestor score.
>>>>>>>
>>>>>>> However, enforcing a rule analogous to BIP125#2 would not only make
>>>>>>> Package RBF
>>>>>>> less useful, but would also break Package RBF for packages with
>>>>>>> parents already
>>>>>>> in the mempool: if a package parent has already been submitted, it
>>>>>>> would look
>>>>>>> like the child is spending a "new" unconfirmed input. In example K
>>>>>>> [18], we're
>>>>>>> looking to replace M1 with the entire package including P1, P2, and
>>>>>>> P3. We must
>>>>>>> consider the case where one of the parents is already in the mempoo=
l
>>>>>>> (in this
>>>>>>> case, P2), which means we must allow P3 to have new unconfirmed
>>>>>>> inputs. However,
>>>>>>> M2 lowers the ancestor score of P3 to 4.3sat/vB, so we should not
>>>>>>> replace M1
>>>>>>> with this package.
>>>>>>>
>>>>>>> Thus, the package RBF rule regarding new unconfirmed inputs is less
>>>>>>> strict than
>>>>>>> BIP125#2. However, we still achieve the same goal of requiring the
>>>>>>> replacement
>>>>>>> transactions to have a ancestor score at least as high as the
>>>>>>> original ones. As
>>>>>>> a result, the entire package is required to be a higher feerate
>>>>>>> mining candidate
>>>>>>> than each of the replaced transactions.
>>>>>>>
>>>>>>> Another note: the [comment][13] above the BIP125#2 code in the
>>>>>>> original RBF
>>>>>>> implementation suggests that the rule was intended to be temporary.
>>>>>>>
>>>>>>> ##### Absolute Fee (Rule #3)
>>>>>>>
>>>>>>> The package must increase the absolute fee of the mempool, i.e. the
>>>>>>> total fees
>>>>>>> of the package must be higher than the absolute fees of the mempool
>>>>>>> transactions
>>>>>>> it replaces. Combined with the CPFP rule above, this differs from
>>>>>>> BIP125 Rule #3
>>>>>>> - an individual transaction in the package may have lower fees than
>>>>>>> the
>>>>>>>   transaction(s) it is replacing. In fact, it may have 0 fees, and
>>>>>>> the child
>>>>>>> pays for RBF.
>>>>>>>
>>>>>>> ##### Feerate (Rule #4)
>>>>>>>
>>>>>>> The package must pay for its own bandwidth; the package feerate mus=
t
>>>>>>> be higher
>>>>>>> than the replaced transactions by at least minimum relay feerate
>>>>>>> (`incrementalRelayFee`). Combined with the CPFP rule above, this
>>>>>>> differs from
>>>>>>> BIP125 Rule #4 - an individual transaction in the package can have =
a
>>>>>>> lower
>>>>>>> feerate than the transaction(s) it is replacing. In fact, it may
>>>>>>> have 0 fees,
>>>>>>> and the child pays for RBF.
>>>>>>>
>>>>>>> ##### Total Number of Replaced Transactions (Rule #5)
>>>>>>>
>>>>>>> The package cannot replace more than 100 mempool transactions. This
>>>>>>> is identical
>>>>>>> to BIP125 Rule #5.
>>>>>>>
>>>>>>> ### Expected FAQs
>>>>>>>
>>>>>>> 1. Is it possible for only some of the package to make it into the
>>>>>>> mempool?
>>>>>>>
>>>>>>>    Yes, it is. However, since we evict transactions from the mempoo=
l
>>>>>>> by
>>>>>>> descendant score and the package child is supposed to be sponsoring
>>>>>>> the fees of
>>>>>>> its parents, the most common scenario would be all-or-nothing. This
>>>>>>> is
>>>>>>> incentive-compatible. In fact, to be conservative, package
>>>>>>> validation should
>>>>>>> begin by trying to submit all of the transactions individually, and
>>>>>>> only use the
>>>>>>> package mempool acceptance logic if the parents fail due to low
>>>>>>> feerate.
>>>>>>>
>>>>>>> 2. Should we allow packages to contain already-confirmed
>>>>>>> transactions?
>>>>>>>
>>>>>>>     No, for practical reasons. In mempool validation, we actually
>>>>>>> aren't able to
>>>>>>> tell with 100% confidence if we are looking at a transaction that
>>>>>>> has already
>>>>>>> confirmed, because we look up inputs using a UTXO set. If we have
>>>>>>> historical
>>>>>>> block data, it's possible to look for it, but this is inefficient,
>>>>>>> not always
>>>>>>> possible for pruning nodes, and unnecessary because we're not going
>>>>>>> to do
>>>>>>> anything with the transaction anyway. As such, we already have the
>>>>>>> expectation
>>>>>>> that transaction relay is somewhat "stateful" i.e. nobody should be
>>>>>>> relaying
>>>>>>> transactions that have already been confirmed. Similarly, we
>>>>>>> shouldn't be
>>>>>>> relaying packages that contain already-confirmed transactions.
>>>>>>>
>>>>>>> [1]: https://github.com/bitcoin/bitcoin/pull/22290
>>>>>>> [2]:
>>>>>>> https://github.com/bitcoin/bips/blob/1f0b563738199ca60d32b4ba779797=
fc97d040fe/bip-0141.mediawiki#transaction-size-calculations
>>>>>>> [3]:
>>>>>>> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f4=
0746f392eb75e/src/policy/policy.cpp#L282
>>>>>>> [4]: https://github.com/bitcoin/bitcoin/pull/16400
>>>>>>> [5]: https://github.com/bitcoin/bitcoin/pull/21062
>>>>>>> [6]: https://github.com/bitcoin/bitcoin/pull/22675
>>>>>>> [7]: https://github.com/bitcoin/bitcoin/pull/22796
>>>>>>> [8]: https://github.com/bitcoin/bitcoin/pull/20833
>>>>>>> [9]: https://github.com/bitcoin/bitcoin/pull/21800
>>>>>>> [10]: https://github.com/bitcoin/bitcoin/pull/16401
>>>>>>> [11]: https://github.com/bitcoin/bitcoin/pull/19621
>>>>>>> [12]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawik=
i
>>>>>>> [13]:
>>>>>>> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c61=
4ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104
>>>>>>> [14]:
>>>>>>> https://user-images.githubusercontent.com/25183001/133567078-075a97=
1c-0619-4339-9168-b41fd2b90c28.png
>>>>>>> [15]:
>>>>>>> https://user-images.githubusercontent.com/25183001/132856734-fc17da=
75-f875-44bb-b954-cb7a1725cc0d.png
>>>>>>> [16]:
>>>>>>> https://user-images.githubusercontent.com/25183001/133567347-a3e2e4=
a8-ae9c-49f8-abb9-81e8e0aba224.png
>>>>>>> [17]:
>>>>>>> https://user-images.githubusercontent.com/25183001/133567370-21566d=
0e-36c8-4831-b1a8-706634540af3.png
>>>>>>> [18]:
>>>>>>> https://user-images.githubusercontent.com/25183001/133567444-bfff11=
42-439f-4547-800a-2ba2b0242bcb.png
>>>>>>> [19]:
>>>>>>> https://user-images.githubusercontent.com/25183001/133456219-0bb447=
cb-dcb4-4a31-b9c1-7d86205b68bc.png
>>>>>>> [20]:
>>>>>>> https://user-images.githubusercontent.com/25183001/132857787-7b7c6f=
56-af96-44c8-8d78-983719888c19.png
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--0000000000002dd02d05cd162aa1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Bastien<br><div><br>&gt; In the case of LN, an attacker=
 can game this and heavily restrict<div>your RBF attempts if you&#39;re onl=
y allowed to use confirmed inputs</div><div>and have many channels (and a l=
imited number of confirmed inputs).</div><div>Otherwise you&#39;ll need nod=
e operators to pre-emptively split their</div><div>utxos into many small ut=
xos just for fee bumping, which is inefficient...<br><br></div><div>I share=
 the concern about splitting utxos into smaller ones.<br>IIRC, the carve-ou=
t tolerance is only 2txn/10_000 vb. If one of your counterparties attach a =
junk branch on her own anchor output, are you allowed to chain your self-ow=
ned unconfirmed CPFP ?<br>I&#39;m thinking about the topology &quot;Chained=
 CPFPs&quot; exposed here : <a href=3D"https://github.com/rust-bitcoin/rust=
-lightning/issues/989">https://github.com/rust-bitcoin/rust-lightning/issue=
s/989</a>.<br></div><div>Or if you have another L2 broadcast topology which=
 could be safe w.r.t our current mempool logic :) ?<br> </div><div><br></di=
v></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">Le=C2=A0lun. 27 sept. 2021 =C3=A0=C2=A003:15, Bastien TEINTURIER &l=
t;<a href=3D"mailto:bastien@acinq.fr">bastien@acinq.fr</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think we could=
 restrain package acceptance to only confirmed inputs for now and revisit l=
ater this point ? For LN-anchor, you can assume that the fee-bumping UTXO f=
eeding the CPFP is already<br>confirmed. Or are there currently-deployed us=
e-cases which would benefit from your proposed Rule #2 ?<br></blockquote><d=
iv><br></div><div>I think constraining package acceptance to only confirmed=
 inputs</div><div>is very limiting and quite dangerous for L2 protocols.</d=
iv><div><br></div><div>In the case of LN, an attacker can game this and hea=
vily restrict</div><div>your RBF attempts if you&#39;re only allowed to use=
 confirmed inputs</div><div>and have many channels (and a limited number of=
 confirmed inputs).</div><div>Otherwise you&#39;ll need node operators to p=
re-emptively split their</div><div>utxos into many small utxos just for fee=
 bumping, which is inefficient...</div><div><br></div><div>Bastien</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0lun. 27 sept. 2021 =C3=A0=C2=A000:27, Antoine Riard via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Gl=
oria,<br><br>Thanks for your answers,<br><br>&gt; In summary, it seems that=
 the decisions that might still need<br>&gt; attention/input from devs on t=
his mailing list are:<br>&gt; 1. Whether we should start with multiple-pare=
nt-1-child or 1-parent-1-child.<br>&gt; 2. Whether it&#39;s ok to require t=
hat the child not have conflicts with<br>&gt; mempool transactions.<br><br>=
Yes 1) it would be good to have inputs of more potential users of package a=
cceptance . And 2) I think it&#39;s more a matter of clearer wording of the=
 proposal.<br><br>However, see my final point on the relaxation around &quo=
t;unconfirmed inputs&quot; which might in fact alter our current block cons=
truction strategy.<br><br>&gt; Right, the fact that we essentially always c=
hoose the first-seen witness is<br>&gt; an unfortunate limitation that exis=
ts already. Adding package mempool<br>&gt; accept doesn&#39;t worsen this, =
but the procedure in the future is to replace<br>&gt; the witness when it m=
akes sense economically. We can also add logic to<br>&gt; allow package fee=
rate to pay for witness replacements as well. This is<br>&gt; pretty far in=
to the future, though.<br><br>Yes I agree package mempool doesn&#39;t worse=
n this. And it&#39;s not an issue for current LN as you can&#39;t significa=
ntly inflate a spending witness for the 2-of-2 funding output.<br>However, =
it might be an issue for multi-party protocol where the spending script has=
 alternative branches with asymmetric valid witness weights. Taproot should=
 ease that kind of script so hopefully we would deploy wtxid-replacement no=
t too far in the future.<br><br>&gt; I could be misunderstanding, but an at=
tacker wouldn&#39;t be able to<br>&gt; batch-attack like this. Alice&#39;s =
package only conflicts with A&#39; + D&#39;, not A&#39;<br>&gt; + B&#39; + =
C&#39; + D&#39;. She only needs to pay for evicting 2 transactions.<br><br>=
Yeah I can be clearer, I think you have 2 pinning attacks scenarios to cons=
ider.<br><br>In LN, if you&#39;re trying to confirm a commitment transactio=
n to time-out or claim on-chain a HTLC and the timelock is near-expiration,=
 you should be ready to pay in commitment+2nd-stage HTLC transaction fees a=
s much as the value offered by the HTLC.<br><br>Following this security ass=
umption, an attacker can exploit it by targeting together commitment transa=
ctions from different channels by blocking them under a high-fee child, of =
which the fee value<br>is equal to the top-value HTLC + 1. Victims&#39;s fe=
e-bumping logics won&#39;t overbid as it&#39;s not worthy to offer fees bey=
ond their competed HTLCs. Apart from observing mempools state, victims can&=
#39;t learn they&#39;re targeted by the same attacker.<br><br>To draw from =
the aforementioned topology, Mallory broadcasts A&#39; + B&#39; + C&#39; + =
D&#39;, where A&#39; conflicts with Alice&#39;s P1, B&#39; conflicts with B=
ob&#39;s P2, C&#39; conflicts with Caroll&#39;s P3. Let&#39;s assume P1 is =
confirming the top-value HTLC of the set. If D&#39; fees is higher than P1 =
+ 1, it won&#39;t be rational for Alice or Bob or Caroll to keep offering c=
ompeting feerates. Mallory will be at loss on stealing P1, as she has paid =
more in fees but will realize a gain on P2+P3.<br><br>In this model, Alice =
is allowed to evict those 2 transactions (A&#39; + D&#39;) but as she is ec=
onomically-bounded she won&#39;t succeed.<br><br>Mallory is maliciously exp=
loiting RBF rule 3 on absolute fee. I think this 1st pinning scenario is co=
rrect and &quot;lucractive&quot; when you sum the global gain/loss.<br><br>=
There is a 2nd attack scenario where A + B + C + D, where D is the child of=
 A,B,C. All those transactions are honestly issued by Alice. Once A + B + C=
 + D are propagated in network mempools, Mallory is able to replace A + D w=
ith =C2=A0A&#39; + D&#39; where D&#39; is paying a higher fee. This package=
 A&#39; + D&#39; will confirm soon if D feerate was compelling but Mallory =
succeeds in delaying the confirmation<br>of B + C for one or more blocks. A=
s B + C are pre-signed commitments with a low-fee rate they won&#39;t confi=
rm without Alice issuing a new child E. Mallory can repeat the same trick b=
y broadcasting<br>B&#39; + E&#39; and delay again the confirmation of C.<br=
><br>If the remaining package pending HTLC has a higher-value than all the =
malicious fees over-bid, Mallory should realize a gain. With this 2nd pinni=
ng attack, the malicious entity buys confirmation delay of your packaged-to=
gether commitments.<br><br>Assuming those attacks are correct, I&#39;m lean=
ing towards being conservative with the LDK broadcast backend. Though once =
again, other L2 devs have likely other use-cases and opinions :)<br><br>&gt=
; =C2=A0B&#39; only needs to pay for itself in this case.<br><br>Yes I thin=
k it&#39;s a nice discount when UTXO is single-owned. In the context of sha=
red-owned UTXO (e.g LN), you might not if there is an in-mempool package al=
ready spending the UTXO and have to assume the worst-case scenario. I.e hav=
e B&#39; committing enough fee to pay for A&#39; replacement bandwidth. I t=
hink we can&#39;t do that much for this case...<br><br>&gt; If a package me=
ets feerate requirements as a<br>package, the parents in the transaction ar=
e allowed to replace-by-fee<br>mempool transactions. The child cannot repla=
ce mempool transactions.&quot;<br><br>I agree with the Mallory-vs-Alice cas=
e. Though if Alice broadcasts A+B&#39; to replace A+B because the first bro=
adcast isn&#39;t satisfying anymore due to mempool spikes ? Assuming B&#39;=
 fees is enough, I think that case as child B&#39; replacing in-mempool tra=
nsaction B. Which I understand going against=C2=A0 &quot;The child cannot r=
eplace mempool transactions&quot;.<br><br>Maybe wording could be a bit clea=
rer ?<br><br>&gt; While it would be nice to have full RBF, malleability of =
the child won&#39;t<br>&gt; block RBF here. If we&#39;re trying to replace =
A&#39;, we only require that A&#39;<br>&gt; signals replaceability, and don=
&#39;t mind if its child doesn&#39;t.<br><br>Yes, it sounds good.<br><br>&g=
t; Yes, A+C+D pays 2500sat more in fees, but it is also 1000vB larger. A mi=
ner<br>&gt; should prefer to utilize their block space more effectively.<br=
><br>If your mempool is empty and only composed of A+C+D or A+B, I think ta=
king A+C+D is the most efficient block construction you can come up with as=
 a miner ?<br><br>&gt; No, because we don&#39;t use that model.<br><br>Can =
you describe what miner model we are using ? Like the block construction st=
rategy implemented by `addPackagesTxs` or also encompassing our current mem=
pool acceptance policy, which I think rely on absolute fee over ancestor sc=
ore in case of replacement ?<br><br>I think this point is worthy to discuss=
 as otherwise we might downgrade the efficiency of our current block constr=
uction strategy in periods of near-empty mempools. A knowledge which could =
be discreetly leveraged by a miner to gain an advantage on the rest of the =
mining ecosystem.<br><br>Note, I think we *might* have to go in this direct=
ion if we want to replace replace-by-fee by replace-by-feerate or replace-b=
y-ancestor and solve in-depth pinning attacks. Though if we do so, <br>IMO =
we would need more thoughts.<br><br>I think we could restrain package accep=
tance to only confirmed inputs for now and revisit later this point ? For L=
N-anchor, you can assume that the fee-bumping UTXO feeding the CPFP is alre=
ady<br>confirmed. Or are there currently-deployed use-cases which would ben=
efit from your proposed Rule #2 ?<br><br>Antoine<br></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 23 sept. 2=
021 =C3=A0=C2=A011:36, Gloria Zhao &lt;<a href=3D"mailto:gloriajzhao@gmail.=
com" target=3D"_blank">gloriajzhao@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">H=
i Antoine,<br><br><div>Thanks as always for your input. I&#39;m glad we agr=
ee on so much!</div><div><br></div><div>In summary, it seems that the decis=
ions that might still need attention/input from devs on this mailing list a=
re:</div>1. Whether we should start with multiple-parent-1-child or 1-paren=
t-1-child.<br>2. Whether it&#39;s ok to require that the child not have con=
flicts with mempool transactions.<br><br><div>Responding to your comments..=
.</div><div><br></div>&gt; IIUC, you have package A+B, during the dedup pha=
se early in `AcceptMultipleTransactions` if you observe same-txid-different=
-wtixd A&#39; and A&#39; is higher feerate than A, you trim A and replace b=
y A&#39; ?<br><br>&gt; I think this approach is safe, the one who appears u=
nsafe to me is when A&#39; has a _lower_ feerate, even if A&#39; is already=
 accepted by our mempool ? In that case iirc that would be a pinning.<br><b=
r>Right, the fact that we essentially always choose the first-seen witness =
is an unfortunate limitation that exists already. Adding package mempool ac=
cept doesn&#39;t worsen this, but the procedure in the future is to replace=
 the witness when it makes sense economically. We can also add logic to all=
ow package feerate to pay for witness replacements as well. This is pretty =
far into the future, though.<br><br>&gt; It sounds uneconomical for an atta=
cker but I think it&#39;s not when you consider than you can &quot;batch&qu=
ot; attack against multiple honest counterparties. E.g, Mallory broadcast A=
&#39; + B&#39; + C&#39; + D&#39; where A&#39; conflicts with Alice&#39;s ho=
nest package P1, B&#39; conflicts with Bob&#39;s honest package P2, C&#39; =
conflicts with Caroll&#39;s honest package P3. And D&#39; is a high-fee chi=
ld of A&#39; + B&#39; + C&#39;.<br><br>&gt; If D&#39; is higher-fee than P1=
 or P2 or P3 but inferior to the sum of HTLCs confirmed by P1+P2+P3, I thin=
k it&#39;s lucrative for the attacker ?<br><br>I could be misunderstanding,=
 but an attacker wouldn&#39;t be able to batch-attack like this. Alice&#39;=
s package only conflicts with A&#39; + D&#39;, not A&#39; + B&#39; + C&#39;=
 + D&#39;. She only needs to pay for evicting 2 transactions.<br><br>&gt; D=
o we assume that broadcasted packages are &quot;honest&quot; by default and=
 that the parent(s) always need the child to pass the fee checks, that way =
saving the processing of individual transactions which are expected to fail=
 in 99% of cases or more ad hoc composition of packages at relay ?<br>&gt; =
I think this point is quite dependent on the p2p packages format/logic we&#=
39;ll end up on and that we should feel free to revisit it later ?<br><br>I=
 think it&#39;s the opposite; there&#39;s no way for us to assume that p2p =
packages will be &quot;honest.&quot; I&#39;d like to have two things before=
 we expose on P2P: (1) ensure that the amount of resources potentially allo=
cated for package validation isn&#39;t disproportionately higher than that =
of single transaction validation and (2) only use package validation when w=
e&#39;re unsatisifed with the single validation result, e.g. we might get b=
etter fees.<br>Yes, let&#39;s revisit this later :)<br>=C2=A0<br>=C2=A0&gt;=
 Yes, if you receive A+B, and A is already in-mempoo, I agree you can disca=
rd its feerate as B should pay for all fees checked on its own. Where I&#39=
;m unclear is when you have in-mempool A+B and receive A+B&#39;. Should B&#=
39; have a fee high enough to cover the bandwidth penalty replacement (`Pay=
sForRBF`, 2nd check) of both A+B&#39; or only B&#39; ?<br>=C2=A0<br>=C2=A0B=
&#39; only needs to pay for itself in this case.<br>=C2=A0<br>&gt; &gt; Do =
we want the child to be able to replace mempool transactions as well?<br><b=
r>&gt; If we mean when you have replaceable A+B then A&#39;+B&#39; try to r=
eplace with a higher-feerate ? I think that&#39;s exactly the case we need =
for Lightning as A+B is coming from Alice and A&#39;+B&#39; is coming from =
Bob :/<br><br><div>Let me clarify this because I can see that my wording wa=
s ambiguous, and then please let me know if it fits Lightning&#39;s needs?<=
/div><div><br></div>In my proposal, I wrote &quot;If a package meets feerat=
e requirements as a package, the parents in the transaction are allowed to =
replace-by-fee mempool transactions. The child cannot replace mempool trans=
actions.&quot; What I meant was: the package can replace mempool transactio=
ns if any of the parents conflict with mempool transactions. The child cann=
ot not conflict with any mempool transactions.<br>The Lightning use case th=
is attempts to address is: Alice and Mallory are LN counterparties, and hav=
e packages A+B and A&#39;+B&#39;, respectively. A and A&#39; are their comm=
itment transactions and conflict with each other; they have shared inputs a=
nd different txids.<br>B spends Alice&#39;s anchor output from A. B&#39; sp=
ends Mallory&#39;s anchor output from A&#39;. Thus, B and B&#39; do not con=
flict with each other.<br>Alice can broadcast her package, A+B, to replace =
Mallory&#39;s package, A&#39;+B&#39;, since B doesn&#39;t conflict with the=
 mempool.<br><br>Would this be ok?<br><br>&gt; The second option, a child o=
f A&#39;, In the LN case I think the CPFP is attached on one&#39;s anchor o=
utput.<br><br>While it would be nice to have full RBF, malleability of the =
child won&#39;t block RBF here. If we&#39;re trying to replace A&#39;, we o=
nly require that A&#39; signals replaceability, and don&#39;t mind if its c=
hild doesn&#39;t.<br><br>&gt; &gt; B has an ancestor score of 10sat/vb and =
D has an<br>&gt; &gt; ancestor score of ~2.9sat/vb. Since D&#39;s ancestor =
score is lower than B&#39;s,<br>&gt; &gt; it fails the proposed package RBF=
 Rule #2, so this package would be<br>&gt; &gt; rejected. Does this meet yo=
ur expectations?<br><br>&gt; Well what sounds odd to me, in my example, we =
fail D even if it has a higher-fee than B. Like A+B absolute fees are 2000 =
sats and A+C+D absolute fees are 4500 sats ?<br><br>Yes, A+C+D pays 2500sat=
 more in fees, but it is also 1000vB larger. A miner should prefer to utili=
ze their block space more effectively.<br><br>&gt; Is this compatible with =
a model where a miner prioritizes absolute fees over ancestor score, in the=
 case that mempools aren&#39;t full-enough to fulfill a block ?<br><br>No, =
because we don&#39;t use that model.<br><br>Thanks,<br>Gloria</div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 23=
, 2021 at 5:29 AM Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.c=
om" target=3D"_blank">antoine.riard@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; Correct,=
 if B+C is too low feerate to be accepted, we will reject it. I<br>&gt; pre=
fer this because it is incentive compatible: A can be mined by itself,<br>&=
gt; so there&#39;s no reason to prefer A+B+C instead of A.<br>&gt; As anoth=
er way of looking at this, consider the case where we do accept<br>&gt; A+B=
+C and it sits at the &quot;bottom&quot; of our mempool. If our mempool rea=
ches<br>&gt; capacity, we evict the lowest descendant feerate transactions,=
 which are<br>&gt; B+C in this case. This gives us the same resulting mempo=
ol, with A and not<br>&gt; B+C.<br><br>I agree here. Doing otherwise, we mi=
ght evict other transactions mempool in `MempoolAccept::Finalize` with a hi=
gher-feerate than B+C while those evicted transactions are the most compell=
ing for block construction.<br><br>I thought at first missing this acceptan=
ce requirement would break a fee-bumping scheme like Parent-Pay-For-Child w=
here a high-fee parent is attached to a child signed with SIGHASH_ANYONECAN=
PAY but in this case the child fee is capturing the parent value. I can&#39=
;t think of other fee-bumping schemes potentially affected. If they do exis=
t I would say they&#39;re wrong in their design assumptions.<br><br>&gt; If=
 or when we have witness replacement, the logic is: if the individual<br>&g=
t; transaction is enough to replace the mempool one, the replacement will<b=
r>&gt; happen during the preceding individual transaction acceptance, and<b=
r>&gt; deduplication logic will work. Otherwise, we will try to deduplicate=
 by<br>&gt; wtxid, see that we need a package witness replacement, and use =
the package<br>&gt; feerate to evaluate whether this is economically ration=
al.<br><br>IIUC, you have package A+B, during the dedup phase early in `Acc=
eptMultipleTransactions` if you observe same-txid-different-wtixd A&#39; an=
d A&#39; is higher feerate than A, you trim A and replace by A&#39; ?<br><b=
r>I think this approach is safe, the one who appears unsafe to me is when A=
&#39; has a _lower_ feerate, even if A&#39; is already accepted by our memp=
ool ? In that case iirc that would be a pinning.<br><br>Good to see progres=
s on witness replacement before we see usage of Taproot tree in the context=
 of multi-party, where a malicious counterparty inflates its witness to jam=
 a honest spending.<br><br>(Note, the commit linked currently points nowher=
e :))<br><br><br>&gt; Please note that A may replace A&#39; even if A&#39; =
has higher fees than A<br>&gt; individually, because the proposed package R=
BF utilizes the fees and size<br>&gt; of the entire package. This just requ=
ires E to pay enough fees, although<br>&gt; this can be pretty high if ther=
e are also potential B&#39; and C&#39; competing<br>&gt; commitment transac=
tions that we don&#39;t know about.<br><br>Ah right, if the package accepta=
nce waives `PaysMoreThanConflicts` for the individual check on A, the hones=
t package should replace the pinning attempt. I&#39;ve not fully parsed the=
 proposed implementation yet.<br><br>Though note, I think it&#39;s still un=
safe for a Lightning multi-commitment-broadcast-as-one-package as a malicio=
us A&#39; might have an absolute fee higher than E. It sounds uneconomical =
for<br>an attacker but I think it&#39;s not when you consider than you can =
&quot;batch&quot; attack against multiple honest counterparties. E.g, Mallo=
ry broadcast A&#39; + B&#39; + C&#39; + D&#39; where A&#39; conflicts with =
Alice&#39;s honest package P1, B&#39; conflicts with Bob&#39;s honest packa=
ge P2, C&#39; conflicts with Caroll&#39;s honest package P3. And D&#39; is =
a high-fee child of A&#39; + B&#39; + C&#39;.<br><br>If D&#39; is higher-fe=
e than P1 or P2 or P3 but inferior to the sum of HTLCs confirmed by P1+P2+P=
3, I think it&#39;s lucrative for the attacker ?<br><br>&gt; So far, my und=
erstanding is that multi-parent-1-child is desired for<br>&gt; batched fee-=
bumping (<br>&gt; <a href=3D"https://github.com/bitcoin/bitcoin/pull/22674#=
issuecomment-897951289" target=3D"_blank">https://github.com/bitcoin/bitcoi=
n/pull/22674#issuecomment-897951289</a>) and<br>&gt; I&#39;ve also seen you=
r response which I have less context on (<br>&gt; <a href=3D"https://github=
.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202" target=3D"_blank">h=
ttps://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202</a>). T=
hat<br>&gt; being said, I am happy to create a new proposal for 1 parent + =
1 child<br>&gt; (which would be slightly simpler) and plan for moving to<br=
>&gt; multi-parent-1-child later if that is preferred. I am very interested=
 in<br>&gt; hearing feedback on that approach.<br><br>I think batched fee-b=
umping is okay as long as you don&#39;t have time-sensitive outputs encumbe=
ring your commitment transactions. For the reasons mentioned above, I think=
 that&#39;s unsafe.<br><br>What I&#39;m worried about is=C2=A0 L2 developer=
s, potentially not aware about all the mempool subtleties blurring the diff=
erence and always batching their broadcast by default.<br><br>IMO, a good t=
hing by restraining to 1-parent + 1 child, =C2=A0we artificially constraint=
 L2 design space for now and minimize risks of unsafe usage of the package =
API :)<br><br>I think that&#39;s a point where it would be relevant to have=
 the opinion of more L2 devs.<br><br>&gt; I think there is a misunderstandi=
ng here - let me describe what I&#39;m<br>&gt; proposing we&#39;d do in thi=
s situation: we&#39;ll try individual submission for A,<br>&gt; see that it=
 fails due to &quot;insufficient fees.&quot; Then, we&#39;ll try package<br=
>&gt; validation for A+B and use package RBF. If A+B pays enough, it can st=
ill<br>&gt; replace A&#39;. If A fails for a bad signature, we won&#39;t lo=
ok at B or A+B. Does<br>&gt; this meet your expectations?<br><br>Yes there =
was a misunderstanding, I think this approach is correct, it&#39;s more a q=
uestion of performance. Do we assume that broadcasted packages are &quot;ho=
nest&quot; by default and that the parent(s) always need the child to pass =
the fee checks, that way saving the processing of individual transactions w=
hich are expected to fail in 99% of cases or more ad hoc composition of pac=
kages at relay ?<br><br>I think this point is quite dependent on the p2p pa=
ckages format/logic we&#39;ll end up on and that we should feel free to rev=
isit it later ?<br><br><br>&gt; What problem are you trying to solve by the=
 package feerate *after* dedup<br>rule ?<br>&gt; My understanding is that a=
n in-package transaction might be already in<br>the mempool. Therefore, to =
compute a correct RBF penalty replacement, the<br>vsize of this transaction=
 could be discarded lowering the cost of package<br>RBF.<br><br>&gt; I&#39;=
m proposing that, when a transaction has already been submitted to<br>&gt; =
mempool, we would ignore both its fees and vsize when calculating package<b=
r>&gt; feerate. <br><br>Yes, if you receive A+B, and A is already in-mempoo=
, I agree you can discard its feerate as B should pay for all fees checked =
on its own. Where I&#39;m unclear is when you have in-mempool A+B and recei=
ve A+B&#39;. Should B&#39; have a fee high enough to cover the bandwidth pe=
nalty replacement (`PaysForRBF`, 2nd check) of both A+B&#39; or only B&#39;=
 ?<br><br>If you have a second-layer like current Lightning, you might have=
 a counterparty commitment to replace and should always expect to have to p=
ay for parent replacement bandwidth.<br><br>Where a potential discount soun=
ds interesting is when you have an univoque state on the first-stage of tra=
nsactions. E.g DLC&#39;s funding transaction which might be CPFP by any par=
ticipant iirc.<br><br>&gt; Note that, if C&#39; conflicts with C, it also c=
onflicts with D, since D is a<br>&gt; descendant of C and would thus need t=
o be evicted along with it.<br><br>Ah once again I think it&#39;s a misunde=
rstanding without the code under my eyes! If we do C&#39; `PreChecks`, solv=
e the conflicts provoked by it, i.e mark for potential eviction D and don&#=
39;t consider it for future conflicts in the rest of the package, I think D=
&#39; `PreChecks` should be good ?<br><br>&gt; More generally, this example=
 is surprising to me because I didn&#39;t think<br>&gt; packages would be u=
sed to fee-bump replaceable transactions. Do we want the<br>&gt; child to b=
e able to replace mempool transactions as well?<br><br>If we mean when you =
have replaceable A+B then A&#39;+B&#39; try to replace with a higher-feerat=
e ? I think that&#39;s exactly the case we need for Lightning as A+B is com=
ing from Alice and A&#39;+B&#39; is coming from Bob :/<br><br>&gt; I&#39;m =
not sure what you mean? Let&#39;s say we have a package of parent A + child=
<br>&gt; B, where A is supposed to replace a mempool transaction A&#39;. Ar=
e you saying<br>&gt; that counterparties are able to malleate the package c=
hild B, or a child of<br>&gt; A&#39;? <br><br>The second option, a child of=
 A&#39;, In the LN case I think the CPFP is attached on one&#39;s anchor ou=
tput.<br><br>I think it&#39;s good if we assume the solve-conflicts-after-p=
arent&#39;s`&#39;PreChecks` mentioned above or fixing inherited signaling o=
r full-rbf ?<br><br>&gt; Sorry, I don&#39;t understand what you mean by &qu=
ot;preserve the package<br>&gt; integrity?&quot; Could you elaborate?<br><b=
r>After thinking the relaxation about the &quot;new&quot; unconfirmed input=
 is not linked to trimming but I would say more to the multi-parent support=
.<br><br>Let&#39;s say you have A+B trying to replace C+D where B is also s=
pending already in-mempool E. To succeed, you need to waive the no-new-unco=
nfirmed input as D isn&#39;t spending E.<br><br>So good, I think we agree o=
n the problem description here.<br><br>&gt; I am in agreement with your cal=
culations but unsure if we disagree on the<br>&gt; expected outcome. Yes, B=
 has an ancestor score of 10sat/vb and D has an<br>&gt; ancestor score of ~=
2.9sat/vb. Since D&#39;s ancestor score is lower than B&#39;s,<br>&gt; it f=
ails the proposed package RBF Rule #2, so this package would be<br>&gt; rej=
ected. Does this meet your expectations?<br><br>Well what sounds odd to me,=
 in my example, we fail D even if it has a higher-fee than B. Like A+B abso=
lute fees are 2000 sats and A+C+D absolute fees are 4500 sats ?<br><br>Is t=
his compatible with a model where a miner prioritizes absolute fees over an=
cestor score, in the case that mempools aren&#39;t full-enough to fulfill a=
 block ?<br><br>Let me know if I can clarify a point.<br><br>Antoine<br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0lun. 20 sept. 2021 =C3=A0=C2=A011:10, Gloria Zhao &lt;<a href=3D"mail=
to:gloriajzhao@gmail.com" target=3D"_blank">gloriajzhao@gmail.com</a>&gt; a=
 =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><br>Hi Antoine,<br><br>First of all, thank you for the =
thorough review. I appreciate your insight on LN requirements.<br><br>&gt; =
IIUC, you have a package A+B+C submitted for acceptance and A is already in=
 your mempool. You trim out A from the package and then evaluate B+C.<br><b=
r>&gt; I think this might be an issue if A is the higher-fee element of the=
 ABC package. B+C package fees might be under the mempool min fee and will =
be rejected, potentially breaking the acceptance expectations of the packag=
e issuer ?<br><br>Correct, if B+C is too low feerate to be accepted, we wil=
l reject it. I prefer this because it is incentive compatible: A can be min=
ed by itself, so there&#39;s no reason to prefer A+B+C instead of A.<br>As =
another way of looking at this, consider the case where we do accept A+B+C =
and it sits at the &quot;bottom&quot; of our mempool. If our mempool reache=
s capacity, we evict the lowest descendant feerate transactions, which are =
B+C in this case. This gives us the same resulting mempool, with A and not =
B+C.<br><div><br></div><div><br></div>&gt; Further, I think the dedup shoul=
d be done on wtxid, as you might have multiple valid witnesses. Though with=
 varying vsizes and as such offering different feerates.<br><br>I agree tha=
t variations of the same package with different witnesses is a case that mu=
st be handled. I consider witness replacement to be a project that can be d=
one in parallel to package mempool acceptance because being able to accept =
packages does not worsen the problem of a same-txid-different-witness &quot=
;pinning&quot; attack.<br><br>If or when we have witness replacement, the l=
ogic is: if the individual transaction is enough to replace the mempool one=
, the replacement will happen during the preceding individual transaction a=
cceptance, and deduplication logic will work. Otherwise, we will try to ded=
uplicate by wtxid, see that we need a package witness replacement, and use =
the package feerate to evaluate whether this is economically rational.<br><=
br>See the #22290 &quot;handle package transactions already in mempool&quot=
; commit (<a href=3D"https://github.com/bitcoin/bitcoin/pull/22290/commits/=
fea75a2237b46cf76145242fecad7e274bfcb5ff" target=3D"_blank">https://github.=
com/bitcoin/bitcoin/pull/22290/commits/fea75a2237b46cf76145242fecad7e274bfc=
b5ff</a>), which handles the case of same-txid-different-witness by simply =
using the transaction in the mempool for now, with TODOs for what I just de=
scribed.<br><br><br>&gt; I&#39;m not clearly understanding the accepted top=
ologies. By &quot;parent and child to share a parent&quot;, do you mean the=
 set of transactions A, B, C, where B is spending A and C is spending A and=
 B would be correct ?<br><br>Yes, that is what I meant. Yes, that would a v=
alid package under these rules.<br><br>&gt; If yes, is there a width-limit =
introduced or we fallback on MAX_PACKAGE_COUNT=3D25 ?<br><br>No, there is n=
o limit on connectivity other than &quot;child with all unconfirmed parents=
.&quot; We will enforce MAX_PACKAGE_COUNT=3D25 and child&#39;s in-mempool +=
 in-package ancestor limits.<br><br><br>&gt; Considering the current Core&#=
39;s mempool acceptance rules, I think CPFP batching is unsafe for LN time-=
sensitive closure. A malicious tx-relay jamming successful on one channel c=
ommitment transaction would contamine the remaining commitments sharing the=
 same package.<br><br>&gt; E.g, you broadcast the package A+B+C+D+E where A=
,B,C,D are commitment transactions and E a shared CPFP. If a malicious A&#3=
9; transaction has a better feerate than A, the whole package acceptance wi=
ll fail. Even if A&#39; confirms in the following block,<br>the propagation=
 and confirmation of B+C+D have been delayed. This could carry on a loss of=
 funds.<br><br>Please note that A may replace A&#39; even if A&#39; has hig=
her fees than A individually, because the proposed package RBF utilizes the=
 fees and size of the entire package. This just requires E to pay enough fe=
es, although this can be pretty high if there are also potential B&#39; and=
 C&#39; competing commitment transactions that we don&#39;t know about.<br>=
<br><br>&gt; IMHO, I&#39;m leaning towards deploying during a first phase 1=
-parent/1-child. I think it&#39;s the most conservative step still improvin=
g second-layer safety.<br><br>So far, my understanding is that multi-parent=
-1-child is desired for batched fee-bumping (<a href=3D"https://github.com/=
bitcoin/bitcoin/pull/22674#issuecomment-897951289" target=3D"_blank">https:=
//github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289</a>) and I&#=
39;ve also seen your response which I have less context on (<a href=3D"http=
s://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202" target=3D=
"_blank">https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-9003522=
02</a>). That being said, I am happy to create a new proposal for 1 parent =
+ 1 child (which would be slightly simpler) and plan for moving to multi-pa=
rent-1-child later if that is preferred. I am very interested in hearing fe=
edback on that approach.<br><br><br>&gt; If A+B is submitted to replace A&#=
39;, where A pays 0 sats, B pays 200 sats and A&#39; pays 100 sats. If we a=
pply the individual RBF on A, A+B acceptance fails. For this reason I think=
 the individual RBF should be bypassed and only the package RBF apply ?<br>=
<br>I think there is a misunderstanding here - let me describe what I&#39;m=
 proposing we&#39;d do in this situation: we&#39;ll try individual submissi=
on for A, see that it fails due to &quot;insufficient fees.&quot; Then, we&=
#39;ll try package validation for A+B and use package RBF. If A+B pays enou=
gh, it can still replace A&#39;. If A fails for a bad signature, we won&#39=
;t look at B or A+B. Does this meet your expectations?<br><br><br>&gt; What=
 problem are you trying to solve by the package feerate *after* dedup rule =
?<br>&gt; My understanding is that an in-package transaction might be alrea=
dy in the mempool. Therefore, to compute a correct RBF penalty replacement,=
 the vsize of this transaction could be discarded lowering the cost of pack=
age RBF.<br><br>I&#39;m proposing that, when a transaction has already been=
 submitted to mempool, we would ignore both its fees and vsize when calcula=
ting package feerate. In example G2, we shouldn&#39;t count M1 fees after i=
ts submission to mempool, since M1&#39;s fees have already been used to pay=
 for its individual bandwidth, and it shouldn&#39;t be used again to pay fo=
r P2 and P3&#39;s bandwidth. We also shouldn&#39;t count its vsize, since i=
t has already been paid for.<br><br><br>&gt; I think this is a footgunish A=
PI, as if a package issuer send the multiple-parent-one-child package A,B,C=
,D where D is the child of A,B,C. Then try to broadcast the higher-feerate =
C&#39;+D&#39; package, it should be rejected. So it&#39;s breaking the naiv=
e broadcaster assumption that a higher-feerate/higher-fee package always re=
places ?<br><br><div>Note that, if C&#39; conflicts with C, it also conflic=
ts with D, since D is a descendant of C and would thus need to be evicted a=
long with it. Implicitly, D&#39; would not be in conflict with D.<br></div>=
<div>More generally, this example is surprising to me because I didn&#39;t =
think packages would be used to fee-bump replaceable transactions. Do we wa=
nt the child to be able to replace mempool transactions as well? This can b=
e implemented with a bit of additional logic.</div><br>&gt; I think this is=
 unsafe for L2s if counterparties have malleability of the child transactio=
n. They can block your package replacement by opting-out from RBF signaling=
. IIRC, LN&#39;s &quot;anchor output&quot; presents such an ability.<br><br=
>I&#39;m not sure what you mean? Let&#39;s say we have a package of parent =
A + child B, where A is supposed to replace a mempool transaction A&#39;. A=
re you saying that counterparties are able to malleate the package child B,=
 or a child of A&#39;? If they can malleate a child of A&#39;, that shouldn=
&#39;t matter as long as A&#39; is signaling replacement. This would be han=
dled identically with full RBF and what Core currently implements.<br><br>&=
gt; I think this is an issue brought by the trimming during the dedup phase=
. If we preserve the package integrity, only re-using the tx-level checks r=
esults of already in-mempool transactions to gain in CPU time we won&#39;t =
have this issue. Package childs can add unconfirmed inputs as long as they&=
#39;re in-package, the bip125 rule2 is only evaluated against parents ?<br>=
<br>Sorry, I don&#39;t understand what you mean by &quot;preserve the packa=
ge integrity?&quot; Could you elaborate?<br><br>&gt; Let&#39;s say you have=
 in-mempool A, B where A pays 10 sat/vb for 100 vbytes and B pays 10 sat/vb=
 for 100 vbytes. You have the candidate replacement D spending both A and C=
 where D pays 15sat/vb for 100 vbytes and C pays 1 sat/vb for 1000 vbytes.<=
br><br>&gt; Package A + B ancestor score is 10 sat/vb.<br><br>&gt; D has a =
higher feerate/absolute fee than B.<br><br>&gt; Package A + C + D ancestor =
score is ~ 3 sat/vb ((A&#39;s 1000 sats + C&#39;s 1000 sats + D&#39;s 1500 =
sats) / A&#39;s 100 vb + C&#39;s 1000 vb + D&#39;s 100 vb)<br><br><div>I am=
 in agreement with your calculations but unsure if we disagree on the expec=
ted outcome. Yes, B has an ancestor score of 10sat/vb and D has an ancestor=
 score of ~2.9sat/vb. Since D&#39;s ancestor score is lower than B&#39;s, i=
t fails the proposed package RBF Rule #2, so this package would be rejected=
. Does this meet your expectations?</div><div><br></div><div>Thank you for =
linking to projects that might be interested in package relay :)<br></div><=
br>Thanks,<br>Gloria<br></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, Sep 20, 2021 at 12:16 AM Antoine Riard &lt;=
<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">Hi Gloria,<br><br>&gt; A package may contain tr=
ansactions that are already in the mempool. We<br>&gt; remove<br>&gt; (&quo=
t;deduplicate&quot;) those transactions from the package for the purposes o=
f<br>&gt; package<br>&gt; mempool acceptance. If a package is empty after d=
eduplication, we do<br>&gt; nothing.<br><br>IIUC, you have a package A+B+C =
submitted for acceptance and A is already in your mempool. You trim out A f=
rom the package and then evaluate B+C.<br><br>I think this might be an issu=
e if A is the higher-fee element of the ABC package. B+C package fees might=
 be under the mempool min fee and will be rejected, potentially breaking th=
e acceptance expectations of the package issuer ?<br><br>Further, I think t=
he dedup should be done on wtxid, as you might have multiple valid witnesse=
s. Though with varying vsizes and as such offering different feerates.<br><=
br>E.g you&#39;re going to evaluate the package A+B and A&#39; is already i=
n your mempool with a bigger valid witness. You trim A based on txid, then =
you evaluate A&#39;+B, which fails the fee checks. However, evaluating A+B =
would have been a success.<br><br>AFAICT, the dedup rationale would be to s=
ave on CPU time/IO disk, to avoid repeated signatures verification and pare=
nt UTXOs fetches ? Can we achieve the same goal by bypassing tx-level check=
s for already-in txn while conserving the package integrity for package-lev=
el checks ?<br><br>&gt; Note that it&#39;s possible for the parents to be<b=
r>&gt; indirect<br>&gt; descendants/ancestors of one another, or for parent=
 and child to share a<br>&gt; parent,<br>&gt; so we cannot make any other t=
opology assumptions.<br><br>I&#39;m not clearly understanding the accepted =
topologies. By &quot;parent and child to share a parent&quot;, do you mean =
the set of transactions A, B, C, where B is spending A and C is spending A =
and B would be correct ?<br><br>If yes, is there a width-limit introduced o=
r we fallback on MAX_PACKAGE_COUNT=3D25 ?<br><br>IIRC, one rationale to com=
e with this topology limitation was to lower the DoS risks when potentially=
 deploying p2p packages.<br><br>Considering the current Core&#39;s mempool =
acceptance rules, I think CPFP batching is unsafe for LN time-sensitive clo=
sure. A malicious tx-relay jamming successful on one channel commitment tra=
nsaction would contamine the remaining commitments sharing the same package=
.<br><br>E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitm=
ent transactions and E a shared CPFP. If a malicious A&#39; transaction has=
 a better feerate than A, the whole package acceptance will fail. Even if A=
&#39; confirms in the following block, <br>the propagation and confirmation=
 of B+C+D have been delayed. This could carry on a loss of funds.<br><br>Th=
at said, if you&#39;re broadcasting commitment transactions without time-se=
nsitive HTLC outputs, I think the batching is effectively a fee saving as y=
ou don&#39;t have to duplicate the CPFP.<br><br>IMHO, I&#39;m leaning towar=
ds deploying during a first phase 1-parent/1-child. I think it&#39;s the mo=
st conservative step still improving second-layer safety.<br><br>&gt; *Rati=
onale*: =C2=A0It would be incorrect to use the fees of transactions that ar=
e<br>&gt; already in the mempool, as we do not want a transaction&#39;s fee=
s to be<br>&gt; double-counted for both its individual RBF and package RBF.=
<br><br>I&#39;m unsure about the logical order of the checks proposed.<br><=
br>If A+B is submitted to replace A&#39;, where A pays 0 sats, B pays 200 s=
ats and A&#39; pays 100 sats. If we apply the individual RBF on A, A+B acce=
ptance fails. For this reason I think the individual RBF should be bypassed=
 and only the package RBF apply ? <br><br>Note this situation is plausible,=
 with current LN design, your counterparty can have a commitment transactio=
n with a better fee just by selecting a higher `dust_limit_satoshis` than y=
ours.<br><br>&gt; Examples F and G [14] show the same package, but P1 is su=
bmitted<br>&gt; individually before<br>&gt; the package in example G. In ex=
ample F, we can see that the 300vB package<br>&gt; pays<br>&gt; an addition=
al 200sat in fees, which is not enough to pay for its own<br>&gt; bandwidth=
<br>&gt; (BIP125#4). In example G, we can see that P1 pays enough to replac=
e M1, but<br>&gt; using P1&#39;s fees again during package submission would=
 make it look like a<br>&gt; 300sat<br>&gt; increase for a 200vB package. E=
ven including its fees and size would not be<br>&gt; sufficient in this exa=
mple, since the 300sat looks like enough for the 300vB<br>&gt; package. The=
 calculcation after deduplication is 100sat increase for a<br>&gt; package<=
br>&gt; of size 200vB, which correctly fails BIP125#4. Assume all transacti=
ons have<br>&gt; a<br>&gt; size of 100vB.<br><br>What problem are you tryin=
g to solve by the package feerate *after* dedup rule ?<br><br>My understand=
ing is that an in-package transaction might be already in the mempool. Ther=
efore, to compute a correct RBF penalty replacement, the vsize of this tran=
saction could be discarded lowering the cost of package RBF.<br><br>If we k=
eep a &quot;safe&quot; dedup mechanism (see my point above), I think this d=
iscount is justified, as the validation cost of node operators is paid for =
?<br><br>&gt; The child cannot replace mempool transactions.<br><br>Let&#39=
;s say you issue package A+B, then package C+B&#39;, where B&#39; is a chil=
d of both A and C. This rule fails the acceptance of C+B&#39; ?<br><br>I th=
ink this is a footgunish API, as if a package issuer send the multiple-pare=
nt-one-child package A,B,C,D where D is the child of A,B,C. Then try to bro=
adcast the higher-feerate C&#39;+D&#39; package, it should be rejected. So =
it&#39;s breaking the naive broadcaster assumption that a higher-feerate/hi=
gher-fee package always replaces ? And it might be unsafe in protocols wher=
e states are symmetric. E.g a malicious counterparty broadcasts first S+A, =
then you honestly broadcast S+B, where B pays better fees.<br><br>&gt; All =
mempool transactions to be replaced must signal replaceability.<br><br>I th=
ink this is unsafe for L2s if counterparties have malleability of the child=
 transaction. They can block your package replacement by opting-out from RB=
F signaling. IIRC, LN&#39;s &quot;anchor output&quot; presents such an abil=
ity.<br><br>I think it&#39;s better to either fix inherited signaling or mo=
ve towards full-rbf.<br><br>&gt; if a package parent has already been submi=
tted, it would<br>&gt; look<br>&gt;like the child is spending a &quot;new&q=
uot; unconfirmed input.<br><br>I think this is an issue brought by the trim=
ming during the dedup phase. If we preserve the package integrity, only re-=
using the tx-level checks results of already in-mempool transactions to gai=
n in CPU time we won&#39;t have this issue. Package childs can add unconfir=
med inputs as long as they&#39;re in-package, the bip125 rule2 is only eval=
uated against parents ?<br><br>&gt; However, we still achieve the same goal=
 of requiring the<br>&gt; replacement<br>&gt; transactions to have a ancest=
or score at least as high as the original<br>&gt; ones.<br><br>I&#39;m not =
sure if this holds...<br><br>Let&#39;s say you have in-mempool A, B where A=
 pays 10 sat/vb for 100 vbytes and B pays 10 sat/vb for 100 vbytes. You hav=
e the candidate replacement D spending both A and C where D pays 15sat/vb f=
or 100 vbytes and C pays 1 sat/vb for 1000 vbytes.<br><br>Package A + B anc=
estor score is 10 sat/vb.<br><br>D has a higher feerate/absolute fee than B=
.<br><br>Package A + C + D ancestor score is ~ 3 sat/vb ((A&#39;s 1000 sats=
 + C&#39;s 1000 sats + D&#39;s 1500 sats) / <br>A&#39;s 100 vb + C&#39;s 10=
00 vb + D&#39;s 100 vb)<br><br>Overall, this is a review through the lenses=
 of LN requirements. I think other L2 protocols/applications<br>could be ca=
ndidates to using package accept/relay such as:<br>* <a href=3D"https://git=
hub.com/lightninglabs/pool" target=3D"_blank">https://github.com/lightningl=
abs/pool</a><br>* <a href=3D"https://github.com/discreetlogcontracts/dlcspe=
cs" target=3D"_blank">https://github.com/discreetlogcontracts/dlcspecs</a><=
br>* <a href=3D"https://github.com/bitcoin-teleport/teleport-transactions/"=
 target=3D"_blank">https://github.com/bitcoin-teleport/teleport-transaction=
s/</a><br>* <a href=3D"https://github.com/sapio-lang/sapio" target=3D"_blan=
k">https://github.com/sapio-lang/sapio</a><br>* <a href=3D"https://github.c=
om/commerceblock/mercury/blob/master/doc/statechains.md" target=3D"_blank">=
https://github.com/commerceblock/mercury/blob/master/doc/statechains.md</a>=
<br>* <a href=3D"https://github.com/revault/practical-revault" target=3D"_b=
lank">https://github.com/revault/practical-revault</a><br><br>Thanks for ro=
lling forward the ball on this subject.<br><br>Antoine<br></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 16 s=
ept. 2021 =C3=A0=C2=A003:55, Gloria Zhao via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi there,<br><br>I&#39=
;m writing to propose a set of mempool policy changes to enable package<br>=
validation (in preparation for package relay) in Bitcoin Core. These would =
not<br>be consensus or P2P protocol changes. However, since mempool policy<=
br>significantly affects transaction propagation, I believe this is relevan=
t for<br>the mailing list.<br><br>My proposal enables packages consisting o=
f multiple parents and 1 child. If you<br>develop software that relies on s=
pecific transaction relay assumptions and/or<br>are interested in using pac=
kage relay in the future, I&#39;m very interested to hear<br>your feedback =
on the utility or restrictiveness of these package policies for<br>your use=
 cases.<br><br>A draft implementation of this proposal can be found in [Bit=
coin Core<br>PR#22290][1].<br><br>An illustrated version of this post can b=
e found at<br><div><a href=3D"https://gist.github.com/glozow/dc4e9d5c5b14ad=
e7cdfac40f43adb18a" target=3D"_blank">https://gist.github.com/glozow/dc4e9d=
5c5b14ade7cdfac40f43adb18a</a>.</div><div>I have also linked the images bel=
ow.</div><br>## Background<br><br>Feel free to skip this section if you are=
 already familiar with mempool policy<br>and package relay terminology.<br>=
<br>### Terminology Clarifications<br><br>* Package =3D an ordered list of =
related transactions, representable by a Directed<br>=C2=A0 Acyclic Graph.<=
br>* Package Feerate =3D the total modified fees divided by the total virtu=
al size of<br>=C2=A0 all transactions in the package.<br>=C2=A0 =C2=A0 - Mo=
dified fees =3D a transaction&#39;s base fees + fee delta applied by the us=
er<br>=C2=A0 =C2=A0 =C2=A0 with `prioritisetransaction`. As such, we expect=
 this to vary across<br>mempools.<br>=C2=A0 =C2=A0 - Virtual Size =3D the m=
aximum of virtual sizes calculated using [BIP141<br>=C2=A0 =C2=A0 =C2=A0 vi=
rtual size][2] and sigop weight. [Implemented here in Bitcoin Core][3].<br>=
=C2=A0 =C2=A0 - Note that feerate is not necessarily based on the base fees=
 and serialized<br>=C2=A0 =C2=A0 =C2=A0 size.<br><br>* Fee-Bumping =3D user=
/wallet actions that take advantage of miner incentives to<br>=C2=A0 boost =
a transaction&#39;s candidacy for inclusion in a block, including Child Pay=
s<br>for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our intention=
 in<br>mempool policy is to recognize when the new transaction is more econ=
omical to<br>mine than the original one(s) but not open DoS vectors, so the=
re are some<br>limitations.<br><br>### Policy<br><br>The purpose of the mem=
pool is to store the best (to be most incentive-compatible<br>with miners, =
highest feerate) candidates for inclusion in a block. Miners use<br>the mem=
pool to build block templates. The mempool is also useful as a cache for<br=
>boosting block relay and validation performance, aiding transaction relay,=
 and<br>generating feerate estimations.<br><br>Ideally, all consensus-valid=
 transactions paying reasonable fees should make it<br>to miners through no=
rmal transaction relay, without any special connectivity or<br>relationship=
s with miners. On the other hand, nodes do not have unlimited<br>resources,=
 and a P2P network designed to let any honest node broadcast their<br>trans=
actions also exposes the transaction validation engine to DoS attacks from<=
br>malicious peers.<br><br>As such, for unconfirmed transactions we are con=
sidering for our mempool, we<br>apply a set of validation rules in addition=
 to consensus, primarily to protect<br>us from resource exhaustion and aid =
our efforts to keep the highest fee<br>transactions. We call this mempool _=
policy_: a set of (configurable,<br>node-specific) rules that transactions =
must abide by in order to be accepted<br>into our mempool. Transaction &quo=
t;Standardness&quot; rules and mempool restrictions such<br>as &quot;too-lo=
ng-mempool-chain&quot; are both examples of policy.<br><br>### Package Rela=
y and Package Mempool Accept<br><br>In transaction relay, we currently cons=
ider transactions one at a time for<br>submission to the mempool. This crea=
tes a limitation in the node&#39;s ability to<br>determine which transactio=
ns have the highest feerates, since we cannot take<br>into account descenda=
nts (i.e. cannot use CPFP) until all the transactions are<br>in the mempool=
. Similarly, we cannot use a transaction&#39;s descendants when<br>consider=
ing it for RBF. When an individual transaction does not meet the mempool<br=
>minimum feerate and the user isn&#39;t able to create a replacement transa=
ction<br>directly, it will not be accepted by mempools.<br><br>This limitat=
ion presents a security issue for applications and users relying on<br>time=
-sensitive transactions. For example, Lightning and other protocols create<=
br>UTXOs with multiple spending paths, where one counterparty&#39;s spendin=
g path opens<br>up after a timelock, and users are protected from cheating =
scenarios as long as<br>they redeem on-chain in time. A key security assump=
tion is that all parties&#39;<br>transactions will propagate and confirm in=
 a timely manner. This assumption can<br>be broken if fee-bumping does not =
work as intended.<br><br>The end goal for Package Relay is to consider mult=
iple transactions at the same<br>time, e.g. a transaction with its high-fee=
 child. This may help us better<br>determine whether transactions should be=
 accepted to our mempool, especially if<br>they don&#39;t meet fee requirem=
ents individually or are better RBF candidates as a<br>package. A combinati=
on of changes to mempool validation logic, policy, and<br>transaction relay=
 allows us to better propagate the transactions with the<br>highest package=
 feerates to miners, and makes fee-bumping tools more powerful<br>for users=
.<br><br>The &quot;relay&quot; part of Package Relay suggests P2P messaging=
 changes, but a large<br>part of the changes are in the mempool&#39;s packa=
ge validation logic. We call this<br>*Package Mempool Accept*.<br><br>### P=
revious Work<br><br>* Given that mempool validation is DoS-sensitive and co=
mplex, it would be<br>=C2=A0 dangerous to haphazardly tack on package valid=
ation logic. Many efforts have<br>been made to make mempool validation less=
 opaque (see [#16400][4], [#21062][5],<br>[#22675][6], [#22796][7]).<br>* [=
#20833][8] Added basic capabilities for package validation, test accepts on=
ly<br>=C2=A0 (no submission to mempool).<br>* [#21800][9] Implemented packa=
ge ancestor/descendant limit checks for arbitrary<br>=C2=A0 packages. Still=
 test accepts only.<br>* Previous package relay proposals (see [#16401][10]=
, [#19621][11]).<br><br>### Existing Package Rules<br><br>These are in mast=
er as introduced in [#20833][8] and [#21800][9]. I&#39;ll consider<br>them =
as &quot;given&quot; in the rest of this document, though they can be chang=
ed, since<br>package validation is test-accept only right now.<br><br>1. A =
package cannot exceed `MAX_PACKAGE_COUNT=3D25` count and<br>`MAX_PACKAGE_SI=
ZE=3D101KvB` total size [8]<br><br>=C2=A0 =C2=A0*Rationale*: This is alread=
y enforced as mempool ancestor/descendant limits.<br>Presumably, transactio=
ns in a package are all related, so exceeding this limit<br>would mean that=
 the package can either be split up or it wouldn&#39;t pass this<br>mempool=
 policy.<br><br>2. Packages must be topologically sorted: if any dependenci=
es exist between<br>transactions, parents must appear somewhere before chil=
dren. [8]<br><br>3. A package cannot have conflicting transactions, i.e. no=
ne of them can spend<br><div>the same inputs. This also means there cannot =
be duplicate transactions. [8]</div><div><br></div>4. When packages are eva=
luated against ancestor/descendant limits in a test<br>accept, the union of=
 all of their descendants and ancestors is considered. This<br>is essential=
ly a &quot;worst case&quot; heuristic where every transaction in the packag=
e<br>is treated as each other&#39;s ancestor and descendant.  [8]<br>Packag=
es for which ancestor/descendant limits are accurately captured by this<br>=
<div>heuristic: [19]</div><br>There are also limitations such as the fact t=
hat CPFP carve out is not applied<br>to package transactions. #20833 also d=
isables RBF in package validation; this<br>proposal overrides that to allow=
 packages to use RBF.<br><br>## Proposed Changes<br><br>The next step in th=
e Package Mempool Accept project is to implement submission<br>to mempool, =
initially through RPC only. This allows us to test the submission<br>logic =
before exposing it on P2P.<br><br>### Summary<br><br>- Packages may contain=
 already-in-mempool transactions.<br>- Packages are 2 generations, Multi-Pa=
rent-1-Child.<br>- Fee-related checks use the package feerate. This means t=
hat wallets can<br>create a package that utilizes CPFP.<br>- Parents are al=
lowed to RBF mempool transactions with a set of rules similar<br>=C2=A0 to =
BIP125. This enables a combination of CPFP and RBF, where a<br>transaction&=
#39;s descendant fees pay for replacing mempool conflicts.<br><br>There is =
a draft implementation in [#22290][1]. It is WIP, but feedback is<br>always=
 welcome.<br><br>### Details<br><br>#### Packages May Contain Already-in-Me=
mpool Transactions<br><br>A package may contain transactions that are alrea=
dy in the mempool. We remove<br>(&quot;deduplicate&quot;) those transaction=
s from the package for the purposes of package<br>mempool acceptance. If a =
package is empty after deduplication, we do nothing.<br><br>*Rationale*: Me=
mpools vary across the network. It&#39;s possible for a parent to be<br>acc=
epted to the mempool of a peer on its own due to differences in policy and<=
br>fee market fluctuations. We should not reject or penalize the entire pac=
kage for<br>an individual transaction as that could be a censorship vector.=
<br><br>#### Packages Are Multi-Parent-1-Child<br><br>Only packages of a sp=
ecific topology are permitted. Namely, a package is exactly<br>1 child with=
 all of its unconfirmed parents. After deduplication, the package<br>may be=
 exactly the same, empty, 1 child, 1 child with just some of its<br>unconfi=
rmed parents, etc. Note that it&#39;s possible for the parents to be indire=
ct<br>descendants/ancestors of one another, or for parent and child to shar=
e a parent,<br>so we cannot make any other topology assumptions.<br><br>*Ra=
tionale*: This allows for fee-bumping by CPFP. Allowing multiple parents<br=
>makes it possible to fee-bump a batch of transactions. Restricting package=
s to a<br>defined topology is also easier to reason about and simplifies th=
e validation<br>logic greatly. Multi-parent-1-child allows us to think of t=
he package as one big<br>transaction, where:<br><br>- Inputs =3D all the in=
puts of parents + inputs of the child that come from<br>=C2=A0 confirmed UT=
XOs<br>- Outputs =3D all the outputs of the child + all outputs of the pare=
nts that<br>=C2=A0 aren&#39;t spent by other transactions in the package<br=
><br>Examples of packages that follow this rule (variations of example A sh=
ow some<br>possibilities after deduplication): ![image][15]<br><br>#### Fee=
-Related Checks Use Package Feerate<br><br>Package Feerate =3D the total mo=
dified fees divided by the total virtual size of<br>all transactions in the=
 package.<br><br>To meet the two feerate requirements of a mempool, i.e., t=
he pre-configured<br>minimum relay feerate (`minRelayTxFee`) and dynamic me=
mpool minimum feerate, the<br>total package feerate is used instead of the =
individual feerate. The individual<br>transactions are allowed to be below =
feerate requirements if the package meets<br>the feerate requirements. For =
example, the parent(s) in the package can have 0<br>fees but be paid for by=
 the child.<br><br>*Rationale*: This can be thought of as &quot;CPFP within=
 a package,&quot; solving the<br>issue of a parent not meeting minimum fees=
 on its own. This allows L2<br>applications to adjust their fees at broadca=
st time instead of overshooting or<br>risking getting stuck/pinned.<br><br>=
We use the package feerate of the package *after deduplication*.<br><br>*Ra=
tionale*: =C2=A0It would be incorrect to use the fees of transactions that =
are<br>already in the mempool, as we do not want a transaction&#39;s fees t=
o be<br>double-counted for both its individual RBF and package RBF.<br><br>=
Examples F and G [14] show the same package, but P1 is submitted individual=
ly before<br>the package in example G. In example F, we can see that the 30=
0vB package pays<br>an additional 200sat in fees, which is not enough to pa=
y for its own bandwidth<br>(BIP125#4). In example G, we can see that P1 pay=
s enough to replace M1, but<br>using P1&#39;s fees again during package sub=
mission would make it look like a 300sat<br>increase for a 200vB package. E=
ven including its fees and size would not be<br>sufficient in this example,=
 since the 300sat looks like enough for the 300vB<br>package. The calculcat=
ion after deduplication is 100sat increase for a package<br>of size 200vB, =
which correctly fails BIP125#4. Assume all transactions have a<br>size of 1=
00vB.<br><br>#### Package RBF<br><br>If a package meets feerate requirement=
s as a package, the parents in the<br>transaction are allowed to replace-by=
-fee mempool transactions. The child cannot<br>replace mempool transactions=
. Multiple transactions can replace the same<br>transaction, but in order t=
o be valid, none of the transactions can try to<br>replace an ancestor of a=
nother transaction in the same package (which would thus<br>make its inputs=
 unavailable).<br><br>*Rationale*: Even if we are using package feerate, a =
package will not propagate<br>as intended if RBF still requires each indivi=
dual transaction to meet the<br>feerate requirements.<br><br>We use a set o=
f rules slightly modified from BIP125 as follows:<br><br>##### Signaling (R=
ule #1)<br><br>All mempool transactions to be replaced must signal replacea=
bility.<br><br>*Rationale*: Package RBF signaling logic should be the same =
for package RBF and<br>single transaction acceptance. This would be updated=
 if single transaction<br>validation moves to full RBF.<br><br>##### New Un=
confirmed Inputs (Rule #2)<br><br>A package may include new unconfirmed inp=
uts, but the ancestor feerate of the<br>child must be at least as high as t=
he ancestor feerates of every transaction<br>being replaced. This is contra=
ry to BIP125#2, which states &quot;The replacement<br>transaction may only =
include an unconfirmed input if that input was included in<br>one of the or=
iginal transactions. (An unconfirmed input spends an output from a<br>curre=
ntly-unconfirmed transaction.)&quot;<br><br>*Rationale*: The purpose of BIP=
125#2 is to ensure that the replacement<br>transaction has a higher ancesto=
r score than the original transaction(s) (see<br>[comment][13]). Example H =
[16] shows how adding a new unconfirmed input can lower the<br>ancestor sco=
re of the replacement transaction. P1 is trying to replace M1, and<br>spend=
s an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat, and M2 pays<=
br>100sat. Assume all transactions have a size of 100vB. While, in isolatio=
n, P1<br>looks like a better mining candidate than M1, it must be mined wit=
h M2, so its<br>ancestor feerate is actually 4.5sat/vB.=C2=A0 This is lower=
 than M1&#39;s ancestor<br>feerate, which is 6sat/vB.<br><br>In package RBF=
, the rule analogous to BIP125#2 would be &quot;none of the<br>transactions=
 in the package can spend new unconfirmed inputs.&quot; Example J [17] show=
s<br>why, if any of the package transactions have ancestors, package feerat=
e is no<br>longer accurate. Even though M2 and M3 are not ancestors of P1 (=
which is the<br>replacement transaction in an RBF), we&#39;re actually inte=
rested in the entire<br>package. A miner should mine M1 which is 5sat/vB in=
stead of M2, M3, P1, P2, and<br>P3, which is only 4sat/vB. The Package RBF =
rule cannot be loosened to only allow<br>the child to have new unconfirmed =
inputs, either, because it can still cause us<br>to overestimate the packag=
e&#39;s ancestor score.<br><br>However, enforcing a rule analogous to BIP12=
5#2 would not only make Package RBF<br>less useful, but would also break Pa=
ckage RBF for packages with parents already<br>in the mempool: if a package=
 parent has already been submitted, it would look<br>like the child is spen=
ding a &quot;new&quot; unconfirmed input. In example K [18], we&#39;re<br>l=
ooking to replace M1 with the entire package including P1, P2, and P3. We m=
ust<br>consider the case where one of the parents is already in the mempool=
 (in this<br>case, P2), which means we must allow P3 to have new unconfirme=
d inputs. However,<br>M2 lowers the ancestor score of P3 to 4.3sat/vB, so w=
e should not replace M1<br>with this package.<br><br>Thus, the package RBF =
rule regarding new unconfirmed inputs is less strict than<br>BIP125#2. Howe=
ver, we still achieve the same goal of requiring the replacement<br>transac=
tions to have a ancestor score at least as high as the original ones. As<br=
>a result, the entire package is required to be a higher feerate mining can=
didate<br>than each of the replaced transactions.<br><br>Another note: the =
[comment][13] above the BIP125#2 code in the original RBF<br>implementation=
 suggests that the rule was intended to be temporary.<br><br>##### Absolute=
 Fee (Rule #3)<br><br>The package must increase the absolute fee of the mem=
pool, i.e. the total fees<br>of the package must be higher than the absolut=
e fees of the mempool transactions<br>it replaces. Combined with the CPFP r=
ule above, this differs from BIP125 Rule #3<br>- an individual transaction =
in the package may have lower fees than the<br>=C2=A0 transaction(s) it is =
replacing. In fact, it may have 0 fees, and the child<br>pays for RBF.<br><=
br>##### Feerate (Rule #4)<br><br>The package must pay for its own bandwidt=
h; the package feerate must be higher<br>than the replaced transactions by =
at least minimum relay feerate<br>(`incrementalRelayFee`). Combined with th=
e CPFP rule above, this differs from<br>BIP125 Rule #4 - an individual tran=
saction in the package can have a lower<br>feerate than the transaction(s) =
it is replacing. In fact, it may have 0 fees,<br>and the child pays for RBF=
.<br><br>##### Total Number of Replaced Transactions (Rule #5)<br><br>The p=
ackage cannot replace more than 100 mempool transactions. This is identical=
<br>to BIP125 Rule #5.<br><br>### Expected FAQs<br><br>1. Is it possible fo=
r only some of the package to make it into the mempool?<br><br>=C2=A0 =C2=
=A0Yes, it is. However, since we evict transactions from the mempool by<br>=
descendant score and the package child is supposed to be sponsoring the fee=
s of<br>its parents, the most common scenario would be all-or-nothing. This=
 is<br>incentive-compatible. In fact, to be conservative, package validatio=
n should<br>begin by trying to submit all of the transactions individually,=
 and only use the<br>package mempool acceptance logic if the parents fail d=
ue to low feerate.<br><br>2. Should we allow packages to contain already-co=
nfirmed transactions?<br><br>=C2=A0 =C2=A0 No, for practical reasons. In me=
mpool validation, we actually aren&#39;t able to<br>tell with 100% confiden=
ce if we are looking at a transaction that has already<br>confirmed, becaus=
e we look up inputs using a UTXO set. If we have historical<br>block data, =
it&#39;s possible to look for it, but this is inefficient, not always<br>po=
ssible for pruning nodes, and unnecessary because we&#39;re not going to do=
<br>anything with the transaction anyway. As such, we already have the expe=
ctation<br>that transaction relay is somewhat &quot;stateful&quot; i.e. nob=
ody should be relaying<br>transactions that have already been confirmed. Si=
milarly, we shouldn&#39;t be<br>relaying packages that contain already-conf=
irmed transactions.<br><br>[1]: <a href=3D"https://github.com/bitcoin/bitco=
in/pull/22290" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/22=
290</a><br>[2]: <a href=3D"https://github.com/bitcoin/bips/blob/1f0b5637381=
99ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculati=
ons" target=3D"_blank">https://github.com/bitcoin/bips/blob/1f0b563738199ca=
60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations<=
/a><br>[3]: <a href=3D"https://github.com/bitcoin/bitcoin/blob/94f83534e4b7=
71944af7d9ed0f40746f392eb75e/src/policy/policy.cpp#L282" target=3D"_blank">=
https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392=
eb75e/src/policy/policy.cpp#L282</a><br>[4]: <a href=3D"https://github.com/=
bitcoin/bitcoin/pull/16400" target=3D"_blank">https://github.com/bitcoin/bi=
tcoin/pull/16400</a><br>[5]: <a href=3D"https://github.com/bitcoin/bitcoin/=
pull/21062" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/21062=
</a><br>[6]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/22675" targ=
et=3D"_blank">https://github.com/bitcoin/bitcoin/pull/22675</a><br>[7]: <a =
href=3D"https://github.com/bitcoin/bitcoin/pull/22796" target=3D"_blank">ht=
tps://github.com/bitcoin/bitcoin/pull/22796</a><br>[8]: <a href=3D"https://=
github.com/bitcoin/bitcoin/pull/20833" target=3D"_blank">https://github.com=
/bitcoin/bitcoin/pull/20833</a><br>[9]: <a href=3D"https://github.com/bitco=
in/bitcoin/pull/21800" target=3D"_blank">https://github.com/bitcoin/bitcoin=
/pull/21800</a><br>[10]: <a href=3D"https://github.com/bitcoin/bitcoin/pull=
/16401" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/16401</a>=
<br>[11]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/19621" target=
=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19621</a><br>[12]: <a h=
ref=3D"https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" targ=
et=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0125.mediawik=
i</a><br>[13]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/6871/file=
s#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R110=
1-R1104" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6871/fil=
es#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R11=
01-R1104</a><br>[14]: <a href=3D"https://user-images.githubusercontent.com/=
25183001/133567078-075a971c-0619-4339-9168-b41fd2b90c28.png" target=3D"_bla=
nk">https://user-images.githubusercontent.com/25183001/133567078-075a971c-0=
619-4339-9168-b41fd2b90c28.png</a><br>[15]: <a href=3D"https://user-images.=
githubusercontent.com/25183001/132856734-fc17da75-f875-44bb-b954-cb7a1725cc=
0d.png" target=3D"_blank">https://user-images.githubusercontent.com/2518300=
1/132856734-fc17da75-f875-44bb-b954-cb7a1725cc0d.png</a><br>[16]: <a href=
=3D"https://user-images.githubusercontent.com/25183001/133567347-a3e2e4a8-a=
e9c-49f8-abb9-81e8e0aba224.png" target=3D"_blank">https://user-images.githu=
busercontent.com/25183001/133567347-a3e2e4a8-ae9c-49f8-abb9-81e8e0aba224.pn=
g</a><br>[17]: <a href=3D"https://user-images.githubusercontent.com/2518300=
1/133567370-21566d0e-36c8-4831-b1a8-706634540af3.png" target=3D"_blank">htt=
ps://user-images.githubusercontent.com/25183001/133567370-21566d0e-36c8-483=
1-b1a8-706634540af3.png</a><br>[18]: <a href=3D"https://user-images.githubu=
sercontent.com/25183001/133567444-bfff1142-439f-4547-800a-2ba2b0242bcb.png"=
 target=3D"_blank">https://user-images.githubusercontent.com/25183001/13356=
7444-bfff1142-439f-4547-800a-2ba2b0242bcb.png</a><br>[19]: <a href=3D"https=
://user-images.githubusercontent.com/25183001/133456219-0bb447cb-dcb4-4a31-=
b9c1-7d86205b68bc.png" target=3D"_blank">https://user-images.githubusercont=
ent.com/25183001/133456219-0bb447cb-dcb4-4a31-b9c1-7d86205b68bc.png</a><br>=
[20]: <a href=3D"https://user-images.githubusercontent.com/25183001/1328577=
87-7b7c6f56-af96-44c8-8d78-983719888c19.png" target=3D"_blank">https://user=
-images.githubusercontent.com/25183001/132857787-7b7c6f56-af96-44c8-8d78-98=
3719888c19.png</a><br></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>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></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>
</blockquote></div>

--0000000000002dd02d05cd162aa1--