policy: restore 80-byte default for datacarriersize #34214

1. 
   bensig commented at 9:29 pm on January 6, 2026: contributor

   Restore the historical default of 80 bytes (83 with OP_RETURN + pushdata overhead) for -datacarriersize, while preserving the ability for node operators to configure any limit they prefer.

   This is not a hard cap - users can still set -datacarriersize=100000 (or any value) to allow larger OP_RETURN outputs. The change only affects the default behavior when no explicit configuration is provided.

   Rationale:

   • The unlimited default introduced in #32406 remains controversial
   • ~20% of nodes run Bitcoin Knots which maintains the 80-byte default
   • Inscriptions have no economic incentive to move to OP_RETURN since witness data is ~4x cheaper due to the segwit discount
   • Restoring the default provides a middle ground while respecting node operator choice

   Test changes add explicit -datacarriersize=100000 to tests that require large OP_RETURN outputs for transaction padding.

2. DrahtBot added the label TX fees and policy on Jan 6, 2026
3. 
   DrahtBot commented at 9:29 pm on January 6, 2026: contributor

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

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34214.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   Concept NACK	waketraindev, l0rinc
   Concept ACK	frkrueger

   If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

4. 
   waketraindev commented at 9:39 pm on January 6, 2026: contributor

   Concept NACK

   Extra pool too small to hold them, resulting in nodes redownloading transactions they’ve already seen.

5. 
   l0rinc commented at 9:42 pm on January 6, 2026: contributor

   NACK, we’ve discussed this before, there’s still no good technical argument for making the garbage bin smaller.
6. 
   frkrueger commented at 9:45 pm on January 6, 2026: none

   ACK There is no need to fight this battle. The community should come together on this.
7. policy: restore 80-byte default for datacarriersize

   Restore the historical default of 80 bytes (83 with OP_RETURN + pushdata
   overhead) for -datacarriersize, while preserving the ability for node
   operators to configure any limit they prefer.
   
   This is not a hard cap - users can still set -datacarriersize=100000 (or
   any value) to allow larger OP_RETURN outputs. The change only affects
   the default behavior when no explicit configuration is provided.
   
   Rationale:
   - The unlimited default introduced in #32406 remains controversial
   - ~20% of nodes run Bitcoin Knots which maintains the 80-byte default
   - Inscriptions have no economic incentive to move to OP_RETURN since
     witness data is ~4x cheaper due to the segwit discount
   - Restoring the default provides a middle ground while respecting
     node operator choice
   
   Test changes add explicit -datacarriersize=100000 to tests that require
   large OP_RETURN outputs for transaction padding.

   65ce535b9a
8. bensig force-pushed on Jan 6, 2026
9. DrahtBot added the label CI failed on Jan 6, 2026
10. 
    DrahtBot commented at 9:49 pm on January 6, 2026: contributor

    🚧 At least one of the CI tasks failed. Task macOS native: https://github.com/bitcoin/bitcoin/actions/runs/20762668088/job/59621364840 LLM reason (✨ experimental): Transaction tests failed (test 112: transaction_tests), causing the CI failure.

    Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

    • Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

    • A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

    • An intermittent issue.

    Leave a comment here, if you need help tracking down a confusing failure.

11. 
    pinheadmz commented at 9:51 pm on January 6, 2026: member

    This is a duplicate of issues #33298 and #33240 Not to mention extensive discussion in pull requests #32381 #32359 #32406 and the meta discussion https://github.com/bitcoin-core/meta/discussions/18 and also the mailing list post.

    Additional op_return concerns were already addressed at length here, here and here.

    I also reccommend reading this stack exchange answer: Implications of OP_RETURN changes in upcoming Bitcoin Core version 30.0

    Bitcoin Core v30.0 still includes the -datacarriersize command line flag which you can set to 83 to get ~ the same configuration as a pre-v30.0 node (although it will permit multiple smaller OP_RETURNs up to the total limit, see the release notes for more details).

    In addition please keep in mind the Bitcoin Core issue tracker is used for bug reports and feature requests for this software implementation. Please see https://github.com/bitcoin-core/meta for moderation guidelines about what is considered on or off topic comments.

12. pinheadmz closed this on Jan 6, 2026

    ---

13. 
    sipa commented at 9:51 pm on January 6, 2026: member

    NACK. See https://bitcoincore.org/en/2025/06/06/relay-statement/
14. 
    bensig commented at 4:47 pm on January 7, 2026: contributor

    You probably don’t follow me on X, but I have been advocating in support of this decision to remove the limit up until yesterday.

    I completely understand that it is still possible to set datacarriersize to 80 in the options, which is why up (until yesterday) I thought that Knots and the division was really just theater…

    but after learning more about core dev and how things get approved and merged, I realized that a mistake was made. Now you guys obviously don’t see it that way, but changing this one line of code would actually sew back together a huge rift in the Bitcoin community.

    I’ll happily take this discussion to the mailing list or wherever, I’m still ’learning the ropes’ of how you guys do things here and I’m legitimately here to help out. This was a little side quest - but I do think it is the correct move at this point in time.

Contributors
bensig DrahtBot waketraindev l0rinc frkrueger pinheadmz sipa

Labels
TX fees and policy CI failed