policy: enable full-rbf by default #30493

pull 1440000bytes wants to merge 2 commits into bitcoin:master from 1440000bytes:2023-07-enable-full-rbf changing 6 files +15 −4
  1. 1440000bytes commented at 5:24 am on July 20, 2024: none

    This pull request enables full rbf (mempool policy) by default. #28132 was closed recently with this comment.


    Rationale:

  2. DrahtBot commented at 5:24 am on July 20, 2024: contributor

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

    Code Coverage

    For detailed information about the code coverage, see the test coverage report.

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK instagibbs, petertodd, glozow, ariard, murchandamus, achow101
    Concept ACK reardencode, 0xB10C

    If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #28676 ([WIP] Cluster mempool implementation by sdaftuar)

    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.

  3. DrahtBot added the label TX fees and policy on Jul 20, 2024
  4. BitcoinErrorLog commented at 8:37 am on July 20, 2024: none
    mempoolfullrbf should be removed, and RBF is a redundant unenforceable feature. If we believe miners only care about the the largest fee/rate then simply providing them with all txns is good enough. Miners can choose how to sort themselves.
  5. reardencode commented at 1:52 pm on July 20, 2024: none
    ACK
  6. 1440000bytes commented at 6:31 pm on July 22, 2024: none

    Thanks @reardencode for the review and ACK as its obvious full-rbf should be default. There is some politics involved in it which I wanted to highlight:


    image

    I don’t know the reason for deleting this comments and others who reacted with emojis, however it will be better for bitcoin if we can get some ACKs to merge it. I did not mention the vulnerability in rationale because other things are sufficient to make it default.

    This also affects coinjoin and I am working on joinstr so less politics would help bitcoin core and everyone involved in bitcoin.

  7. murchandamus commented at 6:40 pm on July 22, 2024: contributor

    Concept ACK

    Given the majority of the hashrate using mempoolfullrbf, Bitcoin Core should adapt its default behavior to match its expectations to the blocks being published.

  8. in doc/release-notes-28132.md:1 in fbdc61ed54 outdated
    0@@ -0,0 +1,5 @@
    1+Full Replace-By-Fee
    


    murchandamus commented at 6:41 pm on July 22, 2024:
    This file is named incorrectly.

    1440000bytes commented at 7:05 pm on July 22, 2024:
    I can rename it if one of the maintainers can review this pull request because I cannot assign a version that would include this PR.

    achow101 commented at 9:20 pm on July 22, 2024:
    Release note fragments should have the PR number in them, and this is PR 30493, not 28132. The release version is not relevant for release note fragments.
  9. tdb3 commented at 8:02 pm on July 22, 2024: contributor

    Thanks @reardencode for the review and ACK as its obvious full-rbf should be default. There is some politics involved in it which I wanted to highlight:

    Sorry for the confusion. To clarify, I had deleted my own comment. I wanted to think a bit more about it before commenting again.

  10. 1440000bytes commented at 8:14 pm on July 22, 2024: none

    Thanks @reardencode for the review and ACK as its obvious full-rbf should be default. There is some politics involved in it which I wanted to highlight:

    Sorry for the confusion. To clarify, I had deleted my own comment. I wanted to think a bit more about it before commenting again.

    1. What did you think when you commented “Concept ACK”?
    2. Why did you delete it?
    3. What do you think about this pull request now?

    Its okay, if you refuse to answer something and not forced to do it.

  11. pinheadmz commented at 9:06 pm on July 22, 2024: member
    @1440000bytes hello from your friendly neighborhood moderator. This is just a reminder to keep all discussions technical. Pull request comments should be focused on the code in question. Discussions about personal opinions, moderator or maintainer actions (including responses to this comment) can be opened here
  12. 1440000bytes commented at 9:12 pm on July 22, 2024: none

    @1440000bytes hello from your friendly neighborhood moderator. This is just a reminder to keep all discussions technical. Pull request comments should be focused on the code in question. Discussions about personal opinions, moderator or maintainer actions (including responses to this comment) can be opened here

    Code in question:

    0-static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{false};
    1+static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{true};
    

    Issue related to this pull request is already open here: https://github.com/bitcoin-core/meta/issues/5

    I am free to respond to reviewers and ask them a few questions which they can even refuse to answer.

  13. 1440000bytes force-pushed on Jul 22, 2024
  14. ariard commented at 9:28 pm on July 26, 2024: contributor

    @1440000bytes hello from your friendly neighborhood moderator. This is just a reminder to keep all discussions technical. > Pull request comments should be focused on the code in question. Discussions about personal opinions, moderator or maintainer actions (including responses to this comment) can be opened [here](https://github.com/bitcoin core/meta/issues) @pinheadmz you or another moderator still has not reply on the meta-comment I made on the moderation rules available here. I understand you can be in a situation of conflict of interest as the example I’m giving to you is related to your current employer to comment so and take a position.

    As such from someone who is a code contributor and regular reviewer to this github repository, this is hard to think that moderation can be followed of good faith, when “discussions about personal opinions, moderator or maintainer actions” are not addressed after 2 months of having being mentioned.

  15. ariard commented at 9:56 pm on July 26, 2024: contributor

    Concept ACK.

    For the same vector of DoS attack about contracting protocols and multi-party explained in my post on the mailing list in 2021 (“Mempool Funny Games against Multi-Party Funded Transactions).

    I believe one of the best long-term solution to avoid new use-case conflict (in the present “0 conf tx acceptance versus multi-party built transaction like coinjoin”) is to minimize the scope of the transaction-relay policy in the bitcoin core codebase, while this cannot be always followed when it’s mitigating a DoS vector (e.g MIN_STANDARD_TX_NONWITNESS_SIZE). I made such more or less experiment to have this approach of having transaction-relay policy rules signaled among transaction issuers and miners with #29448 and similarly transaction-flags user-defined has been discussed on the mailing list here.

    Historically, there has been some attempt to have the policy rules validated in an external module with a set of patch proposed by jtimon (e.g see 6416, 6420, 6424 and other PRs around the same period). See e.g https://github.com/jtimon/bitcoin/commits/policy-replacement-alt for example of abstractions for “alternative replacement policies”.

  16. ariard commented at 8:09 pm on July 28, 2024: contributor
    For my comments that was marked as off-topic by @pinheadmz, I invite a more wider group of regular bitcoin core contributors to express opinion on the issue, as pineheadmz as a matter t stake in marking as off-topic my comment so his moderation cannot be considered as objectively neutral. The issue is here: https://github.com/bitcoin-core/meta/issues/3 (edit: mistyped the github login of Matthew Zipkin at first).
  17. ariard commented at 8:51 pm on July 28, 2024: contributor

    About the ongoing issue on moderation, I did a cryptographic timestamp of this github HTML page in the bitcoin blockchain, if this needs to be discussed on another public communication channel.

    Maintainers or moderators can for sure mark as off-topic comments on the github repository, though they do no have the proof-of-work to reorganize the mainchain (edited).

  18. gmaxwell commented at 4:31 pm on July 31, 2024: contributor

    FWIW, I had some friends running nodes either do nothing or turn this on. In the last 144 blocks, a default node sees only 64.58% blocks reconstructed with zero round trips which, in my view, means compact blocks is significantly broken for its latency reducing purpose. A node with this enabled sees 94.44% reconstruct without a roundtrip, which is maybe a little low but not broken.

    I imagine that if more of the network were running enabled that number might increase further, as it may still be held down due to transactions that fail to propagate well (consistent with that, it seems most nodes with no inbound have low rates regardless of the setting, which presumably wouldn’t be so if most nodes had this setting).

    I shared my concerns with another bitcoiner who likes to monitor network health, they replicated, and got similar results (which I presume they’ll share eventually).

  19. JeremyRubin commented at 7:19 pm on July 31, 2024: contributor
    concept ack given the above data from @gmaxwell.
  20. in test/functional/feature_rbf.py:38 in c57a4a8573 outdated
    33                 "-limitancestorcount=50",
    34                 "-limitancestorsize=101",
    35                 "-limitdescendantcount=200",
    36                 "-limitdescendantsize=101",
    37             ],
    38             # second node has default mempool parameters
    


    murchandamus commented at 9:02 pm on July 31, 2024:

    This comment is outdated:

    0            # second node has default mempool parameters, besides mempoolfullrbf being disabled
    

  21. murchandamus commented at 9:05 pm on July 31, 2024: contributor

    ACK 406cdd56e1065fe721f62a0c52fa024455748bbb

    I reviewed the code and replicated the test changes to confirm that these are the minimal changes to pass all tests.

  22. DrahtBot requested review from ariard on Jul 31, 2024
  23. luke-jr commented at 10:51 pm on July 31, 2024: member

    If we believe miners only care about the the largest fee/rate then simply providing them with all txns is good enough.

    That would be a reason to support this PR, as full-RBF simply provides miners with all txns. Without full RBF enabled by relays, miners would typically only see the “first” transaction.

    FWIW, I had some friends running nodes either do nothing or turn this on. In the last 144 blocks, a default node sees only 64.58% blocks reconstructed with zero round trips which, in my view, means compact blocks is significantly broken for its latency reducing purpose. A node with this enabled sees 94.44% reconstruct without a roundtrip, which is maybe a little low but not broken.

    This behaviour was originally intended to put pressure on miners to match node policies; it’s not supposed to be an excuse to pressure nodes to adapt to miner policies.

    (Personally, I’m ~0 on whether this actually gets merged or not; Knots has had full RBF by default for years, and “first seen” doesn’t really make sense as a policy)

  24. gmaxwell commented at 0:08 am on August 1, 2024: contributor

    @luke-jr I don’t know that I’d say ‘intended’, particularly since poor propagation either helps or hurts miners depend on their hashrate– it benefits sufficiently large centralized miners when other miners take more time to get their blocks– but regardless of intent it works the way it works.

    I would say that to the extent someone is ambivalent with respect to the policy, as you just expressed, it’s preferable to improve block propagation latency since higher latency is a centralization pressure. The existence of the extrapool is intended to decouple policy from block propagation– allowing nodes to keep around some txn they wouldn’t prefer to mine/relay for the benefit of reconstructing blocks, but it only goes so far.

    Ultimately it would be best if block relay latency were less fragile– methods have been implemented (the FEC reconstruction of fibre, for example) but never incorporated in widely deployed node software. And even those work particularly well if only a few transactions are missing relative to the node’s mempool and extrapool. So even if more robust block relay was in use, it’s preferable to do whatever lowers the discrepancy, all other things equal (and they’re not always equal, for sure).

  25. luke-jr commented at 1:05 am on August 1, 2024: member
    I say “intended” because policy centralization was a concern I had and raised about compact blocks before they were merged, and @sipa explicitly justified CB’s behaviour in this regard as a way for nodes to exert influence on miners in this respect.
  26. 1440000bytes force-pushed on Aug 1, 2024
  27. 0xB10C commented at 3:18 pm on August 1, 2024: contributor

    I shared my concerns with another bitcoiner who likes to monitor network health, they replicated, and got similar results (which I presume they’ll share eventually).

    Correct, I too found enabling mempoolfullrbf to be helpful for compact block reconstruction without requesting transactions.

    By analyzing compact block reconstructions in the debug.logs (with debug=cmpctblock enabled) of my monitoring nodes, I noticed that many block reconstructions need an additional round-trip to fetch unknown transactions. While this situation has slightly improved over the last weeks (~50% -> 70+%) as mempool activity died down, this still clearly shows a divergence in policy.

    I suspected that the divergence might originate from nearly all pools mining with mempoolfullrbf. I enabled -mempoolfullrbf=1 on the monitoring node/host erin on 2024-07-26. Since then, this node needed request transactions during significantly fewer blocks reconstructions than the other nodes.

    Concept ACK

    image (note that while 75% or so might show up as light green here, doesn’t necessarily mean that 75% is “good”. Ideally, we want this to be close to 100% of blocks reconstructions needing no transaction requests)

  28. in doc/release-notes-30493.md:4 in a2ae0ab768 outdated
    0@@ -0,0 +1,5 @@
    1+Full Replace-By-Fee
    2+===================
    3+
    4+`mempoolfullrbf=1` is now set by default, which matches the policies of the
    


    instagibbs commented at 3:31 pm on August 1, 2024:

    non-blocking nit

    0`mempoolfullrbf=1` is now set by default, which seems to match the policies of the
    
  29. in test/functional/p2p_permissions.py:33 in fbd4ca6ea9 outdated
    29@@ -30,7 +30,7 @@ def run_test(self):
    30         self.check_tx_relay()
    31 
    32         self.checkpermission(
    33-            # default permissions (no specific permissions)
    


    instagibbs commented at 4:44 pm on August 1, 2024:
    non-blocking, but you could do something like this instead, since this test doesn’t really need to test rbf signaling: https://github.com/instagibbs/bitcoin/commit/a9ebb28d49769ca0f8696d32364ef1c218dc1c8c

    glozow commented at 4:14 pm on August 2, 2024:
    Agree. That patch would need some comment cleanup as well^
  30. instagibbs approved
  31. instagibbs commented at 4:47 pm on August 1, 2024: member

    ACK fbd4ca6ea9a3d2f6fe0af3cb5dfe8e1a7fdb4032

    Given the weight of evidence on block propagation and the implied miner uptake, I think it’s a conservative flip of the switch.

  32. DrahtBot requested review from 0xB10C on Aug 1, 2024
  33. DrahtBot requested review from murchandamus on Aug 1, 2024
  34. fanquake commented at 5:47 pm on August 1, 2024: member

    If the conclusion is that it’s now better for a node to have this “on”, rather than “off”, and this is merged for 28.x, then I think we should also:

    • Backport the default change to the relevant release branches.
    • Ultimately just remove the option (doesn’t have to be done here).
  35. murchandamus commented at 6:32 pm on August 1, 2024: contributor

    If the conclusion is that it’s now better for a node to have this “on”, rather than “off”, and this is merged for 28.x, then I think we should also:

    * Backport the default change to the relevant release branches.
    * Ultimately just remove the option (doesn't have to be done here).
    

    We should probably wait with the removal for a bit, but then we could also stop signaling replaceability by default to get rid of a fingerprint.

  36. ariard commented at 2:24 am on August 2, 2024: contributor

    Reposting the analysis of the full-rbf change on other mempools mechanism, the earlier branch opened by Peter Todd.


    On analyzing tangential mempool behaviors hypothetically affected by setting mempoolfullrbf=1 by default:

    (a) Wtxid: nsequence signaling is encompassed both in txid and wtxid. After this change and assuming reboot a local mempool can re-accept a bip125 opt-out transaction previously rejected as identical non-witness data might not have change, yet the wtxid being different.

    (b) Mempool.dat / persistence: the dump of mempool transaction. Dump of transactions are expected to be altered with mempoolfulrbf=1 as bip125 opt-out transactions are expected to be accepted with this change.

    (c) Datacarrier: one op_return data carrying output. The data carriage is implemented in the scriptpubkey while the signaling rbf mechanism is implemented in one of the input. There is no effect expected on data carriage mempool acceptance, unless very exotic usage of sighash malleability, where the txid can be altered yet the hash of the op_return scriptpubkey stays identical.

    (d) Dust: the dust satoshi threshold. The dust check is implemented on the output amounts while the signaling rbf mechanism is implemeted in one of the input. There is no effect expected on data carriage mempool acceptance, unless very exotic usage of sighash malleability, where the txid can be altered yet the hash of one of the output amount under the dust threshold stays identical.

    (e) Mempool expiry: by default after 14 days transactions are sorted out. Transactions accepted under mempoolfullrbf=0 and still in the mempool until reaching expiration could be replaced by an opt-out transactions. I think this a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.

    (f) Mempool limits / RBF carve-out. When mempool limits are reached out (25 descendants), there is an exemption to get one more child to be connected on the parent. As bip125 inheritance is not implemented in core, the one more opt-out child could be re-accepted in the mempool. I think this is a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.

    (g) Package initial acceptance / RBF. In-mempool packages are submitted to descendants and ancestors limits. As bip125 inheritance is not implemented in core, a subset of child could be re-accepted in the mempool. I think this is a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.

    (h) Mempool Reorg. Signaling mechanism is implemented on the nSequence field. In case of chain reorgs, the pool of disconnected transactions can be re-added in mempool. There is no effect expected on disconnected transactions re-acceptance.

    (i) Mempool sigops limits. Script sig ops limits are evaluated on the scriptSig / witness spend. This mempool limit check only happens once a transaction is good for acceptance and scripts have to be validated. An opt-out transaction can be accepted for the same sig ops budget, I think this a transient genuine risk of opportunistic full-node ressource consumption during the deployment of mempoolfullrbf=1 as a default.

    (j). Mempool unbroadcast. Transaction delivery is ensured by re-broadcasting transactions until a GETDATA is received. After this change and assuming reboot a local mempool can re-accept a bip125 opt-out transaction previously rejected and keep re-announcing this transaction to non-upgraded peers, provoking a free transaction relay bandwidth. I think this a transient minor risk of bandwidth ressource denial-of-service during the deployment of mempoolfullrbf=1 as a default.


    On backporting on earlier versions than 28.0, I don’t know if it is the best approach as you might have temporary double-spend risks in function of how the user is using upgraded bitcoin core software, e.g if the bitcoind process is reboot and there are transactions re-broadcast.

    On removing the mempoolfullrbf option definitively, I don’t think this is as easy as you have new use-cases like lightning with channel negotiation options like option_zeroconf to get fast liquidity allocated without waiting for 1st confirmation. It is for sure less safe than waiting for 3 or 6 chain confirmations, however in practice it is contributing to preserve the “instant payment” property of lightning with a low-rate of routing failure.

  37. ariard commented at 3:43 am on August 2, 2024: contributor

    I would say that to the extent someone is ambivalent with respect to the policy, as you just expressed, it’s preferable to improve block propagation latency since higher latency is a centralization pressure. The existence of the extrapool is intended to decouple policy from block propagation– allowing nodes to keep around some txn they wouldn’t prefer to mine/relay for the benefit of reconstructing blocks, but it only goes so far.

    I say “intended” because policy centralization was a concern I had and raised about compact blocks before they were merged, and @sipa explicitly justified CB’s behaviour in this regard as a way for nodes to exert influence on miners in this respect.

    Originally, when all the economical pinning issues affecting lightning were found I advocated on the mailing list for more homogeneity in transaction-relay policy among the network of nodes (cf. “Advances in Bitcoin Contracting: Uniform Policy and Package Relay”). Similarly when it was found that bitcoin core didn’t implement bip125 inheritance correctly. For the lightning world, non-propagating transactions due to the usage of timelock is jeopardizing channel funds which is a more severe security risk than non-propagating transactions for simple wallet payment.

    Non-propagating transaction is also a denial-of-service risk for usecases like asymmetric peg side-chains where you have consensus failure among validators and the timelock fallback script path have to be used on the chain.

    With the experience of mempoolfullrbf deployment and all the conversations that happens on the mailing list (cf. “On mempool consistency”), I think it turns out there was no common transaction-relay policy that will satisfy equally all the use-cases of that day (lightning, old school payment channel, coin-join, 0-conf acceptance by merchants).

    Personally, I think it will be better to have transaction-relay policy mechanism in its own module, moving away from this notion of a consistent transaction-relay policy on the network. Policy asymmetries among transaction-relay nodes are more likely to provide a vector of exploitation at block validation, especially if the bip152 extrapool differs too much.

    In a post-subsidy world, where we have use-cases driven by different consensus-validated timelock duration or service-level-agreement on unix-epoch measured quality of service, I think it is better to let use-cases signal with their on-chain fees traffic what is the most convenient transaction-relay policy for them.

    In the lack of better heuristics in matters of transaction-relay policy design and deployment, I think it’s better to have the transaction-relay policy default to be harmonized with what can be measured to be run by the majority of miners to keep block propagation latency low, since it’s a centralization vector (and assuming it’s not at odds with the economic majority of on-chain fee paying users or long-term coins holders).

    I don’t have a non-invasive measurement methodology of miners mempools settings to observe if mempoolfullrbf=1 is widely adopted by a majority of miners, which is non-redundant with the methodology of petertodd (which sounds to be based on OTS transactions fee-bumping) or 0xB10C and gmaxwell ones on compact block reconstruction success rate.

  38. petertodd commented at 8:22 am on August 2, 2024: contributor

    ACK 590456e3f1043ba0680e0afec9fd7653db1098bb

    (including all the slight modifications made since I wrote it)

  39. in doc/release-notes-30493.md:5 in a2ae0ab768 outdated
    0@@ -0,0 +1,5 @@
    1+Full Replace-By-Fee
    2+===================
    3+
    4+`mempoolfullrbf=1` is now set by default, which matches the policies of the
    5+supermajority of hash power.
    


    glozow commented at 4:12 pm on August 2, 2024:

    Or just

    0`mempoolfullrbf=1` is now set by default.
    
  40. glozow commented at 4:23 pm on August 2, 2024: member

    Concept ACK fbd4ca6ea9a3d2f6fe0af3cb5dfe8e1a7fdb4032, default options shouldn’t cause significantly reduced block relay efficiency. Frequently rejecting transactions that are likely to confirm makes the node much less useful wrt fee estimation, being aware of payments, etc. Agree that it also wouldn’t make sense to have the option if it’s just a footgun.

    I’ve also been collecting data on -mempoolfullrbf={0,1} nodes and also observed

    • Seemingly very high miner uptake. Analyzing blocks with a substantial number of full RBFs in them (5-10 or more), during times when mempool evictions aren’t pushing a bunch of txns out, I’ve seen quite a few such blocks mined by Foundry, Binance, ViaBTC, F2Pool, AntPool, Luxor, MARA, Poolin, Braiins, SECPOOL, BTC.com. This is consistent with #28132#issue-1817178316. (Fwiw, I think the initial post potentially had a lot of false positives, but AFAICT it is accurate now).
    • My mempoolfullrbf=0 node rejects quite a few non-signaling but otherwise valid replacements that later confirm (I see ~26% confirm but have heard others report higher). I didn’t measure compact block reconstruction specifically, but missing ~400-500 txns per day (which may or may not still be in vExtraTxnForCompact) seems consistent with #30493 (comment).
    • Recent full RBF experiments (if I broadcast non-signaling transactions, and then replacements, do the replacements confirm?) seem to have a high success rate (past experiments in 2022, 2023, were less successful). I did a few replacements myself, and also observed propagation of another person’s.

    Happy to reACK if you take the suggestions, or can do followup.

  41. doc: add release notes for full-rbf 195e98ea8e
  42. policy: enable full-rbf by default
    Enable full rbf (mempool policy) by default and update tests accordingly.
    590456e3f1
  43. 1440000bytes force-pushed on Aug 2, 2024
  44. 1440000bytes commented at 8:31 pm on August 2, 2024: none
  45. DrahtBot requested review from murchandamus on Aug 2, 2024
  46. DrahtBot requested review from glozow on Aug 2, 2024
  47. glozow commented at 7:10 pm on August 3, 2024: member
    reACK 590456e3f1043ba0680e0afec9fd7653db1098bb
  48. ariard commented at 2:51 am on August 5, 2024: contributor
    tested ACK 590456e3
  49. achow101 added this to the milestone 29.0 on Aug 5, 2024
  50. achow101 removed this from the milestone 29.0 on Aug 5, 2024
  51. achow101 added this to the milestone 28.0 on Aug 5, 2024
  52. murchandamus commented at 5:49 pm on August 5, 2024: contributor
    reACK 590456e3f1043ba0680e0afec9fd7653db1098bb
  53. achow101 commented at 7:52 pm on August 5, 2024: member

    ACK 590456e3f1043ba0680e0afec9fd7653db1098bb

    I did my own testing a few weeks ago where I made transactions that did not signal and replaced them to see how many were mined. The methodology was to create a transaction and replace it after 2 minutes. A total of 122 transactions were created, with 118 of the replacements being accepted. This took place on July 10th to 11th over the course of about 30 hours. With a 96.7% success rate, I think that’s pretty good evidence that miners have enabled mempoolfullrbf.

    This gist contains the script that I used as well as a log of all of the transactions that were created.

  54. DrahtBot requested review from achow101 on Aug 5, 2024
  55. achow101 merged this on Aug 5, 2024
  56. achow101 closed this on Aug 5, 2024

  57. jaybny commented at 11:38 pm on August 5, 2024: none

    Concept NACK: Opposition to Full-RBF by Default Without Broad Consensus I have several critical concerns regarding the default implementation of Full Replace-By-Fee (RBF):

    1. Deviation from the First-Seen Rule: Bitcoin’s game theory initially hinged on the “first-seen” rule, which is fundamental in preventing malicious double spends by confirming the first transaction broadcast. Moving away from this to a model where transactions can be outbid by higher fees undermines both the security and predictability of transactions, which are essential for maintaining user trust and the overall integrity of the Bitcoin network.

    2. Increased Centralization of Block Production: The last decade has seen a notable increase in the centralization of block production, concentrated among a few large pools. This trend jeopardizes Bitcoin’s democratic and decentralized principles. Implementing changes like RBF, which could be exploited by these centralized entities, further aggravates this problem.

    3. RBF as a Temporary Scaling Measure: Introduced as a stopgap for handling network congestion and scaling issues, RBF falls short as a long-term solution. It overshadows more sustainable approaches such as implementing larger blocks or enhancements like OP_CHECKTEMPLATEVERIFY (OP_CTV). RBF’s temporary nature could potentially obstruct the broader vision of scaling Bitcoin into a viable peer-to-peer currency.

    4. Lack of Broad Social Consensus: The decision to implement a significant protocol change such as RBF without widespread community consensus is deeply concerning. This practice is misaligned with Bitcoin’s governance principles, where substantial changes should be thoroughly debated and agreed upon by the community.

    5. Implications for Bitcoin’s Role as P2P Money: The ongoing reliance on and expansion of RBF features could impede Bitcoin’s ability to scale effectively as practical, peer-to-peer money. It pivots the system towards a competitive fee market, moving away from fostering user empowerment and accessibility—both of which are crucial for Bitcoin’s adoption and functionality as a currency.

    Given these points, I strongly recommend a reevaluation of RBF’s role and its implementation strategy. We need to consider more robust and decentralized scaling solutions that adhere to Bitcoin’s original intentions, supporting its development into a reliable and universally accessible digital currency.

  58. Theschorpioen approved
  59. fanquake commented at 11:54 am on August 6, 2024: member
    Backported for 27.x in #30558.

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-18 04:12 UTC

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