Great, thanks for this clarification! Can you confirm that this won't be an issue either with your example 2C (in your first set of diagrams)? If I understand it correctly it shouldn't, but I'd rather be 100% sure.
A package A + C will be able to replace A' + B regardless of the weight of A' + B? Thanks, Bastien Le mar. 21 sept. 2021 à 18:42, Gloria Zhao <gloriajz...@gmail.com> a écrit : > Hi Bastien, > > Excellent diagram :D > > > Here the issue is that a revoked commitment tx A' is pinned in other > > mempools, with a long chain of descendants (or descendants that reach > > the maximum replaceable size). > > We would really like A + C to be able to replace this pinned A'. > > We can't submit individually because A on its own won't replace A'... > > Right, this is a key motivation for having Package RBF. In this case, A+C > can replace A' + B1...B24. > > Due to the descendant limit (each node operator can increase it on their > own node, but the default is 25), A' should have no more than 25 > descendants, even including CPFP carve out. As long as A only conflicts > with A', it won't be trying to replace more than 100 transactions. The > proposed package RBF will allow C to pay for A's conflicts, since their > package feerate is used in the fee comparisons. A is not a descendant of > A', so the existence of B1...B24 does not prevent the replacement. > > Best, > Gloria > > On Tue, Sep 21, 2021 at 4:18 PM Bastien TEINTURIER <bast...@acinq.fr> > wrote: > >> Hi Gloria, >> >> > I believe this attack is mitigated as long as we attempt to submit >> transactions individually >> >> Unfortunately not, as there exists a pinning scenario in LN where a >> different commit tx is pinned, but you actually can't know which one. >> >> Since I really like your diagrams, I made one as well to illustrate: >> >> https://user-images.githubusercontent.com/31281497/134198114-5e9c6857-e8fc-405a-be57-18181d5e54cb.jpg >> >> Here the issue is that a revoked commitment tx A' is pinned in other >> mempools, with a long chain of descendants (or descendants that reach >> the maximum replaceable size). >> >> We would really like A + C to be able to replace this pinned A'. >> We can't submit individually because A on its own won't replace A'... >> >> > I would note that this proposal doesn't accommodate something like >> diagram B, where C is getting CPFP carve out and wants to bring a +1 >> >> No worries, that case shouldn't be a concern. >> I believe any L2 protocol can always ensure it confirms such tx trees >> "one depth after the other" without impacting funds safety, so it >> only needs to ensure A + C can get into mempools. >> >> Thanks, >> Bastien >> >> Le mar. 21 sept. 2021 à 13:18, Gloria Zhao <gloriajz...@gmail.com> a >> écrit : >> >>> Hi Bastien, >>> >>> Thank you for your feedback! >>> >>> > In your example we have a parent transaction A already in the mempool >>> > and an unrelated child B. We submit a package C + D where C spends >>> > another of A's inputs. You're highlighting that this package may be >>> > rejected because of the unrelated transaction(s) B. >>> >>> > The way I see this, an attacker can abuse this rule to ensure >>> > transaction A stays pinned in the mempool without confirming by >>> > broadcasting a set of child transactions that reach these limits >>> > and pay low fees (where A would be a commit tx in LN). >>> >>> I believe you are describing a pinning attack in which your adversarial >>> counterparty attempts to monopolize the mempool descendant limit of the >>> shared transaction A in order to prevent you from submitting a fee-bumping >>> child C; I've tried to illustrate this as diagram A here: >>> https://user-images.githubusercontent.com/25183001/134159860-068080d0-bbb6-4356-ae74-00df00644c74.png >>> (please let me know if I'm misunderstanding). >>> >>> I believe this attack is mitigated as long as we attempt to submit >>> transactions individually (and thus take advantage of CPFP carve out) >>> before attempting package validation. So, in scenario A2, even if the >>> mempool receives a package with A+C, it would deduplicate A, submit C as an >>> individual transaction, and allow it due to the CPFP carve out exemption. A >>> more general goal is: if a transaction would propagate successfully on its >>> own now, it should still propagate regardless of whether it is included in >>> a package. The best way to ensure this, as far as I can tell, is to always >>> try to submit them individually first. >>> >>> I would note that this proposal doesn't accommodate something like >>> diagram B, where C is getting CPFP carve out and wants to bring a +1 (e.g. >>> C has very low fees and is bumped by D). I don't think this is a use case >>> since C should be the one fee-bumping A, but since we're talking about >>> limitations around the CPFP carve out, this is it. >>> >>> Let me know if this addresses your concerns? >>> >>> Thanks, >>> Gloria >>> >>> On Mon, Sep 20, 2021 at 10:19 AM Bastien TEINTURIER <bast...@acinq.fr> >>> wrote: >>> >>>> Hi Gloria, >>>> >>>> Thanks for this detailed post! >>>> >>>> The illustrations you provided are very useful for this kind of graph >>>> topology problems. >>>> >>>> The rules you lay out for package RBF look good to me at first glance >>>> as there are some subtle improvements compared to BIP 125. >>>> >>>> > 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and >>>> > `MAX_PACKAGE_SIZE=101KvB` total size [8] >>>> >>>> I have a question regarding this rule, as your example 2C could be >>>> concerning for LN (unless I didn't understand it correctly). >>>> >>>> This also touches on the package RBF rule 5 ("The package cannot >>>> replace more than 100 mempool transactions.") >>>> >>>> In your example we have a parent transaction A already in the mempool >>>> and an unrelated child B. We submit a package C + D where C spends >>>> another of A's inputs. You're highlighting that this package may be >>>> rejected because of the unrelated transaction(s) B. >>>> >>>> The way I see this, an attacker can abuse this rule to ensure >>>> transaction A stays pinned in the mempool without confirming by >>>> broadcasting a set of child transactions that reach these limits >>>> and pay low fees (where A would be a commit tx in LN). >>>> >>>> We had to create the CPFP carve-out rule explicitly to work around >>>> this limitation, and I think it would be necessary for package RBF >>>> as well, because in such cases we do want to be able to submit a >>>> package A + C where C pays high fees to speed up A's confirmation, >>>> regardless of unrelated unconfirmed children of A... >>>> >>>> We could submit only C to benefit from the existing CPFP carve-out >>>> rule, but that wouldn't work if our local mempool doesn't have A yet, >>>> but other remote mempools do. >>>> >>>> Is my concern justified? Is this something that we should dig into a >>>> bit deeper? >>>> >>>> Thanks, >>>> Bastien >>>> >>>> Le jeu. 16 sept. 2021 à 09:55, Gloria Zhao via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> a écrit : >>>> >>>>> 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. These >>>>> 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 Core >>>>> 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 = an ordered list of related transactions, representable by >>>>> a Directed >>>>> Acyclic Graph. >>>>> * Package Feerate = the total modified fees divided by the total >>>>> virtual size of >>>>> all transactions in the package. >>>>> - Modified fees = a transaction's base fees + fee delta applied by >>>>> the user >>>>> with `prioritisetransaction`. As such, we expect this to vary >>>>> across >>>>> mempools. >>>>> - Virtual Size = the maximum of virtual sizes calculated using >>>>> [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 = 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 are >>>>> 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 descendants >>>>> when >>>>> considering it for RBF. When an individual transaction does not meet >>>>> 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 users >>>>> 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 scenarios >>>>> 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 more >>>>> 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=25` count and >>>>> `MAX_PACKAGE_SIZE=101KvB` 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 them >>>>> can spend >>>>> the same inputs. This also means there cannot be duplicate >>>>> transactions. [8] >>>>> >>>>> 4. When packages are evaluated against ancestor/descendant limits in 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 purposes >>>>> of package >>>>> mempool acceptance. If a package is empty after deduplication, we do >>>>> 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 entire >>>>> 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 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. >>>>> >>>>> *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 = all the inputs of parents + inputs of the child that come >>>>> from >>>>> confirmed UTXOs >>>>> - Outputs = 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 = 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. The >>>>> 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 be >>>>> 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 own >>>>> 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 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. >>>>> >>>>> #### Package RBF >>>>> >>>>> 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. 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 the >>>>> 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 the >>>>> 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 mempool >>>>> (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 must >>>>> 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 mempool 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/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations >>>>> [3]: >>>>> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392eb75e/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.mediawiki >>>>> [13]: >>>>> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104 >>>>> [14]: >>>>> https://user-images.githubusercontent.com/25183001/133567078-075a971c-0619-4339-9168-b41fd2b90c28.png >>>>> [15]: >>>>> https://user-images.githubusercontent.com/25183001/132856734-fc17da75-f875-44bb-b954-cb7a1725cc0d.png >>>>> [16]: >>>>> https://user-images.githubusercontent.com/25183001/133567347-a3e2e4a8-ae9c-49f8-abb9-81e8e0aba224.png >>>>> [17]: >>>>> https://user-images.githubusercontent.com/25183001/133567370-21566d0e-36c8-4831-b1a8-706634540af3.png >>>>> [18]: >>>>> https://user-images.githubusercontent.com/25183001/133567444-bfff1142-439f-4547-800a-2ba2b0242bcb.png >>>>> [19]: >>>>> https://user-images.githubusercontent.com/25183001/133456219-0bb447cb-dcb4-4a31-b9c1-7d86205b68bc.png >>>>> [20]: >>>>> https://user-images.githubusercontent.com/25183001/132857787-7b7c6f56-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
