I appreciate the dialogue.
On point 1: Fair, but the OP_RETURN expansion makes data more readily accessible in standard format, which is your concern. The legal risk difference between encrypted and accessible is what Szabo flagged.
On point 2: If Bitcoin can’t store images, what are ordinals/inscriptions doing? Taproot witness data allows arbitrary data that reassembles into images and files. The technical distinction doesn’t change the practical reality.
On point 3: If Bitcoin’s survival requires coordinated human filtering rather than protocol level incentives making attacks expensive, that’s a fundamentally different security model than what Bitcoin was designed for.
On point 4: The disagreement is whether filtering makes Bitcoin ‘better’ or fundamentally changes what Bitcoin is.
What’s the technical solution that doesn’t require ongoing human judgment about legitimate versus illegitimate data?
2) Ordinals/Inscriptions are just spam. It's basically a scamcoin using proof-of-attacking-Bitcoin as its "algorithm". Taproot witness data does not allow arbitrary data - that's just an abusive *mis*interpretation of script code that Ordinals is doing completely unrelated to Bitcoin. This _is_ a relevant distinction.
3) Satoshi introduced spam filters to deal with the spam issue. So Bitcoin literally _was_ designed to work this way.
4) Again, Bitcoin has used spam filters from the start. It is Core30 that aims to change Bitcoin by removing some.
Calling it spam’ or a scam coin doesn’t change that it exists and uses valid transaction structures post Taproot. Whether it’s abuse or not, the protocol accepts it. If Taproot witness data doesn’t allow arbitrary data, why does the exploit work? The protocol is the arbiter, not our opinions about intended use.
Satoshi’s spam filters were protocol level consensus rules (like block size), not mempool policy that filters by content type. There’s a difference between “this transaction is too big” and “this transaction contains the wrong kind of data.”
Core 30 is expanding limits that already existed, not removing spam filters entirely. The question is whether expanding those limits is allowing Bitcoin to be what it became post Taproot, or breaking from original design. I’d argue Taproot itself was the change, and Core 30 is just acknowledging the reality that change created.
I’d still like this fundamental question answered: if filtering spam requires ongoing human judgment about what’s real Bitcoin use versus attack, who decides? And doesn’t that create the gatekeeping we’re trying to avoid?
The exploit works because Core neglected to update the spam filters a few years ago, and refuses to fix the vulnerability.
And no, you're wrong. Satoshi's spam filters were VERY picky about what was inside transactions. Anything that he didn't foresee being used was rejected.
Core30's malicious changes have nothing whatsoever to do with Taproot.
Each user decides for himself. Collectively, our nodes form consensus around what is spam and what maybe isn't.
If Core neglected to update spam filters and refuses to fix the vulnerability, that sounds like the Core development consensus chose not to restrict it. Whether through action or inaction, that became Bitcoin’s reality post Taproot.
On Satoshi’s filters: can you point to specific examples where Satoshi rejected transactions based on content type rather than structural validity? I want to understand the historical precedent you’re citing.
On Core 30 and Taproot: if they’re unrelated, what specifically is Core 30 changing that enables the threat you’re warning about?
On “each user decides” agreed. But there’s a difference between individual nodes filtering their own mempools versus advocating that filtering should be the standard. Your post isn’t just “here’s what I’m doing”, it’s “everyone should do this NOW.” That’s attempting to establish collective filtering as the norm, not individual choice.
Pretty sure that’s not what happened big guy
policy exists not because they are less important than consensus, but because its more beneficial for them to be dynamic. because we dont wanna lock ourselves in.
and also i believe having more dynamic options between nodes keeps the protocol more decentralized.
if we suddenly have a ceo of bitcoin (core maintainer) changing what its, is it still bitcoin? you cant just change playing field and expect everything to keep working. if you change the multiplier of gravity you would break many things.
if you remove all of the policy, its not the same bitcoin anymore.
and tapscript didn't exist while satoshi was active.
also there was nothing stopping inscriptions from being existed before taproot, except the script size limit policy for witness. which was also removed for tabscript with the taproot fork. so policy has stopped exploits like these many times before. until its removed for another excuse.
because of policy vitalik left bitcoin and built the ethereum shitshow. let them build their own country, because they are not welcomed fucking with people's money.
bitcoin doesnt run on the ether, it runs on people's devices, that what makes it different and decentralized. and just like in any protocol you have to filter spam, exploits of protocol, and other attacks.
timechain is not a storage. it exists to prevent double spend. if we had another solution, it wouldn't have existed.
Core, whether through omission or commission, through the changes they instituted created ordinals regardless of whether this is #Bitcoin’s reality currently………
I personally do not see ordinals as a positive for Bitcoin given what that has done to the data storage on my full node, perhaps you do.
Now we are asked by this group to open things up further in op return? Most reasonable and logical individuals would look at the past, see the track record, and ask what may result of such action……….
What’s the impetus for the change if things are currently working fine?
Their track record shows that they are not able to anticipate unknowns nor patch them when they occur….….
We are now given V30 which blows open the op return……..
Running a FULL node and keeping the barrier to entry (cost) minimized is in line with #Bitcoin’s ethos……..
Enforcement should be cheap (running a full node), profiting should be expensive (Bitcoin mining)………..
Adding more data to the time chain increases the costs for node operators to run FULL nodes……
I know I personally have to upgrade my set up (memory constraints) due to what ordinals has added to the storage requirements which was caused by Core……
Perhaps you don’t mind this, but I do and I am against unnecessary changes that further bloat the time chain………..
Seems to me you’re looking for all sorts of ways to justify having a wrong opinion. Maybe this will help you clear your thoughts:
Excellent comment! I just want to add that Ethereum, while younger than Bitcoin is already over 15TB for a full archival node. Not to mention RAM and CPU requirements. Stop the #Enshitcoinification
Core does nothing to stop inscriptions spam bloating the UTXO set. #Knots fixes this.
v30 is malware. Once you see that, the gaslighting becomes obvious.
Trojan horse
Wonder if you’d get a reply.
You make a fair point about policy being dynamic and beneficial. But there’s a critical distinction: policy that protects Bitcoin’s structure like script size limits and block size versus policy that judges transaction content.
Filtering based on structural limits is objective. Filtering based on whether data belongs here requires ongoing human judgment about what’s legitimate Bitcoin use.
On Taproot: if policy prevented inscriptions before and Taproot removed that barrier, then the Bitcoin community achieved consensus to expand what’s allowed. Calling it an exploit now is reframing a consensus change as a bug.
On the money argument: inscriptions are paying full freight in fees. They’re expensive. If someone wants to pay $50 to inscribe data, they’re not attacking the fee market, they’re participating in it.
The timechain isn’t storage by design, agreed. But fee markets should make storage economically prohibitive, not developer policy deciding what counts as storage versus payment.
Where does content filtering stop once we accept it as legitimate?
The specific Satoshi filter is that prior to OP_RETURN, data of an unknown content type was rejected from being relayed (i.e. filtered).
However, a transaction sent directly to a miner with data of an unknown content type could still be mined... the miner could even call the output an "OP_RETURN" (or any other op code unknown to anyone else) if he wanted to. The difference is, when all the other nodes validate a block containing a transaction with an op code that it doesn't recognize, it just assumes it's unspendable - which was convenient for the introduction of OP_RETURN (also unspendable) since it didn't change node behavior vis a vis block validation (and thus, no chain-split)
The net result of OP_RETURN was to allow data of unknown content type to be relayed; and consequently, way more likely to get minded - then when it was previous being 'filtered' (i.e. 'picky') from being relayed in the first place.
So the introduction of OP_RETURN itself was already a move toward allowing arbitrary data to be relayed, not filtered. Satoshi filtered unknown content types, but the community consensus through OP_RETURN was to explicitly allow a mechanism for arbitrary data.
The question becomes: was OP_RETURN a bug or a feature? If it was intentionally introduced to allow data relay that was previously filtered, then expanding its capacity seems consistent with that original decision to permit arbitrary data.
If the argument is that OP_RETURN was a mistake that opened the door to abuse, then we’re debating whether to roll back a consensus change that’s been part of Bitcoin for over a decade.
Either way, the decision to allow arbitrary data relay was made long before inscriptions. The current debate is about the scale, not the principle.
What a soulless, pedantic, ridiculous argument in favor of those looking to destroy humanity's only hope.
We are here to save humanity, not conform to past mistakes.
💯
'bug' or 'feature' is ultimately a matter of perspective... and the community - through the collective decisions of its independent actors - will eventually settle on a resolution (or it won't and fork).
I'm not sure what you mean by rolling back a 'consensus change'; but, as I indicated, nodes don't have to be in alignment on recognizing "OP_RETURN" or not in order to avoid a chain-split. As such, introducing OP_RETURN wasn't a change to the consensus rules in the first place.
The debate was always about scale - which resulted in a compromise from each side on their principles... but yeah, witness-data stuffing (e.g. inscriptions) are a separate issue.
Fair correction on OP_RETURN not being a consensus change since it didn’t require nodes to align. I appreciate the clarification.
On the scale question: if the original introduction of OP_RETURN was itself a compromise on principles, then the current debate about expanding it is really about whether that compromise should hold or shift further.
My concern is that scale debates become legitimacy debates. Once we accept that limiting arbitrary data is about protecting Bitcoin’s purpose rather than just technical constraints, we’re making ongoing judgments about what belongs. That feels like a different kind of governance than protocol rules.
But I take your point that witness data stuffing is a separate mechanism from OP_RETURN expansion, even if they’re related in practice.
> Filtering based on structural limits is objective. Filtering based on whether data belongs here requires ongoing human judgment about what’s legitimate Bitcoin use.
that's why filters are dynamic. i would go further and say that we need isolated custom filter scripts and plugins. free market of network policy.
for example i can make a plugin that delays the propagation of blocks by weight of the txs that doesnt fit into my filtering policy. simulating a slow connection. making it more likely to be a stale block.
> On Taproot: if policy prevented inscriptions before and Taproot removed that barrier, then the Bitcoin community achieved consensus to expand what’s allowed. Calling it an exploit now is reframing a consensus change as a bug.
that's why i used to phrase "excuse", the goal of size limit policy being removed had nothing to do with that use case. its a side effect of poor decision making, and lack of attention on the codebase by normal plebs as i said "changing the multiplier of gravity will have untended side effects". and script size limit was a policy, not a consensus.
> On the money argument: inscriptions are paying full freight in fees. They’re expensive. If someone wants to pay $50 to inscribe data, they’re not attacking the fee market, they’re participating in it.
> The timechain isn’t storage by design, agreed. But fee markets should make storage economically prohibitive, not developer policy deciding what counts as storage versus payment.
its called an exploit, because its an exploit. if i start using your nostr relay to spam chunks of a blob data as posts, then im exploiting your relay. if i use my bank's transaction history to encode and store random blob data, then im exploiting their database. if i use youtube as cloud storage by encoding blob data into videos, thumbnails and video title and descriptions, then im exploiting the youtube.
they are attacking because script space is not intended as storage space.
talking about some policy like "objective" or "subjective" is miss-leading as well. policy is policy. if consensus said "max script size is x, and max op_return size is y, or tx size has to be idk an odd number". then you wouldn't be able to make the same argument. because consensus is consensus.
with consensus, if you disagree, you either have to split and lose or accept what the majority says. in consensus "yes" and "no" can't exists together on the same chain. in policy you dont have to split, you can add any rules you want as long as you are staying inside the frame of consensus. different policy rules can exists in parallel in the free market of network policy.
its free speech, just like i can choose what to gossip with others physically, i can choose what to gossip with other nodes around me.
in a community culture might not be a written rule, but it protects it. and lack of it would ruin it.
> Where does content filtering stop once we accept it as legitimate?
blob data on the timechain is not legitimate. there is no category. its simple.
there aren't many financially viable ways to store blob data on the chain. if we filter some as they get popular, eventually there will be no p2p way to store blob data. unless core creates another opening again. but until then hopefully core will be irrelevant in the free market node software.
if they can have tools to decode it, then you can filter it.
You make compelling points, especially on policy as free market competition between nodes rather than centralized mandates. Individual nodes choosing their own filtering rules is fundamentally different from advocating everyone should filter the same way.
On the exploit framing, I understand the analogy to using YouTube for storage or a bank database for encoding data. But there’s a key difference. Those are private platforms with terms of service. Bitcoin is a permissionless protocol. The question isn’t whether inscriptions are the intended use, but whether Bitcoin can remain permissionless while enforcing intended use.
Now on consensus versus policy, you’re right that policy allows parallel rules without chain splits. That’s valuable. But when the debate becomes not just what policy individuals choose, but what policy should be standard or what pools should be boycotted for not filtering, we’ve moved from free market policy to prescriptive policy.
Your vision of a free market of network policy with custom filter scripts and plugins is actually more aligned with permissionless principles than mandating everyone filter the same way. Let nodes compete, let fee markets work, let the best approach win.
Where we might agree: individual sovereignty in filtering. Where we differ: whether there’s a collective responsibility to filter or whether that emerges naturally from individual choice.
> On the exploit framing, I understand the analogy to using YouTube for storage or a bank database for encoding data. But there’s a key difference. Those are private platforms with terms of service. Bitcoin is a permissionless protocol. The question isn’t whether inscriptions are the intended use, but whether Bitcoin can remain permissionless while enforcing intended use.
bitcoin is a money protocol, break any other use case is not against the protocol. and again bitcoin doesnt live on the ether, in runs on people's devices. bitcoin is permissionless money.
> Now on consensus versus policy, you’re right that policy allows parallel rules without chain splits. That’s valuable. But when the debate becomes not just what policy individuals choose, but what policy should be standard or what pools should be boycotted for not filtering, we’ve moved from free market policy to prescriptive policy.
many policy has been part of the bitcoin for a very long time. they are part of what bitcoin is. only reason they are not consensus is just in case, so we dont accidentally trap ourselves. these are yes mostly standard. and many has the purpose of mitigating the blob data storage usage from the early satoshi days.
> Your vision of a free market of network policy with custom filter scripts and plugins is actually more aligned with permissionless principles than mandating everyone filter the same way. Let nodes compete, let fee markets work, let the best approach win.
exactly knots go up, and everyone has right to believe other implementation is shit, and go do wars on it. everyone has right to preach knots, and teach others why its the best option we have. its social. and because technically core arguments makes no sense, if people think longer than 10 mins.
i think he heard you
Bitcoin being a money protocol, agreed. But the mechanism that makes it work as permissionless money is validation without requiring permission or judgment about transaction purpose. Once we start validating based on intended use rather than protocol rules, we’ve introduced a gatekeeper even if it’s decentralized.
Longstanding policy does shape Bitcoin’s identity, fair point. But there’s still a difference between policy that protects structure and policy that judges content. Script size limits are structural. Deciding what data is blob storage versus legitimate use requires interpretation.
You’re right that everyone has the right to advocate for their preferred implementation and try to win that argument socially. That’s legitimate. My pushback is specifically when that advocacy uses fear and emergency framing rather than technical merit. Preach Knots on its merits, fine. Use CSAM panic to force immediate action, that’s manipulation.
If Knots wins on technical arguments and social consensus, so be it. But let it win on merit, not manufactured urgency.
OP_FALSE OP_IF and its variants are structure. if it wasnt a structure we would be able to filter it. we would had need machine learning to filter it. any IDE can detect unreachable code.
and BSV already did the exact same change. and we saw what happened. its not panic, if its real. also its not like people on the knots side doesnt make any technical arguments, there are many technical arguments made by knots side (its just there is also left side of the bell curve).
you can make technical arguments and also point out things like CSAM vulnerability at he same time. two things can exists and be true at the same time.
and CSAM is also a technically a valid concern based on history, what happened to BSV.
The OP_FALSE OP_IF structure being detectable is a fair. If it’s identifiable as unreachable code, then filtering it is more technically objective than I was framing it.
What happened with BSV and CSAM? I’m not familiar with that specific case but would like to understand the precedent you’re citing.
I can accept that technical arguments and CSAM concerns can both be valid. My issue is specifically with the emergency framing and pool boycott tactics, not with raising CSAM as a legitimate risk factor in the debate.
If the technical argument is strong enough on its own merits and the BSV precedent demonstrates real consequences, then the case should stand without the NOW NOW NOW urgency that bypasses careful consideration
just search "BSV CSAM" on any search engine. it was a mess and node runners had to make their own client with filters. and invent pruning methods.
there is a rush because v30 comes out this week.
also you can watch videos of the "Bitcoin University" on YT , he aggregates many information in his videos. he has hours of content on it (probably, didnt count).
there is also a video of BitcoinMechanic called "Bitcoin OG and Legend Jason Hughes Explains the Damage Of 100KB OP_RETURN".
some old post from satoshi:
you can also search: "BSV CSAM OP_RETURN"
Thanks for the BSV context, I remember this now.
The BSV case actually proves my point. When the 100KB limit led to CSAM being uploaded, the solution was services like Money Button and BitcoinFiles blacklisting content at the application layer. They updated Terms of Service and moderated their platforms. The blockchain itself remained neutral while services filtered. That’s exactly what I’m advocating, individual operators making their own choices without protocol level censorship.
Satoshi said messages should not be recorded in the blockchain as a design principle. I agree with the intent. But there’s a difference between what Bitcoin should be used for versus hardcoding enforcement of that through filtering. Satoshi built structural constraints like block size limits, not content filters requiring ongoing human judgment about transaction intent.
The fundamental question remains, does Bitcoin survive through protocol neutrality plus responsible application layer filtering, or through coordinated protocol level censorship? BSV handled it without changing the base protocol. That’s evidence the permissionless layer can work while services act responsibly.
Isn't BSV a Bitcoin fork? Or is that something else
its a fork of bcash which is a fork of bitcoin.
What is bash
Bcash
Bitcoin cash?
yes.
So what's stopping people from just using these Bitcoin's?
what? you meant "what is stopping people from just using these forks"?
nothing, go use them, leave the bitcoin alone. as i said at the higher in the thread.
But these are all Bitcoin?
Btw I didn't read your thread lol 🤣
Good try, but this is a category error. Fruit Loops has a definition. It’s a specific breakfast cereal made by Kellogg’s. Calling something else Fruit Loops when it’s literally soup would be false.
Spam isn’t a protocol property, it’s an opinion about use. This meme assumes there’s an objective definition of spam in Bitcoin. There isn’t. Show me the spam field in a transaction
But they’re served in a bowl, you eat it with a spoon, it has a liquid base.
Any transaction that prioritizes data storage over value transfer is one definition.
Buying a bowl of soup with btc is a transfer of value.
Inscribing dickbutts is not.
Filtering inscriptions isn’t censorship because there’s no transfer of value to prevent.
You should ask Core about the spam filters they haven’t proposed removing. Why are you ok with those?
The bowl and spoon don’t make it cereal. The ingredients do. You’re describing consumption, not definition.
According to your spam definition, who measures whether data storage is prioritized over value transfer? An inscription pays fees for block space. That IS value transfer to miners. If someone pays $50 for a dickbutt, they’re transferring $50 in value. You think it’s stupid. The economic transfer is real.
On existing filters, block size and script size are objective structural limits. They don’t judge transaction content or intent. This transaction is too big is measurable. This transaction has the wrong purpose requires human judgment.
Show me how to objectively measure data storage priority versus value transfer priority without judging intent. Priority is subjective. Bytes and fees are not.
He did. It’s telling he still avoided to say anything.
You got part of that right. It is a category error. The difference between soup and cereal is the base. Soup is a cooked broth, cereal milk.
The spammers themselves define the spam. Inscriptions follow a protocol. Create or use a protocol for inscribing data, you’re prioritizing data. Doesn’t matter what the data is, that’s why it’s not censorship, it’s filtering spam. Different category
A miner isn’t a peer in a btc transaction. The fee paid doesn’t enter into the value transfer. Different category.
(I also take issue with miners the feel they own the block space and can fill it with whatever garbage they want for a quick buck leaving the nodes to shoulder the cost forever)
Convincing someone to pay $50 for a UTXO with an inscription is a transfer of value, but it has nothing to do with the transaction that inscribed it. That transaction prioritizes data storage. Ascribing value to the result after the fact is irrelevant.
It’s basically Bitcoin branded beanie babies. Shitcoin on Bitcoin. Nobody wants it. How do we stop it? Filter the inscriptions. How? Filter the protocol.
It’s not censorship. It’s spam filtering.
Different category.
There’s more going on than you realize. Hashers can switch pools with a few clicks. No mining pool wants to be a pariah. If a mining pool lets the wrong jpeg slip in they’ll never recover.
There’s a big difference between “expanding its capacity” to say 160 bytes and removing the limit entirely as Core v30 does. I think there would be much less concern if this was an increase to 160 bytes to support some vaguely plausible use-case.
Good - I’m happy - you recall correctly. Your logic agrees with mine as well. Next awareness is #Terranode. It goes live in November. It scales ideally. It’s cheap! It’s Wide like 24 lane highway. XRP could run on it (If they were smart). They always use Child Porn when they wanna break ya. They’re the only ones allowed to PRON! BTC is currency - Yay… Keep it that way. Transact with sats all ya want on BSV it’s just a cheap AF immutable pay rail. Immutable too P2P -
You got it backwards Slayer. BTC is a Fork of BSV Brother.
Only back then BSV WAS BitCoin! The Corporation of BitCoin took the copyright name and tilted the B to right offset.
Why? Because Child pron was posted… HA!!
