I think there are broadly speaking two categories of Knots supporters.
Category 1: Believes there is a moral difference between (illegal) data in OP_RETURNs vs. Inscriptions. This category includes nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk.
Category 2: “I don’t like spam, Luke doesn’t like spam, therefore I support Luke.” This category includes ~everyone else.
Never underestimate your enemies.
Putting people into boxes won't help with it either.
I’ve actually tried real hard to understand their perspective.
But at the end of the day, I really don’t see how their approach makes any sense _unless_ you draw some kind of moral distinction between content in OP_RETURNs versus Inscriptions/fake pubkeys/etc.
But you discount "the movement" as being all stupid followers of its leader.
We very recently observed the shift to this "sanctioned data" stance and you had commented on a stream where Mechanic learned about that but I think it's not mere semantics. A legal attack on Bitcoin could argue on this distinction when determining if a benign protocol is being abused or complicit in the spread of "illegal data".
In a world where judges cared only about what is right, we wouldn't have to worry but Bitcoin is under attack in 200 jurisdictions and if this provides half an argument for some of those to put users closer to jail, it would be bad or at least way worse for bitcoin than having to keep maintaining 20 lines of code and a 160B default datacarriersize.
Right, so then the argument is that a judge would say:
- CSAM in Inscription: no jail
- CSAM in 101kb OP_RETURN: no jail
- CSAM in 100kb OP_RETURN prior to September 2025: no jail
- CSAM in 100kb OP_RETURN post September 2025: jail!
Correct?
I suspect sarcasm but anyway ...
My comment is not only about judges but also about politicians and explicitly not about people caring about what is just and good for the people but about those who want to attack Bitcoin on the one hand and on the other hand the cost of both not deprecating a long established policy setting and setting the default to 160B instead of 100kB.
I think, the cost of limiting OP_RETURN to 160B for the foreseeable future is almost zero. Maybe I'm wrong about that. Maybe the centralization from big OP_RETURNs not getting relayed is bigger than I thought. But given that very tiny cost, the very tiny potential for legal ramifications makes it just not worth it and the drama and noise Core went through to still go along with deprecation+100kB over 160B just feels off.
That said, appeasement is a slippery slope, too. If drama on social media can influence engineers to opt for more centralization then we might be on the way to getting Bitcoin captured by politicians.
So I'm not arguing for or against either side but I think it's not just Luke who cares about that nuance.
So to answer your list of examples:
- Using Bitcoin - a protocol that as of 2025 is designed for arbitrary data distribution: jail!
And again, I assume "using bitcoin -> jail" is reality in some jurisdictions already and we have to assume it will come to more jurisdictions either way. Having less CSAM in less readable formats on the chain might marginally help slow this trend while limiting OP_RETURN to 160B is a trivial burden thus I lean towards 160B limits over 100kB limits but more importantly I give it to knots proponents to see it just like that and don't want to discount their conviction as some Luke-cult thing.
>Using Bitcoin - a protocol that as of 2025 is designed for arbitrary data distribution: jail!
But only if/when there's illegal content between 80 bytes and 100kb in an OP_RETURN, right?
No I'm not being sarcastic.
I think, Luke argues that by defining how to store arbitrary data, a precedence is made that Bitcoin is for arbitrary data storage, making all other arbitrary data problematic, too.
OP_RETURN was for hashes and then for hashes plus some meta data. With 100kB it's not meta data or hashes anymore.
The problem won't be that you have this and that sequence of bytes on your machine but that you are using Bitcoin period.
So by this logic if CSAM is included in Inscriptions that could now land you in jail because Bitcoin Core increased the OP_RETURN policy default. (Even though it was already possible to do that.)
Do you find this argument convincing?
I think that if Luke and others can see it that way, politicians might parrot the sentiment in defense of laws against Bitcoin. Politicians only need majorities and Luke's arguments did move the needle among Bitcoiners or we wouldn't have this debate.
Then it sounds like you're saying if enough people believe 2+2=5, politicians could make 2+2=4 illegal, thus we should take that into account when making engineering decisions?
No, your framing is dishonest.
Respectively, each scenario is:
- no CSAM: no jail
- no CSAM: no jail
- no CSAM: no jail
- CSAM: jail
I’ve heard you say before there can be no CSAM in Inscriptions because CSAM in Inscriptions can only be “misinterpreted” as CSAM.
I doubt many people would agree with this… but let’s park that.
How is 101kb of CSAM in OP_RETURN not CSAM??
Or perhaps nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4spremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq3zamnwvaz7tmwdaehgu3wwa5kuef03j9hac can weigh in?
Who is jailed?
- devs? all devs or just 1-2?
- node running who forwarded Tx data as ones and zeros, without "looking at it"
-miner who archived Tx to the time-chain?
How about the human creator of the CSAM in meat-space, the person who made the image/video, then paid to get it mined? Lets just send all of those people to the wood-chipper.
IMHO intent is everything in these very theoretical scenarios
Yeah, there's no way the government will misinterpret laws to jail whomever they want.
The point is not avoiding illegal things because the government is such a good arbiter. The point is to avoid the government as long as possible because they will use any justification possible.
Either way this debate is stale and gay. Everyone is talking past each other to score Got em points. Either talk about how the taproot incriptions bug was declared a feature and since then the community of bitcoin has been fractured or gtfo.
CORE: Don't like it, run your own node.
KNOTS: Okay
CORE: Not like that, plus if you REALLY want to change spam, you need to reject blocks at the consensus level.
KNOTS: Okay, we'll fork.
CORE: No! Not like that!
Same shit over and over.
Question from someone who's not up to speed on all of the technical details and arguments, but believes that enabling 100kb OP_RETURN is begging for legal problems:
Is it technically possible to develop a compromise solution that gives the "shitcoiners" (projects that want better hooks for integration and new capabilities) what they want without providing an ideal storage space for illegal files?
IMO, inscriptions etc. are nonsense and should be eliminated, if possible, but I can see the utility in improving trustless integration with ancillary systems.
The middle path > ideological purity (IMO)
Did cypherpunks care about the legal system? Bitcoin is already illegal in many of these 200 jurisdictions...
The protocol was not designed around a fear of authority.
Category 3: “Believes bitcoin core devs have demonstrated their ability to unilaterally make unproven, unjustified, controversial changes by knowingly taking advantage of software default settings in the most popular bitcoin reference implementation that exists today, for their own questionable motives that no longer align with what bitcoin was made for - money!” Running Knots is a way to message the disapproval of bitcoin core devs’ entire corrupted handling and poor communication for this mess that they are responsible for.
Fucking legend.
I think there broadly speaking two categories of Core devs.
Category 1: Core devs who are compromised and are destructive to Bitcoin.
Category 2: Core devs who understand what Bitcoin Is, what Satoshi Nakamoto vision is - Bitcoin is Freedom Money. They are constructive to Bitcoin.
