Skip to content

BIP-431: clarify Rule 3 to enforce cluster size 2 and fix inclusive counting #2012

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

BIP-431: clarify Rule 3 to enforce cluster size 2 and fix inclusive counting #2012

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions bip-0431.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -104,10 +104,10 @@ A node that implements this policy would apply their existing standardness and p
</ref>
Note: A TRUC transaction can spend outputs from ''confirmed'' non-TRUC transactions. A non-TRUC transaction can spend outputs from ''confirmed'' TRUC transactions.

3. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant. CPFP Carve Out is not granted to TRUC transactions.
3. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant. A TRUC transaction MUST NOT simultaneously have both an unconfirmed TRUC ancestor and an unconfirmed TRUC descendant. CPFP Carve Out is not granted to TRUC transactions.
<ref>Rationale:
* The larger the descendant limit, the more transactions may need to be replaced. See #1 in Rule 3 Pinning section above. This also makes pinning using Rule 5 more difficult, since a directly conflicting transaction has fewer possible descendants.
* These two limits (ancestor count 2, descendant count 2) effectively create a cluster limit using the existing ancestor and descendant limits. Increasing them to 3 would imply an infinite cluster count limit.
* Using inclusive counting (including the transaction itself), these limits are 2 in each direction. Combined with the prohibition on simultaneously having both an unconfirmed TRUC ancestor and an unconfirmed TRUC descendant, this enforces a maximum cluster size of 2. Increasing either limit to 3 would imply an unbounded cluster size.
* This 1-parent-1-child topology makes it possible to use ancestor score (minimum of ancestor feerate and individual feerate) as a measure of incentive compatibility.

<br />Q: Why not allow multiple parents to enable batched fee-bumping?
Expand Down Expand Up @@ -147,7 +147,7 @@ Note: A TRUC transaction can spend outputs from ''confirmed'' non-TRUC transacti

====Related Work====

This 1-parent-1-child (aka cluster size 2) topology restriction makes the transactions much easier to reason about, which enables additional features like
This 1-parent-1-child (aka cluster size 2; at most two unconfirmed transactions total, i.e., no simultaneous parent and child) topology restriction makes the transactions much easier to reason about, which enables additional features like
feerate diagram comparisons
<ref>
[https://github.com/bitcoin/bitcoin/pull/29242 this PR] implements feerate diagram creation and comparison for sets of transactions in which the maximum cluster size is 2, e.g. all TRUC transactions.
Expand Down