I see both sides here.
Taproot had unintended consequences — one of which is Nostr. Nostr identity is based on the Taproot BIP, and it's given Bitcoin the beginnings of a social layer.
There’s a difference between maintenance and renovation.
You maintain a school by mopping the floors; you renovate it by adding a new door to a corridor.
In any system or standard, there’s always a grey area between minor maintenance changes and behaviour-altering changes.
At the W3C, we have something called “class 2” changes — used for typos, improved examples, and other edits that don’t affect behaviour. They follow a lightweight process. Larger changes are “class 3” and go through wider review.
It’s common to see people try to pass class 3 changes off as class 2 — but the rule is: if there’s disagreement, it’s not class 2. (Of course, who defines disagreement is a whole other problem.)
Bitcoin might benefit from a similar distinction: separating maintenance from behavioural changes, and handling them with different levels of review and process. Discussion is always good in these situations.
Login to reply
Replies (2)
Thank you for your insight.
For me there is one “core” question.
Why do we need to de-restrict the OP_RETURN field?
Is there any benefit?
Do you have any insight into this question?
Hi Mike,
You are asking the wrong question. Why do we need to restrict the op_return field?
Restricting it is not preventing anyone from using large op_returns.
Also, you are not a customer of core and running 3 nodes doesn't give you any votes.
If you want to run knots, go ahead. The disadvantage will only be yours because you won't get accurate fee predictions and you just be a part of a silo'd sub-network of the Bitcoin network with limited knowledge of the rest of the network.
Nobody needs to convince you because your nodes don't matter to anyone but you, especially if they won't relay valid transactions.