Re-include RBF replacement txs in fee estimation #22539

pull darosior wants to merge 4 commits into bitcoin:master from darosior:fee_est_rbf changing 3 files +131 −35
  1. darosior commented at 3:09 pm on July 23, 2021: member

    This effectively reverts #9519.

    RBF is now largely in use on the network (signaled for by around 20% of all transactions on average) and replacement logic is implemented in most end-user wallets. The rate of replaced transactions is also expected to rise as fee-bumping techniques are being developed for pre-signed transaction (“L2”) protocols.

  2. in src/validation.cpp:887 in 68959526f3 outdated
    981@@ -982,7 +982,6 @@ bool MemPoolAccept::Finalize(const ATMPArgs& args, Workspace& ws)
    982     const CAmount& nModifiedFees = ws.m_modified_fees;
    983     const CAmount& nConflictingFees = ws.m_conflicting_fees;
    984     const size_t& nConflictingSize = ws.m_conflicting_size;
    985-    const bool fReplacementTransaction = ws.m_replacement_transaction;
    


    MarcoFalke commented at 3:26 pm on July 23, 2021:
    Can also remove m_replacement_transaction, now that it is unused and inline setConflicts.size() again?

    darosior commented at 3:52 pm on July 23, 2021:
    Done.
  3. ghost commented at 3:32 pm on July 23, 2021: none

    Concept ACK

    image

  4. darosior force-pushed on Jul 23, 2021
  5. darosior commented at 4:08 pm on July 23, 2021: member
    Asking the mempool statistics reference on IRC, @0xB10C pointed out to me there are between 2000 and 6000 replacements per day at the moment.
  6. in src/validation.cpp:807 in d76493ec22 outdated
    802@@ -805,8 +803,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
    803     // If we don't hold the lock allConflicting might be incomplete; the
    804     // subsequent RemoveStaged() and addUnchecked() calls don't guarantee
    805     // mempool consistency for us.
    806-    fReplacementTransaction = setConflicts.size();
    807-    if (fReplacementTransaction)
    808+    if (setConflicts.size())
    809     {
    


    MarcoFalke commented at 4:08 pm on July 23, 2021:

    nit: braces go on the same line

    0    if (setConflicts.size()) {
    

    darosior commented at 4:12 pm on July 23, 2021:
    Done.
  7. MarcoFalke commented at 4:10 pm on July 23, 2021: member
    Out of interest, did anyone collect stats on how many txs are replacements? Edit: see previous comment
  8. darosior force-pushed on Jul 23, 2021
  9. DrahtBot added the label Validation on Jul 23, 2021
  10. ghost commented at 4:34 pm on July 23, 2021: none

    Out of interest, did anyone collect stats on how many txs are replacements? Edit: see previous comment

    Although 0xb10c shared there are 2000-6000 replacement tx per day , I don’t think it matters for few reasons:

    1. Fee estimation is a meme IMO or maybe helps in UX for newbies. You cannot predict if a fee rate will confirm the transaction in next N blocks. Context: https://bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why/106129
    2. If fee estimates are used, they should be available for all type of transactions and not based on % of txs per day. Rationale in PR #9519 was not good enough to change something. Not sure about the ACKs in that PR.
    3. If any % still matters to document in PR, it should be RBF per day because if a user did transaction with RBF enabled, fee estimate may be required by replacement tx. Total transaction per day around 200k so 20% is 40k RBF transactions. We shouldn’t wait for usage or other node implementations/wallets to do better before doing things that make sense.
  11. 0xB10C commented at 4:41 pm on July 23, 2021: member

    Out of interest, did anyone collect stats on how many txs are replacements? Edit: see previous comment

    image

  12. in src/validation.cpp:903 in 4abe6aab79 outdated
    992@@ -998,11 +993,10 @@ bool MemPoolAccept::Finalize(const ATMPArgs& args, Workspace& ws)
    993     m_pool.RemoveStaged(allConflicting, false, MemPoolRemovalReason::REPLACED);
    994 
    995     // This transaction should only count for fee estimation if:
    996-    // - it isn't a BIP 125 replacement transaction (may not be widely supported)
    


    MarcoFalke commented at 6:48 am on July 24, 2021:
    One risk I could see is that someone running with a full-rbf patch might pay a higher fee now. So I am wondering if this needs to be re-introduced with a full-rbf patch?

    darosior commented at 3:04 pm on October 7, 2021:
    This can only increase the fees for anyone, but if it does it means that it was necessary (a higher feerate was needed in order to have this transaction go through). How could a full-rbf patch wrongly increase estimates?

    MarcoFalke commented at 11:47 am on October 8, 2021:

    High-fee non-miner-policy txs (In this case full-rbf’ed) might fill your mempool, but never get confirmed, thus raising your estimates.

    This is a general problem and I was just wondering if the patch should be re-introduced for full-rbf (or other similar policy changes in the future).


    darosior commented at 12:02 pm on October 8, 2021:

    Oh for people running it without knowing that some miners do as well.

    I think stopping (again) to consider replacement transactions would be a step backward. However it could make sense for a full-RBF patch to stop considering replacement to not-opted-in transactions for fee estimation until the full-RBF policy is reasonably deployed on the network. Since we only implement explicit signaling it sounds like the complexity of doing so would be reasonable.

  13. MarcoFalke removed the label Validation on Jul 24, 2021
  14. MarcoFalke added the label TX fees and policy on Jul 24, 2021
  15. MarcoFalke deleted a comment on Jul 25, 2021
  16. Rspigler commented at 11:57 pm on July 25, 2021: contributor
    Concept ACK, due to reasons stated in OP
  17. benthecarman approved
  18. benthecarman commented at 7:13 pm on July 26, 2021: contributor
    utACK 4abe6aab798fcb9d80228d4e49844b96690bfa2f
  19. darosior commented at 9:11 am on July 29, 2021: member
    For what it’s worth, I’ve been comparing running this on 2 pretty similar nodes for the past week. This didn’t affect estimates, it must be because we are currently in a pretty low fee period.
  20. tryphe approved
  21. tryphe commented at 4:46 am on July 30, 2021: contributor

    untested ACK 4abe6aab798fcb9d80228d4e49844b96690bfa2f (edited hash, sorry clipboard was bugged)

    Concept is simple and code changes are very straightforward (only one line is effectively changed).

  22. in src/validation.cpp:806 in 4abe6aab79 outdated
    802@@ -805,9 +803,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
    803     // If we don't hold the lock allConflicting might be incomplete; the
    804     // subsequent RemoveStaged() and addUnchecked() calls don't guarantee
    805     // mempool consistency for us.
    806-    fReplacementTransaction = setConflicts.size();
    807-    if (fReplacementTransaction)
    808-    {
    809+    if (setConflicts.size()) {
    


    theStack commented at 8:21 pm on July 30, 2021:

    nit: Not sure if we have this in the coding guidelines, but personally I’m not a fan of implicit int-to-bool casts. Could avoid it via e.g.

    0    if (setConflicts.size() > 0) {
    

    or

    0    if (!setConflicts.empty()) {
    
  23. theStack approved
  24. theStack commented at 8:23 pm on July 30, 2021: member
    Concept and code review ACK 4abe6aab798fcb9d80228d4e49844b96690bfa2f
  25. DrahtBot commented at 8:26 pm on August 10, 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:

    • #23075 (refactoring: Fee estimation functional test cleanups by darosior)
    • #22674 (validation: mempool validation and submission for packages of 1 child + parents 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.

  26. meshcollider added this to the "Chasing Concept ACK" column in a project

  27. josibake approved
  28. josibake commented at 1:30 pm on August 20, 2021: member

    utACK https://github.com/bitcoin/bitcoin/pull/22539/commits/4abe6aab798fcb9d80228d4e49844b96690bfa2f

    reading through #9519 , the general consensus seemed to be “this will be trivial to and should be reverted once RBF is widely adopted by miners.”

    i didn’t get the sense anyone was arguing to never include RBF in fee estimation, so given that RBF is widely adopted, this change makes sense.

  29. Zero-1729 approved
  30. Zero-1729 commented at 2:36 pm on August 20, 2021: contributor

    crACK 4abe6aab798fcb9d80228d4e49844b96690bfa2f

    Change makes sense given the wide adoption of RBF txs. Plus, as stated above, the original PR that excluded RBFs did state a potential revert in the future once there’s increased use in the wild (when widely adopted as “miner policy”).

    Note: I am leaning towards the code suggestion here, specifically if (setConflicts.size() > 0) {, to make the condition more explicit about the expected value of setConflicts.size() (as was similarly done here in the same file). It’s a non-blocking nit, so feel free to ignore.

  31. glozow commented at 12:20 pm on August 23, 2021: member

    code review ACK 4abe6aab798fcb9d80228d4e49844b96690bfa2f

    If we’re at the point where most of the network and miners support RBF, this makes our fee estimates more accurate. My concern correctness-wise was making sure that only the new transaction is considered in fee estimation (I don’t have much knowledge of CBlockPolicyEstimator). I’ve checked that when Finalize() calls RemoveStaged() which calls removeUnchecked() for each transaction, the mempool will call minerPolicyEstimator->removeTx() for the removed transactions.

  32. DrahtBot added the label Needs rebase on Aug 31, 2021
  33. darosior commented at 3:26 pm on August 31, 2021: member
    Rebased on master after #22796 merge and addressed @theStack ’s nit.
  34. darosior force-pushed on Aug 31, 2021
  35. DrahtBot removed the label Needs rebase on Aug 31, 2021
  36. theStack approved
  37. theStack commented at 6:51 pm on September 1, 2021: member

    re-ACK 5b29258076a3665100400768de8124be64eb4c6f 🌴

    Verified via git range-diff 4abe6aab...5b292580 that changes since my last ACK are only rebase-related, plus the slight improvement in the if condition (avoiding implicit int-to-bool cast).

  38. Zero-1729 approved
  39. Zero-1729 commented at 10:41 am on September 2, 2021: contributor
    re-ACK 5b29258 🧉
  40. fanquake commented at 6:45 am on September 10, 2021: member
    @darosior sorry for making you rebase again, but this change is more straightforward than some other PRs in that regard.
  41. DrahtBot added the label Needs rebase on Sep 10, 2021
  42. darosior force-pushed on Sep 15, 2021
  43. darosior commented at 11:18 am on September 15, 2021: member

    Rebased

    sorry for making you rebase again, but this change is more straightforward

    Sure

  44. DrahtBot removed the label Needs rebase on Sep 15, 2021
  45. glozow commented at 2:24 pm on September 16, 2021: member
    reACK fab8ce071566033316189283684340424cb2f7d0. Nice cleanup as well.
  46. theStack approved
  47. theStack commented at 2:30 pm on September 16, 2021: member

    re-ACK fab8ce071566033316189283684340424cb2f7d0

    Verified via git range-diff 5b292580...fab8ce07 that changes since my last ACK are only rebase-related.

  48. benthecarman approved
  49. benthecarman commented at 3:04 pm on September 16, 2021: contributor
    reACK fab8ce071566033316189283684340424cb2f7d0
  50. ghost commented at 3:23 pm on September 16, 2021: none

    ACK https://github.com/bitcoin/bitcoin/pull/22539/commits/fab8ce071566033316189283684340424cb2f7d0

    Although I still have the same opinion: #22539 (comment)

    Lets not restrict it for some transactions because of numbers.

  51. Zero-1729 approved
  52. Zero-1729 commented at 6:17 pm on September 16, 2021: contributor

    re-ACK fab8ce071566033316189283684340424cb2f7d0

    Clean rebase.

  53. DrahtBot added the label Needs rebase on Sep 23, 2021
  54. darosior force-pushed on Sep 24, 2021
  55. darosior commented at 1:48 pm on September 24, 2021: member

    Thanks everyone for following, please bear with me one more time :)

    Rebased on master to solve conflict, added a functional test demonstrating behaviour (similarly to #23074 ) and added release notes.

  56. DrahtBot removed the label Needs rebase on Sep 24, 2021
  57. darosior commented at 4:31 pm on September 24, 2021: member

    So i’ve been plotting the estimates at each block on both a node with this patch and one without. Here are the results for the past 3 days (still running)

    image

    Feerate is low at the moment so there is hardly any divergence. Data for generating this plot can be found here https://github.com/darosior/fee_estimation_hacks

  58. DrahtBot added the label Needs rebase on Sep 28, 2021
  59. Re-include RBF replacement txs in fee estimation
    This effectively reverts de1ae324bf3fb7451c1008a1a9721ff9f469533b.
    
    RBF is now largely in use on the network (signaled for by around 20% of
    all transactions on average) and replacement logic is implemented in
    most end-user wallets. The rate of replaced transactions is also
    expected to rise as fee-bumping techniques are being developed for
    pre-signed transaction ("L2") protocols.
    
    Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
    06c5ce9714
  60. qa: split run_test into smaller parts
    Let's not have run_test get into a giant function as we add more tests
    
    Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
    053415b297
  61. qa: test fee estimation with replacement transactions
    Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
    4556406562
  62. Add release notes for fee est with replacement txs
    Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
    3b613722f6
  63. darosior force-pushed on Sep 29, 2021
  64. darosior commented at 4:31 pm on September 29, 2021: member

    Rebased following conflict with #22722 .

    Here is the plot of the estimates with and without this patch for the past 8 days: image

  65. DrahtBot removed the label Needs rebase on Sep 29, 2021
  66. Zero-1729 commented at 7:05 am on September 30, 2021: contributor
    re-ACK 3b613722f6b895d7b268b3f878fddfc888381226
  67. in test/functional/feature_fee_estimation.py:171 in 3b613722f6
    166+    tx = CTransaction()
    167+    tx.vin = [CTxIn(COutPoint(int(utxo["txid"], 16), utxo["vout"]), SCRIPT_SIG[utxo["vout"]])]
    168+    tx.vout = [CTxOut(int(utxo["amount"] * COIN) - fee, P2SH_1)]
    169+    txid = node.sendrawtransaction(tx.serialize().hex())
    170+
    171+    return txid
    


    glozow commented at 1:40 pm on September 30, 2021:

    In 4556406562:

    A nice followup could be to use MiniWallet and get rid of feature_fee_estimation.py’s dependency on wallet in general? send_self_transfer allows specifying the utxo to spend and the feerate; you wouldn’t have to do these size calculations.


    darosior commented at 3:21 pm on September 30, 2021:
    Yeah i could do that in #23075 once this one is merged :)

    glozow commented at 3:29 pm on September 30, 2021:
    Ah I hadn’t seen that - great!
  68. benthecarman approved
  69. benthecarman commented at 2:06 pm on September 30, 2021: contributor
    reACK 3b613722f6b895d7b268b3f878fddfc888381226
  70. in test/functional/feature_fee_estimation.py:319 in 3b613722f6
    316+                txid = send_tx(node, u, low_feerate)
    317+                utxos_to_respend.append(u)
    318+                txids_to_replace.append(txid)
    319+            # Broadcast 5 low fee transaction which don't need to
    320+            for _ in range(5):
    321+                send_tx(node, utxos.pop(0), low_feerate)
    


    glozow commented at 2:44 pm on September 30, 2021:

    I’m a little confused about why there needs to be 10% of the transactions confirming with low feerate? Why can’t the test be:

    • broadcast low fee transactions, don’t let any of them confirm
    • RBF the low fee transactions with high fee ones, confirm them
    • assert that fee estimate only returns higher feerate

    (edit: ended up just writing it https://github.com/glozow/bitcoin/commit/10b89fc4bc8408a6b9341ff98fb910128f60ee6b)


    darosior commented at 3:23 pm on September 30, 2021:

    I’m a little confused about why there needs to be 10% of the transactions confirming with low feerate?

    There does not need to, i just wanted to simulate a more realistic scenario than just triggering the specific behaviour.

  71. in test/functional/feature_fee_estimation.py:324 in 3b613722f6
    321+                send_tx(node, utxos.pop(0), low_feerate)
    322+            # Mine the transactions on another node
    323+            self.sync_mempools(wait=.1, nodes=[node, miner])
    324+            for txid in txids_to_replace:
    325+                miner.prioritisetransaction(txid=txid, fee_delta=-COIN)
    326+            self.generate(miner, 1)
    


    glozow commented at 2:58 pm on September 30, 2021:
    This mines the replacement transactions from a previous iteration of the loop - is that intentional?

    darosior commented at 3:25 pm on September 30, 2021:
    Yes it is. The point is to simulate a somewhat real life scenario “broadcast a low fee tx, it does not confirm, it gets RBF’d, the replacement gets confirmed”. You would not RBF before a single block was mined

    glozow commented at 3:38 pm on September 30, 2021:
    ah ok, putting it that way makes sense
  72. in doc/release-notes-22539.md:7 in 3b613722f6
    0@@ -0,0 +1,8 @@
    1+Notable changes
    2+===============
    3+
    4+P2P and network changes
    5+-----------------------
    6+
    7+- Fee estimation now takes the feerate of replacement (RBF) transactions into
    


    glozow commented at 3:03 pm on September 30, 2021:
    I have a question about the desired behavior because it’s a subtle thing that isn’t mentioned here: with this PR, if a transaction is RBF’ed in our mempool, we add the replacement transaction and remove the original transaction(s) from the fee estimator. If the original transactions end up being mined in a block anyway (e.g. a miner had already started working on it before the replacement transaction was accepted), we lose that data in fee estimation. Is this what we want? If yes, maybe document?

    darosior commented at 3:30 pm on September 30, 2021:

    Is this what we want?

    Yes, because there is nothing we can do about that. And such a race sounds to be very improbable.. (are there still mining pools refusing RBFs for whatever reason?)

    If yes, maybe document?

    This is not a change in behaviour, i don’t think it should be in the changelog. Before this patch if you accept a replacement transaction in your mempool but the original tx ends up being mined you would lose the data anyways.


    glozow commented at 9:55 am on October 1, 2021:
    Ah you’re right, we’re already removing the original transactions. My mistake!
  73. glozow commented at 3:10 pm on September 30, 2021: member

    Thanks for adding a test! Sorry it’s taken me some time to review - also ended up with an additional question.

    Other possible test extensions:

    • check that children of the original transactions aren’t included in fee estimation (all evicted)
    • transaction is RBF’ed in our mempool, but the original transaction is included in a block
    • same-txid-different-witness transaction i.e. different feerate is included in a block
  74. darosior commented at 3:31 pm on September 30, 2021: member

    transaction is RBF’ed in our mempool, but the original transaction is included in a block

    That’s a very good point. I think with this patch we would keep the replacement tx in the buckets until it expires..

  75. glozow commented at 3:36 pm on September 30, 2021: member

    I think with this patch we would keep the replacement tx in the buckets until it expires..

    Actually, I think it would be removed here when removeForBlock() calls removeConflicts here since it’s conflicted out of the mempool. So that’s fine, we’d just lose a data point.

    I ask because in some cases we keep the original transaction (e.g. we’ll put it in vExtraTxnForCompact for reconstructing compact blocks), so I wondered if that’s something we want here.

  76. glozow commented at 10:01 am on October 1, 2021: member

    ACK 3b613722f6b895d7b268b3f878fddfc888381226

    Thanks for patiently answering my questions! Verified that 053415b297b8665f2d2c4dce7c2c54bcc5298ef4 is move-only, and the added functional test looks correct to me. Will take my test improvement-related comments to #23075.

  77. darosior commented at 10:06 am on October 1, 2021: member

    Actually, I think it would be removed here when removeForBlock() calls removeConflicts here since it’s conflicted out of the mempool. So that’s fine, we’d just lose a data point.

    So at first i did not think it was fine. We in this case call removeTx with inBlock set to false, ie counting this removal as a failure to confirm. This could have led to wrecked estimations because we would count a higher fee tx as failed.

    But actually, we’d only count it as a failure if it didn’t confirm for at least 12 blocks (for short stats, 24 and 42 for med and long). It’s plenty of time for the replacement to have propagated and makes this type of race so unlikely that i think it’s fine.

    Thank you for raising this point!

  78. darosior commented at 10:12 am on October 1, 2021: member
    @tryphe @theStack @josibake do you mind re-[reviewing-and-]ACKing? I think we are getting close to merge and no other conflicting PR reported by Drahbot seem closer to merge.
  79. in test/functional/feature_fee_estimation.py:168 in 4556406562 outdated
    163+    tx_size = overhead + op + scriptsig + nseq + value + spk
    164+    fee = tx_size * feerate
    165+
    166+    tx = CTransaction()
    167+    tx.vin = [CTxIn(COutPoint(int(utxo["txid"], 16), utxo["vout"]), SCRIPT_SIG[utxo["vout"]])]
    168+    tx.vout = [CTxOut(int(utxo["amount"] * COIN) - fee, P2SH_1)]
    


    theStack commented at 6:22 pm on October 2, 2021:

    To avoid manual tx size calculation with magic numbers, you could simply create the CTransaction first (without the fee), determine tx size via len(tx.serialize()) and then subtract the fee.

    0    tx = CTransaction()
    1    tx.vin = [CTxIn(COutPoint(int(utxo["txid"], 16), utxo["vout"]), SCRIPT_SIG[utxo["vout"]])]
    2    tx.vout = [CTxOut(int(utxo["amount"] * COIN), P2SH_1)]
    3    fee = len(tx.serialize()) * feerate
    4    tx.vout[0].nValue -= fee
    

    darosior commented at 10:33 pm on October 3, 2021:
    Oh right since we use legacy txs in this test it’s indeed much cleaner. However i’d like to not invalidate 4 ACKs on a cosmetic change. Do you mind if i make it a follow-up in #23075 ?
  80. in test/functional/feature_fee_estimation.py:332 in 4556406562 outdated
    327+            while True:
    328+                try:
    329+                    u = utxos_to_respend.pop(0)
    330+                    send_tx(node, u, high_feerate)
    331+                except IndexError:
    332+                    break
    


    theStack commented at 6:29 pm on October 2, 2021:

    Might be a bit shorter and more pythonic without exception:

    0            while utxos_to_respond:
    1                u = utxos_to_respend.pop(0)
    2                send_tx(node, u, high_feerate)
    

    darosior commented at 10:35 pm on October 3, 2021:
    Indeed :man_facepalming: but same rationale as above, as ugly as it is i’d rather address it in #23075
  81. theStack approved
  82. theStack commented at 10:18 pm on October 4, 2021: member

    re-ACK 3b613722f6b895d7b268b3f878fddfc888381226 🍪

    Verified that since my last ACK a rebase was done and a test was added which LGTM. Being extra-paranoid, I also checked that the test fails on the master branch on the estimated fee assertion at the end of sanity_check_rbf_estimates. @darosior: I agree that the proposed fixups can be done in a follow-up, was not intending to block a merge (I kind of missed reading previous comments about fixups and PR #23075 that is already prepared for that purpose). BTW I also support the idea of using MiniWallet for creating txs, as suggested by gloria.

  83. laanwj merged this on Oct 7, 2021
  84. laanwj closed this on Oct 7, 2021

  85. sidhujag referenced this in commit e7b32fae51 on Oct 7, 2021
  86. laanwj removed this from the "Chasing Concept ACK" column in a project

  87. in doc/release-notes-22539.md:4 in 3b613722f6
    0@@ -0,0 +1,8 @@
    1+Notable changes
    2+===============
    3+
    4+P2P and network changes
    


    MarcoFalke commented at 12:12 pm on October 8, 2021:

    Is this something that should be mentioned in the release notes at all? Given that less than 25% of txs are opt-in-rbf and way less than that are conflicts, this shouldn’t have any significant effect on real-world fee estimation. See also your findings: #22539 (comment)

    Also, it doesn’t change the P2P protocol or is a network change. At most it would affect your local estimates, so if the notes are kept, the section headline could be adjusted.


    darosior commented at 12:23 pm on October 8, 2021:

    See also your findings: #22539 (comment)

    I expect this to be very different with a not so low fee market (replacement-aware fee estimation to constantly be slightly higher).

    the section headline could be adjusted

    Sure, what do you suggest? To be honest i was not sure what headline to use and since fee estimation is ubiquitous i figured it was a notable change, but happy to change it.


    MarcoFalke commented at 12:34 pm on October 8, 2021:
    This will show up in the section “Policy” (example: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-22.0.md#policy), but I think we never had a “notable change” policy section. Maybe “Fee estimation changes”?

    darosior commented at 9:09 am on October 15, 2021:
  88. darosior referenced this in commit 9dda5b3888 on Oct 15, 2021
  89. darosior referenced this in commit 424f49c3c0 on Oct 15, 2021
  90. darosior referenced this in commit 530735153b on Oct 15, 2021
  91. darosior deleted the branch on Oct 15, 2021
  92. darosior commented at 12:19 pm on October 15, 2021: member
    For what it’s worth here is again another diagram for last ~2 wee 702743_705101 ks
  93. MarcoFalke referenced this in commit ce19f4fd37 on Oct 15, 2021
  94. sidhujag referenced this in commit 4776a8d367 on Oct 15, 2021
  95. glozow referenced this in commit ad1b504176 on Oct 28, 2021
  96. glozow referenced this in commit 9defde8a1e on Oct 28, 2021
  97. glozow referenced this in commit 8fa2936b34 on Oct 28, 2021
  98. janus referenced this in commit 0c5335e90e on Nov 11, 2021
  99. darosior referenced this in commit 0314ae8e0a on Nov 15, 2021
  100. darosior referenced this in commit 7ccd775dcc on Dec 9, 2021
  101. darosior referenced this in commit e50213967b on Dec 9, 2021
  102. MarcoFalke referenced this in commit 799fd7a488 on Jan 6, 2022
  103. mzumsande referenced this in commit 1d0d89ddf0 on Jan 17, 2022
  104. rebroad referenced this in commit 748f37dc5c on Feb 3, 2022
  105. DrahtBot locked this on Oct 30, 2022

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-10-08 07:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me