 Eric asks, how many miners are there out there? How many have successfully mined blocks so far? Where can I find this information? Are most miners traceable to IP addresses? Or are their IP addresses anonymized? Let's start from the beginning. How many miners are there out there? Well, it's actually very difficult to count. Unless miners identify either the pool or the mining system that they use, by mining information into the header of the block, meaning that they put their signature in the block, and self-identify. It's impossible to tell who a miner is. You can maybe get some statistics by looking at the correlation to addresses that they use in the Coinbase. Every block has a Coinbase transaction, which pays the rewards to the miner. That has a miner's Bitcoin address. If they use the same Bitcoin address for every block they mine, you can correlate those blocks. Miners don't have to use the same Bitcoin address for every block. In fact, they can use a different Bitcoin address for every block they mine, and then you'd never be able to correlate them. We don't really know how many miners there are out there. We do see through the signatures in the block headers, where mining pools self-identify. We do see how many mining pools there are. There are about a dozen or so prominent mining pools, with four or five having the majority of the hashing power. These mining pools are not necessarily owners of mining equipment. In many cases, they are independent organizations. The mining equipment belongs to others who are combining it in the mining pool. Miners and mining pools are not the same thing. We can identify mining pools. You can see statistics and a number of websites that show the distribution of hashing power on the Bitcoin network by mining pools. This is self-identification. Miners and mining pools can fail to identify, refuse to identify, or lie in their identification. As a result, you can't really trace. The second question was, are most miners traceable to IP addresses, or are their IP addresses anonymized? They are not traceable to IP addresses. The Bitcoin network doesn't keep track of IP addresses, because both transactions and blocks are propagated through the network... through a mechanism called flooding. With flooding, every node sends everything it receives to all of the nodes it is connected to. If your node is connected to other nodes in the system, and it receives a transaction or a block from another node, it has no idea if the node it just received this transaction from is the first node where that transaction appeared, the originator, if you like, or if it's the node that's mined that block, or if it's a node that's simply relaying information from another node further down the chain. Every node only sees its immediate neighbors. It doesn't know where the information is originating. It just sees that it's coming from its neighbors, and the neighbors may simply be relaying information. When your node relays that information to the next node, the next node doesn't know if you're the miner, or the originator of that transaction, or if you simply received it from somewhere else. As a result, it's actually very difficult to track IP addresses, because you would have to be able to monitor... all of the connections between all of the different nodes on the Bitcoin network. There are certain organizations that can probably do this. Intelligence agencies can probably monitor a very large percentage of the various nodes on the Bitcoin network. The Bitcoin network also uses various cryptographically secured protocols, such as Tor, the onion router, in order to route traffic. If a miner or someone who's creating transactions is on the Tor network, and their node is communicating only by Tor, again, it's very difficult to trace where transactions and blocks are coming from. Jeremy asks, how can the distribution of hash power amongst miners in the Bitcoin network be identified? For example, by looking at statistics on sites like blockchain info slash pools, how reliably can we know this information? We can know this information because most mining pools, if not all mining pools, include a signature in the Coinbase transaction that identifies which pool created the transaction. They leave a fingerprint on purpose, they tag it with their name. The calculation that's used at places like blockchain info uses a database that says, these tags belong to these pools, and then creates a chart looking at all of the blocks in a previous window of time, counting how many of those blocks had which tag and using it to identify miners. When I was at blockchain info, in fact, I was involved in open-sourcing that part of the database, which was exported as a GitHub repository. It's a JSON database, a JavaScript object notation database, that is simply a tag and the name of a mining pool. People can update that to indicate new mining pools, and anything that's not identified falls into that one slice of the pie, that you might notice, that is called unknown. How reliable? Well, theoretically, at least, it's possible that miners may be mistagging the Coinbase. It's voluntary information, they may be lying. A miner could put into the Coinbase the name of another mining pool, to make them appear as to have more hashing power, and to hide in the shadows. There's no way of validating that. You have to take that information with a pinch of salt. Andreas asks, if mining is for preventing miners from double-spending their own transactions, why not simply flag their transactions and check them regularly? Andreas, mining is not for preventing miners from double-spending, it's for preventing anyone from double-spending transactions. Furthermore, even if it was just about miners, you can't flag which transactions are produced by miners, because you can't tell which transactions are produced by miners versus somebody else. There's no way to know who is a miner, and who is not a miner on the system. Nodes operate under this cloak of anonymity, so you can't tell who is a miner on the Bitcoin network. You certainly can't tell where a transaction came from, and who mined it, or who produced it, so as to be able to discern. Mark says, Bitcoin's sausage isn't a general problem so long as honest non-collaborating miners consist of at least 50% of the hashing power in the system. How do I know that at least 50% is an honest miner and not a trader? You don't know that, and the only way to ensure that is to have mining power that is distributed amongst enough miners that they can't collude. Also, the system incentives that even if they do collude, the reward for breaking the system by doing a 51% attack, is not worth destroying the system itself. Susanna asks, during a 51% attack, can the miners spend his or her bitcoins twice? What is meant that a 51% attacker can always produce a longer chain than the other miners, and then for it can reverse its past transactions? A 51% attack doesn't allow a miner to double-spend. This is really, really important to realize. This is a fundamental difference. Just because there is a 51% attack, just because a miner has 51% of the hash power, does not mean that they can produce blocks that are not valid. The reason is that the other nodes on the network, which include other miners, but also other users, merchants, exchanges, wallet infrastructure, and my node that is sitting out there on a server of my own, are all validating blocks and transactions. If I was to receive a block from a miner that had a transaction spending coins that I have already marked as spent, it doesn't matter if they have 51% of the hash power, it doesn't matter if they produce valid proof of work. That is not a valid transaction, and therefore the block it is included in is not a valid block. My node will reject that block, the rest of the network will reject that block, and the miner will have wasted their hashing power. Having 51% of the hash power does not enable miners to produce invalid blocks. This is a really important point. It is also a point of contention in some of the debates that have come up in Bitcoin, specifically around user-activated soft forks and the possibility of changing the consensus rules without agreement from everyone. Mining nodes are not the only nodes that matter. Let's say that a miner does have 51% of the hashing power. What does it mean that they can produce a longer chain? That simply means that they can find more blocks on average than any other miner or than the rest of the miners put together. Which means that they can always produce the longest cumulative difficulty valid chain on the network, but it still has to be valid. How can they benefit from this? They can't double-spend, but what they can do is rewrite a past block and produce a different variation of it, that they then include in a longer chain. This takes a bit more than 51%, because 51% only allows you to be ahead by 1%. If one miner has 51%, the rest of the miners have 49%, that means they can only mine 1% more blocks than everybody else. That is 1.4 blocks a day on average. Let's say you bought something from a merchant and you made a payment as a miner, you made a transaction to pay for a flat-screen TV. That merchant ships that flat-screen TV after one confirmation, and then you create a chain where your payment for the flat-screen TV is removed. Then you created another block building on top of that to make that the longest chain. With just two blocks, you've made it the longest chain, the transaction you paid the merchant for the TV never happened, and the TV is already loaded on the truck and coming your way, flat-screen TV for you. Of course, that's why merchants wouldn't ship the TV after one confirmation. In order to get six confirmations ahead, you would have to sustain a 51% attack for seven days. In order to do that, in order to rewrite the longest chain, you'd have to take enormous risks that you didn't lose the majority of the hashing power. Certainly not worth doing for a flat-screen TV. Again, it doesn't allow you to take other people's money, it doesn't allow you to double-spend money. It simply allows you to remove transactions that happened in the past. You can do that effectively by undoing a payment of your own, so it's the steal money. But it takes quite a bit of work, and it's why in situations where merchants are receiving payment for something, or when an exchange wants to accept a withdrawal on a trade, they wait six confirmations. That massively reduces the risk of an attack on the network. It takes significantly more resources to pull off that kind of attack. Christopher asks, this next question refers to Cornell University's selfish mining model, quoted on page 30 of the course. It's about the threshold of honest, non-fair as the colluding miners at which Bitcoin solves the Byzantine General's problem and creates the guarantee for Bitcoin system integrity. Is it 51% of the hashing power? Is it 66% of the hashing power? What countermeasures might work against dishonest miners? Ultimately, any Bitcoin or other blockchain, serious integrity or security deficiency, might also provide an opportunity to big governments, heavily centralized corporations, or other organizations to enter the fray to attack Bitcoin. In that sense, the Cornell University Bitcoin Adjustment suggestion sounds interesting. In order to patch this theoretical yet possible Bitcoin deficiency while keeping it decentralized, is it gaining any attention and traction? It isn't, at the moment, quite honestly, although there are some proposals to introduce certain measures that prevent dishonest miners and selfish mining capabilities by having other hybrid measures in addition to proof of work. I think we're going to see a lot of experimentation in the future for the time being. What that means is that at the moment, 33% of the hashing power could engage in selfish mining. This is a very high-risk option for the miners. If successful, they can introduce double-spend. For the most part, selfish mining is a destructive attack. It's not an attack that gains the miner or something, really. The opportunities for double-spending are pretty limited. The most effective reason for doing an attack like that is not to gain, but a willingness to spend a lot of money to destroy or damage or deny service in Bitcoin for a prolonged period of time, even knowing that while executing this attack, you're not going to gain anything and probably spend a lot of money doing it. What you need is not just a selfish miner, not just a dishonest miner, but a dishonest miner who is motivated, not by profit, but willing to spend a lot of money just to damage Bitcoin, which is a strong possibility, especially for censorship by state agents or collusion between multiple state agents. A third of the hashing power, with the rate at which hashing power has escalated, becomes very difficult to do. There are a number of countermeasures against that, including the most obvious countermeasure, which we could call the nuclear option, which is a hard fork to change the proof-of-work algorithm, thereby rendering all of the equipment that has been amassed into slag, turning it useless. There are defenses that the Bitcoin community can marshal, but these defenses are very high-cost defenses that can cause a lot of damage. We'll see in the future if selfish mining has some emergent defenses against it, for the time being, I think the practical concern is not high enough to justify additional research or practical deployment against that. Carl asks, how is dishonesty, meaning Bitcoin clients sending transactions moving the same Bitcoin to two different addresses? How is that weeded out? So, Carl, that's what we call double-spend. The way double-spend is weeded out is that when you try to send a transaction like that, who are you sending it to? The way the Bitcoin network works is through flooding broadcasts, meaning that when my node is connected or my wallet is connected to the Bitcoin network, it's just connected to a bunch of other nodes on the network. So, when I send a transaction, what I'm doing is I'm announcing that transaction to the nodes my computer is immediately connected to, or my wallet is immediately connected to. When I send the transaction to those nodes, they will validate it before deciding whether they're going to send it to their adjacent nodes. The way a normal transaction propagates is, I send it to the nodes I'm connected to, they send it to all the nodes they're connected to, which send it to all the nodes they're connected to, etc., until the transaction ripples out across the entire network, and everybody receives a copy of it. One of the nodes that receives a copy of it is probably going to be a miner. They will put it in their mempool, they will wait, and when they have another block to mine, they might choose that transaction, put it in the block, and then send that block out back to everybody in the same way, rippling out across the network until everybody sees it. Now, let's look at what happens when I do a double-spend. I send one transaction and I spend Bitcoins to one address. Then I construct another transaction that spends the same Bitcoin, but sends it to a different address. I send it to the nodes that are immediately connected next to me. They will attempt to validate that transaction. They will find that the Bitcoin I'm trying to spend has already been spent, they will reject that transaction, and they will not propagate it. The problem isn't that I simply can't get it to the miners, I also can't get it past the nodes closest to me. It won't get very far at all. The very first node I tell will reject the transaction as an invalid transaction, because it is double-spending. Every node validates, and as a result, invalid transactions, double-spend transactions, being a particularly egregious case of invalid transactions, should not propagate across the network. Now, that doesn't mean you can't get a double-spend transaction to a miner. In fact, you can. The way you do that is by connecting only and directly to a node that is run by the miner, and then enticing them to ignore the validation rules by attaching a much higher fee to your double-spend transaction. They might go out and try to include it in the block. They won't do it if the first transaction has already been included, but they might replace the transaction they have in their mempool with the second transaction, if neither of them has been mined yet. That's really a double-spend before any confirmations, meaning that zero-confirmation transactions can be double-spent. All you have to do is entice the miner to take the transaction with the greatest fee from their mempool, and ignore the one that has a lower fee than you broadcast earlier. But that only works until one of the transactions is mined, and once it's mined, no miner is going to accept a double-spend of that transaction, because they know that if they do that, their block will be invalid, and their time will be wasted. Roy posted a tweet from June of 2013 that says, g-hash.i is now at 52% hash rate, and this can cause issues. The question from Roy is, did someone find a way to prevent this from happening? Well, yes, in fact, Roy, that particular tweet was misstating the actual hash rate of g-hash.io, which had not reached 52%, but in any case, what happened is that very quickly the hash rate changed, because miners abandoned g-hash.io, so as to remove their hashing power from that pool. At times, various pools jocke for position, entice miners to join them and participate with their hashing, but if it looks like any pool is achieving mining, hashing power that is close to a dangerous level, miners generally tend to switch pools. We've seen this happen with a number of pools over time, and there's no real way to prevent this from happening, because that's the nature of the system. You can't control where miners will commit their mining power, how they'll collaborate to form pools, or who has the mining power. But in fact, because of the costs of creating the mining power, as well as retaining enough power in the network, is very, very high. The practical risk of 51% attacks, as they're called, is very, very low. Over time, we've seen that the amount of hashing power that any one miner or mining pool has, has become more decentralized over time. If you think about it, back in January of 2009, there was one miner, Satoshi, and Satoshi had near 100% of the mining power, and then gradually more and more miners joined, and the mining power was further distributed. Today, we have many different miners who have different varying percentages of the mining power, but the number of pools and the number of miners is greater than it ever was in the past, and mining is quite a decentralized operation. Of course, the risk always exists, but the economic incentives of mining means that even though a 51% attack may become theoretically possible by any one miner, the problem is that by executing such attack, they get very little benefit, but they end up damaging Bitcoin in such a way that they lose all of the investment in mining equipment that they've bought, and all of the energy they've used up to that point. So the economic incentives actually disincentivize miners from, if you like, killing the goose that lays the golden eggs. If the top three Bitcoin mining pools were to merge, asks Jeremy again, they would control 54%. Why hasn't it happened? Because if they did merge, Jeremy, and they did control 54%, the people participating in them would be rightly spooked and would leave them, and at that point they would no longer control 54%. In fact, it may be that the top three miners have a lot more common interests than you might think, but they would rather operate on the different names, so as not to even create the impression of having more than 50%. We saw in the early days, and if you read back about ghash.io, you're going to see some stories about that, where one miner got close to 50%, or rather one mining pool got close to 50%, and as a result, the participants in that mining pool started abandoning the pool out of fear that it might take advantage and do a 51% attack. Even if a mining pool or certain business interests that control mining pools effectively control more than 50% of the network, they certainly don't want anyone to know that, because there will be repercussions, and people will move their hashing power in order to reduce that, or certainly express a lot of concern over that. There's a big difference between having hash power that exceeds 50% and doing something with that hash power, having the power or perceived power, and exercising that power. In many aspects in the Bitcoin consensus system, the power exists as long as it is not exercised, and the moment someone tries to exercise it, it will evaporate.