Upgrade to bitcoin 24

[friedger]

Is your feature request related to a problem? Please describe. bitcoin 24 supports rawtr descriptors

Describe the solution you'd like Upgrade core to 24.0.1

Describe alternatives you've considered There is no alternative to bitcoin knots :-)

[jotapea]

I think Bitcoin Knots has the opportunity to increase its relevance by NOT upgrading to v24. @luke-jr is a voice against the misuse of the bitcoin block space, and v24 allowed very easy storage of arbitrary data.

This comes from someone that actually supports letting anyone store anything they want as long as they pay the fees. BUT, the backwards compatibility of Bitcoin is even more important to me.

I believe Bitcoin lost some (maybe a lot) of its mysticism when suddenly blocks could be up to 4 MB! Me as someone that has been following Bitcoin for the last couple of years definitely took me by surprise.

I have a suggestion for @luke-jr : have easily accessible links to the pre / post soft-fork versions of Bitcoin Core. But beside these, have the same versions for Bitcoin Knots. Then, these Knots versions could be the ones that can continue having critical updates done to them.

The Bitcoin Core team has become the main centralization of the protocol. And I can understand there are pragmatic reasons for this. But then, if this small group of people are making the decisions of the future of the protocol, with each soft-fork Bitcoin becomes more like a crypto.

A "crypto" being a group of people deciding to do "something different to Bitcoin"... but what is "Bitcoin" with continuous soft-forks... 🤔

[luke-jr]

The missing spam filter issue was introduced in v21, unfortunately. The next version of Knots will definitely include at least an option to enable it, regardless of version.

That problem is not caused by a softfork, mind you. More importantly, using software that fails to implement a softfork will do nothing to stop it, but only cause your own node to be insecure.

As for this issue itself, it's likely Knots will have to skip v24, and jump straight to v25.

[jotapea]

Thanks for the response @luke-jr. I don't want to take much of your time, but can you help me understand the following:

If an old node does not update the softfork features, but DOES update security vulnerabilities, would it still be insecure? And if it does, why?

[luke-jr]

Yes, because the softfork features are themselves a security fix. The security of a full node comes from enforcing all the rules. That includes any new rules introduced by a softfork.

[jotapea]

I'm still not convinced, as my understanding is that soft-forks are opt-in. Bitcoin is supposed to be about not changing the rules, but yet a small group of people are doing it and then "soft-forcing" everyone to update their nodes.

This can be the expected practice for general software, but I didn't expect this from Bitcoin.

Back to my argument of these soft-forks / new-rules making Bitcoin become just another crypto. And I believe a way to counter this argument is to continue supporting old node versions.

Do you see any merit to this?

[luke-jr]

No, a small group can't "soft-force" anyone. It's necessary because the entire community has chosen to activate Taproot.

It is not possible to have divergent consensus rules on the same network.

[jotapea]

I wouldn't say "the entire community", but I have seen stats of the active nodes, and it does seem like most people are in post-taproot node versions.

In my opinion the Bitcoin community has lots of very bright people, but sometimes I feel that many fail to see how they are becoming arrogant, in a "we know what we are doing" way.

One example is how the protocol developers don't seem to care about continuing to support pre-soft-fork versions of Bitcoin, failing in one of the most basic principles of the protocol: "nobody can change Bitcoin". This is becoming a lie with every soft-fork.

And my point is that I think this can be fixed by changing the attitude of the developers towards the old versions of Bitcoin. The "consensus rules" argument is what I always hear, but if these are supposed to be soft-forks, then new rules shouldn't break old ones.

[tsjk]

No, a small group can't "soft-force" anyone. It's necessary because the entire community has chosen to activate Taproot.

It is not possible to have divergent consensus rules on the same network.

I too am rather skeptical of taproot. However, I have come to realize that there is no such thing as a community. I think many node-runners are oblivious to what running a certain version means, and that imagines that newer is always better. This is the consequence of one-click-deployment tools, and stuff like Umbrel and others, and thus people just run whatever is bundled. It'd be unreasonable to expect that the providers of such aids should act as some guardianship - even though in some respects that'd be nice.

[luke-jr]

v25.1.knots20231115 has been released. It extends the pre-taproot spam filters to also cover taproot transactions, and includes a few additional spam filter that can be used to target ord spam specifically.

[tsjk]

v25.1.knots20231115 has been released. It extends the pre-taproot spam filters to also cover taproot transactions, and includes a few additional spam filter that can be used to target ord spam specifically.

I think this will be found interesting by many. Would it be possible to have a complete example that accomplishes this filtering?

[luke-jr]

• Add maxscriptsize policy option (default 1650 in Knots 25.1)
• datacarriersize: Match more datacarrying
• Include extra weight (-datacarriercost) in vsize policy consideration

[jotapea]

Hey @luke-jr I've been thinking about the old bitcoin versions argument, and have an idea that maybe is a great middle ground solution...

What if Bitcoin Core can select "emulating" running like a previous version? And it doesn't have to be ALL versions, it can focus on only the soft-forks.

[luke-jr]

Bitcoin Core is kinda off-topic here. And it's not really clear what you mean by that.

[jotapea]

It can be implemented in multiple ways I assume. The simplest can be supplying a combination of config flags that make your node act like a previous bitcoin version.

[luke-jr]

"act like" is undefined

[jotapea]

Good point. How could it be defined? Maybe initially only scope it to the wallet and the transaction types (and addresses) it can do.

But then it could be extended in some ways, like I'm thinking the blockchain storage itself can be different for the "pre-segwit" config, meaning only having 1MB max blocks...

If this doesn't make sense, I would appreciate educating me on the topic lol