Published: October 10, 2025
107
67
512

people making false claims bitcoin op codes, parameters are "designed" or "meant" for spam are actually attacking bitcoin with manufactured legal peril. none of bitcoin is designed for spam, it's all designed for financial transactions, smart-contracts and small anchors,

@adam3us That’s exactly what Nick was saying here. I think we’re all talking past each other a bit. In a nutshell, any feature on bitcoin used for spam is an unintended consequence—not an intentional feature—of bitcoin’s capabilities for financial transactions. Spamless transactions

@colbyserpa he seems to agree with op return2 data-availability. but he's failing at what you said, and appears to be saying changing a node local node parameter on a feature that's been consensus valid for 15 years is "intentionally designed to host non-financial content" which is nonsense.

@adam3us I think @NickSzabo4’s post is saying exactly what your OP post says! That bitcoin wasn’t designed for spam… both of you are saying the same thing there. Core30 explicitly signaled for encouraging arbitrary data (in the eyes of a court, potentially) by removing the cap—even if

@colbyserpa @adam3us @NickSzabo4 May seem unintuitive, but legally, creating a native filter system, process for distribution, and legal notices of activity *increase, not decrease* the likelihood of gov interdiction and courts compelling repurposed use for gov demands - filters are a misadventurous gift to gov.

@csuwildcat @adam3us @NickSzabo4 What type of tech do AML & OFAC compliant farms use when screening transactions? Filters for relaying transactions in the network have existed for a long time, even if they were once less aggressive than luke’s current filters… If governments want to hijack filters, they will.

@colbyserpa @csuwildcat @NickSzabo4 he's talking more about miner filters. and afaik they're not doing that now. build the tools to do it, and you can get compelled that's what @csuwildcat is explaining AWA is about. and that's what @ocean_mining is advocating, and refusing to listen to risk feedback about.

@adam3us @csuwildcat @NickSzabo4 @ocean_mining Mara mined OFAC compliant blocks at one point and then stopped shortly after. https://ir.mara.com/news-event... But the other point still stands. Filters for transactions have been in bitcoin a long time (that differ from consensus limits). The filters are already here. Making the

@colbyserpa @csuwildcat @NickSzabo4 @ocean_mining you could have a point there. but at least not actively filtering is presumably less bad for precedent, as you notice MARA stopped. there is some argument about if they work for miners also as well as there are many miners. @csuwildcat also called the introduction of filters an

@adam3us @csuwildcat @NickSzabo4 @ocean_mining Bitcoin Core is actively filtering though. It just isn’t as aggressive as Knots. Filters that differ from consensus limits are indeed a mistake in terms of this legal attack vector, but now they are here to stay — so we might as well make them optional for deterring spam without

@adam3us @csuwildcat @NickSzabo4 @ocean_mining Otherwise Knots will only gain more momentum and more arbitrary changes—those arbitrary changes are the real risk to bitcoin, not filters. Filters are already here. Satoshi opened that Pandora’s box and there is no putting it back in alas.

@colbyserpa @csuwildcat @NickSzabo4 @ocean_mining someone doing something inadvisable, exposing themselves to security and complexity risks is no excuse for the bitcoin reference client to make the same mistakes, or to make other mistakes based on "urgency" or "expediency" or "prior mistake precedent". calm down...

@adam3us @colbyserpa @csuwildcat @ocean_mining Yes, there is no excuse for the Bitcoin reference client to expose us to the wide variety of extreme legal risks that come with arbitrary content. You don't understand the threat environment.

@NickSzabo4 @adam3us @colbyserpa @ocean_mining This is where I don't understand your position: precedent for illegal content suggests very little legal risk related to such content under this specific fact pattern, whereas precedent for gov forcing use of mechanisms for its ends, absent undue burden, is a proven, high risk 🤷‍♂️

@csuwildcat @adam3us @colbyserpa @ocean_mining What you call "precedent" is actually the least popular position and thus a poor guide for what the law will be in many places going forward: https://x.com/NickSzabo4/statu...

@NickSzabo4 @csuwildcat @adam3us @colbyserpa @ocean_mining Still, @csuwildcat's point about precedent seems to hold in relation to the little marginal risk added to the current (already risky) situation. Claiming "if this stuff happened already and nothing bad followed, so nothing bad will follow if this happens again" is naïve, for the

@giacomozucco @csuwildcat @adam3us @colbyserpa @ocean_mining First of all, most if not all of the content already on the chain is either just hashes, which legally are a very different thing, or other kinds of images, which again are legally a very different thing. Second, one image with one associated set of off-chain evidence, relevant

@NickSzabo4 @giacomozucco @csuwildcat @adam3us @colbyserpa @ocean_mining Listen Linda!!! It is funny how those in the pockets of the mining industry are trotted out to double talk when needed. -Big blocks are bad when ASIC companies want them to be small. -Now Big blocks are good when ASIC companies want them to be big. So obvious. Zuck has now

@NickSzabo4 @giacomozucco @csuwildcat @adam3us @colbyserpa @ocean_mining Thanks for stating this point @NickSzabo4 I’ve been trying to get people to understand from a legal perspective the difference of the way the content exists currently (steganography, hashes, hacky ways that still allow for plausible deniability for node operators) vs contiguous

Share this thread

Read on Twitter

View original thread

Navigate thread

1/20