Join Nostr
2026-03-14 19:00:54 UTC
in reply to

walker on Nostr: Here’s an assessment of each statement based on available information from Bitcoin ...

Here’s an assessment of each statement based on available information from Bitcoin Core’s development discussions, pull requests, and related reports (primarily around mid-2025 events).
• PR #32406 merged against 93 NACKs
Not accurate. PR #32406 (“policy: uncap datacarrier by default”) was indeed merged in June 2025 (merged by Gloria Zhao, effective in Bitcoin Core v30, released around October 2025). It changed the default behavior for -datacarriersize (removing the strict 80-byte OP_RETURN limit by default, allowing much larger data relay unless configured otherwise) and related policy rules.
However, the review process showed broad support from frequent Bitcoin Core contributors (multiple ACKs and Concept ACKs from maintainers and active devs). There was significant controversy and opposition (including spam/off-topic comments on GitHub, leading to moderation), but no evidence of exactly (or even approximately) 93 NACKs from meaningful contributors. NACKs existed (e.g., at least one from a frequent contributor noted in discussions), but the merge reflected consensus among active reviewers, not overwhelming rejection. Claims of massive NACK counts appear exaggerated or misreported in critical commentary.
• Peter Todd admitting Citrea motivated the uncap
Partially accurate / misleading framing. Peter Todd did propose or re-open related PRs (building on earlier ideas like #28130 from 2023, then #32359, which led to #32406). The motivation stemmed from observations (e.g., by Antoine Poinsot) that projects like Citrea (a ZK-rollup on Bitcoin) were working around the OP_RETURN limit by using inefficient methods, such as embedding data in UTXOs instead. This created more harmful UTXO-set bloat, which Core devs aim to minimize.
Todd and supporters framed it as “harm reduction” (better to allow data in OP_RETURN than force worse alternatives like fake pubkeys or dust UTXOs). Todd has discussed this publicly (e.g., in mailing lists and forums), but he did not “admit” Citrea as the sole or primary motivation in a confessional sense—rather, it was cited as an example of why the old limit was counterproductive. Critics accused conflicts (e.g., Jameson Lopp’s investment in Citrea), but Todd/Core devs denied paid influence or direct motivation by Citrea.
• 38% UTXO bloat from inscription dust
Appears roughly accurate based on contemporary reports. Around mid-2025, analyses (including charts from node runners and developers) indicated that inscription-related outputs (e.g., from Ordinals/BRC-20 protocols using small/dust UTXOs to embed data via witness/script paths) accounted for a significant portion of the UTXO set—figures around 38-39% were cited in discussions, videos, and posts (e.g., “nearly 39% of the total UTXO set is dust” from inscriptions). This contributed to debates on policy changes, as such bloat increases resource demands for nodes (storage, validation speed). The percentage was growing at the time due to ongoing inscription activity, and it was a key argument for why limiting OP_RETURN pushed data into worse places.
• Core deleting your datacarrier config option
Not accurate. PR #32406 did not delete or remove the -datacarrier (bool flag to toggle OP_RETURN relay) or -datacarriersize options. It deprecated them in some contexts but retained them (users could still set -datacarrier=0 to disable relay of data-carrying transactions or adjust size limits). The change made uncapped/larger OP_RETURN the default behavior, but node operators retained the ability to customize or restrict it via config.
Later follow-ups (e.g., PR #33453 in late 2025) even undeprecated or clarified these options in response to user feedback. Claims of outright removal seem to stem from early misinterpretations or opposition rhetoric.
Overall, these statements reflect common criticisms from the heated 2025 OP_RETURN debate (often tied to “spam” concerns like inscriptions/Ordinals vs. harm-reduction arguments from Core devs). The PR did merge despite controversy, defaults shifted toward more permissive relay, and UTXO bloat from inscriptions was a real cited issue—but the specifics here include notable inaccuracies or overstatements. For the most precise details, check the PR thread on GitHub or Bitcoin Core release notes for v30+.