 Giovanni asks, isn't the size of the blockchain an issue for the ordinary PC? Currently, my Bitcoin folder size is 153 gigabytes. Definitely an issue preventing people to be part of the transaction validation process. Giovanni, you are correct. In fact, an even bigger problem is the cost of bandwidth. In order to create that blockchain of 153 gigabytes on your hard drive, you probably transmitted and received close to a terabyte of data across your internet connection. In many cases, a single node is connected to eight other nodes. For every block they receive, they transmitted eight times to eight neighboring nodes, which results in eight times the amount of data being transmitted outbound. They will also receive and retransmit blocks that eventually don't end up in the blockchain, orphan blocks, though still will get transmitted. They will support uploading the blockchain again and again to clients that are bootstrapping for the first time, to thin clients that are syncing for the first time. Disk and bandwidth are great considerations. This is the primary argument for keeping the block size to a limited size in order to allow as many people as possible to run fully independent, validating nodes around the world to create a robust decentralized network. With the idea that if the space capacity bandwidth requirements of nodes escalate rapidly, as we're seeing, for example, on the Ethereum chain, eventually that's going to lead to fewer and fewer people running nodes. More and more corporate data centers, centralized solutions for running nodes, which then become much easier to core, to sue, to shut down, to attack, and make the network less robust. Daniel asks, as we see in session two, the mechanism that Bitcoin uses to confirm transactions and resolve the Byzantine general's problems based on consensus of the network. We now have the pressure for activating SegWit 2x on November 1st. It may cause a hard fork in the blockchain. Is this an attack on the Byzantine general's problem solution? No, it isn't. The reason it isn't is because, fundamentally, the consensus algorithm, especially of the Bitcoin blockchain, but more generally of blockchains, is not a coercive system. It's an opt-in system. The decision as to which is the correct chain is an entirely subjective decision that is made on a node-by-node basis. Which is the real Bitcoin? There is no general answer to that. You each choose which is the real Bitcoin for your perspective by running a node that validates the set of consensus rules that you believe are what represents the real Bitcoin. It's an entirely subjective experience. If you have 16 million people running Bitcoin, they can form 16 million different impressions of what they believe the real Bitcoin is. Out of that, something emerges, a majority perhaps, that has more economic activity, more market traction, more hashing power. But that is not always clear-cut. In the end, the only thing that matters is the individual perspective. You are not coerced into making that choice, and it's an opt-in system. The Byzantine general problem solution, or the consensus algorithm, operates within the set of nodes that are following those consensus rules. If part of the network forks off, that's not a failure of the Byzantine general's problem. The consensus algorithm continues to operate. It continues to operate on two separate networks, each of which is fully enforcing the consensus algorithm. It is fully achieving Byzantine general fold protection, but separately from the rest of the network. I think one way of looking at this is the idea of a voluntary cooperation, to imagine it this way. Let's say you have a basketball court, and you have 12 people who show up, and they want to play a game of pick-up basketball. Maybe eight of the people who are there want to make sure that the rules of this particular game of basketball are somewhat softer, meaning that aggressive fouls, or aggressive defense, a few thrown elbows, maybe a bit of shoving and pushing, is tolerated. They want to play a slightly harder game of basketball, and maybe four of the people there don't want to do that. They want to play a less rough game. The good news is that eight of them can play on one side of the court, and four of them can play on the other side of the court, each following their own set of rules, not stepping on each other's toes, and fork the basketball court. The question is, do the rules of basketball still apply? Well, yes. In each of the two games that are happening, the rules of basketball have been preserved, according to whatever those rules are, based on the interpretation of the people who are participating in that game. Nobody is forced to join one or the other game. In fact, they can just take their ball and go home, and decide not to play that day. Really, that's what consensus is, in a very simple way. The next question is, proof of work consensus, developer consensus, miner consensus, exchange consensus, wallet consensus, wallet developer consensus. Can you please develop or expand on these forms of consensus? Yes, one of the questions that comes up often is, who decides what the rules are? The obvious answer is, the miners decide what the rules are. That's not actually true, because the miners operate on a chain because it's profitable. It's profitable only if the underlying currency can be sold on exchanges in order to pay for their electricity. The exchanges will only accept it if it's on the chain that they consider valid. The exchanges will only consider a chain valid if their customers, who are buying and selling on that chain, consider it valid. The customers will only consider it valid if the wallets are using it considered valid, and the wallets will only consider it valid, and the customers will only consider it valid if they can use that cryptocurrency to buy things from merchants. The merchants will only consider it valid if they have code to run, and all of the above categories will only consider it valid if they have good, well-maintained, solid software to run, which means that the developers must consider it valid, but the developers will only consider it valid if they can spend their coins, etc. Essentially, there is an interdependency between all of these constituencies, and all of these constituencies of consensus are themselves overlapping. I am a user, I also am a wallet user, and an investor. I can also be a developer. I might even be a miner too. Some nodes and some users belong to multiple different constituencies. Many of the constituencies have overlapping functions. Developers are also users of Bitcoin. Some exchanges may also be mining. They may also run wallets, and the people working at those exchanges are also themselves users. Maybe they also sell t-shirts, so they are merchants. Everybody has to agree. Essentially, everybody decides for themselves what rules of consensus are valid. That decision is made on an individual basis, but the emergent reality happens across all of those individuals together through marketplaces, through the actions of a free market. This one is going to be a bit controversial, but I will tackle it anyway. Sesame asks, how does a proposal fail to proceed after having majority support from miners? I am studying the events of Segwit 2x, and I am having trouble consolidating in my mind how Segwit 2x failed to proceed on a technical level. People often cite Segwit 2x as an example of how users running full nodes can keep miners in check. I hope to gain a better understanding of how exactly that works with this question. I understand that more than 80% of miners signaled in support of Segwit 2x as per BIP 8 and BIP 9, but what is the mechanism by which this proposal failed? Was the proposal never locked in because of an insufficient percentage of blocks with a bit set? What role did the users, running full nodes, play during the Segwit 2x, to resist such a change? If you don't remember all of this, this is from the deep, deep history of Bitcoin, which means 18 months ago. This is the scaling debate. During the scaling debate, especially during the summer of last year, we saw everything come to a head. Starting in the spring, a number of proposals were made on how to solve the scaling debate. Different groups within Bitcoin positioned different proposals, including Segwit 2x, which was a proposal to simultaneously implement Segwit and an increase of the base block size to 2MB, which effectively would have increased the base block size to 16MB, because Segwit would multiply that by another factor of 4MB. That was one proposal. Segwit, which was due for activation, was being activated by a new technique called BIP 9, which is a mechanism for signaling using a binary field within the header of the Coinbase transaction. There was a previous system called BIP 8 that was partially used in this whole debate. Then there was a lot of flag-waving. Let me explain what I mean by that. Miners have the ability in the Coinbase to put some text that signals their intent. This isn't basically part of the protocol itself. It's like waving a flag. It's like putting a bumper sticker on your car. It doesn't change how the car operates. It just tells people around you what your particular position on an issue is. Let me clarify for you, Sesame Miao. You said you understood that more than 80% of miners signaled in support of Segwit 2x as per BIP 8 and BIP 9. They didn't. In fact, there was no BIP 8 and BIP 9 proposal for that. What was happening was that within the Coinbase transaction, people had the bumper sticker that said Segwit 2x. But they weren't committed to switching over the software in order to run a version that would actually activate that change. In that way, we've got to look at the difference between signaling that doesn't have a material impact on the protocol, which is cheap to do. Bumpers sticker doesn't cost you anything. You're not putting money on the line. You're not changing what you're doing. You're simply putting a bumper sticker. Versus committing in the protocol under a specific software package to run a specific set of consensus rules by a specific date. The reason that proposal didn't garner enough support was because there was enough resistance from groups that were not miners. Consensus is made by multiple constituencies. There's economic interest, which includes exchanges. Exchanges get to have some power because if they decide to list or not list one of the forks, that gives them control over what their users do. Exchanges run nodes and infrastructure through which an enormous number of transactions happen, as well as an enormous number of transactions that happen off-chain on the exchange's own databases, internal payments between users, etc. And again, the exchanges have a lot of control over that. Merchant processing services that process and convert Bitcoin to fiat for merchants who don't want to hold Bitcoin, or that simply aggregate Bitcoin and offer various e-commerce facilities like carts and integration with WordPress, WooCommerce, etc. They have power in the system. You have the big investors who are trading, and they have power in the system by deciding what they're going to buy and sell, whether they're going to short or long various forks. Then you have the users, and some of those users may also be running full nodes, and they decide which blocks and transactions they're going to forward by choosing which software they run. In this particular case, these economic interests were diverging. As a result, miners didn't have, in this particular case, the confidence to move ahead and force that change on the network, because they anticipated that they wouldn't necessarily have enough support. At the same time, there was a big movement called user-activated soft fork that basically had users using their nodes to impose an embargo on miners that didn't activate SegWit by August 1st of 2017. That had some influence, too. The reason the proposal failed to proceed was because it never had, in protocol support, with software nodes to a level where it could fork the original implementation, and keep in mind, the 2x part of SegWit 2x would be a hard fork. It would require a non-backwards compatible change that broke consensus, whereas SegWit itself was not a hard fork, it was a soft fork. In the end, the miners decided to drop the SegWit part, do the hard fork, and do just the 2MB hard fork in the form of Bitcoin Cash, instead of doing both SegWit and 2x. The miners did proceed. They proceeded to fork Bitcoin Cash, and Bitcoin got SegWit, and Bitcoin Cash got its base block increase with a hard fork. They decided explicitly not to put the SegWit component in Bitcoin Cash. That is how it played out. This is a complex balance of economic interest, and these are huge economic interests. If you take a vote against consensus, you have to be willing to risk your investment. In the case of miners, you have this enormous infrastructure investment, and that infrastructure investment could be affected by those decisions in a way that costs millions of dollars. In fact, we are beginning to see some of these decisions have an impact in the hundreds of millions of dollars for some of the miners. It is not as simple as it appears at first glance.