Didn’t have time to watch the whole thing, but Segwit and Taproot were even more elegant than Wicked explained in the first few minutes. The new rules only apply to blocks that contain segwit inputs or taproot inputs respectively.

Regarding segwit, if your block does not contain any segwit transactions, it doesn’t require the newly introduced witness commitment. As unupgraded nodes would consider transaction inputs following the new rules non-standard, they would not collect such transactions into their mempool and not include them in their block templates. Throughout segwit signaling, and even after segwit was activated, unupgraded miners could therefore still build valid blocks that simply did not include any segwit transactions.

For Taproot similarly, transactions containing P2TR inputs would be considered non-standard, and miners would not include them by default.

Since neither of these two soft forks’ deployment mechanisms had a mandatory signaling phase, unupgraded miners would just chug along fine on the same chain throughout signaling and even after activation, beyond potentially missing out on juicy segwit/taproot transactions.

this still took way too long

the only good news?

I got through the entire thing, and used tools [an HTML parser and an Emacs keyboard macro]

Okay, so today I want to talk about soft forks versus hard forks, how they can result in chain splits or not, and then talk about some BIP 110 updates, um, some of the activation information which has been updated and how I envision that activation playing out in the future.

When you're talking about a soft fork or a hard fork, what you're really talking about is a change to the consensus rules. Okay? So, whenever you change these consensus rules, which are the rules dictating how blocks are created, you are either loosening those rules or tightening those rules. Okay? If you're loosening the rules, you're activating a hard fork. And if you're tightening them, you're activating a soft fork. An example of a loosening of the rules is if you were to take the current block size limit and increase it, you'd be loosening it. And as a result, you would be creating a new set of rules which are no longer backwards compatible because those larger blocks that you're now accepting would not be accepted by the older node software. Okay. Okay. And then on the opposite end with the soft fork, you're tightening the rules. So if you were to for example decrease the block size, that'd be a tightening of the rules and that change in consensus would be backwards compatible because your smaller blocks would still be accepted by the older nodes which had a higher block size limit. Okay. So that's the difference between hard fork soft fork.

why it you know one is not backwards compatible and why why the other is.

Okay. So now let's talk about some circumstances that could lead to either causing a chain split or not.

In the case of a hard fork, if you loosen the rules on your node, but then there's a sufficient amount of users and miners who don't want to change the rules, right? Then at the activation height, you'll cause a chain split.

You and the other users who want to change the rules and the miners you bring along with you will now mine according to those new rule sets. and you'll mine blocks that are no longer valid to the older nodes and then the older nodes will continue on their legacy chain with the older rules and those you know miners mining those blocks will just build on that chain. So that results in a chain split and this is what happened with be with Bitcoin Cash. Okay.

Um, an example of a hard fork with no chain split would be if every single user and every single minor updates and then as a result you don't have any blocks left on the legacy chain. Now, a interesting example of a hard fork that will not result in a chain split that is going to happen in the future is the timestamp overflow bug fix. There's a bug in Bitcoin's consensus that will brick nodes in about 80 years, right? In 21106 or so.

And if your node does not update to fix this bug, it will get bricked and it won't follow any, you know, any block any chain anymore, right? There will be no more blocks on that chain. So in that case, the only nodes that survive are the ones that update. So every single node, you know, in theory has to update if they want to continue to be active on Bitcoin. So that's an example of a hard fork with no chain split. Um, in terms of a soft fork, let's say a soft fork with no chain split, this is kind of like what we've seen in the past two soft forks with SegWit and Taproute.

But typically what this means is you have convinced the super majority of miners if not all of them to begin building blocks according to these new tighter set of rules. Um, what you don't have is you no longer have any miners left that want to mine only according to the older rules, thereby creating blocks that are now incompatible with the new nodes, right? Um, because it's kind of like the hard fork but in reverse. So in this case, if a new node that has the tighter rule set were to receive an old block that was slightly larger, it would now reject that because it's, you know, no longer um adhering to its tighter rule set. Okay.

So, a soft fork that results in no chain split is one where there's no blocks being mined that only adhere to the older rule set and all the miners have, you know, begun to mine with the new rules in mind and enforcing them and so on and so forth.

Now, in this case, the older users don't have to worry because they're taking along for the ride, right? um even though they have a looser set of consensus rules, the new consensus rules still fit within their rules. And so all of these new blocks are still valid and you know, they just go along believing nothing's really changed, right? If they're observing the chain, they might realize, oh, blocks are smaller and we don't seem to be getting above this threshold. Um but their node is chugging along and verifying these blocks and to that node you know it's still following the longest chain with no interruption and um you know it itself hasn't updated any anything right so it can be backwards compatible older nodes will still sync to the longest chain tip etc etc so then how do you get a chain split with a soft fork now this is the one that I think a lot of people are confused about.

If you were to say um have a soft that has a very small amount of support both in terms of the users and in terms of the miners, then what you get is at a certain activation height, those tighter rules come into effect and the smaller set of users and miners, they might start building blocks on those tighter, you know, on those tighter rules And as a result, they would also reject any that don't adhere to the tighter rules. So if the activation height was here, and let's say this legacy block is found first, the soft fork nodes will reject it because it's not um following the new rules, and they're just going to wait until they get a block that does. Okay.

So meanwhile, the legacy chain is building on this chain and the software chain is waiting, right? And as long as the hash rate on the software chain is smaller, their chain on average should grow slower. So while they're waiting for the first one, maybe the legacy chain mined a couple and then they get a second one and then they mine a few more, right? So then the legacy chain kind of outgrows the soft fork chain and you have a chain split whether or not the soft fork chain persists, right? Meaning the users and the miners on it are stubborn and they just want to keep it going even though it's growing slower than the legacy chain. Now that's something we have to actually observe and see how these things play out in the wild, right? We can speculate, but we've actually never seen a persistent chain split caused by a soft fork.

That's never happened in Bitcoin's history. So, one of the reasons why I'm kind of excited about BIP 110 is because I think there's a small chance we might observe this happen in the wild and then learn from it. Um, but in all likelihood, I don't think it'll happen. Um, and maybe let's talk about that now, now that we've explained the differences here. Okay, so now let's talk about the BIP 110 updates.

... and I've hit SN post length limits! Not gonna climb the "talking to myself" cliff, unless anyone zaps this first block; and you shouldn't, because I haven't done much cleanup of the auto-generated captions, only formatted them into paragraphs.........