Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 8
Generated: 17:44:01
Nick Szabo, here, is demonstrating, and recommending, handwaving as a security strategy. He conflates a metaphor people can "understand" (locked doors) to support the idea of censoring specific bitcoin transactions at the mempool level. But filters aren't locks. They aren't even doors. They are fences in an open field. They don't prevent trespassers, they increase people walking on the grass. We already know how to censor bitcoin txns we don't like, because we already do it successfully! Miners know there are certain poisonous, yet valid, transactions. Through meatspace, they enforce exclusion of such txns. Sadly, this whole "spam" "war" requires Bitcoiners to take a ride together that ends up supporting the idea of miners being heavily regulated by governments, and the idea that we must be good at censoring txns we do not like. Because, unlike pleb nodes, it is miners that decide what gets into Bitcoin. No one else. Arguing policy is pointless, just make the config you like and convince miners to run it... ...But if you do, know that you are doing evil, and acting as useful idiots for the state. image image
2025-10-02 09:40:25 from 1 relay(s) 6 replies ↓
Login to reply

Replies (8)

Absolute nonsense and pathetic take. Core devs deliberately allowed inscriptions spam. They are now using that as excuse that "spam can't be reduced" or that "spam already exists on Bitcoin because of inscription spam". That is dishonest and an internal attack on Bitcoin. Core devs deliberately allow spam and then defend it like shitcoiners. They also maliciously changed the definition of datacarriersize. Bitcoin Knots has fixed those issues. https://github.com/bitcoin/bitcoin/pull/28408 https://github.com/bitcoin/bitcoin/issues/29187
2025-10-02 10:46:07 from 1 relay(s) ↑ Parent Reply
We know what Core did in 2024. nostr:nevent1qqspkj82ulzayrvp3cpsxurmm7yvmkak99jgyjetay6qc439m52d4lcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qgcwaehxw309aex2mrp0yhxvmm4de6xz6tw9enx6tcxfglvj
2025-10-02 10:47:14 from 1 relay(s) ↑ Parent Reply
Do you keep locks on your house? If so, why? Someone can just kick the door down or throw bricks through your windows. I also follow a youtuber that has shown me how to pick basically any lock ever made. So why have locks?
2025-10-02 11:13:51 from 1 relay(s) ↑ Parent Reply
I think the idea of a size limit is not the same as censoring transactions. Let me explain... Everything has size limits. Blocks were originally limited to 1MB/10min. There was no jpegs in there, but still the number of transactions was limited. The blocksize was eventually raised in 2017 to be effectively 4MB/10min. There are downsides as the blockchain can grow up to 4x faster. Nodes have to store these blocks forever. Each transaction has a maximum total size limit of roughly 100KB. If each transaction used the maximum of 100KB, you could only have about 40 transactions every 10min. Luckily the average transaction only uses about 225b. The average number of transactions per block is around 3k/10min. When OP_RETURN was first introduced by Core it had a default size limit of 40b. The default was later changed to 80b by Core. Knots kept the default of 40b. Node runners could change this to anything, including zero. Core v30 will change the default to be effectively 100KB. Node operators can still change it. However it has been marked as deprecated, meaning in future versions of Core the setting will be ignored. Which has the same effect as setting it to 100KB. The more 100KB transactions you try to cram in 4MB of space, the less average size 225b transactions can fit. This can cause transactions to be delayed and have higher fees. Knots nodes want to have as many transactions as possible by limiting the size of transactions they way they always have been previously. Not to censor. This keeps it fast and fees low. The goal is to use Bitcoin as money not for sending JPEGs. Core wants to allow these large JPEGs by default, which can clog up the blocks with unnecessary data. It still has size limits, just much larger.
2025-10-02 11:41:05 from 1 relay(s) ↑ Parent Reply