They took their time - low time preference was their super power. For example, it took 70 years to carve this chapel in an underground salt mine in Poland: https://www.visitwieliczkasaltmine.com/st-kingas-chapel

Wow - would not have guessed that!

Wow! Just confirmed that myself on Google. DuckDuckGo still returns it as the first result.

Duuuuudddeee - learn about this issue. Core v30 opens the floodgates for VC backed startups to store huge amounts of arbitrary data on the Bitcoin blockchain. That’s not what Bitcoin is about. Bitcoin is money - not storage. Knots doesn’t magically fix the spam problem, but they are working on it rather than enabling it.

Do the work to read the Core developer mailing list and GitHub threads. Core rejected this change twice in the past two years because it’s bad for Bitcoin and therefore controversial. In v30 they pushed through unlimited data storage despite there still being a lot of disagreement - AND they are still unable to make a coherent argument for why we need to change this default that’s been working fine since 2014.

That’s interesting - I hadn’t seen that.

There’s a big difference between “expanding its capacity” to say 160 bytes and removing the limit entirely as Core v30 does. I think there would be much less concern if this was an increase to 160 bytes to support some vaguely plausible use-case.

“Spam will continue until consensus changes.” - I completely agree with you.

That doesn’t mean we shouldn’t run nodes to filter it. And yes, I also know spam flows around nodes that filter it.

I see Knots as a signal to the network that Bitcoin is money, and spam is worth fighting. If enough people run Knots, then Core devs and eventually maybe even miners will decide to join the fight against spam. Blocks that mined spam will be relayed slower by filtering nodes than blocks that didn’t mine spam because compact block propagation requires the previously filtered transactions to be re-downloaded by a node to validate the block and this propagation delay provides a small economic incentive for miners.

In a - probably unrealistically ideal - world, a few years from now we might have enough support for some consensus changes to eradicate the main hacks for embedding non-financial data. We’ll only get there if we at least try to combat spam between now and then.

It’s good that you’re not upgrading yet. Take the time to think through the impact of opening the doors for a new wave of non-financial spam from VC-backed startups that want to use an “officially approved” way to store their data in the blockchain (because a one-time mining fee for permanent storage forever on full-nodes is cheaper than funding their own layer 2 network). The existing hacks spammers use get a 75% Segwit discount compared to using OP_RETURN, so those spammers aren’t going to do extra work so they can pay more. We need to filter what they’re already doing - that’s the battle Knots has taken on and Core has refused to attempt because they are philosophically aligned with miners - “any consensus valid transaction a miner could mine should be relayed and stored by all nodes”.

Long-term, we need a third option that takes the latest Core version and patches in reasonable default filters (that node operators can turn on/off themselves), with no personality-related drama like we currently see between Core and Knots.

Short-term we need to run Knots (which at the moment is essentially Core plus tighter spam filters) to signal to the network that we want Core developers to fight spam instead of worrying about how to enable their buddies at VC-backed startups to spam the network in “approved” ways.

- listened in disbelief to Bitcoin Core devs explain v30 change

- read code in policy.cpp in both Core and Knots

- got frustrated that Knots doesn’t make it trivial to review its changes to Core because it includes other stylistic code changes and bug patches that make diff verbose

- did the work anyway to understand the differences

- concluded that the extra policy code in Knots is reasonable

- now running Knots 29.1

I agree that we should listen to people who want to build, and even make conservative changes to accommodate them. Core could start to filter inscriptions by default and engage in the whack-a-mole task of continuing to add filters that prevent and discourage arbitrary data outside OP_RETURN, then simultaneously increase the data carrier size limit so OP_RETURN can carry a little more data - e.g. for some reason Citrea apparently needs 144 bytes, so we could set a new limit a little larger than that. I think Adam Back threw around 160 bytes as a compromise number to resolve the v30 drama. That sounds reasonable to me as long as we also stomp out data embedding everywhere else.

What am I missing in that thread?

Reasonable financial transactions are not as large as this extreme example, so if the node filters out and doesn’t relay excessively large (non-financial) transactions based on size and doesn’t waste any CPU trying to understand what is in those transactions, the DoS problem doesn’t exist, and occasionally the node estimates fees and what will be mined in upcoming blocks poorly because a miner received and mined a giant transaction out of band. I’m obviously not understanding what the concern is and would like to understand it.

Good decision. I decided to diff the policy.cpp code of Core and Knots to understand the key differences - I can recommend that. The code is not difficult to read.

Some types of centralization are good. Would you like people to throw garbage all over the street (including your front lawn - where you need to deal with it) or use “centralized” garbage cans?

That’s kind of like asking big tobacco’s lawyers if smoking is bad for your health. It’s telling that some of them did acknowledge that v30 may increase legal & political risks.

Knots for now.

Unfortunately Core v29 chooses not to filter inscriptions or that would have been my choice.

Would like to see Core adopt the same filters of non-financial data that Knots already has, and make them defaults in v31 so we can all move on from this drama.

If Core doubles-down on the blockchain being for arbitrary data storage in v31, then they’re shitcoiners not bitcoiners and we will need to create a new reference version.

Almost - I thought that too. Then I looked at the Knots and Core transaction filter code on GitHub. Knots filters out runes, inscriptions, and some other spam that Core refuses to filter. I wasn’t pro-Knots before this drama inspired me to actually look at the code. Core could easily have accepted Luke’s PR to filter this non-monetary garbage but philosophically they don’t believe that Bitcoin should only be money - as you saw in that video with one of the Core maintainers talking about cat videos and wizard JPEGs being fine in the blockchain.

Run the node that aligns best with your personal values, and be fully aware of what you are choosing.

TLDR; the core issue behind the Knots vs. Core v30 debate, excluding the personal attacks, can be summarized as Knots = “Bitcoin is only money” whereas Core v30 = “The Bitcoin blockchain is free data storage, and Bitcoin is also money”.

The main consideration is whether you want your node to relay only financial transactions or also arbitrary data that will be recorded on the blockchain. Knots focuses on relaying financial transactions, filtering out as much spam as reasonably possible - but it cannot block all spam. In contrast, the new Core v30 will relay the existing spam currently encountered by the network (like older Core versions already relay) and introduces a new way for spammers - such as VC-funded startups - to exploit nodes for free data storage without paying additional miner fees to bypass node filters.

Relaying and storing arbitrary data also increases legal risks for node operators compared to channeling that data through the large miners’ choke-points (e.g. via slipstream). Those large mining companies can be held accountable for the arbitrary data they choose to include in the blockchain that nodes refused to relay, creating an incentive for them to avoid mining the most awful content.

Hi Daniel - this v30 drama would be a great topic to cover (again) at PubKey now that it’s heating up more. It would be great to see something like a moderated debate between Kratter & Antoine. Or better yet, Luke or Mechanic vs. Antoine.