Bitcoin’s next major software release, Bitcoin Core v30.0, has reignited a fraught debate over what kinds of data should be permitted to traverse and settle on the network—and who could bear legal responsibility when that data is illicit.
On Monday, cryptography pioneer Nick Szabo weighed in with a pointed warning: changes in v30.0 that relax long-standing relay policies for data-carrying transactions may heighten the legal exposure of full-node operators by making objectionable content easier to retrieve and “view” with everyday software, thereby strengthening claims that operators had knowledge of what they were relaying or storing.
Bitcoin Core V30 Update Could Be A Legal Disaster
Szabo framed the core issue in stark terms: “What then happens when full node operators become informed about illegal content on the blockchain? They then have knowledge and this particular precedent doesn’t protect them.” He added that the risk is not abstractly technical but turns on how non-technical decision-makers—lawyers, judges, and jurors—perceive what a node operator could reasonably know or do.
“A counter argument is that illegal content in a contiguous standard format, thus readily viewable by standard software, is more likely to impress lawyers, judges, and jurors… than data that has been broken up or hidden,” Szabo wrote, stressing that legal outcomes can hinge less on protocol nuance than on whether a “one-click” consumer app can surface the content.
The flashpoint is Bitcoin Core v30.0’s reversal of an informal barrier around OP_RETURN—the script pathway historically used to attach small, prunable blobs of arbitrary data to transactions. For years Core’s default mempool policy would not relay OP_RETURN payloads above ~80 bytes and limited them to one output per transaction, a non-consensus “standardness” rule that deterred large data postings without banning them at the protocol level.
“Fees protect the miners, but they don’t provide enough disincentive to protect the full nodes. This has always been a problem, of course. But increasing the OP_RETURN allowance will likely make this problem worse. It also will increase legal risks,” Szabo wrote via X.
Beginning with Bitcoin Core v30.0, the default policy shifts: nodes will by default relay and mine transactions with larger aggregate OP_RETURN data and permit multiple data-carrier outputs per transaction; the long-used -datacarriersize knob is being deprecated and repurposed, and now applies to the aggregate data across outputs. In effect, the default barrier comes down—though individual node operators can still set stricter local limits.
Core developers and supporters of the change argue that channeling non-financial data into OP_RETURN—precisely because it is prunable—can reduce systemic harm compared with stealthier encodings in non-prunable parts of transactions (e.g., faux public keys or other script hacks). As Szabo summarized the pro-Core position he has “heard”: allowing more data via OP_RETURN “conceivably may reduce legal risks,” since the alternative (hiding data in places that are not pruneable) is worse for the long-term burden on nodes.
Critics counter that relaxing defaults will normalize large, contiguous data payloads that consumer apps can trivially render, making it far easier for prosecutors to demonstrate that node operators had actual or constructive knowledge of illicit material. As Szabo put it, non-technical decision-makers will be “much more impressed” by illegal content that a familiar app can retrieve than by content requiring specialized tools. That persuasion risk, he suggests, is at the heart of operator liability.
The legality question sits awkwardly at the intersection of these technical defaults and real-world perception. Several industry participants argued in response to Szabo that arbitrary data cannot realistically be stopped at all—whether via inscriptions in witness data, encodings in public keys, or OP_RETURN—making the policy debate “fruitless.” Szabo did not dismiss that practical reality but insisted that format and user-experience matter in court: if “an app like one on their phones can retrieve the data,” that could weigh heavily against a defendant Bitcoin node operator; if it requires obscure reconstruction tools, the opposite.
What, then, is the remedy? Szabo floated two classes of mitigations, both imperfect. At the software level, he suggested making it deliberately harder for popular apps to store and retrieve generic media via either OP_RETURN or witness data—essentially nudging developers away from contiguous, human-readable formats.
At the policy level, legislators could consider liability regimes that focus on the signers of offending transactions rather than on relay/storage intermediaries such as node operators. He also emphasized heterogeneity: because legal risk and the app landscape vary by jurisdiction and over time, Bitcoin node operators need freedom to develop “messy, social/technical solutions,” with an eye on avoiding spillover into censorship of ordinary payments.
Notably, Szabo stressed that he has not taken a definitive side on the update and is “exploring the issues,” even while cautioning that “legal issues like this are far from straightforward, and they lie far outside the wheelhouse of most developers.” That, perhaps, is the most sobering takeaway as v30.0 approaches: the technical path may be clear, but the legal terrain it crosses is anything but.
At press time, Bitcoin traded at $112,079.
Featured image created with DALL.E, chart from TradingView.com
Editorial Process for bitcoinist is centered on delivering thoroughly researched, accurate, and unbiased content. We uphold strict sourcing standards, and each page undergoes diligent review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance, and value of our content for our readers.
