← TFTC: A Bitcoin Podcast
TFTC: A Bitcoin Podcast
Risks of Mining Pool Centralization | Jimmy Song, Center of Hash E008
01:29:35
Loading summary
Transcript235 lines
- [00:05]
A
Jimmy, thanks for doing this. Topic of the day is mining centralization. But before we get there, I want to quiz you. Just went down the street to Cooper's, got brisket. I want you to guess what the current price of brisket per pound is at Cooper's.
- [00:22]
B
It's downtown prime location, Austin, which obviously. Oh, yeah, obviously very popular around here. I'm gonna guess 3299.
- [00:41]
A
3950.
- [00:43]
B
What?
- [00:44]
A
Yeah. Do you have any recollection We've been going to Cooper's for a long time around BitDevs. Do you have any recollection of the earliest price you would have remembered at Cooper's?
- [00:55]
B
Well, Cooper's didn't open until like five years ago.
- [00:57]
A
No, it's been at least 2018.
- [01:00]
B
Okay, so seven years ago, something like that. Yeah, but I want to say, like 2299 was maybe like the earliest I.
- [01:11]
A
Can remember, the lowest I saw. And when I started going there more frequently, when I started Unchained, which would have been 2018, 1799. Yeah.
- [01:23]
B
I remember when I first moved to Austin, I went to Rudy's. I think it was like 6:29 or something. Yeah, this was 2012.
- [01:34]
A
It's just amazing. I've triggered a number of people carrying the torch on safe's ribeye as an inflation index, and I'm conditioned to the increase in prices. And even at Cooper's, I think I went and I saw it at 33 or $34, but there was something about that 3950. And I know that I've seen it back in time at the same location, 1799, more than 100%.
- [02:04]
B
Well, in Bitcoin terms, that's actually quite cheap. Now, compared to that, I saw.
- [02:10]
A
A tweet that you put out about something that you were looking to purchase, seeing that it was some amount more expensive, and then realized that it was cheaper in bitcoin terms. And it is true that that brisket is still cheaper in bitcoin terms.
- [02:26]
B
Way cheaper.
- [02:26]
A
The dollar inflation still hits. Still hits.
- [02:32]
C
It does.
- [02:34]
A
Start paying attention, freaks. All right, onto the real topic of the day. Mining centralization. And specifically, we're going to get into pool mining. Pool centralization. Explain in your words, the relationship between bitcoin miners and mining pools. Just to set some context.
- [02:55]
C
Right.
- [02:56]
B
So the reason why pools exist in the first place is because you want variance reduction. If you have a tiny amount of hash rate, you have whatever hash rate you have divided by the global hash rate, percentage chance of finding the next block. It's obviously not going to be very much. And instead of waiting for the one jackpot hit, if you will, you can pool all of your resources and split it equally. That's what a mining pool is supposed to be. Unfortunately, the first design of mining pool stuff uses something called stratum v1. And this is where the mining pool tells everybody, hey, here's the block you have to mine, including this output address that goes to the pool and we'll do the splitting up afterwards. And that means that the pool essentially acts as the block template constructor. And in fact, for any member of the pool, they don't have to run a node at all. They just have to take the template, modify it in whatever way to roll the nonce or whatever, and just hash until they find the block.
- [04:13]
C
Right.
- [04:13]
B
Or find. Really what they do is they find shares and then submit those shares. And if the pool, if they find a block, then it gets spread equally. That's the idea behind pools and that's how it's more or less executed. But you know, one of the things that makes it kind of bad is that the pool operator gets to decide what goes into each block. And that means that there's a centralized block production industrial complex, if you will. There's only maybe 15 pools that have something like 95% of the hash rate that are running Stratum V1, I think Brains Pool, they run Stratum V2, Ocean obviously runs Datum. And then there's like CK Solo Pool and they, they make it so that you can mine solo and decide on your template yourself. But they, they take up, I believe, less than 5%. So 95% of hash rate essentially is controlled by like 16 pool operators. And we know that some of them have like economic, you know, interest in the other. So it's probably more like 10 at the most.
- [05:38]
C
Right.
- [05:38]
B
Like entities.
- [05:39]
A
Yeah. And so you mentioned that most bitcoin miners, if they're working with a centralized pool, are not running their own node.
- [05:49]
B
They don't have to.
- [05:50]
C
No.
- [05:51]
A
And that when they are performing work, they on site, where they're consuming power and running the bitcoin hashing algorithm, they're basically, their primary communication channel is back through the pool. They send the pool all of their work and then not only does their work go back through the pool and the pool does the accounting of how much work all the miners participating in their pool do, but then the money goes directly to the pool and then.
- [06:27]
B
They have to get paid out.
- [06:28]
A
And the pools pay out the miners.
- [06:30]
C
Right.
- [06:30]
B
It's a Big trust relationship, honestly, because every hasher, right. Like we shouldn't call these people that are participating in a pool not really running their own nodes or constructing blocks like an actual miner. They're not really mining as much as they are hashing. The mining pools are mining because they're constructing their own blocks. But they have to have this big trust relationship because the pool does the payout.
- [07:00]
C
Right.
- [07:02]
B
And I believe I used to mine a long time ago and I was like, okay, how do I even verify that this is the amount that I'm owed? Or how do you even know? Because they need to figure out how many shares you submitted and so on. And basically share is like something that doesn't quite meet the proof of work, but is still very difficult that you can prove, hey, I did this much work. And so the pool pays based on that. It's kind of like it's a big trust relationship. It's a bit of a mess because of that.
- [07:41]
A
And then also, just for context, before we discuss the consequences of centralization.
- [07:49]
C
Provide.
- [07:50]
A
Your view of the context of the function that the miners are providing to the aggregate network.
- [07:55]
B
Yeah, they're making it so that it's very hard to go backwards. The blockchain is adding blocks and not going backwards. In order to subvert any transaction that's included in a block, then you not only have to do at least the equivalent amount of work, proof of work wise, but if there are blocks on top of it, you have to do the proof of work of all those blocks as well. So it ends up being a security measure to not quite finalize a transaction, but make it very difficult to reverse it. Nothing is ever final. In theory. You could, if you had, like.
- [08:46]
C
If.
- [08:47]
B
You were God, for example, you can make blocks all the way going back to the Genesis blockchain, Genesis block, and just wipe out everything, at least according to the rules of the software. But you get very good assurance of finality based on proof of work rather than know somebody's trust me, bro assurances or something like that.
- [09:14]
A
Yeah, and I think it was two episodes ago, Pierre and I did a deep dive on the difficulty adjustment and difficulty target. And we, or not we estimated, but the number that we were working on was that there was approximately 20 gigawatts of power securing the Bitcoin network, somewhere probably between 20 and 25 gigawatts, but that on average it would require 20 to 25 gigawatts of power running probabilistically to solve the next block in 10 minutes. And that in order to effectively Undo history or undo potential transactions that were already settled. It would require that much power just, you know, it would be possible probabilistically for someone to do less work just based on luck, but on average it would be that much work, 10 minutes just to rewrite the past block. And then if you were talking about undoing two blocks, to your point of, nothing's technically final. But practically speaking, the more work that's being done, the more work is required to undo a previously valid transaction. And that it's a principal function to ensuring transaction finality in the Bitcoin.
- [10:24]
B
Yeah, and it makes it a lot harder like everything else in sort of like the fiat world is based on. Okay, well, we're going to say this is final by convention or something like that. This actually requires energy and that sort of component is very unique and gives it sort of like a solidness that almost nothing else financial really has.
- [10:52]
A
Yeah. And that is something that I want to talk about as well. This dynamic of. And you drew the distinction between hashing versus mining, but that the participants that are actually doing the work are the hashers or the miners. The mining pools themselves are not the ones that are actually consuming energy, but they're this principal point of centralization. That hash rate is fairly well distributed, but then everything centralizes at the point of creating blocks or putting this set of transactions together that are going to be proposed, say in the next block to the, to the network, as well as managing all the payouts. And you talked a little bit about the number of pools that represent different percentages. Based on, when I look at it, Foundry represents about 30%, Ampool is 14%. But there's a number of other pools that are working off of the same templates as antpool. When you add up what people believe those proxies to be, Foundry and ample are 55%, the top five are 70%, and then the top six or seven are 90% of the network. What do you see as the principal risks of specifically mining pool centralization to the Bitcoin network?
- [12:23]
C
Well.
- [12:26]
B
If you have block construction outsourced to only a few entities, then they can do cartel like behavior. They can do all sorts of things.
- [12:38]
C
Right.
- [12:39]
B
Like they can just say, for example, if they had, I don't know, 95% or something like that, they could literally extort the network if they wanted to. They could just say, hey, if you want a transaction, you have to pay US$500 per transaction. We're not going to include anything else. And that could be cartel like behavior. Right. And they could enfor it if they sort of agree with it. Other problems with cartels and defections and so on. But that's something that they could do. And not only that, but they can let in whatever transaction that they want and not what the rest of the network is trying to get in and so on. They couldn't. I mean, in any point of centralization you can sort of restrict things in ways that aren't optimal for the network to grow and so on. So say those like five or six entities decide at some point we don't like lightning, it's taking away a lot of our fees. So any lightning transaction we're just going to filter.
- [13:55]
C
Right.
- [13:55]
B
And that's a scenario that could happen, in which case they're hoping that if people can't use lightning or open channels with lightning and so on, then people have to come on chain, which would increase the fees and increase their revenue, something like that.
- [14:15]
A
There's a couple different scenarios there and let's talk about it on either side. Let's say there's a scenario where a cartel of miners got together and said there's going to be 22 million Bitcoin. What happens and why is that unrealistic?
- [14:34]
B
Yeah, that's unrealistic because that would require hard work.
- [14:38]
A
But just walk through those dynamics.
- [14:40]
C
Right?
- [14:40]
B
Right. So say they want to do that, then they would have to change their software, in which case I don't know what the emission schedule would be. If it's the same as bitcoin up until certain point, then it'll stay more or less unchanged.
- [14:56]
C
Right.
- [14:56]
B
Like until the point at which the emission schedule changes. So currently the emission schedule is 3.125 every 10 minutes. If they start saying okay, instead of 3.125, we're going to make it five.
- [15:11]
C
Right.
- [15:11]
B
For right now, then it would be an immediate hard fork, at which point they're not hashing bitcoin anymore, they're hashing bitcoin miner or whatever it is.
- [15:21]
A
So there would be two versions of.
- [15:22]
B
The blockchain and they would never come back together because it's a hard fork, they're very different. And it would probably slow down the bitcoin network quite a bit because a lot of hashing power effectively has left. But that means that the difficulty adjustment after a month or two would probably make it so that transactions go through in a reasonable time again or more. Mining comes online like equipment that has been mothballed somewhere, maybe comes online and you get hash rate that way. But ultimately you just have two separate tokens Right.
- [16:06]
A
And it would be effectively the same as the 2017.
- [16:11]
B
Yeah, it would feel like an airdrop.
- [16:15]
C
Yeah.
- [16:15]
A
Everyone has the same amount of Bitcoin A and minor forked bitcoin B and people. And then the market would determine which one they'd rather want to hold and then the hash rate would logically follow.
- [16:36]
B
Because of economic pressure eventually.
- [16:37]
A
Yeah, yeah. But then you also brought up the scenario of censorship and there might be one version of censorship in terms of not validating say Bitcoin from, let's just say an OFAC sanctioned address.
- [16:58]
B
Yeah, that's a more salient one.
- [17:00]
C
Yeah.
- [17:01]
A
And there's two different scenarios. There's ones where they just won't mine it. And if enough of the cartel is together and agreed, the transaction just doesn't get mined. But then if there's a scenario where they hard coded something into their software to say any bitcoin from this address is actually invalid. Talk about the differences between those two different scenarios. Because like one would create a fork versus one would just basically try to carden you off from the network.
- [17:34]
B
Yeah. So if they, if they just, never mind the transactions that are from OFAC sanctions list, then that wouldn't really affect the network that much other than for the person that has that address. Obviously like blocks would still be valid to every node and so on. If you suddenly said, you know, transactions from this are, this address are now invalid, then as long as such a transaction shows up on the network, you would have an instant of hard fork because the software that says this is invalid would deny that block and the software that says it is valid would continue to build on it. Now that would be weird because in a sense I think that would be a soft work because it's a tightening of the rules. So in that case the mining cartel would actually have the advantage in the sense that if they did that said, okay, Transactions from these 17 addresses are invalid, it would be a tightening of the rules. And if they ever overtake the chain that had a transaction from that address in it, then all of the other nodes that have built on it, you have wipeout risk basically, because if the chain is longer with the miners, then everybody else would have to take it. But it's not the reverse, it would be a soft fork.
- [19:14]
A
I'm envisioning this error, although even that I expect to be unlikely, would be someone like the US government saying, hey, here's this set of list that we deem to be enemies of the state more than just filtering the transactions. If you were to mine these transactions, then you are going to be.
- [19:40]
B
Or if it's in your blockchain, then we're going to be liable so that.
- [19:43]
A
Even if somebody else mined it, then you couldn't mine on top of it. If your software said any, anything from this address is invalid.
- [19:54]
B
That.
- [19:57]
A
Do you think that that's a realistic scenario?
- [20:01]
B
I suppose it's possible and who knows what bureaucrats think of. But I mean it could. It's a way to pressure a centralized entity. And the thing is, when a centralized entity exists, then you can sort of choke it and bend it to your will, which is sort of the scenario you're more broadly describing.
- [20:25]
A
And then maybe talk about it or in a scenario where it exists today where say six or seven miners control 90% of the hash rate versus a more distributed set of circumstances, why it would or would not be more likely to be successful if it were attempted.
- [20:50]
B
Yeah, so if, if you do it with like six or seven miners, pretty easy, right? You go to them and like give them, you know, whatever legal notice or whatever and their lawyers get involved and they stop mining or whatever. It's a lot more like, that's a lot more likely to be successful than if you had like a thousand miners distributed all over the world. You have no ide idea where they are, who they are, why, you know, what equipment they use, or how are you even going to serve them.
- [21:21]
C
Right?
- [21:21]
B
Like, ok, go, you're not allowed to do this or whatever. And even if you've deemed that they're enemies of the state or whatever, how are you even going to find out where they are and all that? So it becomes sort of like that nightmare scenario that we talk about in Bitcoin. What happens if the government bans Bitcoin? Like yeah, what, what, what would happen? I'm not entirely sure, but I think a lot of the mining would be outside of the jurisdiction that banned it. And, and yeah, like it's a lot harder obviously when it's decentralized than when it's centralized.
- [22:06]
A
What are. So then what about a scenario where it wasn't something as clearly obvious like increasing the fixed supply from 21 million to something greater and that creating a hard fork, but some other change to the network that maybe discuss a scenario where it's a soft fork but not something that's as overt because in the scenario where they change the fixed supply, that's obviously so core to the economic, economic consensus of the network that the network splits in two and everyone that holds Bitcoin on either chain ultimately would decide Very quickly, what's valuable and what's not. But what are other potential scenarios that are maybe not as overt that you think about in terms of just the risks of changes to the rules?
- [23:10]
B
Yeah, a good question. I think the one you laid out about the OFAC list, maybe that one's too obvious, but I'm going to reverse sort of like the child porn thing that's being discussed online about what happens with that. What if the government says, okay, well if it's in the blockchain, then it's illegal or something like that and anyone who mines it is going to be deemed in possession or something. Then you kind of have the reverse scenario where every minor is going to avoid that like the plague and they might actually adopt like knots or something just so they can avoid that legal liability or something like that?
- [23:59]
A
Well, I mean it seemingly gets into that scenario of do you filter? Or if it was something like that, it would seem like it would potentially need to be hard coded. And the only defense of that is hash rate distribution where it's not credible. And if it's not credible then it's less likely to be attempted. But maybe you also draw the distinction between, because it is current to the debate, and I don't want to go super deep into Opera turn and have this just become a conversation about the Opera turn filter, but discuss the difference between non consensus or like maybe three vectors, non consensus rule, like a relay policy, a consensus rule that creates a hard fork versus a consensus rule that creates a software. We talked about one scenario that would create a software being more restrictive, but just maybe talk about each one of those and how they're different in relation to each other and then where what might or might not be an area of greater or less risk.
- [25:12]
B
Yeah, so consensus rules, there's a bunch of them, but the main ones that you know are like the fact that you have a 21 million limit that's the result of the emission schedule which is halving every four years. And that's specific to the coinbase transaction. There are specific rules about how the Coinbase transaction needs to look and so on that have been encoded into Bitcoin since the beginning. And there's a lot of consensus rules, including the block size limit and number of signature operations and things like that. There's different opcodes and what they do. A lot of them did nothing, but they were changed so that it would be backwards compatible and so on. So there's a whole bunch of things that every node checks for consensus validity and it has to Pass all of those. For a block to be considered valid. And for a block to be considered valid, every transaction within the block has to be considered valid as well. Within each transaction, every opcode and everything has to resolve a particular way, otherwise it's considered invalid. And if you have an invalid transaction or invalid input signature or invalid anything, basically the entire block is invalid. That's the consensus rule. And if you tighten the consensus rules just a little bit, that's called a soft work. If you loosen the consensus rules, like with block size increase in 2017, that would have been loosening because there was a consensus rule that said blocks have to be 1 megabyte. And people, particularly businesses that didn't really want to write all this segwit code, let's just make it into two. But then that would have been a hard fork, because every node that thinks that one megabyte is the limit is going to reject anything bigger than that. So that's what a hard fork is. A soft fork would be like shrinking it.
- [27:29]
C
Right?
- [27:29]
B
Because if it's 500,000 bytes, then that's still under a megabyte. And actually that was like a proposal for a long time because we weren't developing a feedback or whatever. So those are two examples.
- [27:45]
A
And originally, if I'm just to use that as an example, originally there was not a cap. Or was there?
- [27:52]
B
There wasn't. And then I believe Satoshi put it in there as a way to prevent trolling because at the time bitcoin was just so cheap. So you could potentially create these really large blocks and just kind of ruin bitcoin, like a 4 gigabyte block or something like that.
- [28:14]
C
Right.
- [28:17]
B
And decided to put it in there as sort of like an anti denial of service measure.
- [28:24]
A
And I think in my view that having on that point having some fixed space, not just on a denial of service, but it ensures that in concert with the fixed supply that there's scarcity of block space which should ensure the integrity of the system. To have a fee market to actually pay bitcoin miners after the 21 million supply cap is exhausted or issuance schedule. But to hone in on the example of okay, there's a one megabyte block. In 2017, certain participants in the network, including miners, proposed two megabyte block. In that scenario, everyone that was looking at the rules saying a block cannot be larger than one megabyte would have instantly invalidated any block that was greater. And that is what would call what's referred to as a hard fork, a split in the network. But in a scenario where someone using the other example you provided said, hey, we're going to propose a set of rules that say everything. It's only valid if it's over. If it's under half a megabyte, if everybody else continues to mine one megabyte blocks, that would be invalid to the soft fork. But it's more restrictive so it doesn't immediately create a fork. It could create a fork.
- [29:58]
B
It could. If you, if you had somebody mined the 750,000 byte block, then it would be valid on one and invalid on the other. That's where a fork happens.
- [30:09]
A
So just talk about some of those incentives in terms of likelihood, because of. It would seem that it's difficult to affect a hard fork because you'd immediately fork off the network. But with a soft fork, even there would generally need to be wide consensus because of the possibility that someone continues to mine on the old set of rules and what those consequences would be.
- [30:37]
B
Yeah, so in a hard fork, you just sort of go your separate ways. You never merge back or anything like that. With a soft fork, you have this weird possibility where one side has the advantage. If they're ever longer than the other, then the other side kind of has to take it. So the way that works is that people running the old software might have a transaction that's valid to them but is invalid to the new set of rules that would cause a fork. But if at any time the new set of rules, the total amount of work proof of work done on it is greater than the total amount of proof of work done on the other chain on the old chain, then the old chain just takes all the blocks of the new chain.
- [31:33]
C
Right.
- [31:33]
B
It's what you call a wipeout, where all the blocks that you constructed just go away. And this is why whenever you have a software, you want a big majority on the new side so that you don't get wipeout like that, which would be like, from a user experience standpoint, like a nightmare, because you think you've deposited some amount of Bitcoin to Kraken or something, and then it gets wiped out.
- [32:10]
A
It basically reverts back to the address that it was previously in. You don't necessarily lose Bitcoin, but it could have significant consequences for anyone that's doing real commerce.
- [32:19]
B
Yeah, it would be a long. You would basically be going backwards in the blockchain and then going up like another path and it would be. And those scenarios. I know the developers spend a lot of time just trying to figure out what to do in those situations because they're rare, but they're very, very disruptive. So try to avoid them as much as we can.
- [32:48]
A
And then I want to come back to the soft fork idea in terms of a change of consensus rules, but then talk about it in relation to something like a relay policy that's outside of the consensus rules.
- [33:05]
B
Yeah, so relay policy is really about the peer to peer network. And the way Satoshi designed it is that transactions go from node to node and whoever happens to be the miner, they construct a block based on these transactions that are sort of gossiped onto the network. And what I mean by gossip is everyone tells everybody about everything that they know. If you do that for absolutely everything, then you kind of get some bad scenarios, you get denial of service vectors. So if you have enormous transactions that are constantly coming in and there are say like very low fees or something like that, they can kind of take down your node because it's filling up your memory and so on, and your mempool. So relay policy tends to be different than the consensus rules and a little more restrictive because there are valid transactions, but a lot of them, you don't know what they mean. Right, well, explain that.
- [34:12]
A
Validation based on consent, the consensus rules.
- [34:14]
B
But, but you don't, you know. So right now, for example, there's a version field in transaction. There are, I believe, three versions that are allowed right now. I think one, version one is what it began with. Version two is if you're using check sequence verify, which I think was introduced like, I don't know, seven or eight years ago, so I forget. Exactly. And then version three is more recent. I think it's something to do with mempool policy. But it's like there are three versions that are valid that are known by everybody. Version 4 could be valid at some point, could mean something at some point, but it's still perfectly valid as a transaction. But if you don't know what it means, it's like, okay, this is probably a mistake. You just sort of don't relay it even if it's a valid transaction. There are lots of things like that. Like there's something called the Taproot annex and it's a field that's there so that upgrades can happen on the Taproot script, for example, but it's not supposed to be used. So the relay policy says, okay, if there is a Taproot annex, we don't know what it means yet.
- [35:32]
C
Right.
- [35:32]
B
So don't relay it.
- [35:34]
C
Right.
- [35:35]
B
In which case it doesn't get relayed, but it's valid to put stuff into there. And there have been transactions bind with a taproot annex in it and lots of little things like that. Where as a node, when you're relaying stuff, you kind of want to know what the transaction means before you relay it. And if it doesn't make sense to you, then why waste the bandwidth in uploading it to other nodes and so on. So that's kind of the idea of the relay policy, is that you want to know about stuff, but there are things that are legal in the blockchain but that you don't.
- [36:20]
A
Valid.
- [36:20]
B
Yeah. That are technically legal, but isn't necessarily something that you want. It's a lot like the distinction between legality and morality sometimes where something is technically legal, but it's morally dubious. As a node, sometimes you want to just filter for those things because you can have transactions with all kinds of stuff in it that are technically legal, but that would.
- [36:55]
A
When you say legal, you're talking about valid based on consensus rules.
- [36:58]
C
Right?
- [36:58]
B
Right. So like having a transaction version that's for or greater the versions are there so that you can hint to the software, hey, this is what's in it. But a lot of that hasn't been invented yet. Version 2 didn't exist until Check Sequence Verify. And it was there so that there would be a clear distinction between version one and version two. It's like version two, there's a code path that says, okay, now you got to go check the sequence field and figure out the relative time lock for this for this transaction. And version one is like, you, you don't have to worry about the sequence field. Right. So you, you don't have to go through all of this logic that that's, that was like a flag or something like that, and that, that's very useful for the software. And if it's sort of creating, you know, it's adding meaning to something that doesn't exist yet, then you know, it's just kind of polluting the, the blockchain with like bad meaning, if that makes sense.
- [38:10]
C
Right.
- [38:10]
B
It's. How can I put this? It's kind of like a, like a spelling error or something like that. That's that, that's how I would consider it almost. And it's like, okay, yeah, don't like, it's either a mistake or somebody doing something malicious. So it's not really worth relaying something like that.
- [38:31]
A
I think that's one of the areas where when it comes to specifically the relay policy, which is every node in the network is Deciding what they want to relay and not, and that there's a distinction between consensus valid transactions and a node deciding. And that being could be an individual or a business deciding what they do and don't want to broadcast to every one of their peers that they're connected to based on all the transactions that they're seeing. On some rules based when it comes to mining centralization and pool centralization specifically, if in the scenario where say the sixth or seventh largest pool, because what's currently being proposed, without again getting too into the substance of the debate, increasing the OP return limit, using the example of the day, if the largest six or seven pools decide that this is something that they want, can they effectively force that onto the network and then what are the consequences of it?
- [39:47]
B
Yeah, I think they kind of can.
- [39:50]
C
Right.
- [39:50]
B
And that's kind of the point that Libre Relay was making is that as long as they get the transactions themselves, they can mine them. And Libre Relay is like a node that specifically connects to these miners and sends them the large OP return transactions. And if they put it into a block and it's legal or valid, then everyone else takes them and then that's it. The problem here is that because of minor centralization you have these known nodes that are constructing the block. So there aren't that many, probably like 16, like I said, nodes that if you reach probably any one of them or a good number of them, then you're going to get that transaction mined. Like, you know, if it has enough fees and so on, then, then they put it into a block and everyone sort of has to follow it.
- [40:59]
C
Right?
- [40:59]
B
That's, that's the main, main thing that they could do. But if you had a distributed mining system, then you don't know where all the miners are and you're forced to rely on the P2P network to do the distribution. Now it still doesn't take very much for these transactions to go out to everybody, right? There's something called the percolation threshold and that's based on how many connections each node makes to other nodes. But I think the average number of nodes are the number of connections that a node has is something like 10, in which case the percolation threshold I think is 10%. So if more than 10% of the network relays a particular type of transaction, then it's going to be known by everybody pretty much. And that graph is pretty steep right around 10%. So it's like almost zero at 9% and then almost certain by 12%, something like that. So that's just how the math works out with network stuff and gossip protocols and stuff like that. And Peter Todd I think has figured out ways to connect Libre relay nodes to other Libre relay nodes to make sure that the percolation happens a lot more reliably. In which case I think you need even less. So it'll get to a lot of stuff even with a small number. But the bigger thing is that each miner decides what to actually put in and some of them may be economically motivated. This is sort of the argument that a lot of core people have been saying is that oh if they can make 5 more cents they'll totally do it. Well I mean that's not exactly taking in all the costs. We were talking before the show about the cost to a knots miner.
- [43:06]
C
Right.
- [43:07]
B
Like if you're, if you're running knots and mining the risk that you have is that it takes longer for a previous block to get to you because you don't have those transactions in there yet.
- [43:20]
C
Right.
- [43:20]
B
And this is what a lot of core devs are saying is like compact relay is broken. Well compact relay depends on you having some of those transactions for the next block already in your mempool and if you don't have them then you have to now take time to go and get them. So if a block has a bunch of transactions that you don't have in your mempool then it takes you longer. Which means that say you have like a 3 second delay that's like half a percent of the entire time that you could be mining.
- [43:51]
C
Right.
- [43:51]
B
Like given a 10 minute block that's like half a percent of 10 minutes. So you'd be sort of like losing money. But it's kind of a double edged sword. It also hurts the miner that mined that block because if the compact block relay is kind of broken for them then whenever they mine that block then there's orphan risk for them because in the extra time that it takes for the block to propagate then other miners might find the block in which case now you're in a race and you might lose. So the way I would describe that particular dynamic is it's what's called a costly punishment. I'm punishing myself as a way to punish you. And if you're not taking in some of this stuff then I'm giving you a little bit of orphan risk but I'm also giving myself a little bit of orphan risk and it's kind of a game of chicken almost.
- [44:58]
A
Right. So that's one thing as it relates to the relay policy. And part of what I'm trying to frame is the distinction between the relay policy and consensus. And I want to come back to consensus to talk about some of the implications. One of my primary issues with the way that this specific change is being proposed is the recognition that functionally six or seven nodes in the network, the large mining pools, and determine what's best for the network, which if say you took that six or seven mining pools that represent 90% of the hash rate and you said there's 100 mining pools and they all have 1% of the hash rate, and if 90% of 90 out of 100 rather than seven out of seven all decided that something was best, there'd be a greater assurance that there really was consensus over.
- [46:06]
B
Well, it wouldn't be consensus, but not.
- [46:08]
A
Consensus rules, but a rough consensus of the relay policy. And that part of the way that I see Bitcoin's value is that it's purpose built to be difficult to change. It should be difficult to change the relay policy, or at least what the rough consensus of the network is. It should be even harder to change consensus rules, which it is, but that basically the centralization creates a scenario where. And changing the relay policy could create a scenario where either just the six or seven largest blocks or sorry, miners mining pools get to decide, but then what precedent it sets for the future of how changes get made. And so I think there's a scenario where, hey, if it's six or seven mining pools that control 90%, do they just have to functionally bring everyone along? Because if it was more distributed, someone might propose a change and if it wasn't adopted, it would create risk for all miners and then they would re gravitate around there being a rough consensus and relay policy, which to me seems to be lost a lot in this specific conversation. Is there actually value to the network of there being rough consensus and relay policy to reduce risk?
- [47:34]
B
Yeah, I mean it would of course be nice if every node behave the same way or something like that, because then it would make stuff like compact block relay much easier. But I think more than sort of like miners doing that, I think the bigger risk is actually coders doing that, developers doing that, where they get to decide things for the network. Miners, for the most part, I think we saw in 2017, they, they just want to know what the rest of the network wants and then they kind of do it and make the most money they can within those limits. And I put out a tweet a while back, I think they would fold like Cheap chairs. If there was any sort of orphan risk or anything for their business, they're all kind of fragile anyway. They're almost all fiat businesses taking out way too many loans or issuing bonds or something like that and needing to pay stuff off. The bigger risk, I think comes from the developers where if they get to set this relay policy against the wishes of a lot of plebs, a lot of users, then can they do that with a soft work, a contentious one?
- [49:03]
A
Yeah, and I think that that's actually where I want to go before we get there, because I want to discuss that scenario. Specific is I just want to talk about a scenario where say 90% of miners, because in this scenario, the developers, they're just proposing a new relay policy, miners still have to run it. And in this context, node runners, they might not want to relay transactions, but they're going to accept the transactions as valid and that the stakeholders, most of consequence in this debate are miners, because are they going to propagate the transactions and are they going to mine the transactions? And so the developers are just proposing a rule. But again, in that scenario where if there were 100 different miners, each with 1%, part of what I think about is would they even propose it? Because it would be harder to game theory what 100 interests might decide and they're more likely being 40% going one way, 60% going another, and it's creating propagation issues in a real way. Because my understanding of that is if you've seen a transaction and you store it, but you don't pass it on, it's actually very quick, if you see a valid block to validate it, that the real issue is if you've never seen the transaction and you don't have it stored somewhere on your node, even.
- [50:36]
B
If you haven't, then you have to go ask somebody.
- [50:38]
A
Yeah, then you have to go ask somebody. And that's the scenario where there can be some delay, some delay. And it's also what then will cause there to be gravitation around a rough consensus and relay policy because it's not in the interest really of any miners to have their blocks potentially be orphaned.
- [50:55]
B
Right. And that's the costly punishment aspect of it, is that a lot of people are like, oh, you know, it's completely useless to run knots or whatever, but if you're a miner, that's running knots, if, even if you're, if it's a small amount, you're adding just a little bit of orphan risk to the miners that are mining spam.
- [51:21]
C
Right.
- [51:22]
A
So that, that's but is that true if they're in the minority versus if they're in the majority?
- [51:28]
B
Yeah. I mean, you're still hurting them, right? Because even if you have 1% of the hash rate, you might still find something that's always a risk. Even if it's a very tiny risk. It's still a risk, but it's a.
- [51:40]
A
Risk to yourself too because it takes longer for your blocks to propagate.
- [51:43]
B
Right. That's why I call it a costly punishment. You're punishing yourself, but you're also punishing everybody else. The miner that created that block. Which is why, you know, the sort of line that I've heard over and over again is oh yeah, it's completely useless to run knots. What are you doing? Right. Like you're not really changing anything. Actually, if you're even running like a little bit axe at home, you're mining. And if you're doing it in a decentralized way or whatever, you're kind of at least making it a little bit more risky for a big miner to include transactions that you haven't seen because they might get orphaned and that, I mean, I don't think any of them really act until they actually are orphaned. And the probabilities are small enough where it might not happen for quite a while, but once it does, then they're going to be like, okay, we just lost like $4 million.
- [52:42]
C
Right.
- [52:43]
B
What are we going to do because. Or 400,000 or yeah, whatever the current block thing is. 400,000. Like, why take that risk? Let's just do that. So in a way it's I think game theoretically useful to sort of even punish yourself. Even if it's. If there's like very little probability of succeeding, like collectively, it ends up actually starting to matter.
- [53:17]
A
Yeah. And I think coming back to what's I think of greatest consequence here is that, or at least in my framing and thinking is that I wouldn't expect even in this scenario, say the seven largest mining pools that represent 90% to adopt a new version of Bitcoin core that they think would hurt the network. Their interest is aligned. And I even wouldn't think that the Bitcoin core developers are proposing a rule that they think would harm the network. My own opinion is I generally view that they think that it's in the best interest of the network. Where I still see concern though is when there's a shockingly few number of people. In my view, there's always risk to change because there's an unknown, there's an unknown of what incentives are opened up. And the Fiat world is 200 times larger than the bitcoin world. And there's a lot of fiat incentives that are unpredictable. And that so long as there's great distribution and decentralization in decision making, if there's overwhelming adoption of something that's proposed, even if something which I think is discounted in terms of the relay policy because it's not a consensus rule, those smaller number of actors might be making a decision that they think is in their own interest, in the best interest of the network. That actually could have unintended consequences if there were more participants participating in that rough consensus. Even if something like a relay policy, there would be a greater insurance if it was overwhelming, that it actually made sense. Now, let's take it to another. One of my concerns which you raised is if this sets a precedent on the relay, but then something similar happens with a contentious software. If you could lay out, you brought that scenario up, so lay out something tangible and how that might play out.
- [55:31]
B
Yeah, so the, the thing that really bothers me about this particular op return thing, I, I don't think the change is all that big of a deal. We still have like the block size limit and stuff like that to limit spam, so ultimately it's going to get priced out by economic transactions in the end anyway. I mean, maybe in between we suffer a little because blocks are a little bloated or something. But ultimately I think it's a problem that solves itself. So I'm not too concerned about the actual change itself. What I am concerned about is the process which currently is, hey, we're the developers and we're going to. Even though there's a whole bunch of people in the community that don't like this change, we're going to go ahead with it anyway. And there have been several sort of like, justifications for that. One is, hey, if you don't like it, just go run some other client. And then as soon as you start running another client, hey, that client is so stupid, you shouldn't, you shouldn't run it.
- [56:36]
C
Right?
- [56:37]
B
Like that's. Yeah, it's like kind of talking out of both sides of their mouth. And that's, that's to me like a very fiat political tactic of, hey, if you don't like it, then don't do it. But not like that.
- [56:48]
C
Right.
- [56:49]
B
Like it's, it's just kind of closing off all doors because we're the technical experts, which is basically how they push the vax, among other things. So I don't like the tactics that are being used to do that. And I don't like that they basically push this change through more or less forcefully without really listening to community feedback, which suggests to me that this may happen again.
- [57:20]
A
Right? And just on that point, which is if you say, hey, if you don't like it, because that's the idea, it's like, hey, developers are just posing code. There's no auto updates in Bitcoin, certainly not in Bitcoin core. So anybody who runs it would have to voluntarily be opting into it. If you said something along the lines of, hey, if you don't like it, run a different version of the software. But at the same time you're thinking there's not a credible another version of the software, then it's not a genuine.
- [57:56]
B
Yeah, I mean, you're making a power play, right? And that's what I think the whole thing has felt like for pretty much everyone. It's like one of the things about a lot of coders is that they're not entirely socially aware and they think they're hiding their motivations when it's crystal clear to everybody they're forcing this change. They think they're in the right and they think they know better than everybody else and they are basically making it so that it's going in whether you like it or not. And that kind of attitude is just like completely against the ethos of Bitcoin.
- [58:35]
C
Right?
- [58:36]
B
It's supposed to be a community project, it's a consensus system. You're supposed to listen to other people and stuff. And instead what we're getting is, oh, everyone that disagrees is just an influencer or whatever, or you guys are so stupid, it can still go in to blocks and so on. And the attitude is one that inevitably leads to some form of authoritarianism. And I think it might show up in a contentious software.
- [59:11]
A
Let's go there. But that made me think of one last question. Do you think that if mining was more distributed, whether their calculus on changing the relay policy would be different?
- [59:33]
B
So if we had a lot of different miners, I think their arguments would be very different. I don't know if their attitude necessarily would be, or their calculations around that would be because the main arguments that they've been giving is, well, filters don't work, it just gets into blocks anyway and things of that nature. That wouldn't be the case if you had lots of miners, because the P2P network is where the blocks would be coming from and not these five or six players. And A lot of the assumptions or a lot of their arguments depend on these six largely centralized mining pool players staying that way forever.
- [60:20]
C
Right?
- [60:21]
B
Because yeah, filters don't work when you have six players that are creating all of the blocks in the sort of peer to peer transmission sense. There are other ways in which filters work which I won't get into, but those are the types of arguments that they're making is based on the current situation. I think it would be different kinds of arguments, but they would still be sort of digging in their heels on this.
- [60:54]
A
Where I was specifically going is just like their calculus as to whether or not our handicapping of whether the changes would be adopted by minors, that if there were more of them and they were more distributed then they couldn't look at party A, B, C, D, E, F, the six and say, and I'm not suggesting that they went to discuss it with the mining pools, but just even if you didn't, if you could handicap what six or seven large mining pools might do versus there's 100 and you don't know who they are. And what if only 40% adopt versus if 60% didn't? Is this proposed change still a good proposed change, whether that would change their calculus?
- [61:39]
B
I mean, I think they would. If only 40%, say of the miners like adopted it, then your argument that it makes for a more accurate mempool for fees would no longer apply.
- [61:54]
C
Right.
- [61:54]
B
Because that depends on you running the same software as the miners and if only 40% of them are doing it, then you're only going to be accurate.
- [62:03]
A
40% of the time and there'd be propagation issues.
- [62:06]
B
Yeah, and that's. So those kinds of arguments, like the arguments again would be pretty different I think, but they seem pretty determined on this. And I've never seen the core devs quite like this before. I've been in this space for a very long time. The way in which they're so violently suppressing dissent.
- [62:33]
C
Right.
- [62:35]
B
It's been absolutely shocking to me. Just like I saw a core developer say the reason why we're so all in on this is because we think like we've already taken a lot of the hits, let's just go all the way or something like that. Which is like really you're just going to keep going because you're sort of in for a penny, in for a pound fallacy. We've already fought for this long, why not just go all the way now?
- [63:02]
C
Right.
- [63:03]
B
I don't know, it just seems like very, the character of this particular fight is very different. Than anything else I've seen in bitcoin before.
- [63:17]
A
Yeah, well, and you've been around for a lot longer than I have. I was around for the 2017 hard fork, but a lot of that was not being driven or at least the side that was hard forking was not being driven by Cordoba as they were on the conservative side. And then Taproot was a very long process. There was, there was, you know, I think criticisms around activation. Activation, yeah. But I, at least from my seat there was widespread like I don't remember any individual voices of people that I knew that were like adamantly against something and it might have been, but just saying that this does seem like a shift and one of the precedents that it set which they've actively put out there is that if there's consensus amongst our developers, which in this sense there's Luke on one side and maybe one or two others, but by and large there is consensus amongst core developers that they've basically said the precedent is if there's consensus amongst us then we have an obligation to do what we think is best regardless of the users of the network. There's contention. Play that out. If it's a change the consensus rules because I would expect they would say that would be different. But if there was consensus amongst core developers or contributors that some software made sense, then talk about it in relation specifically to mining centralization. If there's six or seven mining pools that control 90% of the hash rate and they agree can functionally core developers by writing code which again users of the network have to adopt. No one's putting a gun to their head. Is it a lot easier than it would seem to. Potentially in a more restrictive way. But also restrictive is a loose term of it opens up surface areas from a transaction perspective, it's restricted. Is it more easily possible to change the rules than it otherwise should be?
- [65:57]
B
I mean, you're asking me to speculate on like what might happen should.
- [66:02]
A
Well, I'm just saying apply the same circumstance to a contours of software.
- [66:06]
B
Yeah, I'm trying to think about it and I think it's kind of an open question right now. Can the developers and miners team up together and screw over their users? I don't know. It's possible.
- [66:19]
A
Let's just play through a scenario. Okay, There is a software proposal. The six mining pools that represent 90% of the hash rate support it, but a lot of users in the network and potentially some cohort of the 10% of the miners that don't support it or assume that 10% don't. What plays out in that world.
- [66:46]
B
Yeah. So in that case, I think it gets. I'd say so. Assuming that the core devs are sort of aligned on this change and they go to the miners, 90% of the miners agree with them.
- [67:00]
A
I don't want to say they go to the miners, they put software out, and the six largest mining pools take it. Okay.
- [67:08]
B
I think it comes down to the users and it's whether they adopt it or not. And this is where it gets kind of tricky, because a lot of users trust the devs right now, although I think some of that is breaking down. Not too many of them trust the miners. I don't think that. I think that 2017 more or less killed that. But there is a scenario in which something like that happens, and then, I don't know, like, maybe there's an alternate implementation, maybe it's not something like that, and they, they don't agree with it. And at that point, like, maybe there's like two incompatible soft forks or something like that, which ends up being a hard fork.
- [68:03]
C
But.
- [68:04]
A
Yeah, but there, but, but. So, like in that scenario, I mean, there's two scenarios. A new version of Bitcoin, as before, that has a soft fork, and if there's 90% of miners that support and say 10% that do not, and they mine an invalid transaction, it would create a hard fork. Which one?
- [68:34]
B
If they mine an invalid transaction, then it's still sort of. They'd be flowing, they would invalidate, but then it can get overtaken. So this is where the game theory gets a little bit complex, because if you can get overtaken and wiped out at any time, you're going to want some protection against that. Now, traditionally, what forks have done is they purposefully make it so that it's going to no longer be a soft fork, but a hard fork, so that they can't get wiped out because you don't want the chain to roll back 100 blocks or something. Right.
- [69:10]
A
And when I said, when I meant mine an invalid block, I meant like mine a block that would be invalid.
- [69:15]
B
Yeah, yeah, but then you can get overtaken if it's longer.
- [69:17]
C
Right?
- [69:18]
A
So that, that's the, that's my point. So there's, There's a. There's a real risk to the minority such that it would.
- [69:23]
B
There are things that the minority can do. So you can do sort of like an incompatible softwork or something like that. I haven't thought through this yet, but.
- [69:34]
A
Like, the users of the software could write code that Says, hey, anything that looks like that is not valid.
- [69:40]
B
Or something like, yeah, something like that. So that what ends up with is like two softworks that are sort of mutually incompatible and everything before just takes the longer chain, but nothing wipes out the other. Something like that, which would be a very weird scenario. I haven't really analyzed that particular one, but that's something that's a potential way in which the minority might deal with it. They might even just hard fork. I don't know.
- [70:07]
A
I think in my mind the most realistic scenario is, and what concerns me about this precedent is that a contentious software meets all the same criteria. And even if someone says that it would be different if it was a consensus rule is that if you could handicap what the six or seven largest mining pools would do, if you set the precedent that if there's consensus amongst core developers, then you have an obligation as a steward to push that change. And the change would go through because the six or seven largest mining pools would. If they follow, I'm saying in the scenario that they do, and then the minority, there's major risk to hard forking. And as users of the network, you might not know. Right, but there's a lot of risk associated with that. And the most likely scenario is it's not going to create immediate catastrophic risk to Bitcoin. It's more of one of those things that's death by a thousand cuts and more realistically, potentially by 10 cuts that cause some change that might not singularly distort incentives. But if you add up a number.
- [71:25]
B
Of changes together, there are too many moving parts though. So the miners would not agree to do that if they saw the possibility that there could be a minority with an economic majority or something. So what would probably happen in a scenario like that before it gets to that would be some sort of futures market. Okay, there's this part that wants to do that. If they ever hard fork, then you get. But you don't know that there would.
- [71:51]
A
Be a hard fork.
- [71:52]
C
Right?
- [71:53]
B
But you can make a futures market that bets on that.
- [71:56]
C
Right?
- [71:57]
B
And you can trade those and maybe deposit some Bitcoin and bet on it. This is what happened with 2017 and so on. And miners would look at that and say, okay, well here's this side and how much it's like, say it's like 90, 10. But when they look at the price of the futures market, it's the other way. It's like 2080 or something like that. Then they're going to be like, well, it makes no economic sense. To go mine on this chain that the core devs are proposing, we're going to have to go with this.
- [72:32]
A
So, yeah, it's one thing if there's two different proposals. Like it's one thing in 2017 where you knew whatever was being proposed would result in a hard fork versus if you don't know whether someone would do something.
- [72:43]
B
Well, so this is where the game theory continues, right? Because that possibility is there. Then somebody might propose something to consolidate the opposition, in which case you have like two incompatible softworks or something. And the softwork that has more hash rate in it kind of wins or is not hash rate in it. More economic majority in it.
- [73:10]
A
Yeah, agree. In the scenario where there is a.
- [73:11]
B
Hard fork, then, no, but like the minority at the point where they know that they're a minority is motivated then to create that scenario so that they can win. Right. Because if you have 90% hash rate and 10% hash rate, you're going to lose. But if you can influence the 90% by creating the scenario, then that's what you're going to do because that's the only way you can win as a 10%.
- [73:38]
A
Right. And in my view, it's like the reality is that you're not like 10% because you don't know what any other economic actors are going to do.
- [73:47]
B
Well, this is why futures markets will probably pop up for that reason. And then you just need a proposal. And then once you have a rallying point, then people will be like, okay, well let's start betting on this, and so on.
- [73:59]
A
But then let me put it another way. There's never been a soft fork. I guess there's never been a contentious soft fork. But there's also never been, when there has been a soft fork, there's never been a hard fork out of there. So it would be an unknown territory.
- [74:16]
B
Well, I mean, bitcoin cash was a hard fork off of it.
- [74:19]
A
Right. But the proposal was always increase the block size. Everyone knew that it was. Now I want to depart there. And this kind of last segment that I want to talk about is one of the other consequences in this circumstance is that it's very much one. One of my other problems is I don't think that there was ever an open debate or interest in a debate. There was a decision made and didn't really matter what another side's perspective was. There was a decision made. One of the most important constituencies in the discussion around the relay policy, specifically the changes to it, is the mining constituency. And they're largely absent from the debate save and accept. You can assume what Marathon does because they have their slipstream and you can know what a pool like Luxor does because they're Luxor. But those are all the pools. All of this seems to be in the disinterest of the miners themselves. They're coming back to the very beginning, which is the miners that are not participating directly in consensus are largely devoid.
- [75:43]
B
Of.
- [75:46]
A
Not just a voice, they don't have control of their hash rate. At the end of the day, someone else is making their decision. And there's always the idea that, oh, you can switch pools, but functionally speaking, what do you think the consequences are of so few miners actually participating directly in consensus as well as in what versions of Bitcoin they run? That includes things like the relay policy that's set outside of consensus.
- [76:17]
B
Yeah, the consequences are that they're sort of mercenaries, right? Like hash rate for sale. And yeah, it's unfortunate because it would be better if they were all sort of individually making decisions and cared about the network. It's a little bit of a fiat artifact. A lot of these miners got into it because they, they happen to have some cheap energy and contacts with the mining equipment at manufacturers or something like that. I think what will happen is that there will be more user level mining to decentralize it a little more. It's already happening with stuff like bitax obviously at a tiny, tiny miniscule scale. But more of that I think is in the interests of a lot of users. And once you get that, then you don't have mining centralization anymore and we don't have to talk about all of the problems that they cause because there are so few people that make the decisions. It's not necessarily that they're bad people, it's just that you want like the entire ethos of a decentralized system is.
- [77:36]
C
That.
- [77:39]
B
You don't have central controllers, authoritarians. And unfortunately we have that in this. And something that I think everybody wants is decentralized mining, including all the devs and everybody on both sides, I think, which is why a lot of the mining voice is not really in this because both sides are claiming that ultimately what they want will decentralize mining.
- [78:07]
A
Right. Kind of like two sides talking to each other. And the miners are just like, hey guys. Well, I mean they're not, because they're generally not part of the conversation.
- [78:15]
B
No, no they're not. And yeah, I mean they've been cut off since 2017 from a lot of this stuff. It's kind of a very Strange thing.
- [78:23]
A
But I mean it is one thing that I also think about which because most of them small to mid sized miners, which I would say small, but they are a dedicated mining business, not somebody running a bit axe or just home mining with a single asic, mining's their business, but they're a small miner. To someone that might be a mid sized miner running 10 megawatts of power, which is a lot of power, there's nothing small about it, but relative to the riots of the world, small that they might be aware that there's a debate about something changing as it relates to relay policy and that might have a certain consequence, but they have no idea the substance. And because they're removed from it via the pool, it's almost as if, I don't want to say it's not their problem, but it's something that they don't realize that they need to have a more active participant or to be a more active participant in because it's their hash rate. And then that leads to the question of, I would wonder, I doubt that riot that has nearly, probably a gigawatt of power online. Securing the bitcoin network is opinionated. And then my question to you would be like, there might be disinterest between a miner and a pool, but if the miners aren't really engaged, the pool isn't seemingly incentivized to do something in the disinterest of their miners. But if they're not actively participating in consensus, how do they.
- [80:06]
B
Yeah, the problem actually comes back to fiat money because a lot of these hashers are fiat funded. And the way fiat money works is that it makes big things grow bigger. So mining is a margin business. You get the marginal energy that the power plant can't sell at higher rates and you get sort of like the leftovers. So there's a ceiling to the amount of energy that's available in any one location. So there's a natural limit to the scale that you can have in any one place because you're just getting the leftover energy from everywhere. But the way fiat money works is that they want to fund the bigger things. And so you can almost always get money printed out of nothing as loans to grow bigger, which is what a lot of these mining conglomerates have done. They've grown bigger. So I suspect most of them, a lot of the big ones probably don't even make money on a lot of that stuff. They build it out just because they.
- [81:12]
A
Can get the, well, I know Marathon mines, bitcoin at a loss just based on their financial statements, which doesn't make any sense.
- [81:19]
B
But that's a fiat consequence, right? Like because they can get these loans, they can sell their shares into the market or something and basically just keep making it look like they're getting bigger. It's kind of a big Ponzi scheme in a sense. But that's something that they can do and that means that they don't have to care that much about all of the stuff that all, all of the stuff that's going on in Bitcoin because it's not really a profit motive. If they were profit motivated, a lot of them should be on like ocean.
- [81:53]
C
Right?
- [81:53]
B
Like you can, you don't have off band payments and stuff like that where if you're a hasher you don't see any off band payments.
- [82:01]
C
Right.
- [82:01]
B
Like if I pay anpool to get a transaction in like off band, right. With a credit card or something, I think via BTC used to have one of those. I don't know if they still do, then none of the hashers see that money.
- [82:17]
A
Right. I mean, I think that in theory some pools might say we set this into the fixed pay per share. However they do their calculations point is it's a black box and you don't know. And that so many of them are addicted to the fixed payout that that's what they're there for. I just, I guess my last question is what do you think causes it to change? That gets more miners engaged and actively being direct participants in the network. And I'm not even saying every miner has to run their own node. And I'm not also saying actively participating in whatever the debate is in the day on Twitter, but not just being reserved to the corner of the world that they're hashing and actually being a more active participant in consensus. Do you think it. Again, I don't even know what the parallel to a Mt. Gox scenario would be. Or it might just be maybe on your line of thinking as there become fewer miners that are fiat minded that actually understand Bitcoin and the conversion of energy to Bitcoin versus energy to bitcoin to fiat that that naturally brings along with it the incentives to engage in consensus and to participate.
- [83:42]
B
Yeah, it's easier for a big company to go get loans than it is to make more profit. If these cashers were more focused on profit, then I think all the problems solved themselves. I really believe that market forces would force them into a more decentralized and active participation in this whole thing. The way they're Doing things now is that they get a lot of their income from fiat money printing in some ways through loans and so on, so they don't have to care. And that's in a sense, once the fiat system collapses, mining will be fixing itself. But of course that's going to take a while.
- [84:27]
A
For now, it's functionally out of sight, out of mind. And it's almost like, well, I don't have to worry about this because the pool is going to make the decision. But at certain points, people with large interests realize that large financial interests realize that they have an actual stake and interest in informing what changes get made and why, both as it might relate to a future software or something like a relay policy. Because the economic incentive doesn't really exist just to defer, because it can either be in your purview and do something actively or not. And in the scenario where you're actually procuring all this energy and hashing what's the benefit to not? So it might be a long death of fiat or it might be a quick death of fiat. But people, I do agree with you that figuring out the bitcoin side of it and the cutting off of the fiat speculative, it is likely a natural decentralizing force that and bitcoin are stepping up.
- [85:38]
B
I run a bitax at home, right. So in a sense I'm mining at least a little bit. Even though it's like maybe five shares a day or something.
- [85:46]
A
Yeah, you're on like 13 cents power.
- [85:49]
C
Yeah.
- [85:49]
B
And it's like.
- [85:50]
C
But.
- [85:53]
B
We haven't really optimized mining very much.
- [85:56]
C
Right.
- [85:56]
B
Like you can heat lots of things and produce other goods where even paying 13 cents per kilowatt hour might make sense if you can use the waste, you do some other process where you can convert that to profit and then the little bit extra you can use for mining or something like that. Those scenarios where entrepreneurs can come in and really make a difference. But yeah, we kind of live in.
- [86:28]
A
A fiat world where Bob Burnett told me that he's mining off of cow waste. So there is innovation happening out there. I'm also going to have Tyler Stevens on who's working on a lot of not only home mining, but specifically the capturing of heat.
- [86:47]
B
Yeah, yeah, I think there's a lot of potential along those lines. And maybe it becomes really more centralized as more innovations come in in those things. Like if you can, I don't know, heat your water heater or something with mining equipment, maybe that makes the economics work. I don't really know. Or there's maybe some other technology that comes in that makes it so that you can generate energy at home. Maybe we can have modular nuclear power plants at home and you don't need electricity lines and use all the excess energy for that. The future is very difficult to.
- [87:27]
A
Well, yeah, I did see. I have bigger questions about large amounts of solar on the grid, but scenarios where people are putting solar panels on their house and there's restrictions on what they can put back into the grid, and they have three times the amount of power that their home actually needs, it's essentially excess. So I definitely see there's a large surface area for innovation and that should help decentralize it. The reality of the scenario is today the level of centralization in my mind, and I always want to see if you agree with this. It makes it easier to change bitcoin when it otherwise should be harder on a relative perspective. And that more miners will inevitably figure out that it's not in their own incentive to essentially outsource decisions about what rules are followed versus not. And that should hopefully drive decentralization as well, which will help make the network harder to change, but not just for its own sake, but to ensure that if changes are made, that there's overwhelming support.
- [88:35]
B
Yeah, I certainly hope so. It's weird, though, I didn't think about it the way you just said it, that a lot of the bitcoin mining centralization is actually like energy centralization, energy production centralization, and all of these fiat things that sort of infect our industry.
- [88:58]
A
Well, no one miner is going to solve it, but in the end, everything's good for bitcoin.
- [89:06]
C
Yeah.
- [89:09]
B
Hope so.
- [89:11]
A
Only because people are not complacent. You gotta be high agency. Well, thanks for the discussion. Appreciate you coming down to the commons. Bitcoin park and we'll do another one sometime soon.
- [89:23]
B
Sounds good.
- [89:24]
C
All right.
- [89:24]
A
Appreciate it. Jimmy.
- [89:25]
C
Yeah.