Nostr Archives

In hindsight, wasn’t Taproot a hostile fork? 1. Over 5 years later, hardly anyone uses it, except spammers. No major product market fit yet. 2. It was a “nice to have”, wasn’t a response to a threat (debatably like segwit was). 3. It ratcheted up the spam problem, which creates another problem now with another possible fork. If you supported Taproot, then what did you get wrong, such that you supported a hostile fork? Do you apologize? Before you get to anything else, it thinks it’s important that you ask yourself those two questions, then reflect on the answers.

💬 25 replies

Replies (25)

Ronin23d ago

Core should be ultra conservative, they should only make rule changes when people and businesses start screaming demanding that new feature.

0000 sats

00x2F9E23d ago

Great privacy benefits and on chain savings, the things you people try to fight man. Get a fucking grip.

0000 sats

Toxic Bitcoiner23d ago

I know that’s the claim and I believe it. But in practice is it being used that much? Does that current usage or hypothetical future usage justify the unintended negative consequences that we’re dealing with now?

0000 sats

Iihsotas23d ago

The consequence now is we have a modest amount of chain growth. Hardly worth bunching panties over. The biggest threat facing Bitcoin is a sustain spam attack on the utxo set that quickly increases the ram requirement to a point past 16gb. The retarded JPEGs guard against this ironically.

0000 sats

JJacob23d ago

But the reality is that it have been a net negative

0000 sats

JJacob23d ago

AFAIK no one suspected Taproot to create this problem. This is from Luke in a debate. The problem was the city current core devs stopped fighting spam. But this should be a lesson of more careful development.

0000 sats

Bob Social, 23d ago

Core must be ultra-conservative, btc is fine, change nothing until (we) the users and businesses are screaming for it🤔 when ...

0000 sats

Bob Social, 23d ago

when no one is demanding it loudly, it doesn’t belong in the core🔍❗️😯 (*) Stability first, (*) innovation earns its way in, (*) TO PROTECT BTC => core isn’t a playground for "too many ideas" (= it will divide us, this is what bankers want😑😓) => core is the last line of protecting the code and trust👀. (1) Every unnecessary change is an attack on reliability. (2) If the ecosystem isn’t begging for it, don’t touch the core. (3!) Why increasing the possibility to break something good, when we the users (MOST) aren't asking for it?

0000 sats

Toxic Bitcoiner23d ago

How do JPEGs guard against a UTXO set spam attack?

0000 sats

Toxic Bitcoiner23d ago

“The consequence now is we have a modest amount of chain *AND UTXO set* growth.” Why did you leave that out?

0000 sats

Iihsotas23d ago

Because the utxo growth only reduces in a post 110 world if you assume spammers don’t use p2sh to continue their trade or that a state actor doesn’t step in to purposefully spam the chain. The fact is spammers keep block space in demand. Monetary users don’t, which leaves us vulnerable to a utxo attack that could happen so quickly all pleb nodes become useless

0000 sats

Iihsotas23d ago

They take up blocks making a pure utxo attack more expensive and take way more time to pull off. The ram requirements growing too fast will centralize bitcoin. The hard disk space growing slightly faster will not.

0000 sats

Toxic Bitcoiner23d ago

The UXTO set from the spam is an issue. Which you said in another comment, but not this one?

0000 sats

Iihsotas23d ago

Spam in the form of a larger witness data transaction means there is less room for dozens of small utxo spam transactions and it cost some modest growth in hard drive required to host a node. Under 110 the cost of attacking the chain with small utxo bloating transactions drops dramatically but worse the time it would take to bloat the utxo set accelerates to an unsustainable level. After activation it would cost around 160 million to spam the chain to the point where in 6 months no nodes with 16gb of ram or less could stay synced. This is a threat. Currently it would cost 10x to do this and it would take an extremely long time because the degenerates like their retarded JPEGs enough to pay 5 grand to put them on chain. TLDR we are being guarded by retards.

0000 sats

JJacob22d ago

Spam is definately an issue. Not now but two years ago main chain was almost dead for economic transaction and full of spam/scam. Im not sure we need bit110 but a reverse to v29.0 with spamfilters would go a long way.

0000 sats

Toxic Bitcoiner23d ago

Then could a compromise where 110 drops the changes to opreturn, but leaves everything else be the best of both worlds?

0000 sats

JackTheMimic23d ago

So, to be clear you're saying it's bad that they make invalid arbitrary sig data so they can never spend their coins? Are Satoshi's coins sitting in over 22,000 different addresses bad? You have to keep those in the UTXO set too.

0000 sats

Toxic Bitcoiner23d ago

You assume there will be JPEGs taking up blocks, why? What if there aren’t JPEGs taking up blocks?

0000 sats

Iihsotas23d ago

Then We would have less utxo and hard drive bloat…and almost no demand for blocks which makes a dedicated attack almost a certainty. They don’t have to kill Bitcoin they just have to make it impractical to run a node on consumer hardware. If no one is running nodes except in data centers Bitcoin is captured.

0000 sats

Toxic Bitcoiner23d ago

By JPEGs did you just mean in opreturn only? Because aren’t inscriptions considered JPEGs too?

0000 sats