pull down to refresh
So offer a deal? Soft-fork in covenants to soft-fork out larger op-returns? This is beyond my technical understanding.
reply
reply
best take
reply
Covenants are instant ethereumification.
If Knots people weren't retarded they'd focus on fighting that.
reply
You'll change your tune once the chain starts getting spamed with CSAM. There are plenty of people that will do it just because they don't like Bitcoin.
reply
If team Knots want to get serious then they should focus on technical merit, being wrong about prunable outputs just shifted the goalpost down this track which is a losers bet. Arbitrary data has always found a way, Knots is powerless to prevent that. Larping about filters in mempools show Knots users ignorance, they don't even know the purpose of the mempool or why they run one at all.
It's sad because I really want to support alternatives to Core, afaik Mechanic and Luke are on CTV just like the rest of them... maybe this is all kayfabe so people sleepwalk past etheriumification.
reply
OP_RETURN isn’t a knob you can twist like stereo volume. It’s baked into the protocol at a fundamental level. Changing it would be like replacing the dot on an ‘i’ with a triangle. Small on the surface, but breaking the rules of the language itself.
reply
Yea and it's not going anywhere, it exists and has for ages, and it only exists because it's less bad than workarounds spammers have come up with.
Miners could censor arbitrary data today without a fork, but they aren't, hense a fork won't stick.
If you want to minimize further damage start fighting the next battle, not the lost one.
reply
Then why make the change v30 is proposing? Seems that it isn't necessary. so round and round we go.
reply
Core makes a lot of useless and potentially hostile changes, they do every version... I'm already anti-Core.
The bar for Knots to be better is not that high yet you're still failing to clear it.
That's why there is going to be a consensus split. What filters/knots advocates are advocating for (no chance of csam on their node period) isn't compatible with Core 30.
Even a small number of Core 30 nodes 'in the wild' means that something/possibly anything could get through into blocks that is reprehensible. Which means knots users have to store that data indefinitely.
Unless knots users decide to run pruned/non-relay nodes (in which case bitcoin dies if everyone does that) OR there is a consensus change to permanently fix the "spam" issue so that knots users can run a full node again and not have to worry about csam again at least in op_return.
In which case there's a consensus split/consensus change with 2 different tokens, 2 different networks which is where we're headed in my opinion.
Bitcoin Core and Bitcoin Knots (Bitcoin Pure?) similar to Bitcoin and Bitcoin Cash in 2017.
reply
There's so much lack of technical understanding here I don't even know where to begin. Unfortunately par for the course with Knots supporters, whom I otherwise align with sentimentally.
I'll just leave this from another comment in the thread.
Miners could censor arbitrary data today without a fork, but they aren't, hense a fork won't stick.
reply
We can reduceOP_RETURNlimits in a soft fork afaik.
This would cause a hard fork.
reply
reply
reply
Luke can also just make it a true chaintip fork, though. There's a nice integration point right here.
Bonus: if you do it without height threshold while implementing Luke's full definition of datacarrier as was recently explained here, you can even fork off those biblical texts someone put on the chain!
reply
A block mined on the current consensus might not get accepted by nodes with the new OP_RETURN limit, thus causing a chain split. All miners would have to also implement that limit.
reply
OP_RETURNlimits in a soft fork afaik. Maybe we can get near universal support for a covenant soft fork if we reduceOP_RETURNthis way.