Exactly.

It's a common mistake to think of 'dev teams' as being distinct from each other. In open source, that can't really happen. Anybody can contribute to multiple projects simultaneously and I can, without your consent, copy your open source code into mine.

In open source, there will always be (at least) one repository that has the best code. And therefore, as it's the best code, there is no need for duplicate repositories and therefore there will be just one repository.

This *appears* centralized, but it's not.

We want on-chain fees to be as low as possible for as long as possible, as it helps with the security and scalability of Layer 2s

Similarly, we don't want people to put more monetary transactions on-chain "in order to price out the spam", for the same reason basically. If your monetary transaction is going to increase the size of the UTXO set, we'd prefer you to use a Layer 2, even if that means the blockspace is taken up by an OP_RETURN instead

The only time we want people to put transactions on-chain is if they consume more inputs than the number of outputs created

TL/DR: the long term goal is to keep blockspace cheap, to help with scaling, and for the inevitable spam to be in OP_RETURNs and in Witness data

Count yourself lucky for not knowing what RTDS is.

It's a proposal to change bitcoin that doesn't include any proposals to make it easier to run a node, or make bitcoin more private, or to help decentralise block templates, or to help scaling. It doesn't contain anything good

It's practical effect, like Knots before it, would be to put more spam into fake pubkeys, thereby making it hard to run a node. It also increases mining centralisation

"where we were before Core30"

i.e. a world where:

Large op_returns were being mined anyway, helping node runners by keeping the spam out of the UTXO set,

and understanding the importance of miner decentralisation - where we help the small miners (template builders, to be precise) to see the same transactions as the big miners - many of the noderunners (using many versions of Core, and some running LibreRelay) were helping decentralisation via their relaxed mempool policy.

That's the world we were on then, and the world we remain in today, and the world we'll be in after you fork off.

The Bitcoin Network makes its own decisions, and doesn't need permission from you - or from Bitcoin Core - when it decides to relax mempool policy in order to help noderunners and help small miners who are building their own templates

Liar

In that case, between two and three weeks until their stricter rules, e.g. against large op_returns, start being enforced

Three weeks is the maximum because the 55% threshold could theoretically be reached just about halfway through the two-week period. In that case, the remaining few days would not yet be LOCKED-IN. After those few days, then we would have two weeks of LOCKED_IN, then finally after that they start enforcing their rules on transactions

Thanks for that. I'm going to follow up here, but I apologize in advance if it seems like I'm changing the subject a bit 😀. My goal is to clarify the order of events, and I'm doing that to help myself think about exactly when we should reject blocks:

TL/DR: even if 55% signalling is reached in one block, the RDTS rules won't be enforced until at least two weeks later.

Two scenarios, discussed separately:

The simplest of the two scenarios is that it never reaches 55% hashrate. In that case, mandatory signalling starts at 961632. This is the first time that BIP110 nodes can reject blocks that would be acceptable to the conventional (i.e. Taproot) nodes. This doesn't guarantee that a split will happen immediately, the BIP110 miners could be lucky and get the first few blocks, but it is the earliest [in this scenario] when a split could occur. After 2016 blocks in this state, they reach their 'LOCKED_IN' state. From the BIP "The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664". During LOCKED_IN, further signalling is *not* required, and miners do not enforce any of the RDTS rules on transactions. It's only in the following retarget period, that they finally reject transactions with large OP_RETURNS and all the other banned transactions

So, summararizing the timeline in this "low hashrate" scenario:
- 961632 to 963647: mandatory signalling, i.e. a permanent chain split can occur here.
- 963648 to 965663: LOCKED_IN. No rules applied, not even any mandatory signalling
- 965664 onward. ACTIVE. Blocks are rejected based on whether the transactions follow the rules


The second scenario kicks in if they get 55% of hashrate. Once they get 55%, they don't immediately reject non-signalling blocks, and they don't reject big OP_RETURNs. When they reach 55% (1109+ blocks out of 2016), the *following* 2016 blocks are in the LOCKED_IN state, i.e. no rejection rules applied. After 2016 blocks in LOCKED_IN, then they switch to ACTIVE and reject blocks with large OP_RETURNs

Interesting! Thanks for looking into this

So, if I understand your video and GitHub correctly, it'll Terry l reject the 1109th signalling block in a given 2016-block difficulty adjustment window

After their "lock-in" height, I guess you reject *any* signalling block? I ask because they start rejecting immediately at the lock in height

So I think that means having a threshold of 1, instead of 1109, from height 961632

Well actually (🙂), the feet and metres do eventually line up

An inch is now officially defined at 25.4 millimetres

I think all the "standard" units are now defined in terms of the metric units

Anyway, brilliant video!

What if it's a successful open source project? i.e. no money is made, but they might claim copyright over the code produced?

I can see this, from Amethyst. Haven't tried any other client

Maybe it depends on the relays?