Jonathan Galea

Since I've been asked, here's my honest point-by-point feedback on this article. > Every full node on the Bitcoin network downloads, stores, and serves the entire blockchain. Factually false. Every full node has to download the entire blockchain, but it only has to store the state (UTxOset), not the chain, in order to function. And it has to serve nothing at all. We may formulate weaker versions of this claim that could be arguably correct: - it's still challenging to run heavy LN-enabled merchant infrastructures on pruned nodes (this can and should be fixed), - we need at least *some* reliable and reachable archival nodes to stay online and keep serving all blocks to keep Bitcoin trustless (a realistic safe number depends on the rate of new syncing nodes needing that data), - downloading and then deleting block data (for pruned/listening full-nodes) with some government-banned encoding could still represent an attack surface to analyze, - some government-banned content can be encoded in the state as well and not in the chain (to be stored by pruned/listening full-nodes too), representing an attack surface to analyze. But the claim itself is false. > Every node operator is storing content embedded by third parties that they didn’t choose, can’t control, and cannot remove. Slightly misleading. Beside the points above about pruning/listening, the phrasing makes this sound as it's a specific Bitcoin issue, while it's true for literally every kind of software. For example: Linux users can't trivially choose, control or remove some parts of the kernel, if they want to use Linux. Bitcoin has indeed a different risk profile in terms of append-only data structures, adversarial use-cases, lack of central governance, etc. But this sentence fails to properly distinguish this profile. > Bitcoin Core v30 expanded the default data relay capacity by over 1,000x, making it dramatically easier to put more of it there. Hard to defend claim. I don't see how the change in the default in v30 would make it "dramatically easier" to embed such content. All default-config pre-v30 Core nodes were already relying large op_returns in blocks. Custom-config Core and Knots nodes (and default LibreRelay nodes) were also relaying them in mempools. Default-config pre-v30 Core nodes were also relaying any kind of large "inscription" (which have a 4x higher rate limit). Default-config Knots nodes were relying any kind of large "stamp" (both in blocks and mempool). Literally all kinds of nodes were relaying multi-tx encodings (easily available since @peterktodd's python tool published back in 2015). A defensible claim would be that "Bitcoin Core v30 expanded the default data relay capacity by over 1,000x, making it *marginally* easier to encode content in a very specific way among many (with a lower rate-limit)". The article also rightly claims that "extracting an inscription from the blockchain is now a single command line, and in 2026 any LLM can generate the extraction script in seconds from a sample transaction". Inscriptions have not been impacted at all by v30 default changes. > BIP110 closes it at the protocol level. Factually false. The claim is referred to government-banned data embedding tout-court, not to the few specific encoding styles that BIP110 would prevent if adopted. Also, internally contradictory. Any change applied from September 2026 on would, by definition, not eliminate the already present government-banned data encoding, which this very article claims exist and "has been documented in peer-reviewed research since 2018". Also, later on: "The content is already on the chain." > Second, the Tor analogy breaks at a critical point. Tor relays route transient traffic. They don’t permanently store anything. Factually false. The analogy would break if the very first sentence of the article held. As explained in my very first comment, it doesn't hold. A pruned, listening full-node is no different from a Tor relay in downloading terms, while it's clearly *less* problematic in uploading terms. ADDITIONAL CLARIFICATION: 1) My point is not that the legal attack surface doesn't exist or should be treated lightly. The very opposite! My point is that it does exist, and should be treated seriously. For example by teaching users how to run nodes adversarially, behind Tor or mixnets and in a covert way, and making it easier, cheaper and practical to do so, in several ways (including consensus change proposals, like block size reductions). Or by focusing the above effort on archival nodes, while at the same time lobbying and arguing in courts for more legal protection for pruned, listening nodes, again making it easier for the users to limit their exposure this way. Creating a false sense of security around BIP110, like this article does, or arguing that some magical properties like "non-contiguity" eliminate all legal risks, is the very opposite of taking the problem seriously. 2) I'm focusing this post on the parts of the articles I find false, misleading or inconsistent. That doesn't mean there are not parts of it (indeed very many) which I find correct. In particular, I agree that the change in v30 were highly controversial and should have not be forced in a supposedly neutral standard reference client, that they were not motivated by any real urgency at all, that the merging has been managed very poorly in the midst of an embarrassingly sloppy governance, that they may have factually facilitated an increase in generic spam due to a perceived social legitimization (even if the technical rate of op_return spam is lower than some pre-v30 common alternatives like "inscriptions").

No hype. Just infrastructure and strategy. $WULF bringing real-world perspective to the stage at #CFCStMoritz. CSO @Kerri_Langlais on AI & Energy. Board Member @MikeBucella on Bitcoin’s Srategic Moment.