jungly

jungly's avatar
jungly
npub1x0yw...9t7k
Rebooting P2Pool: https://github.com/pool2win/p2pool-v2
Some more testing of our stratum server today. Realised our starting difficulty was too low. Fixed that. Thanks to the tester today who spent an hour on our matrix chat patiently waiting while the starting difficulty issue was discovered. Our matrix room We are tying some loose ends on the difficulty adjustment algorithm. Aiming to sort this out over the next couple of days. Then PPLNS!! #hydrapool #p2pool
If you want to make profit, build a centralised service. The corollary is the fun thing: If you are building a centralised service, you will need to make a profit. The corollary is true because you need cap ex to maintain and secure a centralised service. I am thinking of mining pools when I am thinking of such services.
Every machine has had the same history – a long record of sleepless nights and of poverty, of disillusions and of joys, of partial improvements discovered by several generations of nameless workers, who have added to the original invention these little nothings, without which the most fertile idea would remain fruitless. More than that: every new invention is a synthesis, the resultant of innumerable inventions which have preceded it in the vast field of mechanics and industry. The author might as well be talking about #FOSS. But I think he's talking about all machinery, all software!
We have a new stratum server implementation in Rust over at P2Poolv2. Here's why: 1. CKPool is great, but it's complicated and it's written in C.. It is very hard to extend or change. I tried as part of hydrapool effort for 256 Foundation telehash. We ran into issues at load with our changes. Enough to tell me, we need something easier to maintain and extend. 2. C doesn't make it easy to use async programming model where a core is freed while a thread waits for IO. You can do it, but the code gets complicated quick. We wanted to use modern tools like Rust's async/await so we can maintain and extend the server in future. 3. DATUM is again in C. On top of that it's tied to Ocean's model of block template protocols that we don't need in hydrapool or P2Poolv2. Messing with C or to forking the project wasn't a road we wanted to go down on. 4. SV2. This was the closest to our plans and we first tried to use the SV1 components for our user case. However, the code base was more complicated than we expected. There's good reasons for it, SV2 is opinionated to serve the SV2 model and it kind of created issues for us as we wanted to just use the SV1 parts of it. @plebhash and @gitgabe helped a lot, but in the end I took the opportunity to just dive in and write our own. ## So where are we now? We have the server working. It replicates the CKPool behaviour as closely as possible. We have tested with cpuminer and bitaxes. ## Next steps: We are running some load tests to compare our implementation to CKPool. Results coming soon. We need to test our implementation with variety of firmware. ## How can you help? You can help us test by pointing a machine for 5 minutes. That's all we need. We'll log the interaction and if there's any failures we can fix it using the logs. We will set something up soon and invite testers. BTW, initial load tests are showing we are competitive with CKPool. Rust can be fast! πŸš€πŸš€ The repo is here: Stratum server is under the startum crate. Just want to add that building stratum server has directly informed how we want to disseminate block templates and shares on P2Poolv2. That's another post though.
Rust makes it very easy to write code that will be very hard to understand by someone else, including your future self. One responsibility we have as rust programmers is to write code that'll be easy to understand. Think before you write the prompt! Think about what the AI gave you, then have a cup of tea and think some more.
CTV on its own is not the solution P2poolv2 is looking for. It doesn't help in reducing in chain foot print that much and requires miners to exchange extra on chain information. 1. We need log n outputs to create a ctv tree of outputs. 2. When a miner spends his output, it needs to have the rest of the outputs of its siblings as other unspent outputs. The siblings then need to watch the chain to see which utxo they can spend and each utxo spend uses more on chain space as ctv outputs for siblings to spend. All the of the above is complex and still eats block chain space like a monster. Meh. We need something better. As an MVP, p2poolv2 is using simple atomic swaps between sharechain with transactions and BTC. #p2pool