[00:00:00] It's an open secret that one of bitcoin's pillars never worked. As Satoshi predicted at the time he designed bitcoin, it faltered even before bitcoin started getting any real traction. And this failure has been part of the landscape for so long that we normalized it like a crack in the wall that's been growing for years, but we learned to ignore it. Doesn't seem to have any relation to the current mempool policy debate, better known among the plebs as spam filters, but it's actually at the center of the issue.
[00:00:34] I'm obviously referring to mining decentralization or the lack thereof.
[00:00:41] The best in Bitcoin made Audible I am Guy Swan and this is Bitcoin Audible Foreign what is up guys? Welcome back to Bitcoin Audible I am Guy Swan, the guy who has read more about bitcoin than anybody else you know. This show is brought to you by the Human Rights Foundation. Check them
[email protected] and the incredible work that they do as well as subscribe to their amazing newsletter the Financial Freedom Report for news around financial repression and CBDCs and government surveillance and authoritarianism through the banking and monetary infrastructure and the tools that help us fight back against that. You'll find the link right down in the show notes. And of course if you are looking for a non custodial, you hold the keys on chain and lightning. That just works. Check out the Bitkit mobile wallet for iOS and Android.
[00:01:51] All right now today we are going to dig into a read which I found just after I finished the guy's take and I thought this was just a really good, a really clean framing about what the real issue is because I feel like we're, we're arguing one layer up above the core issue and I almost don't like that. The issue around spam and JPEGs and everything has been.
[00:02:14] Has basically put Ocean as the crux between whether or not you want to run filters so that people who think you don't want to run filters are likely to actually be disincentivized to use Ocean or think that Ocean is bad and that what they are doing or using Ocean, the Ocean mining pool would somehow be supporting filters which is not the case. It is supporting the right for the miner to build their own template. And it is the most important project for securing bitcoin's future in my opinion. And I think this is all got lost in the debate. The issue of whether or not we want JPEGs on the blockchain and or if there's anything that we can do about them, whether it be a mempool policy or not. And I actually challenge anybody who is totally supportive of removing the OPER turn filters and is supportive of core and against Luke, to tell me what project you think is more important to the security and long term viability and decentralization of Bitcoin than the mining pool centralization problem. And the fact that bitcoin miners, the actual miners themselves, are not building their own templates. And if you do agree on the importance of that issue, what project is doing more practically, it's actually achieving more in the real world results than ocean right now.
[00:03:45] Because I genuinely find this the most important issue in combination with the most important project actually doing something about it. And to dismiss that just because you're on the different side of a debate about mempool policy is as dumb as saying bitcoin core is completely lost, has never contributed anything of any benefit, and that the reference client is garbage. I think if we actually want to solve Bitcoin's major problems, recognizing the fallacy of both of those statements and not being able to appreciate the good because we disagree on some other topic I think is just deeply foolish. And I thought this article did a great job of framing the more important picture and what's actually being done about it. So without further ado, we'll go ahead and just jump into the article and it's titled Lop Return Wars. The problem is deeper than spam filters. Stratum V1 needs to die by unhosted Marcellus.
[00:04:52] It's an open secret that one of Bitcoin's pillars never worked as Satoshi predicted at the time he designed Bitcoin. It faltered even before Bitcoin started getting any real traction.
[00:05:04] And this failure has been part of the landscape for so long that we normalized it like a crack in the wall that's been growing for years, but we learned to ignore it. Doesn't seem to have any relation to the current mempool policy debate, better known among the plebs as spam filters, but it actually is at the center of the issue.
[00:05:26] I'm obviously referring to mining decentralization or the lack thereof.
[00:05:33] Satoshi's original miscalculation.
[00:05:37] It is well acknowledged today that Satoshi didn't predict the rise of mining pools. If you read the white paper, it seems clear that he thought the network would work on what today is called lottery mining, where large numbers of anonymous small miners with an imperceptible chunk of the total hashrate would be finding blocks at random, maybe just once in their lifetime.
[00:05:58] This property of the system was the basis for Bitcoin's primary defense system and censorship resistance. It's very difficult to do something like enforcing OFAC compliance lists or a malicious fork if literally any Bitcoin node around the world could be the one that mines the next block.
[00:06:15] In other words, for mining to work as desired by Bitcoin's inventor, you should not be able to predict which nodes would mine the next hundreds of blocks, nor identify who they are.
[00:06:29] The following are a few fragments of the white paper that highlight the importance of the node's involvement in the mining process.
[00:06:35] 5. The Network the steps to run the network are as 1. New transactions are broadcast to all nodes. 2. Each node collects new transactions into a block. 3. Each node works on finding a difficult proof of work for its block. 4. When a node finds a proof of work, it broadcasts the block to all nodes.
[00:06:55] 5. Nodes accept the block only if all transactions in it are valid and not already spent. 6. Nodes express their acceptance of the block by working on creating the next block in the chain using the hash of the accepted block as the previous hash, referencing another section quote the proof of work also solves the problem of determining representation in majority decision making. If the majority were based on one IP address, one vote, it could be subverted by anyone able to allocate many IPs.
[00:07:25] Proof of work is essentially one CPU one vote. The majority decision is represented by the longest chain, which has the greatest proof of work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. End Excerpt as we all know, bitcoin mining stopped working like that very early on. In the times of Laszlo, Hynix and Artsfors, each of them held slices of the total hashrate comparable to foundry or ant pool today as a result of having independently developed GPU mining. Satoshi even admonished Laszlo over email for mining too many blocks, which gave birth to several Bitcoin pizza transactions in an altruistic effort to decentralize the issuance of those early coins.
[00:08:14] On November 27, 2010, the first ever mining pool launched Brains, formerly Slush Pool, and a couple of Years later Stratum V1 was finalized and took the mining scene by storm. The rest is history.
[00:08:29] As a bitcoin miner, there are obvious reasons for joining a pool and sharing Rewards, but Stratum V1 has a major flaw. Only the pool operator runs a bitcoin node and miners only plug in their hashing machines completely unaware of the Bitcoin protocol.
[00:08:48] This meant the death of the miner role. As was understood at the outset, it was split into the hasher that just plugs his specialized machines into the power outlet to receive periodic payouts, and the pool operator that runs the bitcoin node takes custody of the rewards and organizes the payout separately. The role of the node runner emerged.
[00:09:15] These are users that maintain a node to verify their own payments, but who don't contribute CPU power to keep the chain honest and today make up the absolute majority of the Bitcoin nodes.
[00:09:28] Even though in theory hashers can switch pools on a whim, this architecture did set the stage for a mining landscape centralized on just a few big players.
[00:09:39] Today, adding more CPU power to the Bitcoin network, or rather ASIC power, no longer contributes to keeping the chain honest.
[00:09:47] Honesty rests instead on the benevolence of our pool operator overlords Reference image for the size of mining pools the absolute state of mining did you know that over 50% of hashrate is KYC compliant too?
[00:10:06] Excerpt from Greg Maxwell and Peter Todd discussing a mining pool design reminiscent of oceans in an email dated from 2013.
[00:10:15] I was talking with Gregory Maxwell about decentralizing mining at the conference. He came up with the idea of tightly integrating mining functionality into the client using Luke Dasher's git block template protocol. The existing git work is not compatible with asics. The idea would be to make solo mining as easy as possible, and furthermore to move pools to a structure where the pool's function is to coordinate share payments, not block construction. Essentially, hashers would become true miners doing transaction selection on their own, and then pools would credit them for their shares and do the accounting. In this model, all a pool can do is defraud miners rather than harm the whole network.
[00:10:52] Smart idea. End quote.
[00:10:55] While it's true that most developers acknowledge this as a problem and have devised a few solutions, they generally don't feel like it's up to them to fix this issue.
[00:11:05] At the end of the day, working as a software engineer or applied cryptographer is very different than going into the ruthless and unforgiving business of Bitcoin mining.
[00:11:15] But to this day, mining centralization is still a big problem, and even more worryingly, it led to a second order effect that has won a lot of developers hearts and minds.
[00:11:28] The siren song of mempol consistency in summary, mempool consistency is a scenario where all nodes in the network run the same mempool policies as the pool operators it turns out that when that happens, the network can run much smoother and makes the lives of the developers building on top of Bitcoin much easier. Over time, they learned to accept mining pool centralization as a given, and they started to rely more and more on this phenomenon to build advanced Bitcoin features. I'll cover one of the first ones, and arguably maybe the most important, the poster child of mempool consistency Compact Block Relay BIP152 Compact Block Relay was proposed in 2016 by Matt Carollo and made its debut in Bitcoin Core 0.13 until that point when a pool operator found the block and broadcasted it to the peer to peer network.
[00:12:24] Nodes relayed the full block along with all the transactions in it. Compact block relay, or CBR, proposed that nodes just relay the block header only 80 bytes and let each node reconstruct the full block locally using the unconfirmed transactions it already has in its own mempool. CBR fixed the traffic spikes that plagued the old peer to peer network when a new tip was found, and it's considered a positive nudge towards keeping mining decentralized. Slower propagation means that on average, small miners with bad connectivity would see more of their blocks orphaned compared to the large pools peered directly over high speed links.
[00:13:08] Another example of something that really benefits from mempool consistency are the fee estimations, which in turn are more important for the smooth operation of L2 protocols. For because all of them are time sensitive and require timely confirmation of their on chain transactions.
[00:13:24] Does running custom mempool policy such as not accepting inscriptions ruin CBR for your node? Not exactly, because when a node discards an unconfirmed transaction due to violating a policy rule, it doesn't remove it altogether. It keeps it around in a secondary mempool precisely for the sake of compact block relay, expecting that it should still be mined. But crucially, it is not relayed to your peers. This is not the case for transactions that violate a policy that is enforced by a super majority of nodes, because in that case it's unlikely that any of your peers will ever relay these transactions to you in the first place. End quote.
[00:13:59] If mempool consistency means that all nodes run the same policies in order to see the same transactions, nothing f it up more royally than when a pool operator includes out of band transactions in a block they mined.
[00:14:13] Ultimately, I believe this is the primary reason why the developer class has been so opposed for the last two years to keeping mempool policies, colloquially known as spam filters up to date and act so viciously against node runners taking the matter into their own hands.
[00:14:30] It makes sense from their point of view. Their primary concern is mempool consistency. They clearly cannot force an old boys club of large pool operators to run sane policies.
[00:14:42] So to keep all mempools equal to the path of least resistance is taking the policies away from node runners who are perceived as being less informed and easier to lead as a herd. Their end goal is that pool operators don't have any reason to accept out of band transactions.
[00:14:59] This is also why they greatly exaggerate the extent to which mempool policies are being bypassed in the wild. See also this on chain study on non standard transactions from OXB10C, which comes to the same conclusion Mempool Policies Debunking the FUD Narratives There is such a level of shit surrounding mempool policy that I need to dedicate a chapter explaining what it is and debunking malicious narratives. To start, I think it's helpful to compare them to consensus rules.
[00:15:34] A consensus rule is a check performed either on a block header or any of its transactions that will flag that block as invalid and rejected by all nodes.
[00:15:46] An example of a consensus rule is that a transaction may not create sats out of thin air. If such a transaction were to be included in a block by a pool operator, the whole block would be rejected.
[00:15:59] A mempool policy is a check performed on a newly seen unconfirmed transaction that may prompt your node to not relay it and not store it in its mempool, but otherwise it's a valid transaction by consensus rules. An example would be a transaction that is trying to pay a fee of 0sat per V byte, or a transaction with an OP return larger than 83 bytes.
[00:16:24] Mempool policy is outside of consensus, and thus each node runner can actually run whatever policies they want in practice. A few of them are configurable in the Bitcoin conf file, and Knots has more of these settings than core. Luke Dasher recently drove this point home by doing a live walkthrough on how to add new mempool policies to Knots.
[00:16:47] Mempool policies have been in use in Bitcoin Core since 2010, and according to developer Antoine Poinceau, they have three primary discouraging malicious DOS transactions that can crash nodes, denial of service, discouraging old kinds of transactions that are about to be invalid in an impending soft fork, what he calls upgrade hooks, and finally nudging behavior to mildly deter certain activities.
[00:17:17] As you can see, developers don't think mempool policy is useless or ineffective. In fact, it's an important tool in their belt on which they rely a lot. But if pool operators don't respect a certain policy or developers expect they won't respect it in the future, what they call incentive incompatible policies, they'd rather remove it from Core than sacrifice mempool consistency.
[00:17:43] At this point, I hope I've made the connection apparent between pool operator centralization and developers optimization for mempool consistency.
[00:17:53] Now it's time to explore the point of view of the filter boys, which is based on reverting the mining centralization we lost almost since the start of Bitcoin. Instead of optimizing for mempool consistency, the anti spammer response datum, not any particular policy since October 18, 2024, you can solo mine with your bitcoin node and still share pool rewards with a group of other hashers, a monumental feat that had never been possible before in the history of bitcoin. That was when Ocean launched its datum mining protocol. Datum pushes the running of the bitcoin node back to the hasher, giving individual hashers power again about what transactions they want to include in their blocks, what forks they want to signal support for, etc. The pool only takes care of coordinating the split of the reward and making sure that miners don't cheat each other by submitting shares to the pool while paying the full reward to themselves.
[00:19:02] Datum makes it possible for the roles of the pool operator and the hasher to merge again into the unified role of the miner. This means the individual CPU power of each hasher contributes again to keeping the chain honest instead of selling their shares to a large pool operator.
[00:19:24] There are other things that excite me about datum. For instance, it wouldn't matter if a datum pool went over 51% of hashrate, as the pool doesn't control the bitcoin node. Another super cool thing is that datum works with mining at any scale. If you are already a node runner today, you can start mining at home with a bitaxe for about $150, feeding it your own block templates and participating in the network as a real miner at a small scale. While most developers won't agree with me, I posit that destroying pool operator centralization is a much more worthwhile endeavor than protecting mempool consistency at all costs. I really like how this tweet summarizes the trade offs at stake.
[00:20:08] Tweet by Eric Holden Ocean your hash, your block nots, your node, your relay policy.
[00:20:17] Every other pool Your hash my block Bitcoin core your node my relay policy this is an attack on Bitcoin. End quote.
[00:20:28] I invite both hashers and node runners who read this article to look into Datum to become sovereign bitcoin miners. And if you are a pool operator, I would like you to start thinking about phasing out stratum v1 in favor of datum or stratum v2.
[00:20:45] Bitcoin needs stratum v1 to die datum versus stratum v2 the main reason I focused on Datum in this article and hardly Even mentioned Stratum V2 is because it's live and ready to use, while stratum V2 is not. Jason Hughes, VP of engineering at Ocean, recently went over why they chose to build a mining protocol from the ground up instead of adopting Stratum v2 in a presentation he gave at the 2025 Bitcoin++ conference in Austin.
[00:21:16] Next up, there's a big topic I had to leave out of this article or it would have been twice as long. It's the common claim that, quote, any transaction that pays a fee is good for bitcoin. This is a discussion mostly centered around economics, so I prefer to do it in two separate parts. The next article will give a proper definition of Bitcoin's security budget, argue why spam is bad for the security budget, and analyze a few Keynesian proposals to, quote, fix the security budget, most notably the demurrage and tail emission proposals by Peter Todd.
[00:21:48] I thought this was a really great way to focus the the main difference because I do agree that Core or I do think that CORE is trying to make the best of a bad situation, but they are taking a policy or an approach that seems to be at odds with actually fixing the situation and what the problem itself even is, because it's not about mempool consistency. And this also leads me back to a point that I made in the guys take is that depending on the centralization of mining and the default policy of the network, the mempool inconsistency could just as could just as easily be bad for the miner as opposed to some node. The idea that it's quote unquote bad for your node is an admission that there's not going to be any change in the centralization of the pool operator and large miners, which I do not believe is something that we should be giving up on or something that we should be building under the assumption that it's going to stay that way. And I don't think it's unreasonable to believe that that this is what the path is making. This is the assumption that that path is making. And my call to action to anyone listening to this is to point your miners at ocean. Whether you want to use filters or mempool policy or not, or you're running core or not, it does not matter. Point your miner at ocean and run a node and build your own block template. This is so unbelievably important for the future and decentralization and resiliency and security of Bitcoin. I don't know how to stress it enough. Regardless of how you feel about this particular issue or op return or spam or anything. Point your miner at ocean, run your own node, build your own block templates. If we don't fix this problem, it's going to be an even bigger problem the longer this goes on. And if you are a developer, if you're a builder, go talk to miners, build the software. And in fact I can't. I keep. It keeps coming back into my head that maybe I should trying to do something about this, but I'm just so drowning in so many other things. I feel like I need to get this other project done before I even think about it. But if anybody else is out there and is looking for help or wants to talk about something or try to get ideas, talk to a miner. Talk to someone. Okay. Okay. How do you plug your software into the pool operator? How do you manage your computer that runs your Asics? What's your problem? How do you need this to look in order to make it so that you can build your own templates and run your own node? Then build that dumb simple UX for the miner to build their own templates. As easy as they are giving that right away to the pool operator right now, that is possible. There is a plug and play way to make this work and somebody listening to this or somebody who gets linked to this from somewhere else or gets told and has this conversation with somebody who is listening to this or read the article, doesn't matter. Somebody out there can fix that problem and actually make it easier to do a plug and play. Build your own block template and run a node. Then the current setup is to connect to a pool operator. I promise you that is possible and somebody could do it. Datum is there. It is ready to use.
[00:25:14] If you are mining, use it. If you are a developer, please try to help it make it easier for other people to use it. If you are a pool operator who cares about the future of Bitcoin, you can implement it. And I want to bring up another point that another one that I made in the guys take as to the the opposite side of the the policy being to to not have the transactions or inscriptions excuse me or not relay the inscriptions and how this is going to be bad for your node because there were actually two things and one thing I thought you would have to set this yourself but I actually didn't realize that how compact block relay is actually implemented apparently has this already. I'm going to try to dig in to make sure that this is true, but it's really interesting if it is. Here's the quote though. So CBR the compact block relay proposed nodes just relay the block header and let each node reconstruct the full block locally using the unconfirmed transactions it already has in its own mempool. So basically every miner or every node just rebuilds the block with transactions is already heard from and if it doesn't have a transaction it will just request it from the nodes around it. So this was a massive quote unquote it fixed the traffic spikes that plagued the old peer to peer network when a new tip was found. So this is a massive massive efficiency gain in bandwidth spikes when new when blocks are found and propagated because all of the information in the block is already distributed so there's no reason to download a second time unless it's specifically something that nodes don't have.
[00:26:50] So quote it's considered a positive nudge towards keeping mining decentralized. Slower propagation means that on average small miners with bad connectivity would see more of their blocks orphaned compared to the large pools peered directly over high speed links.
[00:27:08] But this also means in the reverse like this is why compact block relay was built in the first place because of the risk of having orphaned blocks that are outside of the the scope of or the the peak ability to propagate data and information through the network to get to a fewer nodes when big relays or excuse me big miners and well connected nodes are more likely to actually get their blocks propagated. This was trying to even the playing field. Which is exactly what would make mempool policy tip the scales one way or the other. And why if we were all building our own block templates, somebody like Mara including out of band transactions and then trying to publish to the bitcoin node would have such a huge propagation delay of their block versus miners that were in line with mempool policy for the majority of nodes their block would get to more nodes on the network faster And MARA runs the risk of orphan of having their own blocks orphaned the more out of band transactions they include.
[00:28:18] And keep in mind this is specifically out of band. Not just stuff that ended up in the mempool that has jpegs or whatever, but specifically out of band things that the mempools of all of the nodes don't have.
[00:28:31] Rather than giving into it, establishing those conditions and fixing those two problems would actually disincentivize it to financially. They would punish their own latency and their own ability to propagate blocks in order to try to get some tiny extra margin of fees from people publishing garbage into a block. That is the scenario we want and I think that's what we should be pushing for. And that is not even regardless. That's not even considering whether or not we're deciding what is spam and what is not. But specifically how do you make the conditions such that out of ban transactions that using something like strip slipstream is not good for Mara, but bad but here's the thing again, this is going to the point that I thought was actually something you had to manually configure or something.
[00:29:24] I thought this was something that you'd have to custom figure out. But this quote is interesting and I can't actually figure out where it's from. It doesn't seem he has a link for it if he listens to this or sees this. I'm really curious what this is from. Or is this just him explaining it? So quote does running custom mempool policy such as not accepting inscriptions ruin CBR for your node?
[00:29:49] Not exactly. Because when a node discards an unconfirmed transaction due to violating a policy rule, it doesn't remove it altogether.
[00:29:57] It keeps it around in a secondary mempool precisely for the sake of compact block relay expecting that it could still be mined. But crucially it is not relayed to your peers.
[00:30:09] This is not the case for transactions that violate a policy that is enforced by a supermajority of nodes, because in that case it's unlikely that any of your peers will ever relay these transactions to you in the first place.
[00:30:23] So I did not know that. I was under the assumption that the action would be to drop the transaction. But my immediate thinking when everybody's talking about this is going to be bad for your fee estimation and this is going to be bad for propagation and you getting new blocks is just going to be terrible for your node is that the simple fix is like okay, we'll take it, but don't drop it. Just choose not to relay it because you consider it spam and you don't want to send spam to your friends for exactly the same reason. We have the mempool policy of not accepting and propagating anything that zero SAP that doesn't pay a fee. Like all of those transactions are valid too. But because we want to protect ourselves from denial of service, we have no policies that don't propagate them around. And it works. It works. It works perfectly fine. That is a completely legitimate and simple use for how for what we do with mempool policy to protect the network of propagation of data propagation around the nodes. And I think it's a perfectly reasonable thing to try to focus on the block template and the pool operator centralization problem than thinking that trying to get mempool consistency under the assumption that that problem will never go away or prioritizing development in that direction is not the right course of action. And no, this isn't a demand either that core has to do this or should do this. They can work on what they think they should work on. But my claim and my opinion is that datum and what ocean mining is doing is a thousand times more important than any bullshit with Oprah turn. And to note that changing or removing the oper turn limit isn't going to fix anything about inscriptions. It's not going to fix anything about the UTXO bloat because they are specifically doing it to add 100 kilobytes met a whole megabyte into witness data that gets a 4x discount or gets a 75% discount. They're not going to switch to opreturn. All this did was create a hugely contentious argument that won't move the needle on anything in an effort to get mempool consistency because of problems from mining pool centralization.
[00:32:44] And I really think that this with all.
[00:32:47] You know, again, so much of the technical argument on both sides is actually accurate. There's lots of concerns one way or the other. The question is what conditions of the network and of the mining ecosystem existing exist in order to produce which economic results. Because it's not so simple as that. It's always one way. It's based on the assumption of what the conditions on the network are, what the conditions of the miners are, how many people are building their own block templates, how many hashers are, how many people are actually running their own node, which version of mempool policy is on 90% of the node network. All of those things matter to the technical outcome or the consequence of any of these decisions and the effectiveness of any one solution. So I just really like this quote, so I'll hit it one more time.
[00:33:37] As you can see, developers don't think mempool policy is useless or ineffective. In fact, it's an important tool in their belt on which they rely a lot. But if pool operators don't respect a certain policy, or developers expect they won't respect it in the future, what they call incentive incompatible policies, they'd rather remove it from Core than sacrifice mempool consistency.
[00:34:06] At this point, I hope I've made the connection apparent between pool operator centralization and developers optimization for mempool consistency.
[00:34:16] Now it's time to explore the point of view of the filter boys, which is based on reverting the mining centralization we lost almost since the start of Bitcoin. Instead of optimizing for mempool consistency, I think that is a fair way to frame it. I do not think that is unreasonable. And it seems that all of the arguments from the remove limits discussion are about mempool consistency are about your fees aren't going to work. Even though fee predictors just are never going to be relied upon. They're never going to be so reliable that you can just set a fee based on a fee predictor and then just walk away from it. You always have to watch the network and what the blocks are doing and how much how many, how much volume of transactions are coming in and how long blocks take to actually come in or be found. This is exactly why we have full mpul, rb, full rb, mempool, rbf, whatever the it's why we have RBF and why you can bump the fee in order to get into the next block. If you end up having miscalculated the fee prediction and you're never going to know how many minutes the next block is going to be. We it's probably going to be 10, but it might be one, it might be 80. Whether or not you have every single transaction in the mempool is not going to be the biggest factor that determines whether or not your fee prediction works. It's going to be the weather on the blockchain, which is how many people are publishing right now and how many people have published since you have published your transaction and how many blocks have come in. So since you've published your transaction and are they coming in fast or are they coming in slow? And then the other is again about the compact block relay issue. It's how fast does this data propagate through the network? So that seems fair to me to say that Their priority and all of their arguments are centered around getting mempool consistency, which is a problem because of mining pool centralization. Whereas the clear actual solution, actually fixing the big problem here is to fix mining pool centralization and put all of our time and effort into doing exactly that.
[00:36:30] If you care about the more important problem here, then run a node, use datum and mine on Ocean.
[00:36:38] This problem has been a problem since I got into Bitcoin. I got in a long time ago.
[00:36:46] I want to see this fixed. And I certainly have not reserved myself to the idea that it can't be fixed or that it's a waste of time or that just because everybody, the big pool operators don't want to do it, that I don't care who wants to do it, we are going to fix that. We have to fix that. We don't have an option. We either fix it or we're going to pay for it very dearly on a long enough time frame. All of our centralization problems and lack of resiliency and robustness will come back and bite us in the ass. It just will.
[00:37:20] So I'm going to include a link to Ocean and details on how to implement datum on your start nine or whatever it is you're using.
[00:37:30] And it isn't that hard. It's if you're, you know, not familiar with the command line, it might seem unfamiliar, but I encourage you to just try and just use the default settings. You don't have to filter anything. You don't have to think about that. Just use your own node because that alone just means that the pool operator can't screw. You can't screw the network by making you hash for something that you don't agree with. Even if you have nothing, understand Ocean can't force you to filter. And I would love to see ocean become 10%, 20% of the of the hash on the network. I would love to see new block templates coming in.
[00:38:08] Ocean has already done more in the last year, which you can just see on chain. There is no this is undeniable that there have been more payouts to actual addresses with with actual like the node ran the block template than any than the entirety of the rest of the network. All of the block templates and payout addresses have been. I can't even remember what it is, but it's something like 70 or something. There's like a tiny, tiny, tiny amount of actual variation in the mining ecosystem. And where those bitcoin go an Ocean, the Ocean pool is already the most significant is Far and away the majority of the various template and payouts literally by not. I don't even think they're. They're like 1% of the network or even less. And they're already a majority. They are more. They're providing more genuine decentralization to the mining ecosystem than the entirety of the rest of the ecosystem. That is how important this issue is and that is how important the tools that they have built are. And I don't care what you think about the spam or the JPEG problem. You should care more about the decentralization of the network and the mining centralization problem than you do about whether or not somebody is deciding to broadcast JPEGs around using their node. That's what I think about it. I thought this was a really great article. I really appreciate the ability to break this down. And also I also think this was very fair to the core position. I think this represented it honestly, as opposed to, you know, just calling them shitcoiners or whatever. And that matters because you're not going to convince anybody by doing that. And we do need to convince. There's plenty of people that need to need to get a proper framing of the problem, in my opinion. So hopefully I'm contributing to that. Don't forget to check out the Human Rights foundation and their amazing work and thank them for supporting Bitcoin Audible and also the BitKit wallet. I've actually got something coming very soon that's going to be really cool about Pub Key. So stay tuned. Don't forget to subscribe and share this out. And until next time, everybody. That's my two sats.
[00:40:34] The difference between stupid and intelligent people, and this is true, whether or not they are well educated, is that intelligent people can handle subtlety.
[00:40:44] Neal Stephenson, the Diamond Age.
