 What would be, in your opinion, the best way to activate a soft fork? Recently, Matt Corallo reopened the discussion on the developer mailing list about what would be the best way to activate a soft fork. Can you explain differences between BIP8, BIP9, and more recent proposals, minor activated, user activated, etc? I would really like to know your view on this topic, both technical and opinion. Alberto, it's really funny because over the past, I guess, six to eight months, we've had an ongoing discussion about the development of some important changes that are coming to the Bitcoin system in the form of three proposals that work together called Schnorr, Taproot, and TapScript. These have now been formalized as Bitcoin improvement proposals and Schnorr signatures, which have a number of very, very interesting qualities and capabilities that you can't do with ECDSA signatures. Taproot, which allows you to have a common execution path in a script for the consensus case in a multi-party script execution. And finally, TapScript, which is a number of changes to script, including the implementation of Merkle, Merkleized Abstract Syntax Trees, or MAST. Basically, what this means is that the script language in Bitcoin is going to change with these proposals, and there will be an optional new way of constructing scripts in Bitcoin, which will involve making trees of scripts, where each of the leaves in a tree is a different script execution path, and then selecting those using Merkle tree paths. In addition, having one of those scripts being the case where everybody agrees, which can make all of these scripts appear like a single payment to a single public key, so that all kinds of different exotic scripts and smart contracts that operate from Lightning Network to Coinjoins to other things like that can appear to an external observer as simply a single payment to a single public key with a single signature. And of course, snore signatures that have these magic capability of being able to aggregate signatures, adapter signatures, as they're known, and threshold signatures in order to get all of these neat tricks. For the past eight months, this has been nearing finalization, it's gone through several rounds of reviews, and the funny thing is that until about a month and a half ago, no one talked about the elephant in the room, and the elephant in the room in this case is, how are we going to activate this change given the experience of Segwit? And the experience of Segwit was a wholly scaling war that broke out over a technical change that shouldn't have been controversial from a technology perspective, but became instantly controversial because it turned into a political decision, not about which scaling mechanism should be used, but more importantly about who should have the power to make that decision. And once it went down that road and it became about who should have the power to make that decision, the technical change itself became heavily politicized and turned out into an all-out competition between miners, developers, exchanges, etc., etc. Very, very controversial, a bit of a mess, a mess that lasted for a couple of years and led to a couple of forks of Bitcoin. So until recently, nobody really wanted to talk about how do we make the activation of a soft fork like the Schnur-Taproot TapScript set in a way that works a bit better. Now, Schnur-Taproot and TapScript are soft forks, that means that they are backwards compatible opt-in changes. After these things are introduced, you can still continue to do transactions the old way without changing any of your behavior. You don't need to upgrade wallets, you don't need to upgrade clients, and there will be no radical change for the miners with a hard fork. It's a backwards compatible opt-in feature. In the past, there have been a number of ways to activate this. Bip9 is the mechanism that was used for Segwit activation and was introduced for Segwit activation. And Bip9 is a mechanism where miners signal their readiness for activation by changing some bits in the version field of each block in order to signal readiness. Now, once a specific threshold has been achieved, 95% of all of the blocks in a sequence of blocks, a rolling window that looks backwards at the most recent x number of blocks. Once a certain percentage of those blocks are all signaling readiness, then the change is locked in and is activated subsequently a few blocks later. That's basically the plan for Bip9. Of course, what happened with Bip9 is that for almost a year and a half, there was a battle about that signaling and the threshold barely moved until the Bitcoin Cash hard fork. And at that point, on August 1, 2017, Segwit was activated. Bip8, as far as I remember, is a so-called flag day activation, meaning that a specific date is set and at a specific height in the blockchain, the feature is activated. Other mechanisms that have been suggested, there's obviously miner activation where miners can simply turn on the feature and start accepting it and not rejecting blocks that have this new script mechanism in them. User activation, where users can start configuring their nodes to accept this. And then there's various variations of miner and user activation that involve different degrees of hostility towards transactions and blocks that do not accept this change. For example, a user-activated soft fork might also include rules where any block that isn't accepting transactions like this or isn't signaling readiness is not propagated by the users. And of course, that doesn't mean that block won't get mined and it won't get propagated. It might, but it's certainly going to slow things down if users configure their nodes to not propagate such blocks. Miners can also do that. Miners can create a kind of embargo on blocks where they say we will only accept blocks that have that feature or we will only accept blocks that don't have that feature and refuse to mine on top of reject or block any blocks that don't have that. Again, that's a level of hostility that may backfire very, very badly for both users and miners because then it creates a divergent consensus, two different perspectives on consensus. It can cause a hard fork in the network. It can cause a hard fork of the blockchain. It can cause all kinds of forks in all kinds of places, as well as a lot of drama and animosity. Matt's current suggestion is to use a mechanism that allows for a long period of activation and followed by a flag day. So basically, it's kind of a hybrid. If I remember correctly and I don't want to mischaracterize it, but the basic idea is that miners are given the opportunity to signal readiness and regardless after a period of time, if there is no readiness signaled, then the soft fork is activated regardless. So that's kind of a hybrid of the two approaches, which seems to be a position that more people are comfortable with. Some people are worried that this timeline is too long, so it could take two to four years for this to activate. And as is the case in many Bitcoin developments, there is an element of conservatism in the deployment of such changes so as not to disrupt the system. So we'll see how it plays out. I don't think any agreement has been reached yet. It's still in discussion and we'll see how it goes.