docs: RBF policy and mempool limit exemptions #23711

pull glozow wants to merge 3 commits into bitcoin:master from glozow:2021-12-rbf-docs changing 4 files +143 −4
  1. glozow commented at 4:29 pm on December 8, 2021: member

    Since RBF was first implemented and BIP125 was written, our code has changed, people have highlighted implementation differences, and some people have proposed further changes to it. Many people seem to support the idea of documenting our current RBF policy as it stands today.

    As the ancestor/descendant limit carve-out exemptions are very related to RBF, it seemed appropriate to group them with this PR.

    Related to #22806 - it seems that these policies are the most confusing for people, or at least the most documentation-requested.

  2. darosior commented at 4:35 pm on December 8, 2021: member
    Concept ACK.
  3. laanwj added the label Docs on Dec 8, 2021
  4. ariard commented at 1:04 am on December 9, 2021: member
    Nice! Concept ACK
  5. in doc/policy/README.md:3 in b27af5c522 outdated 
    0@@ -0,0 +1,11 @@
1+# Mempool Policy
2+
3+**Mempool Policy** (aka Transaction Relay Policy) is the node's set of validation rules, in addition
    luke-jr commented at 2:40 am on December 9, 2021:
    Not sure it’s a good idea to call them “rules”. Maybe “conditions”?
    darosior commented at 11:12 am on December 9, 2021:
    nit: i wouldn’t say Mempool Validation policy and Transaction Relay policy are equivalent
    glozow commented at 12:30 pm on December 9, 2021:

    Is it because “rules” sounds too strict? I think “conditions” is too weak otoh, and I’ve used it to mean something else in the docs.

    I’ve added a clarification that these are local rules, only for mempool transactions, not used for block transactions. Hopefully that makes it clear to the reader

  6. DrahtBot commented at 3:54 am on December 9, 2021: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #23121 ([policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  7. in doc/policy/mempool-limits.md:6 in b27af5c522 outdated 
    0@@ -0,0 +1,65 @@
1+# Mempool Limits
2+
3+## Definitions
4+
5+Given any two transactions Tx0 and Tx1 where Tx1 spends the output of Tx0:,
6+Tx0 is the *parent* of Tx1 and Tx1 is the *child* of Tx0.
    t-bast commented at 10:16 am on December 9, 2021:

    nit:

    0Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0,
1Tx0 is the *parent* of Tx1 and Tx1 is a *child* of Tx0.
    glozow commented at 12:31 pm on December 9, 2021:
    Good catch, changed both s/the/a
    t-bast commented at 12:53 pm on December 9, 2021:
    This is still a weird :, at the end of the first line, apart from that it looks good!
  8. in doc/policy/mempool-limits.md:35 in b27af5c522 outdated 
    30+mempool would cause some mempool entry to exceed its descendant limits, an exemption is made if each
31+of the following conditions are met:
32+
33+1. The candidate transaction is no more than 40,000 WU.
34+
35+2. The candidate transaction has an ancestor count of 2 (it has no other ancestors).
    t-bast commented at 10:19 am on December 9, 2021:

    nit: is the following clearer?

    02. The candidate transaction has an ancestor count of 2 (it has only one ancestor).
  9. in doc/policy/mempool-limits.md:52 in b27af5c522 outdated 
    47+
48+When a candidate transaction for submission to the mempool would replace mempool entries, it may
49+also decrease the descendant count of other mempool entries. Since ancestor/descendant limits are
50+calculated prior to removing the would-be-replaced transactions, they may be overestimated.
51+
52+An exemption is given for a candidate transaction would replace mempool transactions and meets each
    t-bast commented at 10:20 am on December 9, 2021:

    nit:

    0An exemption is given for a candidate transaction that would replace mempool transactions and meets each
  10. in doc/policy/mempool-replacements.md:47 in b27af5c522 outdated 
    42+5. The number of original transactions must not exceed 100. More precisely, the sum of all
43+   directly conflicting transactions' descendant counts (number of transactions inclusive of itself
44+   and its descendants) must not exceed 100.
45+
46+   *Rationale*: Prevent a DoS attack where an attacker is able to easily occupy and flush out
47+   significant portions of the node's mempool using replacements.
    t-bast commented at 10:31 am on December 9, 2021:

    This rule confused me a bit when I first encountered it, I think it can be worth clarifying that the attacker would replace multiple transactions at once that each have many descendants, what do you think?

    0   *Rationale*: Prevent a DoS attack where an attacker is able to easily occupy and flush out
