In this episode, we sit down with Agent P to unpack his open-source project GridPool, a radically simple approach to decentralizing Bitcoin mining payouts. We trace his journey from early concerns about mining centralization during the China ban to reverse‑engineering Ocean’s Datum client to build a compatible, open server—enabling client-side block template construction without relying on a centralized payout custodian. Agent P walks us through GridPool’s on-deck and winners lists, how difficulty-ordered but evenly split payout slots remove the need for a latency-prone share chain, and why this design can serve both medium-size miners seeking lower variance and small “lottery” miners. We also discuss compatibility with Hydrapool, potential Stratum V2 and CKPool integrations, bootstrapping a decentralized node network, and how GridPool preserves censorship resistance by only sharing minimal data necessary for verification. We close with a fascinating detour into vibe coding: Agent P details using AI agents to port open-source firmware onto closed miners—compiling and live-loading Mujina onto an S19 XP via SSH with minimal manual intervention—illustrating how AI lowers the barrier for anyone to contribute to open-source mining tools. If you’re passionate about censorship resistance, decentralized pool payouts, and hands-on experimentation, this is a must-listen.
Resources: gridpool.net • Hydropool and P2Pool v2 repos (community forks) • February Forum thread on firmware tips for Antminers • Testnet4 participation for GridPool bootstrapping
[00:00:00] Unknown:
Welcome to pod two fifty six episode one sixteen. It's June 10. We've got a special guest in the studio with us today. Agent P, welcome to the show. Welcome. Thanks for having me, guys. Yeah. We're stoked to have you here. You've been a longtime listener, longtime supporter of the show. I know you've been pointing minors to donation pool for a while and interacting with the community on the telegram. And now we've got our new forum up. So thanks for being here. Thanks for being active in the community.
And you yourself have been taking some of these open source tools and tackling mining centralization in your own way. And we think you've come up well, we recognize that you've come up with some pretty clever solutions, and we wanna hear about it and showcase it on the show and introduce our listeners to GridPool and other exciting things that you're working on. Awesome. Thank you, guys. Yeah. First, I just wanna say I'm really excited to be on the show. This is super
[00:00:58] Unknown:
fun for me. I've been listening since episode one. I remember when the show came out at at the time. So I I got into Bitcoin 2021, but actually didn't didn't buy in right away because I was trying to study it and understand it. And the thing that held me off from jumping in during the COVID liquidity rush and stimulus checks and everything was was mining centralization. I I was trying to understand the system, and I looked and realized that 70% of the hash rate is physically located within People's Republic Of China. And that seemed like a security vulnerability to me that I was not okay with. So I actually did not jump in with both feet in terms of buying until after the China mining ban. Because that ban happened, all the miners, instead of getting confiscated and used against the network, were allowed to leave the country, which to me seems like one of the biggest geopolitical mistakes in history. But whatever. We'll see how this plays out. So mining centralization's kind of always been front and center for me in terms of how I understand the network and the the major challenges that I see facing it over the next decade plus. Obviously, the the mining ban happened. The miners distributed all over the world.
I saw that as positive and jumped in. But then as I started learning more about how mining actually functions, realized that pools were a thing. Pools were centralized. So it was somewhere in in, I think, 2023 when I was learning more about how mining actually functions and realizing how many problems were still out there and how close the whole ecosystem was that February pod February started. And I was like, oh, these are the guys talking about the exact problems that I am seeing. I hadn't seen anyone talking about solutions yet until this podcast showed up. So it really is exciting for me to be able to to be on here and just contribute in my own way, however I can. So with that framing, mining centralization, I started tinkering on a lot of different things, some hardware stuff, some solar stuff, direct DC. So you've seen that before. For work, I thought I was gonna not have access to a garage and a shop for a while starting in 2025.
And so I tried to shift my focus and find a software only project that I could tinker on. So that's what that's how this came about. I was, what what can I do in software to start tackling the the problem of mining centralization? You guys had, I believe you had already announced HydroPool or or maybe shortly after, you started looking at a few different decentralized pool efforts that were in the works. Ocean was starting up. I'm I'm a big Ocean fan. I like what they're doing. I think it it solves some of the problems, but not all. And just being a, I guess, a paranoid cypherpunk and fairly my my day job is is in the security world, I guess, broadly speaking. So I think a lot about adversarial thinking and and that kind of stuff. And so I like that Ocean decentralized the template for block template creation aspect of it. But because they're still managing the payouts from a centralized company, centralized server, that still presents a weak point. And I was trying to figure out how if there's a way to actually decentralize the the the payout split, the reward split. P two pool version one attempted this a long time ago. So this is an old problem in Bitcoin, and it got partially solved with p two p a p two pool v one, but not completely in that protocol had some flaws, which ended up causing further centralization pressure, basically related to their fast block times because they're running a, essentially, a side chain with faster block times, the share chain. Because it kind of is modeled after Bitcoin, it's a winner take all scenario, That means that latency becomes pretty big factor when you're determining who wins that share, who gets to add the next block to the share chain.
It's just like Bitcoin. Latency is a factor. At ten minutes for the for the Bitcoin chain, latency is a thing, but it's not. It hasn't caused extreme centralization. You see some of it if if you're a big mining pool, big miner, and you need to eke out every last fraction of a percent of profitability, then then network latency can be a thing. But for everyone else, it's not not a big deal. When you shorten block times to as fast as p two pool v one was having to do, latency becomes a really big factor. And that means if you can get latency down, you can artificially increase your your hash rate and your control of of that share chain. And so miners that were able to centralize hash rate on p two pool v one were making a lot more than the miners that were decentralized.
That's a problem. So I'm I'm trying to say very carefully p two pool v one to differentiate it from p two pool v two, which is an ongoing effort, a re a a total rethinking of that pool structure. And they have come up with some technical solutions using UNCLE's UNCLE blocks, I believe, from elsewhere in the crypto world, but pulling those ideas back into Bitcoin, which should should solve the latency centralization latency driven centralization pressure. So a lot a lot of things I wanna differentiate, like, p two pool v one had problems. V two, they're working on fixing those problems. And I think it's awesome. I think they're doing great work, and I I want to, like I don't wanna throw shade anywhere. I think they're doing great work. I like it for new problems. I like trying many different solutions. So so I am essentially attacking the exact same problem that p two pool v two is attacking. I don't think that's a bad thing. I think I think we should try a lot of different solutions.
Each one is gonna have different engineering trade offs. And then we'll see in the end which one turns out to be more useful. Maybe both stick around and have their, you know, their their different advantages and disadvantages. Yeah. I think you've got a great point in that there's
[00:06:37] Unknown:
no silver bullet to solving these problems and that they all have trade offs. Just to kind of recap here, so you recognized issues around mining centralization from the get go. And then that was at a very interesting time, like right before the big Chinese mining ban in the summer of twenty twenty one, when majority of the hash rate went offline as it was relocating itself globally. And then you're kind of able to start peeling back the layers as you start learning more about this. It becomes, you realize that mining centralization doesn't just mean geographically centralized, but it also means that the mining pools are a centralizing force. And then, you know, we start understanding that the, you know, manufacturers building the hardware are centralized forces and that they have control over the firmware.
And even the mining rewards going to just a handful of custodians is another centralizing force. So there's all these different layers to centralization. And then you kind of look around at the landscape and you see oceans working on it in their own way. And it's great that they've taken a step forward toward decentralization in that the miners get to contribute to the template that they're mining on, but there's still that centralized point in there where the mining pool operator controls the coin base payout.
So like it's a silver bullet solution. You look at other solutions that are out there like P2Pool V1, but like you mentioned, there's issues with that, the speed of the blocks on the side chain that they're mining on. And then we've got Jungly, who's a February Foundation developer who built HydraPool, working in tandem on P2Pool V2, which incorporated the uncle blocks. I believe that idea came from the Monero community and incorporating that into the side chain to help with that centralizing force. And then now we land at grid pool that you're working on. And so you've kind of taken a lot of the perspective that you've built over the last few years, and you've come up with a pretty clever solution to take a stab at some of these centralized issues. So should we get into to some of the technical details on how on how GridPool sorry. I'm I muted my mic. On how GridPool approaches this? Yeah. And how it's different from p to p. Yes.
[00:09:09] Unknown:
Yeah. Let's do that. We're before we jump to technical stuff, I wanna frame I wanna frame it with a hypothetical scenario. End of the world, the government decides it's time to clamp down on mining. They roll into ocean. So totally hypothetical. They roll into Ocean and they say, your decentralized block templates are great, but you're only allowed to pay and credit miners with shares if they comply with with our transaction set. Let's say. So if a miner sends you a share that includes one of these censored transactions, you're not allowed to pay them. Right? That's that's really the the critical choke point. What do those miners do if they still need to be able to mine Bitcoin, get payouts, but they don't wanna do they don't wanna comply with the censorship. That's really what it's what it comes down to. So this is related the reason I mentioned this is this is related to your vision for this the a similar scenario for why you built HydroPool.
In a similar fashion, I've I've heard I think I've heard you say something like this before that, you know, in a in a end of the world and hypothetical scenario and all the pools get shut down or centralized or or the the controllers come in, we want anybody to be able to quickly and easily spin up their own pool instance to be able to keep building blocks and keep mining Bitcoin without having to comply. This is what keeps keeps Bitcoin free and keeps its censorship resistant, which I think is an awesome vision and HydroPool absolutely needed to exist. So here's where here's where GridPool comes in. Let's say the miners that leave Ocean and the miners that spin up their own HydroPool instances don't have enough hash rate to guarantee that they'll be able to get a block, a payout of some kind before their power bills do. Right? If they're a huge miner and they can get a block a month, they're probably gonna be fine. If it's a small shop, if it's a couple of p to hash, they could go years plus without getting a payout. So then We had a 2.5
[00:11:03] Unknown:
x a hash at the last telehash and still didn't hit a block. Yeah. I I I know the the time was very short in duration, but I just, I think you're approaching this with a very realistic and practical mindset for what an adversarial environment looks like. And to your credit, I don't think it's all that hypothetical based on the trajectory that we've seen things developing over the last few years. Yeah, keep going. I love it. Exactly.
[00:11:32] Unknown:
And, okay, quick sidebar. I'm for my day job, I used to do a lot with deterrence theory. So I would love to build the technical solutions that exist that make it so that such an attack is obviously impossible and futile. And that would guarantee that it never actually happens. That's deterrence theory. So if we build these now and get it in place and make it work really, really well, then it's a given that this would be the obvious fallback option. So using this hypothetical scenario, how do these smallish miners pay their power bills? So, not everyone is going to be able to go full off grid and go without a payout for years.
That's just reality is they're gonna be forced to choose between do I scale down and just run a bid axe on my desk because that's what I can afford, or do I do I comply? Or is there a way that we can get a decentralized payout structure going? So GridPool is built. This is why I spent it took me a year reverse engineering Datum Prime. So let's talk about Ocean. Their built their effort to decentralize template construction uses Datum, and what they open sourced was the Datum client software. So that's what individual miners use to build their templates and then submit shares. So Grid, I in order to make this compatible with Ocean Miners, I spent a while basically reverse engineering the Datum protocol from their open source client so that GridPool nodes can act as Datum servers, Datum prime servers, in the same way that Ocean servers do. So GridPool right now is fully compatible with every miner on OceanPool.
All they do is go into their config settings for Datum and point it to a different server address, put in a different public key.
[00:13:21] Unknown:
So wait, let me just like rephrase, run this back to you in my own words, because I think you I think what you've accomplished there is actually pretty monumental, but you just kinda like glazed over it like it was no big deal. So just to be clear, the ocean server is closed source. They haven't open sourced the pool server that they operate. But they did open source the Datum client that they built. And so essentially what you've done, if if I can just recap in my own words, is you've taken that client, reverse engineered it, and understood what how to construct a server for that client just based on the client alone without any insight into how the Ocean server actually
[00:14:05] Unknown:
is constructed. Exactly. It's amazing. Thank you. I guess I haven't thought I haven't thought about that in a while. I did that reverse engineering work a year ago, and I hadn't thought about that step of the process of the project. But the reason I did that is because the vast majority of miners who are currently building their own templates, right, sovereign minded miners are on Ocean Pool. Like, 99% of the hash rate of people building their own templates are doing it on Ocean and submitting their shares to Ocean. And so I wanted Grid Cool Pool to be instantly compatible with that 99% of miners that are already doing their own template construction. I'm making up the 99% number, but it's it's a lot. Right? Ocean has a lot of hash rate. They get blocks every day. And, you know, so I mean, just for any listeners that aren't clear and, you know, in my own words, it's like Datum is essentially
[00:14:57] Unknown:
Ocean's stab at Stratum V2. And it incorporates a lot of the same upgrades that Stratum V2 promised. The issue is availability of Stratum V2 compatible pools, right? So there's like demand, but if I think you have to like sign up and request access to mine to demand right now, or they may have opened it to the public, I don't know. Last time I checked, which was not that long ago, you had to like go through a sign up process. And then I think Brains has some sort of Stratum V2 server that miners can mine to, if I understand correctly. But all that is to say is that the choices are pretty limited. And what Ocean did was they looked at Stratum V2, decided there were some things about it they didn't really like, and then they came out with Datum. And so, yeah, I think you're spot on. I think the vast majority, maybe not 99% exactly, but the vast majority, I think it's safe to say, of miners who are building their own templates are doing so via ocean because it's kind of this trade off where you're not solo mining, so you're not gonna get like the full block reward. We can save the debate on the definition of solo mining. But what I mean here is that it's not like you're building your own template and then keeping a 100% of the block reward for yourself. Their trade off was that you could still earn small amounts of Bitcoin proportional to your hash rate contribution, and you were selecting which transactions went into the template. Yeah.
[00:16:32] Unknown:
Well said. Stratum V2, the protocol is open source. My understanding is that it's just complex, so adoption has not been very fruitful from these other pools or running the client on your end. Then on the other side of the aisle, the Datum attempt to solve this problem, the server's not open source, they're saying if you want to use it, you have to use it with Ocean Pool. That's what you have reverse engineered. So effectively, Datum becomes on a level playing field with Stratum V2 right now, where it could be a simpler implementation and you could implement it to other pools. And then you've got grid pool to solve the actual payout centralization structure itself, I think, and I want to hear about that. But I just want to frame it that this reverse engineering of the Datum server from the client is effectively bringing a competitor to Stratum V2 to other pools. Is that correct? Yeah, I think you framed that well.
[00:17:28] Unknown:
GridPool is totally open source. So if someone wants to see how to make a Datum compatible server, they can start with my code and then do whatever they want with it from there. You know, if if they don't wanna do the decentralized reward sharing aspect of it. What I'm not doing in grid pool is is tides the share accounting system associated with with Ocean. I'm not doing any share accounting. We'll get to that in a minute. So if someone wanted to make their own Datum compatible pool, they'll have to do that part on their own. But the actual communications structure, they can look at mine and just go from there, fork and do whatever they want. Okay. So I think we I think we set up the problem. Let's go into how GridPool works, and hopefully that it will start to come together.
[00:18:10] Unknown:
Just to quickly frame it quick. So I do want to get into the technicals, the block template construction has been the big talk of town. Everyone seems to know about this. That's like you said, all these cypherpunk minded miners. That's why a vast majority of them are on ocean. Not a lot of people understand the problem of just having a central authority that issues the payout from the Coinbase altogether. And that's what we're teeing up here, right? That's what P2Pool V1 and V2 and GridPool aim to discuss, which is or to overcome, which is why have any central authority issuing the payouts? Can we make this itself a protocol? Is that correct? And then you want to dive into it. Exactly.
[00:18:47] Unknown:
Yep. Yep. The other attempts at this have been pretty complex. They've been good attempts. They had technical issues. So as the as as we talked about before, GridPool's approach is actually, like, really, really simple compared to all the other ones. We make some engineering trade offs that allow us to get that hypersimplicity, and I think it it it allows us to navigate sort of a different solution space in this. But it it really is a simple concept. I'm not like a brilliant developer. I write code on on the side. I I do have a a computer engineering degree that I got a decade and a half ago, and I haven't used it since, except in my hobbies.
So I'm I'm not a professional. Let's go go through how this works with a a a toy example. This is gonna be the easiest way to dive into it, I think. Let's say you and all your friends have bid access, and instead of and you wanted to to make your own you wanted to share the reward amongst each other. You you and nine other friends. Right? So 10 people, you each have a one terahash bid access, and you and you'd rather 10 x your chance of getting something. And you know that everyone's putting in about the same work. You could just agree a verbal agreement to say, let's just split the reward 10 ways. So we'll all configure our block templates. We'll put in each other's nine other addresses, an even 10 way split. And then whenever any of us gets a block, then we all get something. Right? So everyone has now increased their chances of getting something, 10 x, in exchange for only taking 10% of the block reward and sharing the other 90% with everyone else. Right? But you get a 10 x improvement in your variance. That's kind of how you would just do just a verbal agreement. Now let's say you wanted to make sure that everyone else kept their bid access turned on. So you you arrange to have have your different template construction software. You know, one guy might be using HydroPool, another guy's using Datum in solo mode or something. Send each other shares of, hey. Here's the latest template and nonce that I found so that the other guys can see that you're still including all of their addresses in your Coinbase template.
Right? So every once in a while, you send them a share, say, yep, I'm still working on it. I haven't found one yet, but my difficulty is too low, but here's a 1,000,000, here's a one g diff share. It's got all 10 addresses in it. This is how you start to reduce the trust layer. Now it doesn't have to just be 10 friends. It can kind of start to get a lot less trusted if you're actually sharing evidence that you have been working on a template that shares those rewards properly. And that's kind of the consensus layer of GridPool. So GridPool pulls a lot of concepts in from p two pool and from Bitcoin itself. There is the concept of consensus in it. It's a winner take all approach based on difficulty, whatever difficulty the share reaches. We'll get into that in a minute. Unlike p two pool, we're not actually using a a side chain at all. Alright. So now we can go to maybe how how GridPool actually works. Everyone has can have their own node. The the website that you go to, if you see gridpool.net, is just my node. In order to bootstrap a network, just like Bitcoin, there's there's hard coded addresses. And so when this thing launches, we'll have to have a decent number of people that are willing to run stable nodes that are gonna be reachable to anyone new joining the network. That's how Bitcoin bootstraps itself as well when you turn on a new node. So when when you go to the website, that is that is my node, but anyone can run their own and should run their own. Each node is keeping a list. Okay, now we have to define a couple of things. In the code, I call them the winners list and the on deck list.
I'm not good at naming things. If someone has better names, I'm all ears. The winners list is that list of payouts. Whose addresses get added to the coin base for everyone who is wanting to participate in the pool. That's the winners list. The on deck list is a running tally of whose shares have achieved the highest difficulty. Who got closest to winning a real block with a share that included the correct set of payouts in the winners. It matches the winners list. Let me pause there and make sure that those concepts kind of make sense. Any questions? Yeah, I think I'm with you. So I'm looking at
[00:23:04] Unknown:
the grid pool website, which again is gridpool.net. And it's pulling this information in from your node that you're running. Anyone can run their own node. And essentially, you've got it split up into the
[00:23:18] Unknown:
on deck list and the winners list. Is that the same as the the next payout queue and the current paid team? Looking now to make sure I'm looking at the same thing. I just I wanna make sure I see the winners. Let's make sure we're on the same view. In the top section, there's a little box that says view. You can do lottery, business, or nerd mode. These are just different ways of of viewing the data, and they surface different attributes. It's a UI thing. It's working the same on the back end.
[00:23:45] Unknown:
Okay.
[00:23:46] Unknown:
So, yeah, when I click on Nerd, now I see the on deck list and the winners list. Yep. Yeah. So on Nerd, when you scroll all the way down to the bottom, there's a box, winner lists. It's defaults to collapse, but you can expand it and you'll see a whole list of 299 different slots, payout slots. So all these are even even payouts. And on the right hand the right hand column is the difficulty that that share achieved in order to win that slot on the list. Okay. So even if
[00:24:15] Unknown:
one of these participants on the winners list is has submitted a much greater difficulty than some of the other participants, their their reward split is still It's the same split. It's the same split across all the users.
[00:24:32] Unknown:
Yep. And this this is important mathematically. I don't know that I can explain all the math behind it. I did have a codex generate the math behind it into a nice little markdown paper that you can read, assuming that's correct. This is how we maintain fairness, payout fairness. So in a normal pool, they don't pay by the difficulty, they pay by the number of shares. And you commit to achieving a specific minimum difficulty, and then however many shares you can generate at that point, that's that's how they estimate your hash rate, how much power you're putting into the pool, and then they correlate the payout with that with some minor nuances depending on the pool and other stuff. If you were to do payouts based on difficulty, you introduce a whole bunch of statistical variants that you don't wanna you don't wanna do. Because someone they roll a lucky share, and they get paid out a huge amount. So by keeping the payout splits even and just sorting them by difficulty, we still get a mathematically fair breakdown according to how much hash rate you're putting in, but we don't have to track every single share with a lot of fine grained detail.
This is a core thing that differentiates grid pool from p two pool v two and v one, I guess. P two pool is still trying to estimate hash rate with a with a stream of shares, getting frequent shares, they're not looking at difficulty at all, except to make sure that the shares meet a minimum target threshold. We are looking at difficulty, but we don't correlate the payout amount with it. What this breaks down to though is that statistically, if you're putting in 50 percent of the team's, the pool's hash rate, statistically you're going to win 50% of the payout slots, which means you're gonna get 50% of the Coinbase reward. So it still breaks down to a fair distribution, but we arrive at it mathematically via a different route. There's probably a little bit more variance with this, because if you're putting in 50%, sometimes you may get a little more than 50% of the slots, you get a little less. In my tests, it's pretty close. It's not exact, but on average, it is 50. You know, long term averages, it's statistically fair. This is what allows different types of participants to use this protocol from a game theory perspective, and it still be useful. So a business can use this and expect that they're going to get rewarded what they they put in according to know, there there's not a lot of variance.
It's fairly predictable. It's not as predictable as a traditional pool. There's gonna be some more fluctuations, but it's better than pure solo. This also means that the lottery miners Sorry. Let me finish real quick. Okay. Go ahead. You know, guys running bid axes, when this thing gets going, if there's a decent amount of total hash rate, a bid access is gonna have a tiny tiny fraction of the total team's hash rate. They're rarely rarely gonna make it onto the list at all until they get lucky. And then they're gonna get lucky and get one spot on the list. Some people might like that because they're mining with a Bidaxe getting 300x better odds of a onethree hundredth payout of a Block reward. For some people that they might like playing that type of lottery versus going for a full block. It's it's totally up to them. But both both types can can use this, and that's why there are different UI views built in lottery mode, business mode. And then the nerd mode is where I dumped everything that I needed to track and debug and and make sure the system was working. Okay. Iko, you had a question. I cut you off. So how does Miner secure one of these slots? Is it like each client gets its own slot?
Because I'm I'm looking at it and I see, like, you know, there's multiple slots sharing the same address. So, like Yeah. Are those, like, three different clients that all have that address configured? Or Those are the same same client. So really good question. This is really important piece of it. How is in this totally trustless decentralized network, how do you trust? How do you how do you credit shares? How do you know which miner these shares actually belong to? The protocol is is a totally unencrypted HTTP JSON message.
Like, anyone could intercept that and mess with it and then resubmit it. So how do we how do we make sure that this is secure and that the right miners are getting credit for the the slots that they earn? Right? So when you the protocol this is consensus layer type of stuff, put your consensus hat on. Clients take the they get the current winners list. They say, okay. These are the these are the addresses I need to include in my template for this share to be considered valid by the rest of the network. And then they so they that's list is 299 slots long.
So if if it's 299 unique addresses, then then it'll be a list of 299 different slots. If a big miner is taking 50% of of the share, then each each each node can collapse that in order to not use up as much space in the block, the template that they're building. So they can just credit when they're building the actual template. They can total up the payout for that single address when they're constructing that Coinbase transaction. We can come back to that if you need to. That's kind of down in the weeds. So they take the list of two ninety nine potential payouts, they're like, I need to include these for my shares to be considered valid.
And then they insert in slot zero their own payout address for for one share. That's how we cryptographically ensure that that share gets credited to the correct miner. Because they take that template, construct the Merkle tree, calculate the Merkle root, and then start hashing on that until they get a knots that is high enough to submit to the rest of the pool. Once that happens, they wrap this up into an HTTP JSON message that we've designed. They share that with the rest of the network. When other nodes on the network receive that share, they check for basic rules of validity. They make sure it's it's a valid Bitcoin block. There's one exception I'll get to in minute that they don't check. They check that the 299 addresses that are included in that coin base are the correct ones, and they're being paid out correctly. And then they look at slot zero, and they look and see they read which address is in slot zero, and they credit that share to that address that is in slot zero. And so if that share achieved a high enough difficulty to make it up onto the on deck list, then they insert that new spot on the on deck list credited to that address in slot 0 with that single slot payout to it. This means that once you create a share, you've hashed it, you've put the work into it, and you share that with a trustless, unencrypted network, no one can mess with the share. Because if someone tries to change the coinbase on it, the nonce is invalid.
When other nodes check it, the difficulty will be super low. It won't be a high difficulty share and they'll throw it in the trash. So this is how nodes make sure that their shares are credited properly.
[00:31:26] Unknown:
Does that make sense? Yeah, I think I've got it. So there, you're still using that proof of work mechanism where they have to prove that they've done the work. And if they get a high enough proof that puts them on the on deck list. And then so just remind me real quick. What what's the difference between the on deck list and the the winners the winners list? Good. I
[00:31:48] Unknown:
called it winners because whenever someone on the team finds a real block, those are the people that get paid out. They're the winners. So Got it. Okay. Their their addresses have been locked into this this Coinbase template that everyone on the pool needs to use to be able to participate in the network. The on deck list is the people who are vying get their addresses added to the next winners list. So miners take the winners list, they make their templates, they work on them, they submit high difficulty shares to the rest of the network, trying to get their addresses added to the on deck list. Eventually, someone is going to get lucky enough that the share that they produce is actually a real Bitcoin block. It gets added to the chain. Because everyone's running their own node to be able to build their own templates, when they see a real Bitcoin block added to the chain tip that pays out the winners list, the round re resets. So when they see that, the their current view of the on deck list becomes the winners list. For the next round, the on deck list gets cleared, the round resets, and then everybody starts the competition again. And so that's how you're essentially decentralizing
[00:32:57] Unknown:
that Coinbase payout because that can come from any miner who's produced a template that's worked that that meets a good enough difficulty to be on the on deck list. And then that is is it the like the best share from the on deck list gets trying to put this into my I I I can almost like, if I squint my eyes, I can I can almost wrap this all up in my head, but I'm not as smart as you guys? So it's it's like you've got the the on deck list is the highest difficulty or, you know, that's been made so far. And if it reaches a sorry. So it's like the best difficulty from the on deck list gets used for the gets automatically moved up to the winners list. And then that's the template everybody uses to build on until they hit a difficulty high enough for a valid block. Is that right? So it's like you've got kind of like this, I don't know, in my own words, a staging area where everyone's submitting these, their best attempt. And it's it's not a difficulty high enough to hit a block, but it's it's good enough to go on the on deck list. It's everybody's best work that they've done so far. And then the best of those templates from the staging list get moved to the winners list. And each time like a new highest difficulty gets hit, that takes the spot of the winners list. And then they're using that template to construct their blocks in an attempt to hit the network difficulty.
[00:34:25] Unknown:
Is that where how am I doing? No, you're good. I think you're tracking. Feel free to ask any other questions you want if it would help clarify. Is this making sense to you, Tyler, as well? Yeah.
[00:34:36] Unknown:
Correct me if I'm wrong here. How I'm thinking about it is you have the staging area side. You are statistically filtering for how what proportion people should be paid out by how high their difficulty is, not by the number of shares. Correct. And that results in higher variance but also similar payouts proportionally,
[00:34:55] Unknown:
statistically. Statistically, correctly fair
[00:34:59] Unknown:
Correctly fair. Yeah. This is the massive simplification
[00:35:04] Unknown:
you alluded to that doesn't require the share chain. Exactly. It does not require a share chain. And so latency
[00:35:11] Unknown:
is much less of a problem in this. No bigger of a problem than in Bitcoin. Okay. I might have to see it drawn out for me just how the staging and the winners with some arrows and some boxes because I agree with I mean, I can't say it any better than Eco did, but I understand the general strategy of what you're trying to do. It makes sense to me, but please continue.
[00:35:33] Unknown:
That's okay. It's recursive. And so sometimes recursion can throw people for a loop and it takes a little bit to wrap your head around. It is simple. I think it's elegant, but it took me a couple years of working on this to figure out just thinking about it before I came up with something that I thought. Was actually gonna But simple, but still worked. Yeah, how did you have that eureka moment where you were like, Well, what if we just did it this way? I don't know if anyone can explain how eureka moments happen, but it was a year plus of thinking about the problem and then thinking about what if we try this, what if we try this. Okay. Realizing all that wouldn't work. I can't remember where I was, but I do remember the figuring out the slot zero aspect.
That was definitely a eureka moment for me realizing that, oh, I could I can cryptographically secure these shares to a specific miner by having them include their own address in the payout. And then I also, as a side benefit, get some resistance to block withholding attacks out of that, which we'll talk about a little later if there's time. How many addresses can be paid out from grid pool? Up to
[00:36:40] Unknown:
300 at a time. Two ninety nine and then the zero slot.
[00:36:43] Unknown:
Exactly. And yeah, so up to 300 total, but one of those always belongs to the block finder. Yeah, okay. This is very interesting. It's a weird concept. I think it works, but I'm one of the only people in the world that's been like thinking about how the system works for a long time. So so as I open it up and I it gets more eyes and more publicity. I'm a very adversarial thinker. I would love people to to tear the system apart and find the thing that I missed. Right? I would love no more than
[00:37:12] Unknown:
that. If someone was like, Hey, you didn't think about this, or I can break your system this way. I can cheat this way. That would be awesome. Please tell me. That was one thing I was going to ask, which is what would be Well, obviously that would be cool to get people way smarter than the three of us or that have different blind spots or identify different things than us to peek under the hood and take a look at it but also what would be helpful for your development? Is it more hash rate pointed? Is it running a grid node, right? A grid pool node? Do you want to speak a little bit to that? How people can actually start to not just poke around, but also try it out? Yeah. I would say very soon they can start running their own version. There's a there's a Docker Docker script created that that should make it easy to do as well. Point their datum node at it and and try it out. I had someone from
[00:38:00] Unknown:
open size Open Source Miners United Discord actually helped me out end of last year, pointed me a bit of hash rate and put in weird things that I didn't expect for his worker names and broke a whole bunch of stuff. And that was super helpful. Super helpful for me for working through a few bugs. Yeah. So it this thing is is a little bit hard to tell when it's done enough to launch. So, at this point, I think I'm probably pretty close, but I think I would like to do more testing on Testnet four. I had just, just in the last couple weeks, I started spinning up a few of those Testnet four nodes to be able to try to get some real blocks on there. Right now, I've been I've been cycling the rounds artificially because I don't have enough hash rate to get real blocks. And so but because the round cycling and all that math is an important part of the system and how it functions, I need to be able to see that working. I'm using just an artificial trigger to cycle new rounds on Mainnet.
But on Testnet, I'd like to use the real trigger on Testnet. So I think if people want to get involved, download the code, try running it, see see if if it's easy enough to to spin up your own version and get it connected. Tell me how it goes. Give me feedback. Listen to the podcast. Think about the system and how it functions and see if you can break it. That would be awesome. Yeah. I think I think some of those are the main ways. As we get closer to being ready ready to launch, it would be really, really helpful if we had a few people who were committed to, like, running stable, well connected nodes just to make sure that we can sort of get the network bootstrapped.
We have enough enough sort of stable seed nodes online that that we know that we can sort of get the thing launched and rolling. I have a couple questions.
[00:39:41] Unknown:
One, to solve the block template construction problem is in its current architecture is Datum the only method for doing that? Could Stratum V2 also be implemented where you could use either client side block template construction? Yeah, let's talk about client side. So Datum was the one I went for first
[00:40:02] Unknown:
Ocean has a lot of Datum hashrate. That's why. Second one I did was HydraPool. So I forked HydraPool. I had to fork P2Pool v2 as well in order to be able to do custom payout to be able to control the customized payout list. But on my forked version of HydroPool, HydroPool can submit its own shares to the GridPool network. So the ideal setup for that would be someone spins up a hydro pool node, they spin up their own grid pool node, their hydro pool node submits shares to their grid pool node, their grid pool node checks them and shares them with the rest of the network. And then their Gridpool node is also maintaining their own sovereign copies of the two lists that we talked about, and then feeding the Hydropool node that list data so that your Hydropool node knows how to construct a correct Coinbase payout. So this works in in my forked version of HydroPool.
I've been talking with Jungly. I put in a PR, and he's he's he's supportive of it. He wants to go a slightly different route just in the codebase in in terms of how he enables this going forward. So so the PR is is in, and he's working through that. But I I don't wanna step in his chili too much over sidetrack his other efforts and stuff. But hydro pool is is pretty trivial to make work. Because this protocol is so simple, like, it's just a couple of HTTP JSON messages, it's we could almost vibe code compatibility to any other pool implementation.
I could see so on my list would be c c k pool, public pool, stratum v two would be those would be towards the top of my list. Atlas Pool is another forked version of CKPool. I even used a Bidaxe directly. So this is an interesting side project. Again, VibeCoded in, I think, one shot. Codex made it so that my Bidax uses RPC commands to my Bitcoin node to construct a block template. It also used the HTTP JSON protocol to talk to my grid pool node to get the current payout list. It constructed its own share, worked on it. Once it found the work, submitted that work back to my Gridpool node, a 100% running on the BITX. So that was with no other stratum layer involved at all. Because the protocol is so simple, you really could you could do anything with it.
It it'd be it's trivial to plug anything into the network. My next test was gonna be doing this with Magena, which I would expect should be similarly trivial. Probably easier than the BidX. But if sorry. You Go ahead, Iko. If I understand, you had your Bidax acting as the grid pool client? So the Bidax was doing was doing was acting as a datum client. Let me simplify it like that. Okay. So so it was talking to the Bitcoin node. It was constructing the template with all the correct Coinbase payout splits, and then when it got a good share, it was submitting that to my GridPool node. It was not acting as a complete GridPool node itself, so for that it would have to also be connecting to a lot of other GridPool nodes, so it's got a well connected view into the network, receiving shares that other nodes are sharing around the network. When someone says, hey, I got a new thing to add to the list. Each share has to be checked for for the validity rules and stuff. So the BidX is not doing that part of it. It but it was it was getting the Coinbase Coinbase split from my grid pool node, building its own work, and then submitting shares back without a stratum layer involved at all. That's pretty good for a ESP
[00:43:31] Unknown:
32.
[00:43:32] Unknown:
Yeah. Right? Which means literally anything can use this this pool. Yeah. Like, you've got the the
[00:43:39] Unknown:
Datum client code simplified enough there that
[00:43:43] Unknown:
that anything can run it. Yeah. I mean I mean, to to clarify, that's not using any Datum code at all. That was that's using the ESP minor code base. And then I just told Codex, hey, I want this thing to reach out with RPC commands and then build its Okay. Build build its own templates. So there's no stratum layer involved at all. It's going straight to the Bitcoin node and and then straight to the grid pool node for the for the pool split. Gotcha. Okay. Is the fair payouts with higher variance enough to convince larger miners to use this? Good question. Because everyone's got Fiat brain rot. So Yeah.
So my hope is there's no fees on this. 0% fees and you get lower variance for free. So game theory would say that it's in everyone's best interest to use this. That includes not just small miners, that includes Mara, that includes Ant Pool, that includes F2 Pool. It's in their best interest to participate in this coin based split. Now the real big pools are probably not gonna bother because they're big enough that variance is not an issue for them. I think for for your middle tier pools, I think this could be huge because now they can they can get over that hump of, like, the danger zone when pools die, you know, when you're not getting a block more than every week or so. Mhmm.
[00:45:01] Unknown:
And it's just at that point, the pool can't survive. But if they use this, they get a payout. Yeah. So good for the medium sized guys. I mean, what we've learned with the large mega miners, you mentioned some of the big guys that are using Foundry or whatever, it doesn't even matter what it costs. It's about compliance and SOC two and all this legal BS. Like that's the reason they pay to have the pool managed for them. Maybe there's no convincing to be done there. What about the smaller guys though?
If I am understanding this correctly, if the grid is sufficiently large with enough participants and only 300 slots in the payout, the small guys might still be SOL.
[00:45:40] Unknown:
Is that true? Not SOL. It's still better for the small guys
[00:45:45] Unknown:
Versus going a 100% solo. And is that because it's based on them getting a good difficulty, not necessarily
[00:45:53] Unknown:
how much hash rate they've got? They just need to get enough to get one share onto that payout list. And statistically, if they have one three hundredth of the pool's hash rate, on average, they're gonna get one payout slot per round rotation. So if if the the total pool is small it's getting one Let's say the total pool size is 300 P2H. So, a one P2H miner on average is gonna get one slot on that list every month. And on average, that team is gonna get one block a month. So, there's their they're gonna get one slot payout a month on average. Let's say the pool doubles in size. So now it's a 600 P2H pool, and they're getting a block every two weeks. But now it's twice as hard for that P2H miner to make it onto the list. He's still getting on average one payout slot every month. So once you get up above a certain threshold, it's actually no it your payouts start to even out and you're still going to be getting on average paid the same. Does that help explain it? Yes, but if you're a small small miner say with 10 terahash,
[00:47:03] Unknown:
that's when you're still waiting quite a while. Yes. You're still waiting quite a while.
[00:47:07] Unknown:
You're waiting mathematically 300 times shorter than if you were pure solo. Gotcha. So, that's, you know, at a 10 terahash level, that's a 100% a personal choice. Do I want the jackpot?
[00:47:21] Unknown:
Right. Do I want a low chance of getting a jackpot or do I want a slightly larger but still low chance of getting a small payout? So there's a sweet spot. I mean, it's not enforced, but there is kind of like a sweet spot for depending on how large the pool is, how big your share should be to get your desired
[00:47:39] Unknown:
cadence of payouts, you know? Yeah. In the business view on the pool page, I tried to produce some of these metrics so that if someone was wanting to predict what their payout cadence would be Mhmm. Mathematically, they could they could see this. And this is based on the the hash rate of the total pool versus their own hash rate versus the network hash rate, network difficulty.
[00:48:04] Unknown:
And using that and some math we can predict what someone's payout cadence is going to be. From your development of this project, do you think that if you have the 10 terahash space heater or whatever and you want your 500 stats per day, and you also want pool payouts to be a protocol, not a centralized entity. Is that where the share accounting and share chain has to exist? I'm just curious your commentary on that to solve that problem. That's a good question. So if so if you if you want 500
[00:48:36] Unknown:
a day, you can't you can't do payouts direct from the Coinbase at all. Yeah. You just can't. You and which means you have to do a solution that involves lightning and I don't want to say a custodian because I think there's clever technical solutions. I know there's people working on this problem. Yeah. I'm not smart enough to understand them. So if someone can figure that out, that's awesome. And I hope that that option exists for miners that would like that to exist.
[00:49:05] Unknown:
Yeah. Mean, that's my vision and dream is regardless of size of your mine or system, you plug it in and the network's a protocol, the nodes a protocol, and the mining and the payouts are also a protocol. There should be no centralized risk. Yeah. We we figured out a way to plug computers in, connect them, they talk to each other, and they value each other's efforts, and they pay each other. Like, done. Right. Right. Yeah. Yeah. Now the 300 payout slots is that was a that was a design choice. I kinda guessed if if we include a lot more payout slots, then we could get finer grained payouts.
[00:49:40] Unknown:
You're not gonna get down to 500 stats. No, of course not. But you could get a more fine grained split. What it ends up doing is you might fill up the entire block with Coinbase payouts and not include very many transactions. Right? We're limited on block space. And if you go less than 300, we could have done a 150. Now you're getting more into lottery range. It's it's harder to get one of those slots. The payout is bigger, but the variance increases. 300 seems like felt like a rough kind of middle ground. The other piece that played into it is that a lot of minor firmware is broken and cannot handle Coinbase transactions that are too large.
The the datum guys dealt with this a lot and if you dig into their code, they have some very complex code to figure out how to like fingerprint each miner and then give it the right block size. What that means is that certain mining machines will not be able to contribute or participate in grid pool. And that might be an open problem that might be bigger than I realize, depending on how much the network hash rate is able to handle a 300 slot Coinbase transaction.
[00:50:50] Unknown:
I don't know. I I say it's more incentive to get different kinds of firmware running on Antminers. Mean, let's just reveal the elephant in the room. It's Antminers that can't handle these large coin base. Exactly.
[00:51:05] Unknown:
Well, you actually have some experience with that. Agent P, why don't you I saw a cool forum topic from you on the February forum answering my question, which is, Hey, hey, Neanderthal here. How do I start hacking away to try and get Mugena open source firmware onto an Antminer? And you posted some awesome tips. And before the call, before we started the pod, you said, you know, you learned a lot during that experience. So why don't you talk on that? Yeah.
[00:51:32] Unknown:
Let's say so let me first say all of my hacking, tinkering, coding is, like, in my spare time. I've got a lot of small kids and I don't have a lot of spare time. So the the time that I have to be able to the times I get to sit down at a computer and write code for two to three unbroken hours, like, I get maybe a handful of those a year. It's not much. So so vibe coding has changed my life because I can sit down at a Codex terminal and bang out a quick prompt for five minutes. And then I go and, you know, I change a diaper. I get dinner on the table. I'm tucking kids in bed. I'm like, you know, just doing family life or whatever. And then I come back and check on it. And half the time the thing is done, it's come up with a better solution that could have figured out on my own or I steer it differently or whatever. But it really has allowed me to to start contributing and producing things that I would never have had time to to do before. So I'm super bullish on open source for that reason. Like, the barrier to be able to contribute has now been lowered all the way down to the floor. Like, it cannot be any easier to start producing open source code. It truly is amazing. So as I was building GridPool, I I was starting to expand my testing, and I realized I needed three to four different nodes all set up and talking to each other and running the code so that I could start testing the actual network protocol. And it was getting a little bit much to manage, and I was using the AI agents a little bit for for some of the coding stuff, and I just wasn't able to get all these things talking to each other. And I just asked Codex at one point, can you just SSH into my laptop and fix this for me? Here's the IP address. And it was like, yeah, sure. Here's the key. Can you paste this into the config? Alright. So it helped me set up the SSH key. And now Codex SSHs into all of my nodes. When I need to change something, it handles all of the network configurations.
Before this, I wanted to swap a bunch of the nodes back over to main net just so I could kinda demo and get more of the hash rate back into main net. That was one prompt. I said, hey. Can you switch over the everything back over to net for me? Sure. I walked away. It was done when I came back. So the power of these things is is incredible. That's basically how I approach the s 19 XP thing. I have some XPs laying around, and I saw Scott's post about hacking on the J Pro and all the stuff he was doing with that, and he was doing it most of it through vibe coding. I was like, well, let me me give it a shot. I've been wanting to try Mugena on the XP.
And rather than waiting for someone else to build it, I was like, maybe see if Codex can do So so it was one prompt. For first, I downloaded the code base, you know, cloned the the repos on GitHub. I cloned the ESP minor repo and the Magena repo. I wish I'd also cloned Scott's branch. I didn't realize he had a separate actual separate branch. But so that those were available locally that the AI seem to do better if the code is just right there on the file system that it can read. And then in one prompt, I said, hey. Here's the ESP Miner code base, which does work on s 19 XP chips. So here's how to talk to the chips. Here's Mugena. Can you make Mugena talk to my s 19 XP?
And then here's a loader. Here's a Mugena loader that someone else used to to get it onto that onto that board. So in one prompt, I had it build the the code base for Mogina. And then once it was ready and I was sitting there monitoring the machine physically, I had a power meter on it just for safety. I didn't I didn't want it doing anything automatic on the on a running miner without me around. Then I told it to go. I said, okay. I'm watching. Go ahead and remote into the machine. Here's the IP address. It should be default username, password. See if can get Magena running. And so it came up with its own testing plan.
First, it remoted in and just verified that it could get UART connectivity and just did a scan of the chains and made sure it can it can read from all the chips. Once it was happy with that, then it it loaded Magena as well. This control board had LuxOS already running on it, that handled the secure boot piece. I think that's a more difficult challenge that I haven't looked into yet. So it shut down the LuxOS program that was running. And this is not SD cards swapping images. It just hijacked it while it was running. Purely through the LAN. It SSH ed into the miner, shut down the LuxOS program, booted up the Mugena program after it copied the It compiled Mugena for that control board, copied it onto the control board, started it up, sniffed all the traffic on the UART, watched the debug logs as it was running to make sure that it was doing what was expected. Yeah.
In the first test, it realized that it was running, the chips were hashing, and returning super low difficulty shares. All the shares were like zero or one difficulty. Nothing. So then it on its own realized that on the S19XP chips, the byte order of the nonce is reversed when it's communicating it back. So it just flipped that byte order around in Mugena, recompiled it, and reran it, and then that solved that issue. I didn't have to ask it to solve that issue. Like, did it. It figured that out on its own and then just recompiled this Magena, reloaded it, fired it back up again. After that, it was working. There was some weirdness with the PSU. It wasn't properly
[00:56:39] Unknown:
spinning up the PSU, so I did have to interact with it a little bit there to tell it what was going on when the hash board wouldn't turn on at first and it just forgot to signal to the PSU to turn on. But other than that, was it was working. It was like seventeen minutes to get Oh it my gosh. Running. So like This is amazing. Yeah. We gotta I I I wanna figure out how to do this if you don't have Secure Boot cracked already because that's kind of where we're at with all the What's Minor machines. Really? Just because there's not a lot of aftermarket firmware support for them. People haven't spent the time to crack Secure Boot. But Yeah. For all the machines that do have aftermarket firmwares, brains or luxOS, it sounds like this strategy is quick
[00:57:18] Unknown:
and completely unlocks the machine. It's unreal, isn't it, Iko? It's amazing hearing this. It's like life comes at you really fast because it just, it wasn't that long ago where your firmware options for a miner were very limited. And it's just the threshold to be able to do what you want with your own hardware that you own. That threshold is continually getting pushed lower and lower. And it's, I love to see it. It's just, it's amazing. It's, I'm a very big proponent for it's your hardware, it should be your rules, not the manufacturer's rules and breaking that hardware free and using these AI tools to do it in like very short durations of time. It's just it's mind blowing and
[00:58:03] Unknown:
I think it's great. So excellent work. Yeah. I'm super bullish on open source for this reason. Like anyone can contribute now. If you can write a prompt, you can contribute. And that means, like, there is no moat in software anymore or really firmware. Right? Like, there it's just gone. Once once a thing is open sourced, it's this is gonna get ported to every machine instantly.
[00:58:27] Unknown:
Like, anyone that wants this to run on their bespoke machine, it's it's one prompt and, like, twenty minutes of watching the thing work, and then it's running. And even if you try to keep your special sauce via closed source software, reverse engineering these AI tools are getting so good at it. I saw this week that someone reverse engineered the Google Fitbit software so you don't need your subscription and your data is not going to Google and so now your little health wearable just reports your data locally, builds a dashboard on your laptop. Same goes for firmware on machines, on miners. It does seem like a silly hill to die on, right?
Build your moat around whatever quality hardware or good customer support and services. Exactly. Not code.
[00:59:11] Unknown:
I do think it's gonna be a really interesting challenge going forward for maintainers of open source projects because because the barrier is so low. Now, literally anyone can submit a PR for something they want. Know Ryan's That may or may not be a good idea. It's Yeah. Ryan's had some really good ideas on this front and I'm excited to see how those work. He's willing to try stuff as well. Well, highlights the importance
[00:59:36] Unknown:
of a maintainer as well. Because if everyone can vibe code whatever hack job solution to their unique specific problem, that doesn't necessarily mean it was architected properly into the original code base for a merge so that they can be distributed to everyone else. So, I do agree. Like, the maintainers of open source projects have a lot of lift in front of them. Yeah. He's had some good ideas too with using
[01:00:01] Unknown:
agents. Md files in the repo in order to if someone downloads the repo and starts hacking on it, the the context is there to guide those agents into producing better architectures that fit with the rest the goals of the rest of the project. Yeah. And I think you'll get much better contributions that way. So I'm excited to see where that goes too. Incredible. Well, anything else you wanted to hit on here? It's awesome to see the Vibe Coding open source firmware onto closed source miners. I encourage all of our listeners to go try that. I still need to try it myself. So thanks for replying some tips and tricks that are on the forum, as I said. And gridpool.net,
[01:00:38] Unknown:
amazing to see. Hopefully, can get some folks to spin up some gridpool nodes and contribute feedback to the code base and point some hash rate too to start testing this out. Yeah. Thank you. Thank you guys for your time and for
[01:00:50] Unknown:
bringing me down. I'll keep you guys updated with where it goes and what we need next. I think that covered pretty much everything. Anything else for you, Ico? Well, just to bring it full circle, I think the more
[01:01:03] Unknown:
eyes and participants we have, the resources we have, these open source resources and trying different things and making new attempts, applying new ideas with the end goal in mind of helping decentralized Bitcoin mining. That's the ultimate goal and it is going to take a lot of different people trying a lot of different things, different payout methods, different accounting methods. And I think what you've done here is amazing. I love that you're keeping it in the open source ethos and I just encourage anyone who's curious to just get started. It's never been easier to get started with this stuff.
The open source resources we have today are just, we've come light years in a very short duration of time as in regards to Bitcoin mining firmware and pool software and what's capable. I mean, it wasn't that long ago that it was next to impossible for a person like me who doesn't have any coding experience to mine to my own node, Like in 2021, 2022, like that was next to impossible for a non developer to be able to do. Fast forward, here we are four, three years later. I mean, just look at what we're talking about. Like you have an AI agent in twenty minutes taking control of your miner and putting new firmware on it. And it's just, it's incredible. I mean, the innovation that's happened is
[01:02:31] Unknown:
happening at a very rapid pace. So, so hop on board and give it a shot. I mean, it's, it's never been easier. That was a beautiful way to wrap up. And I thought of one last critical piece of grid pool that I wanted to say. I'm sorry. That was like, that was a really good way to wrap up. I should have just ended it. Okay. Censorship resistance. When grid pool nodes take these shares and they pass them around the network, they only include the bare minimum to be able to verify that the thing is consensus valid with GridPool. We don't share the full set of transactions.
We're only sharing the Merkle leaf and the the minimum to be able to verify if they had the correct Coinbase payout. What this means is that no one can censor you on grid pool for including the wrong transactions. So the the pool is designed to be a 100 censorship resistant sort of at the at the foundation level.
[01:03:25] Unknown:
Alright. That's awesome. Wanted to close on that. So No. And I'm glad you said that because it's you know, that's one of the the primary concerns on a on a completely transparent ledger is that they can see what's in the mempool. Anyone can see what's in the mempool and they can they can tell you, you know, this is here's an arbitrary list of transactions that you're not allowed to include or addresses that you have to blacklist. And if the miners can't see what transactions are included,
[01:03:54] Unknown:
then that problem in theory goes away. Right? In theory. Yep. Alright. Thanks for letting me sneak in that final bit. We freeze. Tyler, you looked like you're gonna say something. Well, I think he is. You're back. You froze for a minute. We didn't hear anything you said. I'm here. Thanks for letting me sneak in that final bit of
[01:04:11] Unknown:
knowledge. Most certainly we'll have to have you back on in the coming months to hear some progress updates as we get more people to take a peek at it and try it out. I'm really eager to follow along with the progress of this project. Thank you, guys. Definitely. Thank you. I'm going to wrap the show up there, so don't hang up, but we're going to end the recording now. Thanks guys. See you everyone. Thanks.
Welcome to pod two fifty six episode one sixteen. It's June 10. We've got a special guest in the studio with us today. Agent P, welcome to the show. Welcome. Thanks for having me, guys. Yeah. We're stoked to have you here. You've been a longtime listener, longtime supporter of the show. I know you've been pointing minors to donation pool for a while and interacting with the community on the telegram. And now we've got our new forum up. So thanks for being here. Thanks for being active in the community.
And you yourself have been taking some of these open source tools and tackling mining centralization in your own way. And we think you've come up well, we recognize that you've come up with some pretty clever solutions, and we wanna hear about it and showcase it on the show and introduce our listeners to GridPool and other exciting things that you're working on. Awesome. Thank you, guys. Yeah. First, I just wanna say I'm really excited to be on the show. This is super
[00:00:58] Unknown:
fun for me. I've been listening since episode one. I remember when the show came out at at the time. So I I got into Bitcoin 2021, but actually didn't didn't buy in right away because I was trying to study it and understand it. And the thing that held me off from jumping in during the COVID liquidity rush and stimulus checks and everything was was mining centralization. I I was trying to understand the system, and I looked and realized that 70% of the hash rate is physically located within People's Republic Of China. And that seemed like a security vulnerability to me that I was not okay with. So I actually did not jump in with both feet in terms of buying until after the China mining ban. Because that ban happened, all the miners, instead of getting confiscated and used against the network, were allowed to leave the country, which to me seems like one of the biggest geopolitical mistakes in history. But whatever. We'll see how this plays out. So mining centralization's kind of always been front and center for me in terms of how I understand the network and the the major challenges that I see facing it over the next decade plus. Obviously, the the mining ban happened. The miners distributed all over the world.
I saw that as positive and jumped in. But then as I started learning more about how mining actually functions, realized that pools were a thing. Pools were centralized. So it was somewhere in in, I think, 2023 when I was learning more about how mining actually functions and realizing how many problems were still out there and how close the whole ecosystem was that February pod February started. And I was like, oh, these are the guys talking about the exact problems that I am seeing. I hadn't seen anyone talking about solutions yet until this podcast showed up. So it really is exciting for me to be able to to be on here and just contribute in my own way, however I can. So with that framing, mining centralization, I started tinkering on a lot of different things, some hardware stuff, some solar stuff, direct DC. So you've seen that before. For work, I thought I was gonna not have access to a garage and a shop for a while starting in 2025.
And so I tried to shift my focus and find a software only project that I could tinker on. So that's what that's how this came about. I was, what what can I do in software to start tackling the the problem of mining centralization? You guys had, I believe you had already announced HydroPool or or maybe shortly after, you started looking at a few different decentralized pool efforts that were in the works. Ocean was starting up. I'm I'm a big Ocean fan. I like what they're doing. I think it it solves some of the problems, but not all. And just being a, I guess, a paranoid cypherpunk and fairly my my day job is is in the security world, I guess, broadly speaking. So I think a lot about adversarial thinking and and that kind of stuff. And so I like that Ocean decentralized the template for block template creation aspect of it. But because they're still managing the payouts from a centralized company, centralized server, that still presents a weak point. And I was trying to figure out how if there's a way to actually decentralize the the the payout split, the reward split. P two pool version one attempted this a long time ago. So this is an old problem in Bitcoin, and it got partially solved with p two p a p two pool v one, but not completely in that protocol had some flaws, which ended up causing further centralization pressure, basically related to their fast block times because they're running a, essentially, a side chain with faster block times, the share chain. Because it kind of is modeled after Bitcoin, it's a winner take all scenario, That means that latency becomes pretty big factor when you're determining who wins that share, who gets to add the next block to the share chain.
It's just like Bitcoin. Latency is a factor. At ten minutes for the for the Bitcoin chain, latency is a thing, but it's not. It hasn't caused extreme centralization. You see some of it if if you're a big mining pool, big miner, and you need to eke out every last fraction of a percent of profitability, then then network latency can be a thing. But for everyone else, it's not not a big deal. When you shorten block times to as fast as p two pool v one was having to do, latency becomes a really big factor. And that means if you can get latency down, you can artificially increase your your hash rate and your control of of that share chain. And so miners that were able to centralize hash rate on p two pool v one were making a lot more than the miners that were decentralized.
That's a problem. So I'm I'm trying to say very carefully p two pool v one to differentiate it from p two pool v two, which is an ongoing effort, a re a a total rethinking of that pool structure. And they have come up with some technical solutions using UNCLE's UNCLE blocks, I believe, from elsewhere in the crypto world, but pulling those ideas back into Bitcoin, which should should solve the latency centralization latency driven centralization pressure. So a lot a lot of things I wanna differentiate, like, p two pool v one had problems. V two, they're working on fixing those problems. And I think it's awesome. I think they're doing great work, and I I want to, like I don't wanna throw shade anywhere. I think they're doing great work. I like it for new problems. I like trying many different solutions. So so I am essentially attacking the exact same problem that p two pool v two is attacking. I don't think that's a bad thing. I think I think we should try a lot of different solutions.
Each one is gonna have different engineering trade offs. And then we'll see in the end which one turns out to be more useful. Maybe both stick around and have their, you know, their their different advantages and disadvantages. Yeah. I think you've got a great point in that there's
[00:06:37] Unknown:
no silver bullet to solving these problems and that they all have trade offs. Just to kind of recap here, so you recognized issues around mining centralization from the get go. And then that was at a very interesting time, like right before the big Chinese mining ban in the summer of twenty twenty one, when majority of the hash rate went offline as it was relocating itself globally. And then you're kind of able to start peeling back the layers as you start learning more about this. It becomes, you realize that mining centralization doesn't just mean geographically centralized, but it also means that the mining pools are a centralizing force. And then, you know, we start understanding that the, you know, manufacturers building the hardware are centralized forces and that they have control over the firmware.
And even the mining rewards going to just a handful of custodians is another centralizing force. So there's all these different layers to centralization. And then you kind of look around at the landscape and you see oceans working on it in their own way. And it's great that they've taken a step forward toward decentralization in that the miners get to contribute to the template that they're mining on, but there's still that centralized point in there where the mining pool operator controls the coin base payout.
So like it's a silver bullet solution. You look at other solutions that are out there like P2Pool V1, but like you mentioned, there's issues with that, the speed of the blocks on the side chain that they're mining on. And then we've got Jungly, who's a February Foundation developer who built HydraPool, working in tandem on P2Pool V2, which incorporated the uncle blocks. I believe that idea came from the Monero community and incorporating that into the side chain to help with that centralizing force. And then now we land at grid pool that you're working on. And so you've kind of taken a lot of the perspective that you've built over the last few years, and you've come up with a pretty clever solution to take a stab at some of these centralized issues. So should we get into to some of the technical details on how on how GridPool sorry. I'm I muted my mic. On how GridPool approaches this? Yeah. And how it's different from p to p. Yes.
[00:09:09] Unknown:
Yeah. Let's do that. We're before we jump to technical stuff, I wanna frame I wanna frame it with a hypothetical scenario. End of the world, the government decides it's time to clamp down on mining. They roll into ocean. So totally hypothetical. They roll into Ocean and they say, your decentralized block templates are great, but you're only allowed to pay and credit miners with shares if they comply with with our transaction set. Let's say. So if a miner sends you a share that includes one of these censored transactions, you're not allowed to pay them. Right? That's that's really the the critical choke point. What do those miners do if they still need to be able to mine Bitcoin, get payouts, but they don't wanna do they don't wanna comply with the censorship. That's really what it's what it comes down to. So this is related the reason I mentioned this is this is related to your vision for this the a similar scenario for why you built HydroPool.
In a similar fashion, I've I've heard I think I've heard you say something like this before that, you know, in a in a end of the world and hypothetical scenario and all the pools get shut down or centralized or or the the controllers come in, we want anybody to be able to quickly and easily spin up their own pool instance to be able to keep building blocks and keep mining Bitcoin without having to comply. This is what keeps keeps Bitcoin free and keeps its censorship resistant, which I think is an awesome vision and HydroPool absolutely needed to exist. So here's where here's where GridPool comes in. Let's say the miners that leave Ocean and the miners that spin up their own HydroPool instances don't have enough hash rate to guarantee that they'll be able to get a block, a payout of some kind before their power bills do. Right? If they're a huge miner and they can get a block a month, they're probably gonna be fine. If it's a small shop, if it's a couple of p to hash, they could go years plus without getting a payout. So then We had a 2.5
[00:11:03] Unknown:
x a hash at the last telehash and still didn't hit a block. Yeah. I I I know the the time was very short in duration, but I just, I think you're approaching this with a very realistic and practical mindset for what an adversarial environment looks like. And to your credit, I don't think it's all that hypothetical based on the trajectory that we've seen things developing over the last few years. Yeah, keep going. I love it. Exactly.
[00:11:32] Unknown:
And, okay, quick sidebar. I'm for my day job, I used to do a lot with deterrence theory. So I would love to build the technical solutions that exist that make it so that such an attack is obviously impossible and futile. And that would guarantee that it never actually happens. That's deterrence theory. So if we build these now and get it in place and make it work really, really well, then it's a given that this would be the obvious fallback option. So using this hypothetical scenario, how do these smallish miners pay their power bills? So, not everyone is going to be able to go full off grid and go without a payout for years.
That's just reality is they're gonna be forced to choose between do I scale down and just run a bid axe on my desk because that's what I can afford, or do I do I comply? Or is there a way that we can get a decentralized payout structure going? So GridPool is built. This is why I spent it took me a year reverse engineering Datum Prime. So let's talk about Ocean. Their built their effort to decentralize template construction uses Datum, and what they open sourced was the Datum client software. So that's what individual miners use to build their templates and then submit shares. So Grid, I in order to make this compatible with Ocean Miners, I spent a while basically reverse engineering the Datum protocol from their open source client so that GridPool nodes can act as Datum servers, Datum prime servers, in the same way that Ocean servers do. So GridPool right now is fully compatible with every miner on OceanPool.
All they do is go into their config settings for Datum and point it to a different server address, put in a different public key.
[00:13:21] Unknown:
So wait, let me just like rephrase, run this back to you in my own words, because I think you I think what you've accomplished there is actually pretty monumental, but you just kinda like glazed over it like it was no big deal. So just to be clear, the ocean server is closed source. They haven't open sourced the pool server that they operate. But they did open source the Datum client that they built. And so essentially what you've done, if if I can just recap in my own words, is you've taken that client, reverse engineered it, and understood what how to construct a server for that client just based on the client alone without any insight into how the Ocean server actually
[00:14:05] Unknown:
is constructed. Exactly. It's amazing. Thank you. I guess I haven't thought I haven't thought about that in a while. I did that reverse engineering work a year ago, and I hadn't thought about that step of the process of the project. But the reason I did that is because the vast majority of miners who are currently building their own templates, right, sovereign minded miners are on Ocean Pool. Like, 99% of the hash rate of people building their own templates are doing it on Ocean and submitting their shares to Ocean. And so I wanted Grid Cool Pool to be instantly compatible with that 99% of miners that are already doing their own template construction. I'm making up the 99% number, but it's it's a lot. Right? Ocean has a lot of hash rate. They get blocks every day. And, you know, so I mean, just for any listeners that aren't clear and, you know, in my own words, it's like Datum is essentially
[00:14:57] Unknown:
Ocean's stab at Stratum V2. And it incorporates a lot of the same upgrades that Stratum V2 promised. The issue is availability of Stratum V2 compatible pools, right? So there's like demand, but if I think you have to like sign up and request access to mine to demand right now, or they may have opened it to the public, I don't know. Last time I checked, which was not that long ago, you had to like go through a sign up process. And then I think Brains has some sort of Stratum V2 server that miners can mine to, if I understand correctly. But all that is to say is that the choices are pretty limited. And what Ocean did was they looked at Stratum V2, decided there were some things about it they didn't really like, and then they came out with Datum. And so, yeah, I think you're spot on. I think the vast majority, maybe not 99% exactly, but the vast majority, I think it's safe to say, of miners who are building their own templates are doing so via ocean because it's kind of this trade off where you're not solo mining, so you're not gonna get like the full block reward. We can save the debate on the definition of solo mining. But what I mean here is that it's not like you're building your own template and then keeping a 100% of the block reward for yourself. Their trade off was that you could still earn small amounts of Bitcoin proportional to your hash rate contribution, and you were selecting which transactions went into the template. Yeah.
[00:16:32] Unknown:
Well said. Stratum V2, the protocol is open source. My understanding is that it's just complex, so adoption has not been very fruitful from these other pools or running the client on your end. Then on the other side of the aisle, the Datum attempt to solve this problem, the server's not open source, they're saying if you want to use it, you have to use it with Ocean Pool. That's what you have reverse engineered. So effectively, Datum becomes on a level playing field with Stratum V2 right now, where it could be a simpler implementation and you could implement it to other pools. And then you've got grid pool to solve the actual payout centralization structure itself, I think, and I want to hear about that. But I just want to frame it that this reverse engineering of the Datum server from the client is effectively bringing a competitor to Stratum V2 to other pools. Is that correct? Yeah, I think you framed that well.
[00:17:28] Unknown:
GridPool is totally open source. So if someone wants to see how to make a Datum compatible server, they can start with my code and then do whatever they want with it from there. You know, if if they don't wanna do the decentralized reward sharing aspect of it. What I'm not doing in grid pool is is tides the share accounting system associated with with Ocean. I'm not doing any share accounting. We'll get to that in a minute. So if someone wanted to make their own Datum compatible pool, they'll have to do that part on their own. But the actual communications structure, they can look at mine and just go from there, fork and do whatever they want. Okay. So I think we I think we set up the problem. Let's go into how GridPool works, and hopefully that it will start to come together.
[00:18:10] Unknown:
Just to quickly frame it quick. So I do want to get into the technicals, the block template construction has been the big talk of town. Everyone seems to know about this. That's like you said, all these cypherpunk minded miners. That's why a vast majority of them are on ocean. Not a lot of people understand the problem of just having a central authority that issues the payout from the Coinbase altogether. And that's what we're teeing up here, right? That's what P2Pool V1 and V2 and GridPool aim to discuss, which is or to overcome, which is why have any central authority issuing the payouts? Can we make this itself a protocol? Is that correct? And then you want to dive into it. Exactly.
[00:18:47] Unknown:
Yep. Yep. The other attempts at this have been pretty complex. They've been good attempts. They had technical issues. So as the as as we talked about before, GridPool's approach is actually, like, really, really simple compared to all the other ones. We make some engineering trade offs that allow us to get that hypersimplicity, and I think it it it allows us to navigate sort of a different solution space in this. But it it really is a simple concept. I'm not like a brilliant developer. I write code on on the side. I I do have a a computer engineering degree that I got a decade and a half ago, and I haven't used it since, except in my hobbies.
So I'm I'm not a professional. Let's go go through how this works with a a a toy example. This is gonna be the easiest way to dive into it, I think. Let's say you and all your friends have bid access, and instead of and you wanted to to make your own you wanted to share the reward amongst each other. You you and nine other friends. Right? So 10 people, you each have a one terahash bid access, and you and you'd rather 10 x your chance of getting something. And you know that everyone's putting in about the same work. You could just agree a verbal agreement to say, let's just split the reward 10 ways. So we'll all configure our block templates. We'll put in each other's nine other addresses, an even 10 way split. And then whenever any of us gets a block, then we all get something. Right? So everyone has now increased their chances of getting something, 10 x, in exchange for only taking 10% of the block reward and sharing the other 90% with everyone else. Right? But you get a 10 x improvement in your variance. That's kind of how you would just do just a verbal agreement. Now let's say you wanted to make sure that everyone else kept their bid access turned on. So you you arrange to have have your different template construction software. You know, one guy might be using HydroPool, another guy's using Datum in solo mode or something. Send each other shares of, hey. Here's the latest template and nonce that I found so that the other guys can see that you're still including all of their addresses in your Coinbase template.
Right? So every once in a while, you send them a share, say, yep, I'm still working on it. I haven't found one yet, but my difficulty is too low, but here's a 1,000,000, here's a one g diff share. It's got all 10 addresses in it. This is how you start to reduce the trust layer. Now it doesn't have to just be 10 friends. It can kind of start to get a lot less trusted if you're actually sharing evidence that you have been working on a template that shares those rewards properly. And that's kind of the consensus layer of GridPool. So GridPool pulls a lot of concepts in from p two pool and from Bitcoin itself. There is the concept of consensus in it. It's a winner take all approach based on difficulty, whatever difficulty the share reaches. We'll get into that in a minute. Unlike p two pool, we're not actually using a a side chain at all. Alright. So now we can go to maybe how how GridPool actually works. Everyone has can have their own node. The the website that you go to, if you see gridpool.net, is just my node. In order to bootstrap a network, just like Bitcoin, there's there's hard coded addresses. And so when this thing launches, we'll have to have a decent number of people that are willing to run stable nodes that are gonna be reachable to anyone new joining the network. That's how Bitcoin bootstraps itself as well when you turn on a new node. So when when you go to the website, that is that is my node, but anyone can run their own and should run their own. Each node is keeping a list. Okay, now we have to define a couple of things. In the code, I call them the winners list and the on deck list.
I'm not good at naming things. If someone has better names, I'm all ears. The winners list is that list of payouts. Whose addresses get added to the coin base for everyone who is wanting to participate in the pool. That's the winners list. The on deck list is a running tally of whose shares have achieved the highest difficulty. Who got closest to winning a real block with a share that included the correct set of payouts in the winners. It matches the winners list. Let me pause there and make sure that those concepts kind of make sense. Any questions? Yeah, I think I'm with you. So I'm looking at
[00:23:04] Unknown:
the grid pool website, which again is gridpool.net. And it's pulling this information in from your node that you're running. Anyone can run their own node. And essentially, you've got it split up into the
[00:23:18] Unknown:
on deck list and the winners list. Is that the same as the the next payout queue and the current paid team? Looking now to make sure I'm looking at the same thing. I just I wanna make sure I see the winners. Let's make sure we're on the same view. In the top section, there's a little box that says view. You can do lottery, business, or nerd mode. These are just different ways of of viewing the data, and they surface different attributes. It's a UI thing. It's working the same on the back end.
[00:23:45] Unknown:
Okay.
[00:23:46] Unknown:
So, yeah, when I click on Nerd, now I see the on deck list and the winners list. Yep. Yeah. So on Nerd, when you scroll all the way down to the bottom, there's a box, winner lists. It's defaults to collapse, but you can expand it and you'll see a whole list of 299 different slots, payout slots. So all these are even even payouts. And on the right hand the right hand column is the difficulty that that share achieved in order to win that slot on the list. Okay. So even if
[00:24:15] Unknown:
one of these participants on the winners list is has submitted a much greater difficulty than some of the other participants, their their reward split is still It's the same split. It's the same split across all the users.
[00:24:32] Unknown:
Yep. And this this is important mathematically. I don't know that I can explain all the math behind it. I did have a codex generate the math behind it into a nice little markdown paper that you can read, assuming that's correct. This is how we maintain fairness, payout fairness. So in a normal pool, they don't pay by the difficulty, they pay by the number of shares. And you commit to achieving a specific minimum difficulty, and then however many shares you can generate at that point, that's that's how they estimate your hash rate, how much power you're putting into the pool, and then they correlate the payout with that with some minor nuances depending on the pool and other stuff. If you were to do payouts based on difficulty, you introduce a whole bunch of statistical variants that you don't wanna you don't wanna do. Because someone they roll a lucky share, and they get paid out a huge amount. So by keeping the payout splits even and just sorting them by difficulty, we still get a mathematically fair breakdown according to how much hash rate you're putting in, but we don't have to track every single share with a lot of fine grained detail.
This is a core thing that differentiates grid pool from p two pool v two and v one, I guess. P two pool is still trying to estimate hash rate with a with a stream of shares, getting frequent shares, they're not looking at difficulty at all, except to make sure that the shares meet a minimum target threshold. We are looking at difficulty, but we don't correlate the payout amount with it. What this breaks down to though is that statistically, if you're putting in 50 percent of the team's, the pool's hash rate, statistically you're going to win 50% of the payout slots, which means you're gonna get 50% of the Coinbase reward. So it still breaks down to a fair distribution, but we arrive at it mathematically via a different route. There's probably a little bit more variance with this, because if you're putting in 50%, sometimes you may get a little more than 50% of the slots, you get a little less. In my tests, it's pretty close. It's not exact, but on average, it is 50. You know, long term averages, it's statistically fair. This is what allows different types of participants to use this protocol from a game theory perspective, and it still be useful. So a business can use this and expect that they're going to get rewarded what they they put in according to know, there there's not a lot of variance.
It's fairly predictable. It's not as predictable as a traditional pool. There's gonna be some more fluctuations, but it's better than pure solo. This also means that the lottery miners Sorry. Let me finish real quick. Okay. Go ahead. You know, guys running bid axes, when this thing gets going, if there's a decent amount of total hash rate, a bid access is gonna have a tiny tiny fraction of the total team's hash rate. They're rarely rarely gonna make it onto the list at all until they get lucky. And then they're gonna get lucky and get one spot on the list. Some people might like that because they're mining with a Bidaxe getting 300x better odds of a onethree hundredth payout of a Block reward. For some people that they might like playing that type of lottery versus going for a full block. It's it's totally up to them. But both both types can can use this, and that's why there are different UI views built in lottery mode, business mode. And then the nerd mode is where I dumped everything that I needed to track and debug and and make sure the system was working. Okay. Iko, you had a question. I cut you off. So how does Miner secure one of these slots? Is it like each client gets its own slot?
Because I'm I'm looking at it and I see, like, you know, there's multiple slots sharing the same address. So, like Yeah. Are those, like, three different clients that all have that address configured? Or Those are the same same client. So really good question. This is really important piece of it. How is in this totally trustless decentralized network, how do you trust? How do you how do you credit shares? How do you know which miner these shares actually belong to? The protocol is is a totally unencrypted HTTP JSON message.
Like, anyone could intercept that and mess with it and then resubmit it. So how do we how do we make sure that this is secure and that the right miners are getting credit for the the slots that they earn? Right? So when you the protocol this is consensus layer type of stuff, put your consensus hat on. Clients take the they get the current winners list. They say, okay. These are the these are the addresses I need to include in my template for this share to be considered valid by the rest of the network. And then they so they that's list is 299 slots long.
So if if it's 299 unique addresses, then then it'll be a list of 299 different slots. If a big miner is taking 50% of of the share, then each each each node can collapse that in order to not use up as much space in the block, the template that they're building. So they can just credit when they're building the actual template. They can total up the payout for that single address when they're constructing that Coinbase transaction. We can come back to that if you need to. That's kind of down in the weeds. So they take the list of two ninety nine potential payouts, they're like, I need to include these for my shares to be considered valid.
And then they insert in slot zero their own payout address for for one share. That's how we cryptographically ensure that that share gets credited to the correct miner. Because they take that template, construct the Merkle tree, calculate the Merkle root, and then start hashing on that until they get a knots that is high enough to submit to the rest of the pool. Once that happens, they wrap this up into an HTTP JSON message that we've designed. They share that with the rest of the network. When other nodes on the network receive that share, they check for basic rules of validity. They make sure it's it's a valid Bitcoin block. There's one exception I'll get to in minute that they don't check. They check that the 299 addresses that are included in that coin base are the correct ones, and they're being paid out correctly. And then they look at slot zero, and they look and see they read which address is in slot zero, and they credit that share to that address that is in slot zero. And so if that share achieved a high enough difficulty to make it up onto the on deck list, then they insert that new spot on the on deck list credited to that address in slot 0 with that single slot payout to it. This means that once you create a share, you've hashed it, you've put the work into it, and you share that with a trustless, unencrypted network, no one can mess with the share. Because if someone tries to change the coinbase on it, the nonce is invalid.
When other nodes check it, the difficulty will be super low. It won't be a high difficulty share and they'll throw it in the trash. So this is how nodes make sure that their shares are credited properly.
[00:31:26] Unknown:
Does that make sense? Yeah, I think I've got it. So there, you're still using that proof of work mechanism where they have to prove that they've done the work. And if they get a high enough proof that puts them on the on deck list. And then so just remind me real quick. What what's the difference between the on deck list and the the winners the winners list? Good. I
[00:31:48] Unknown:
called it winners because whenever someone on the team finds a real block, those are the people that get paid out. They're the winners. So Got it. Okay. Their their addresses have been locked into this this Coinbase template that everyone on the pool needs to use to be able to participate in the network. The on deck list is the people who are vying get their addresses added to the next winners list. So miners take the winners list, they make their templates, they work on them, they submit high difficulty shares to the rest of the network, trying to get their addresses added to the on deck list. Eventually, someone is going to get lucky enough that the share that they produce is actually a real Bitcoin block. It gets added to the chain. Because everyone's running their own node to be able to build their own templates, when they see a real Bitcoin block added to the chain tip that pays out the winners list, the round re resets. So when they see that, the their current view of the on deck list becomes the winners list. For the next round, the on deck list gets cleared, the round resets, and then everybody starts the competition again. And so that's how you're essentially decentralizing
[00:32:57] Unknown:
that Coinbase payout because that can come from any miner who's produced a template that's worked that that meets a good enough difficulty to be on the on deck list. And then that is is it the like the best share from the on deck list gets trying to put this into my I I I can almost like, if I squint my eyes, I can I can almost wrap this all up in my head, but I'm not as smart as you guys? So it's it's like you've got the the on deck list is the highest difficulty or, you know, that's been made so far. And if it reaches a sorry. So it's like the best difficulty from the on deck list gets used for the gets automatically moved up to the winners list. And then that's the template everybody uses to build on until they hit a difficulty high enough for a valid block. Is that right? So it's like you've got kind of like this, I don't know, in my own words, a staging area where everyone's submitting these, their best attempt. And it's it's not a difficulty high enough to hit a block, but it's it's good enough to go on the on deck list. It's everybody's best work that they've done so far. And then the best of those templates from the staging list get moved to the winners list. And each time like a new highest difficulty gets hit, that takes the spot of the winners list. And then they're using that template to construct their blocks in an attempt to hit the network difficulty.
[00:34:25] Unknown:
Is that where how am I doing? No, you're good. I think you're tracking. Feel free to ask any other questions you want if it would help clarify. Is this making sense to you, Tyler, as well? Yeah.
[00:34:36] Unknown:
Correct me if I'm wrong here. How I'm thinking about it is you have the staging area side. You are statistically filtering for how what proportion people should be paid out by how high their difficulty is, not by the number of shares. Correct. And that results in higher variance but also similar payouts proportionally,
[00:34:55] Unknown:
statistically. Statistically, correctly fair
[00:34:59] Unknown:
Correctly fair. Yeah. This is the massive simplification
[00:35:04] Unknown:
you alluded to that doesn't require the share chain. Exactly. It does not require a share chain. And so latency
[00:35:11] Unknown:
is much less of a problem in this. No bigger of a problem than in Bitcoin. Okay. I might have to see it drawn out for me just how the staging and the winners with some arrows and some boxes because I agree with I mean, I can't say it any better than Eco did, but I understand the general strategy of what you're trying to do. It makes sense to me, but please continue.
[00:35:33] Unknown:
That's okay. It's recursive. And so sometimes recursion can throw people for a loop and it takes a little bit to wrap your head around. It is simple. I think it's elegant, but it took me a couple years of working on this to figure out just thinking about it before I came up with something that I thought. Was actually gonna But simple, but still worked. Yeah, how did you have that eureka moment where you were like, Well, what if we just did it this way? I don't know if anyone can explain how eureka moments happen, but it was a year plus of thinking about the problem and then thinking about what if we try this, what if we try this. Okay. Realizing all that wouldn't work. I can't remember where I was, but I do remember the figuring out the slot zero aspect.
That was definitely a eureka moment for me realizing that, oh, I could I can cryptographically secure these shares to a specific miner by having them include their own address in the payout. And then I also, as a side benefit, get some resistance to block withholding attacks out of that, which we'll talk about a little later if there's time. How many addresses can be paid out from grid pool? Up to
[00:36:40] Unknown:
300 at a time. Two ninety nine and then the zero slot.
[00:36:43] Unknown:
Exactly. And yeah, so up to 300 total, but one of those always belongs to the block finder. Yeah, okay. This is very interesting. It's a weird concept. I think it works, but I'm one of the only people in the world that's been like thinking about how the system works for a long time. So so as I open it up and I it gets more eyes and more publicity. I'm a very adversarial thinker. I would love people to to tear the system apart and find the thing that I missed. Right? I would love no more than
[00:37:12] Unknown:
that. If someone was like, Hey, you didn't think about this, or I can break your system this way. I can cheat this way. That would be awesome. Please tell me. That was one thing I was going to ask, which is what would be Well, obviously that would be cool to get people way smarter than the three of us or that have different blind spots or identify different things than us to peek under the hood and take a look at it but also what would be helpful for your development? Is it more hash rate pointed? Is it running a grid node, right? A grid pool node? Do you want to speak a little bit to that? How people can actually start to not just poke around, but also try it out? Yeah. I would say very soon they can start running their own version. There's a there's a Docker Docker script created that that should make it easy to do as well. Point their datum node at it and and try it out. I had someone from
[00:38:00] Unknown:
open size Open Source Miners United Discord actually helped me out end of last year, pointed me a bit of hash rate and put in weird things that I didn't expect for his worker names and broke a whole bunch of stuff. And that was super helpful. Super helpful for me for working through a few bugs. Yeah. So it this thing is is a little bit hard to tell when it's done enough to launch. So, at this point, I think I'm probably pretty close, but I think I would like to do more testing on Testnet four. I had just, just in the last couple weeks, I started spinning up a few of those Testnet four nodes to be able to try to get some real blocks on there. Right now, I've been I've been cycling the rounds artificially because I don't have enough hash rate to get real blocks. And so but because the round cycling and all that math is an important part of the system and how it functions, I need to be able to see that working. I'm using just an artificial trigger to cycle new rounds on Mainnet.
But on Testnet, I'd like to use the real trigger on Testnet. So I think if people want to get involved, download the code, try running it, see see if if it's easy enough to to spin up your own version and get it connected. Tell me how it goes. Give me feedback. Listen to the podcast. Think about the system and how it functions and see if you can break it. That would be awesome. Yeah. I think I think some of those are the main ways. As we get closer to being ready ready to launch, it would be really, really helpful if we had a few people who were committed to, like, running stable, well connected nodes just to make sure that we can sort of get the network bootstrapped.
We have enough enough sort of stable seed nodes online that that we know that we can sort of get the thing launched and rolling. I have a couple questions.
[00:39:41] Unknown:
One, to solve the block template construction problem is in its current architecture is Datum the only method for doing that? Could Stratum V2 also be implemented where you could use either client side block template construction? Yeah, let's talk about client side. So Datum was the one I went for first
[00:40:02] Unknown:
Ocean has a lot of Datum hashrate. That's why. Second one I did was HydraPool. So I forked HydraPool. I had to fork P2Pool v2 as well in order to be able to do custom payout to be able to control the customized payout list. But on my forked version of HydroPool, HydroPool can submit its own shares to the GridPool network. So the ideal setup for that would be someone spins up a hydro pool node, they spin up their own grid pool node, their hydro pool node submits shares to their grid pool node, their grid pool node checks them and shares them with the rest of the network. And then their Gridpool node is also maintaining their own sovereign copies of the two lists that we talked about, and then feeding the Hydropool node that list data so that your Hydropool node knows how to construct a correct Coinbase payout. So this works in in my forked version of HydroPool.
I've been talking with Jungly. I put in a PR, and he's he's he's supportive of it. He wants to go a slightly different route just in the codebase in in terms of how he enables this going forward. So so the PR is is in, and he's working through that. But I I don't wanna step in his chili too much over sidetrack his other efforts and stuff. But hydro pool is is pretty trivial to make work. Because this protocol is so simple, like, it's just a couple of HTTP JSON messages, it's we could almost vibe code compatibility to any other pool implementation.
I could see so on my list would be c c k pool, public pool, stratum v two would be those would be towards the top of my list. Atlas Pool is another forked version of CKPool. I even used a Bidaxe directly. So this is an interesting side project. Again, VibeCoded in, I think, one shot. Codex made it so that my Bidax uses RPC commands to my Bitcoin node to construct a block template. It also used the HTTP JSON protocol to talk to my grid pool node to get the current payout list. It constructed its own share, worked on it. Once it found the work, submitted that work back to my Gridpool node, a 100% running on the BITX. So that was with no other stratum layer involved at all. Because the protocol is so simple, you really could you could do anything with it.
It it'd be it's trivial to plug anything into the network. My next test was gonna be doing this with Magena, which I would expect should be similarly trivial. Probably easier than the BidX. But if sorry. You Go ahead, Iko. If I understand, you had your Bidax acting as the grid pool client? So the Bidax was doing was doing was acting as a datum client. Let me simplify it like that. Okay. So so it was talking to the Bitcoin node. It was constructing the template with all the correct Coinbase payout splits, and then when it got a good share, it was submitting that to my GridPool node. It was not acting as a complete GridPool node itself, so for that it would have to also be connecting to a lot of other GridPool nodes, so it's got a well connected view into the network, receiving shares that other nodes are sharing around the network. When someone says, hey, I got a new thing to add to the list. Each share has to be checked for for the validity rules and stuff. So the BidX is not doing that part of it. It but it was it was getting the Coinbase Coinbase split from my grid pool node, building its own work, and then submitting shares back without a stratum layer involved at all. That's pretty good for a ESP
[00:43:31] Unknown:
32.
[00:43:32] Unknown:
Yeah. Right? Which means literally anything can use this this pool. Yeah. Like, you've got the the
[00:43:39] Unknown:
Datum client code simplified enough there that
[00:43:43] Unknown:
that anything can run it. Yeah. I mean I mean, to to clarify, that's not using any Datum code at all. That was that's using the ESP minor code base. And then I just told Codex, hey, I want this thing to reach out with RPC commands and then build its Okay. Build build its own templates. So there's no stratum layer involved at all. It's going straight to the Bitcoin node and and then straight to the grid pool node for the for the pool split. Gotcha. Okay. Is the fair payouts with higher variance enough to convince larger miners to use this? Good question. Because everyone's got Fiat brain rot. So Yeah.
So my hope is there's no fees on this. 0% fees and you get lower variance for free. So game theory would say that it's in everyone's best interest to use this. That includes not just small miners, that includes Mara, that includes Ant Pool, that includes F2 Pool. It's in their best interest to participate in this coin based split. Now the real big pools are probably not gonna bother because they're big enough that variance is not an issue for them. I think for for your middle tier pools, I think this could be huge because now they can they can get over that hump of, like, the danger zone when pools die, you know, when you're not getting a block more than every week or so. Mhmm.
[00:45:01] Unknown:
And it's just at that point, the pool can't survive. But if they use this, they get a payout. Yeah. So good for the medium sized guys. I mean, what we've learned with the large mega miners, you mentioned some of the big guys that are using Foundry or whatever, it doesn't even matter what it costs. It's about compliance and SOC two and all this legal BS. Like that's the reason they pay to have the pool managed for them. Maybe there's no convincing to be done there. What about the smaller guys though?
If I am understanding this correctly, if the grid is sufficiently large with enough participants and only 300 slots in the payout, the small guys might still be SOL.
[00:45:40] Unknown:
Is that true? Not SOL. It's still better for the small guys
[00:45:45] Unknown:
Versus going a 100% solo. And is that because it's based on them getting a good difficulty, not necessarily
[00:45:53] Unknown:
how much hash rate they've got? They just need to get enough to get one share onto that payout list. And statistically, if they have one three hundredth of the pool's hash rate, on average, they're gonna get one payout slot per round rotation. So if if the the total pool is small it's getting one Let's say the total pool size is 300 P2H. So, a one P2H miner on average is gonna get one slot on that list every month. And on average, that team is gonna get one block a month. So, there's their they're gonna get one slot payout a month on average. Let's say the pool doubles in size. So now it's a 600 P2H pool, and they're getting a block every two weeks. But now it's twice as hard for that P2H miner to make it onto the list. He's still getting on average one payout slot every month. So once you get up above a certain threshold, it's actually no it your payouts start to even out and you're still going to be getting on average paid the same. Does that help explain it? Yes, but if you're a small small miner say with 10 terahash,
[00:47:03] Unknown:
that's when you're still waiting quite a while. Yes. You're still waiting quite a while.
[00:47:07] Unknown:
You're waiting mathematically 300 times shorter than if you were pure solo. Gotcha. So, that's, you know, at a 10 terahash level, that's a 100% a personal choice. Do I want the jackpot?
[00:47:21] Unknown:
Right. Do I want a low chance of getting a jackpot or do I want a slightly larger but still low chance of getting a small payout? So there's a sweet spot. I mean, it's not enforced, but there is kind of like a sweet spot for depending on how large the pool is, how big your share should be to get your desired
[00:47:39] Unknown:
cadence of payouts, you know? Yeah. In the business view on the pool page, I tried to produce some of these metrics so that if someone was wanting to predict what their payout cadence would be Mhmm. Mathematically, they could they could see this. And this is based on the the hash rate of the total pool versus their own hash rate versus the network hash rate, network difficulty.
[00:48:04] Unknown:
And using that and some math we can predict what someone's payout cadence is going to be. From your development of this project, do you think that if you have the 10 terahash space heater or whatever and you want your 500 stats per day, and you also want pool payouts to be a protocol, not a centralized entity. Is that where the share accounting and share chain has to exist? I'm just curious your commentary on that to solve that problem. That's a good question. So if so if you if you want 500
[00:48:36] Unknown:
a day, you can't you can't do payouts direct from the Coinbase at all. Yeah. You just can't. You and which means you have to do a solution that involves lightning and I don't want to say a custodian because I think there's clever technical solutions. I know there's people working on this problem. Yeah. I'm not smart enough to understand them. So if someone can figure that out, that's awesome. And I hope that that option exists for miners that would like that to exist.
[00:49:05] Unknown:
Yeah. Mean, that's my vision and dream is regardless of size of your mine or system, you plug it in and the network's a protocol, the nodes a protocol, and the mining and the payouts are also a protocol. There should be no centralized risk. Yeah. We we figured out a way to plug computers in, connect them, they talk to each other, and they value each other's efforts, and they pay each other. Like, done. Right. Right. Yeah. Yeah. Now the 300 payout slots is that was a that was a design choice. I kinda guessed if if we include a lot more payout slots, then we could get finer grained payouts.
[00:49:40] Unknown:
You're not gonna get down to 500 stats. No, of course not. But you could get a more fine grained split. What it ends up doing is you might fill up the entire block with Coinbase payouts and not include very many transactions. Right? We're limited on block space. And if you go less than 300, we could have done a 150. Now you're getting more into lottery range. It's it's harder to get one of those slots. The payout is bigger, but the variance increases. 300 seems like felt like a rough kind of middle ground. The other piece that played into it is that a lot of minor firmware is broken and cannot handle Coinbase transactions that are too large.
The the datum guys dealt with this a lot and if you dig into their code, they have some very complex code to figure out how to like fingerprint each miner and then give it the right block size. What that means is that certain mining machines will not be able to contribute or participate in grid pool. And that might be an open problem that might be bigger than I realize, depending on how much the network hash rate is able to handle a 300 slot Coinbase transaction.
[00:50:50] Unknown:
I don't know. I I say it's more incentive to get different kinds of firmware running on Antminers. Mean, let's just reveal the elephant in the room. It's Antminers that can't handle these large coin base. Exactly.
[00:51:05] Unknown:
Well, you actually have some experience with that. Agent P, why don't you I saw a cool forum topic from you on the February forum answering my question, which is, Hey, hey, Neanderthal here. How do I start hacking away to try and get Mugena open source firmware onto an Antminer? And you posted some awesome tips. And before the call, before we started the pod, you said, you know, you learned a lot during that experience. So why don't you talk on that? Yeah.
[00:51:32] Unknown:
Let's say so let me first say all of my hacking, tinkering, coding is, like, in my spare time. I've got a lot of small kids and I don't have a lot of spare time. So the the time that I have to be able to the times I get to sit down at a computer and write code for two to three unbroken hours, like, I get maybe a handful of those a year. It's not much. So so vibe coding has changed my life because I can sit down at a Codex terminal and bang out a quick prompt for five minutes. And then I go and, you know, I change a diaper. I get dinner on the table. I'm tucking kids in bed. I'm like, you know, just doing family life or whatever. And then I come back and check on it. And half the time the thing is done, it's come up with a better solution that could have figured out on my own or I steer it differently or whatever. But it really has allowed me to to start contributing and producing things that I would never have had time to to do before. So I'm super bullish on open source for that reason. Like, the barrier to be able to contribute has now been lowered all the way down to the floor. Like, it cannot be any easier to start producing open source code. It truly is amazing. So as I was building GridPool, I I was starting to expand my testing, and I realized I needed three to four different nodes all set up and talking to each other and running the code so that I could start testing the actual network protocol. And it was getting a little bit much to manage, and I was using the AI agents a little bit for for some of the coding stuff, and I just wasn't able to get all these things talking to each other. And I just asked Codex at one point, can you just SSH into my laptop and fix this for me? Here's the IP address. And it was like, yeah, sure. Here's the key. Can you paste this into the config? Alright. So it helped me set up the SSH key. And now Codex SSHs into all of my nodes. When I need to change something, it handles all of the network configurations.
Before this, I wanted to swap a bunch of the nodes back over to main net just so I could kinda demo and get more of the hash rate back into main net. That was one prompt. I said, hey. Can you switch over the everything back over to net for me? Sure. I walked away. It was done when I came back. So the power of these things is is incredible. That's basically how I approach the s 19 XP thing. I have some XPs laying around, and I saw Scott's post about hacking on the J Pro and all the stuff he was doing with that, and he was doing it most of it through vibe coding. I was like, well, let me me give it a shot. I've been wanting to try Mugena on the XP.
And rather than waiting for someone else to build it, I was like, maybe see if Codex can do So so it was one prompt. For first, I downloaded the code base, you know, cloned the the repos on GitHub. I cloned the ESP minor repo and the Magena repo. I wish I'd also cloned Scott's branch. I didn't realize he had a separate actual separate branch. But so that those were available locally that the AI seem to do better if the code is just right there on the file system that it can read. And then in one prompt, I said, hey. Here's the ESP Miner code base, which does work on s 19 XP chips. So here's how to talk to the chips. Here's Mugena. Can you make Mugena talk to my s 19 XP?
And then here's a loader. Here's a Mugena loader that someone else used to to get it onto that onto that board. So in one prompt, I had it build the the code base for Mogina. And then once it was ready and I was sitting there monitoring the machine physically, I had a power meter on it just for safety. I didn't I didn't want it doing anything automatic on the on a running miner without me around. Then I told it to go. I said, okay. I'm watching. Go ahead and remote into the machine. Here's the IP address. It should be default username, password. See if can get Magena running. And so it came up with its own testing plan.
First, it remoted in and just verified that it could get UART connectivity and just did a scan of the chains and made sure it can it can read from all the chips. Once it was happy with that, then it it loaded Magena as well. This control board had LuxOS already running on it, that handled the secure boot piece. I think that's a more difficult challenge that I haven't looked into yet. So it shut down the LuxOS program that was running. And this is not SD cards swapping images. It just hijacked it while it was running. Purely through the LAN. It SSH ed into the miner, shut down the LuxOS program, booted up the Mugena program after it copied the It compiled Mugena for that control board, copied it onto the control board, started it up, sniffed all the traffic on the UART, watched the debug logs as it was running to make sure that it was doing what was expected. Yeah.
In the first test, it realized that it was running, the chips were hashing, and returning super low difficulty shares. All the shares were like zero or one difficulty. Nothing. So then it on its own realized that on the S19XP chips, the byte order of the nonce is reversed when it's communicating it back. So it just flipped that byte order around in Mugena, recompiled it, and reran it, and then that solved that issue. I didn't have to ask it to solve that issue. Like, did it. It figured that out on its own and then just recompiled this Magena, reloaded it, fired it back up again. After that, it was working. There was some weirdness with the PSU. It wasn't properly
[00:56:39] Unknown:
spinning up the PSU, so I did have to interact with it a little bit there to tell it what was going on when the hash board wouldn't turn on at first and it just forgot to signal to the PSU to turn on. But other than that, was it was working. It was like seventeen minutes to get Oh it my gosh. Running. So like This is amazing. Yeah. We gotta I I I wanna figure out how to do this if you don't have Secure Boot cracked already because that's kind of where we're at with all the What's Minor machines. Really? Just because there's not a lot of aftermarket firmware support for them. People haven't spent the time to crack Secure Boot. But Yeah. For all the machines that do have aftermarket firmwares, brains or luxOS, it sounds like this strategy is quick
[00:57:18] Unknown:
and completely unlocks the machine. It's unreal, isn't it, Iko? It's amazing hearing this. It's like life comes at you really fast because it just, it wasn't that long ago where your firmware options for a miner were very limited. And it's just the threshold to be able to do what you want with your own hardware that you own. That threshold is continually getting pushed lower and lower. And it's, I love to see it. It's just, it's amazing. It's, I'm a very big proponent for it's your hardware, it should be your rules, not the manufacturer's rules and breaking that hardware free and using these AI tools to do it in like very short durations of time. It's just it's mind blowing and
[00:58:03] Unknown:
I think it's great. So excellent work. Yeah. I'm super bullish on open source for this reason. Like anyone can contribute now. If you can write a prompt, you can contribute. And that means, like, there is no moat in software anymore or really firmware. Right? Like, there it's just gone. Once once a thing is open sourced, it's this is gonna get ported to every machine instantly.
[00:58:27] Unknown:
Like, anyone that wants this to run on their bespoke machine, it's it's one prompt and, like, twenty minutes of watching the thing work, and then it's running. And even if you try to keep your special sauce via closed source software, reverse engineering these AI tools are getting so good at it. I saw this week that someone reverse engineered the Google Fitbit software so you don't need your subscription and your data is not going to Google and so now your little health wearable just reports your data locally, builds a dashboard on your laptop. Same goes for firmware on machines, on miners. It does seem like a silly hill to die on, right?
Build your moat around whatever quality hardware or good customer support and services. Exactly. Not code.
[00:59:11] Unknown:
I do think it's gonna be a really interesting challenge going forward for maintainers of open source projects because because the barrier is so low. Now, literally anyone can submit a PR for something they want. Know Ryan's That may or may not be a good idea. It's Yeah. Ryan's had some really good ideas on this front and I'm excited to see how those work. He's willing to try stuff as well. Well, highlights the importance
[00:59:36] Unknown:
of a maintainer as well. Because if everyone can vibe code whatever hack job solution to their unique specific problem, that doesn't necessarily mean it was architected properly into the original code base for a merge so that they can be distributed to everyone else. So, I do agree. Like, the maintainers of open source projects have a lot of lift in front of them. Yeah. He's had some good ideas too with using
[01:00:01] Unknown:
agents. Md files in the repo in order to if someone downloads the repo and starts hacking on it, the the context is there to guide those agents into producing better architectures that fit with the rest the goals of the rest of the project. Yeah. And I think you'll get much better contributions that way. So I'm excited to see where that goes too. Incredible. Well, anything else you wanted to hit on here? It's awesome to see the Vibe Coding open source firmware onto closed source miners. I encourage all of our listeners to go try that. I still need to try it myself. So thanks for replying some tips and tricks that are on the forum, as I said. And gridpool.net,
[01:00:38] Unknown:
amazing to see. Hopefully, can get some folks to spin up some gridpool nodes and contribute feedback to the code base and point some hash rate too to start testing this out. Yeah. Thank you. Thank you guys for your time and for
[01:00:50] Unknown:
bringing me down. I'll keep you guys updated with where it goes and what we need next. I think that covered pretty much everything. Anything else for you, Ico? Well, just to bring it full circle, I think the more
[01:01:03] Unknown:
eyes and participants we have, the resources we have, these open source resources and trying different things and making new attempts, applying new ideas with the end goal in mind of helping decentralized Bitcoin mining. That's the ultimate goal and it is going to take a lot of different people trying a lot of different things, different payout methods, different accounting methods. And I think what you've done here is amazing. I love that you're keeping it in the open source ethos and I just encourage anyone who's curious to just get started. It's never been easier to get started with this stuff.
The open source resources we have today are just, we've come light years in a very short duration of time as in regards to Bitcoin mining firmware and pool software and what's capable. I mean, it wasn't that long ago that it was next to impossible for a person like me who doesn't have any coding experience to mine to my own node, Like in 2021, 2022, like that was next to impossible for a non developer to be able to do. Fast forward, here we are four, three years later. I mean, just look at what we're talking about. Like you have an AI agent in twenty minutes taking control of your miner and putting new firmware on it. And it's just, it's incredible. I mean, the innovation that's happened is
[01:02:31] Unknown:
happening at a very rapid pace. So, so hop on board and give it a shot. I mean, it's, it's never been easier. That was a beautiful way to wrap up. And I thought of one last critical piece of grid pool that I wanted to say. I'm sorry. That was like, that was a really good way to wrap up. I should have just ended it. Okay. Censorship resistance. When grid pool nodes take these shares and they pass them around the network, they only include the bare minimum to be able to verify that the thing is consensus valid with GridPool. We don't share the full set of transactions.
We're only sharing the Merkle leaf and the the minimum to be able to verify if they had the correct Coinbase payout. What this means is that no one can censor you on grid pool for including the wrong transactions. So the the pool is designed to be a 100 censorship resistant sort of at the at the foundation level.
[01:03:25] Unknown:
Alright. That's awesome. Wanted to close on that. So No. And I'm glad you said that because it's you know, that's one of the the primary concerns on a on a completely transparent ledger is that they can see what's in the mempool. Anyone can see what's in the mempool and they can they can tell you, you know, this is here's an arbitrary list of transactions that you're not allowed to include or addresses that you have to blacklist. And if the miners can't see what transactions are included,
[01:03:54] Unknown:
then that problem in theory goes away. Right? In theory. Yep. Alright. Thanks for letting me sneak in that final bit. We freeze. Tyler, you looked like you're gonna say something. Well, I think he is. You're back. You froze for a minute. We didn't hear anything you said. I'm here. Thanks for letting me sneak in that final bit of
[01:04:11] Unknown:
knowledge. Most certainly we'll have to have you back on in the coming months to hear some progress updates as we get more people to take a peek at it and try it out. I'm really eager to follow along with the progress of this project. Thank you, guys. Definitely. Thank you. I'm going to wrap the show up there, so don't hang up, but we're going to end the recording now. Thanks guys. See you everyone. Thanks.