1   significant portions of the node's mempool by replacing multiple independent chains of
2   transactions at once.
    glozow commented at 12:31 pm on December 9, 2021:
    Added!
  11. t-bast commented at 10:32 am on December 9, 2021: member
    Thanks for documenting this, it’s very helpful. A few nits / suggestions, feel free to ignore what you don’t like.
  12. jnewbery commented at 10:57 am on December 9, 2021: member
    Strong concept ACK. Thank you for adding documentation!
  13. in doc/bips.md:35 in b27af5c522 outdated 
    31@@ -32,7 +32,7 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v22.0**):
32 * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, and enforced for all peer versions as of **v0.13.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579) and [PR #6641](https://github.com/bitcoin/bitcoin/pull/6641)).
33 * [`BIP 112`](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki): The CHECKSEQUENCEVERIFY opcode has been implemented since **v0.12.1** ([PR #7524](https://github.com/bitcoin/bitcoin/pull/7524)), and has been *buried* since **v0.19.0** ([PR #16060](https://github.com/bitcoin/bitcoin/pull/16060)).
34 * [`BIP 113`](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki): Median time past lock-time calculations have been implemented since **v0.12.1** ([PR #6566](https://github.com/bitcoin/bitcoin/pull/6566)), and has been *buried* since **v0.19.0** ([PR #16060](https://github.com/bitcoin/bitcoin/pull/16060)).
35-* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). Enabled by default in the wallet GUI as of **v0.18.1** ([PR #11605](https://github.com/bitcoin/bitcoin/pull/11605))
36+* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling partially implemented. See doc/policy/mempool-replacements.md.
    darosior commented at 11:11 am on December 9, 2021:
    :100:
  14. glozow force-pushed on Dec 9, 2021
  15. in doc/policy/mempool-limits.md:33 in abd4c7c8ac outdated 
    28+
29+**CPFP Carve Out** if a transaction candidate for submission to the
30+mempool would cause some mempool entry to exceed its descendant limits, an exemption is made if each
31+of the following conditions are met:
32+
33+1. The candidate transaction is no more than 40,000 WU.
    darosior commented at 12:57 pm on December 9, 2021:
    nit: it’s in effect 10,000 vb according to our local definition of vbytes
    jnewbery commented at 11:19 am on December 14, 2021:
    I agree that it’d be better to refer to this using virtual bytes, since the code checks the transaction’s m_vsize against EXTRA_DESCENDANT_TX_SIZE_LIMIT
    glozow commented at 6:35 pm on December 16, 2021:
    Yeah you’re right, changed to vB
  16. in doc/policy/mempool-limits.md:46 in abd4c7c8ac outdated 
    41+limits in two-party contract protocols such as LN.  Also see the [mailing list
42+post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html).
43+
44+This rule was introduced in [PR #15681](https://github.com/bitcoin/bitcoin/pull/15681).
45+
46+### Single-Conflict RBF
    darosior commented at 1:01 pm on December 9, 2021:
    nit: maybe name it something like “RBF Carve Out” or explicit it’s to be able to RBF a transaction added using the above carveout?
    glozow commented at 6:35 pm on December 16, 2021:
    Added
  17. in doc/policy/mempool-replacements.md:11 in abd4c7c8ac outdated 
     6+spend one or more of the same inputs. A transaction may conflict with multiple in-mempool
 7+transactions.
 8+
 9+A transaction ("replacement transaction") may replace its directly conflicting transactions and
10+their in-mempool descendants (together, "original transactions") if, in addition to passing all
11+other consensus and policy rules, each of the following conditions are met:
    darosior commented at 1:02 pm on December 9, 2021:
    Defining “directly conflicting txs”, “replacement tx” and “original txs” is neat :+1:
  18. in doc/policy/mempool-replacements.md:31 in abd4c7c8ac outdated 
    26+3. The replacement transaction must pay an absolute fee of at least the sum paid by the original
27+   transactions.
28+
29+   *Rationale*: Only requiring the replacement transaction to have a higher feerate could allow an
30+   attacker to bypass node minimum relay feerate requirements and cause the network to repeatedly
31+   relay slightly smaller replacement transactions without adding any more fees.
    darosior commented at 1:06 pm on December 9, 2021:
    Also to reduce the expected mining income if the mempool is less than 1vb.
    glozow commented at 6:34 pm on December 16, 2021:
    Ah yes, added “Additionally, if any of the original transactions would be included in the next block assembled by an economically rational miner, a replacement policy allowing the replacement transaction to decrease the absolute fees in the next block would be incentive-incompatible.”
  19. in doc/policy/mempool-replacements.md:44 in abd4c7c8ac outdated 
    39+   *Rationale*: Try to attempt DoS attacks where an attacker causes the network to repeatedly relay
40+   transactions each paying a tiny additional amount in fees, e.g. just 1 satoshi.
41+
42+5. The number of original transactions must not exceed 100. More precisely, the sum of all
43+   directly conflicting transactions' descendant counts (number of transactions inclusive of itself
44+   and its descendants) must not exceed 100.
    darosior commented at 1:12 pm on December 9, 2021:
    nit: maybe mention that it may be overstimated?
    glozow commented at 6:33 pm on December 16, 2021:
    Added “it is possible that this overestimates the true number of original transactions”
  20. darosior approved
  21. darosior commented at 1:17 pm on December 9, 2021: member

    ACK abd4c7c8acccbc32a66ff3fe5cb22135c348a4bc – thanks, that’s great

    Bikeshedding a few things, but it looks good to me as such. I also find compelling the point raised by John in the linked issue to have this in the wiki instead, but absolutely not a blocker for me.

  22. in doc/policy/README.md:6 in abd4c7c8ac outdated 
    0@@ -0,0 +1,12 @@
1+# Mempool Policy
2+
3+**Mempool Policy** (aka Transaction Relay Policy) is the node's set of validation rules, in addition
4+to consensus, enforced for unconfirmed transactions before submitting them to the mempool.  These
5+local rules include restrictions on the transaction itself and the transaction in relation to the
6+node's mempool contents. They are *not* applied to transactions in blocks.
    ariard commented at 11:08 pm on December 12, 2021:
    I would also say “and chain tip” as your chain tip is changing the outcome of some RBF rules, such as rule 2 on unconfirmed inputs.
    glozow commented at 6:36 pm on December 16, 2021:
    Added
  23. in doc/policy/README.md:9 in abd4c7c8ac outdated 
    0@@ -0,0 +1,12 @@
1+# Mempool Policy
2+
3+**Mempool Policy** (aka Transaction Relay Policy) is the node's set of validation rules, in addition
4+to consensus, enforced for unconfirmed transactions before submitting them to the mempool.  These
5+local rules include restrictions on the transaction itself and the transaction in relation to the
6+node's mempool contents. They are *not* applied to transactions in blocks.
7+
    ariard commented at 11:11 pm on December 12, 2021:

    Maybe it should precise that a subset of those rules are fine-tunable by the node operator (-mintxfee, -limitdescendantsize, -limitancestorsize, …) ?

    I think it’s interesting to notice that, to underscore that those rules might not even be uniform across the Bitcoin Core node of the same version.

    glozow commented at 6:36 pm on December 16, 2021:
    Ah true, added " These rules are local to the node and configurable (e.g. -minrelaytxfee, -limitancestorsize,-incrementalRelayFee)."
  24. in doc/policy/mempool-limits.md:18 in abd4c7c8ac outdated 
    13+A mempool entry's *descendant count* is the total number of in-mempool (unconfirmed) transactions in
14+its descendant set, including itself.
15+
16+A mempool entry's *ancestor size* is the aggregated virtual size of in-mempool (unconfirmed)
17+transactions in its ancestor set, including itself.
18+A mempool entry's *descendant count* is the aggregated virtual size of in-mempool (unconfirmed)
    ariard commented at 11:13 pm on December 12, 2021:
    s/count/size/g ?
    glozow commented at 6:36 pm on December 16, 2021:
    oooh good catch @ariard
  25. in doc/policy/mempool-limits.md:57 in abd4c7c8ac outdated 
    52+An exemption is given for a candidate transaction that would replace mempool transactions and meets
53+each of the following conditions:
54+
55+1. The candidate transaction has exactly 1 directly conflicting transaction.
56+
57+2. The candidate transaction does not spend any unconfirmed inputs that are not also spent by the
    ariard commented at 11:29 pm on December 12, 2021:
    In fact this is checked by the rule 2 requirement in ReplacementChecks not in the exemption single-conflict RBF in PreChecks, maybe confusing to mention it here ?
    glozow commented at 6:39 pm on December 16, 2021:
    It is explicitly a requirement for this carve-out though. As commented here: https://github.com/bitcoin/bitcoin/blob/8c0bd871fcf6c5ff5851ccb18a7bc7554a0484b0/src/validation.cpp#L821-L825
    ariard commented at 0:04 am on December 20, 2021:
    Okay, I got your point there are logically united if you want a working carve-out, though spread out in the code.
  26. in doc/policy/mempool-replacements.md:54 in abd4c7c8ac outdated 
    45+
46+   *Rationale*: Try to prevent DoS attacks where an attacker is able to easily occupy and flush out
47+   significant portions of the node's mempool using replacements with multiple directly conflicting
48+   transactions, each with large descendant sets.
49+
50+This set of rules is similar but distinct from BIP125.
    ariard commented at 11:39 pm on December 12, 2021:
    I’m not sure I understand what you mean here by “similar but distinct” ? Maybe say we’re partial implementation of BIP125 as we have at least one known divergence (though maybe fixed by #22698)
    glozow commented at 6:33 pm on December 16, 2021:

    I think there’s a lot of differences and it may change over time, so it’s better to just say they’re distinct than try to convey a measurement of how different they are. I also don’t like the framing of “partial implementation”, since the goal was never to implement BIP125. If anything, BIP125 is a partial description of our code.

    More differences:

    • We use the node’s incrementalRelayFee, not minrelayfeerate now, so if the user sets something different for those two values, we’re diverging from BIP125
    • We use the sum of directly conflicting transactions’ descendant counts, not the exact number of original transactions.
    ariard commented at 0:02 am on December 20, 2021:

    since the goal was never to implement BIP125

    Yes BIP125 was written from Core’s implementation. Thanks for the explanation, I agree :)

  27. ariard commented at 11:54 pm on December 12, 2021: member

    ACK abd4c7c (though maybe few typos/minors comments worthy to fix)

    Given mempool policy is directly consumed by downstream projects for a number of safety-critical operations, I believe its documentation correctness matters. I don’t think we have, at least not yet (?), a consistent review process for the wiki.

    Further, I think it’s good to minimize reliance on GH and to have essential documentation canonically replicated in each one’s git tree.

  28. luke-jr commented at 11:56 pm on December 12, 2021: member

    Given mempool policy is directly consumed by downstream projects for a number of safety-critical operations

    It shouldn’t be. It makes no guarantees, and nodes should vary their mempool policy. Relying on it for anything safety-critical is a security vulnerability. Just don’t do it.

  29. fanquake deleted a comment on Dec 13, 2021
  30. fanquake deleted a comment on Dec 13, 2021
  31. JeremyRubin commented at 0:07 am on December 13, 2021: contributor

    concept ACK!

    will review more closely. It may make sense to try to write these up with 2 levels and one level refining the other. The higher level might be nice as to describing what we want the policy to accomplish and then the concrete policy can be described separately.

    not to make more work for you, but this would be helpful in the future when we’re discussing what the policy should be so we can separate from the higher-order-goals and the things that happen to be true as an artifact of our specific engineering choices.

    edit: a lot of this already in the rationale, but if you collected the main points from the rationales, you could then link the rationales to the higher order doc

  32. DrahtBot added the label Needs rebase on Dec 14, 2021
  33. in doc/policy/mempool-limits.md:5 in abd4c7c8ac outdated 
    0@@ -0,0 +1,65 @@
1+# Mempool Limits
2+
3+## Definitions
4+
5+Given any two transactions Tx0 and Tx1 where Tx1 spends the output of Tx0:,
    jnewbery commented at 11:14 am on December 14, 2021: 
    0Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0,
  34. in doc/policy/mempool-limits.md:35 in abd4c7c8ac outdated 
    30+mempool would cause some mempool entry to exceed its descendant limits, an exemption is made if each
31+of the following conditions are met:
32+
33+1. The candidate transaction is no more than 40,000 WU.
34+
35+2. The candidate transaction has an ancestor count of 2 (it has exactly 1 ancestor).
    jnewbery commented at 11:21 am on December 14, 2021: 
    02. The candidate transaction has an ancestor count of 2 (itself and 1 true ancestor).
    glozow commented at 6:35 pm on December 16, 2021:
    I don’t want people to be confused thinking there are untrue ancestors, so I’ve changed it to “itself and exactly 1 ancestor”
  35. in doc/policy/mempool-limits.md:30 in abd4c7c8ac outdated 
    25+## Exemptions
26+
27+### CPFP Carve Out
28+
29+**CPFP Carve Out** if a transaction candidate for submission to the
30+mempool would cause some mempool entry to exceed its descendant limits, an exemption is made if each
    jnewbery commented at 11:22 am on December 14, 2021: 
    0mempool would cause some mempool entry to exceed its descendant limits, an exemption is made if all
  36. in doc/policy/mempool-limits.md:53 in abd4c7c8ac outdated 
    48+When a candidate transaction for submission to the mempool would replace mempool entries, it may
49+also decrease the descendant count of other mempool entries. Since ancestor/descendant limits are
50+calculated prior to removing the would-be-replaced transactions, they may be overestimated.
51+
52+An exemption is given for a candidate transaction that would replace mempool transactions and meets
53+each of the following conditions:
    jnewbery commented at 11:22 am on December 14, 2021: 
    0all of the following conditions:
  37. in doc/policy/mempool-limits.md:64 in abd4c7c8ac outdated 
    59+
60+The following discounts are given to account for the would-be-replaced transaction(s):
61+
62+1. The descendant count limit is temporarily increased by 1.
63+
64+2. The descendant size limit temporarily increased by the virtual size of the to-be-replaced
    jnewbery commented at 11:23 am on December 14, 2021: 
    02. The descendant size limit is temporarily increased by the virtual size of the to-be-replaced
  38. in doc/policy/mempool-replacements.md:24 in abd4c7c8ac outdated 
    19+2. The replacement transaction may only include an unconfirmed input if that input was included in
20+   one of the directly conflicting transactions. An unconfirmed input spends an output from a
21+   currently-unconfirmed transaction.
22+
23+   *Rationale*: When RBF was originally implemented, the mempool did not keep track of
24+   ancestor scores yet. This rule was suggested as a temporary restriction.
    jnewbery commented at 11:25 am on December 14, 2021: 
    0   ancestor fee rates yet. This rule was suggested as a temporary restriction.

    (perhaps also add a link to the discussion)

    glozow commented at 6:34 pm on December 16, 2021:
    Ah good catch. I tend to use them interchangably
  39. in doc/policy/mempool-replacements.md:13 in abd4c7c8ac outdated 
     8+
 9+A transaction ("replacement transaction") may replace its directly conflicting transactions and
10+their in-mempool descendants (together, "original transactions") if, in addition to passing all
11+other consensus and policy rules, each of the following conditions are met:
12+
13+1. The directly conflicting transactions must all signal replaceability explicitly. A transaction is
    jnewbery commented at 11:28 am on December 14, 2021:

    The “must”, “may”, etc words in these conditions are redundant with the sentence above and can be removed

    0... all of the following conditions are met:
1
21. The directly conflicting transactions all signal...
32. The replacement transaction only includes ...
    glozow commented at 6:34 pm on December 16, 2021:
    Removed
  40. jnewbery commented at 11:30 am on December 14, 2021: member

    ACK abd4c7c8acccbc32a66ff3fe5cb22135c348a4bc

    A few minor comments inline.

  41. glozow force-pushed on Dec 16, 2021
  42. in doc/policy/mempool-replacements.md:42 in 1c75f184a1 outdated 
    37+   sum paid by the original transactions) pays for the replacement transaction's bandwidth at or
38+   above the rate set by the node's incremental relay feerate. For example, if the incremental relay
39+   feerate is 1 satoshi/vB and the replacement transaction is 500 virtual bytes total, then the
40+   replacement pays a fee at least 500 satoshis higher than the sum of the original transactions.
41+
42+   *Rationale*: Try to attempt DoS attacks where an attacker causes the network to repeatedly relay
    t-bast commented at 6:40 pm on December 16, 2021:

    nit: I guess you mean:

    0   *Rationale*: Try to prevent DoS attacks where an attacker causes the network to repeatedly relay
    glozow commented at 6:45 pm on December 16, 2021:
    gahhh how embarrassing 🤦 thank you @t-bast!
  43. in doc/policy/mempool-limits.md:5 in 1c75f184a1 outdated 
    0@@ -0,0 +1,65 @@
1+# Mempool Limits
2+
3+## Definitions
4+
5+Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0:,
    t-bast commented at 6:42 pm on December 16, 2021:

    nit: you should decide between : and , :laughing:

    0Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0:

    or

    0Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0,
    glozow commented at 6:45 pm on December 16, 2021:
    oops yes, thank you! 😅
  44. t-bast approved
  45. t-bast commented at 6:43 pm on December 16, 2021: member
    ACK https://github.com/bitcoin/bitcoin/pull/23711/commits/1c75f184a11d143f0e78d99e46b2a787852610b9, only a couple of very nits
  46. [doc] current rbf policy 919ae8b8cd
  47. [doc] clarify RBF difference from BIP125 
    It can be argued that BIP125#1 signaling is honored because
descendants of signaling transactions are replaceable by RBF.

Regardless, since there are multiple details in our RBF policy that are
not captured in BIP125, point to our doc instead.
    1fd49eb498
  48. [doc] CPFP carve out and single-conflict RBF exemption 82858bab64
  49. glozow force-pushed on Dec 16, 2021
  50. DrahtBot removed the label Needs rebase on Dec 16, 2021
  51. t-bast approved
  53. darosior commented at 10:22 am on December 17, 2021: member
    re-ACK 82858bab64274506cfcd365a6588a1a9141fb22c
  54. MarcoFalke commented at 10:39 am on December 17, 2021: member
    @glozow Do you want this merged or wait a bit more for nits/reviews?
  55. glozow commented at 10:45 am on December 17, 2021: member

    @glozow Do you want this merged or wait a bit more for nits/reviews?

    I think we should give @ariard some time to see #23711 (review) and #23711 (review) since he had questions about correctness. Then, I’d feel confident that people agree this documentation is accurate, and any nits can be addressed in a followup. Thanks for asking!

  56. glozow commented at 10:52 am on December 17, 2021: member

    Regarding placement of docs and high-level vs low-level:

    It may make sense to try to write these up with 2 levels and one level refining the other. The higher level might be nice as to describing what we want the policy to accomplish and then the concrete policy can be described separately.

    I like this framing: that we should (1) communicate our overall design philosophy in a resource for developers and (2) provide concrete/precise documentation of the code we’re releasing to other devs/users.

    Given mempool policy is directly consumed by downstream projects for a number of safety-critical operations, I believe its documentation correctness matters. I don’t think we have, at least not yet (?), a consistent review process for the wiki.

    I agree with this. The high-level ideas fit well in the dev wiki (which we can all collaborate freely on) and the concrete documentation of our policy interface should be reviewed + packaged with the code.

  57. dunxen commented at 7:02 am on December 18, 2021: contributor

    ACK 82858ba

    Had a read through and the language seems approachable and actually clears some things up for me. Thanks for this!

  58. in doc/policy/mempool-limits.md:21 in 82858bab64 
    16+A mempool entry's *ancestor size* is the aggregated virtual size of in-mempool (unconfirmed)
17+transactions in its ancestor set, including itself.
18+A mempool entry's *descendant size* is the aggregated virtual size of in-mempool (unconfirmed)
19+transactions in its descendant set, including itself.
20+
21+Transactions submitted to the mempool must not exceed the ancestor and descendant limits (aka
    JeremyRubin commented at 4:43 pm on December 18, 2021:

    nit: change ‘submitted to’ to ‘present in’

    it’s fine to submit them, nothing bad happens.

  59. ariard commented at 0:11 am on December 20, 2021: member

    ACK 82858ba

    Thanks for that!

    I like this framing: that we should (1) communicate our overall design philosophy in a resource for developers and (2) provide concrete/precise documentation of the code we’re releasing to other devs/users.

    Agree to document the overall design philosophy and I think too it might be better suited in the wiki as we might have heterogeneous, evolving viewpoints among contributors.

    An exception, one piece of document which could fit in the repo would be a formalized process for policy rules tightening with known implications towards Bitcoin applications/L2 (cf. discussion on potential class of policy changes, see Jeremy’s https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019400.html)

  60. MarcoFalke merged this on Dec 20, 2021
  61. MarcoFalke closed this on Dec 20, 2021
  62. sidhujag referenced this in commit 2a913acfbb on Dec 20, 2021
  63. DrahtBot locked this on Dec 20, 2022


glozow darosior ariard luke-jr DrahtBot t-bast jnewbery JeremyRubin MarcoFalke dunxen

Labels
Docs

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-07-03 07:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me