Open Bitcoin Challenge Mining Pool

Hey folks, I've been putting together this public mining pool aimed at getting a community together to tackle some Bitcoin challenge puzzles. The idea is to keep everything as transparent as possible while ensuring the private key stays safe from any potential misuse if someone cracks the solution. Just a heads up, because of this, the client and server software will have to stay closed source since we can't avoid using the actual private key hex values. I’ve got a functioning client/server setup that hands out work to clients randomly based on the current puzzle. The server adjusts what each client gets so they can wrap up their tasks in about a minute, then send back the results and get a fresh chunk of work. This keeps things running smoothly and efficiently in the pool. The system's up and running, but I’m really keen to hear what everyone thinks. Any suggestions for boosting security or improving how the pool works would be awesome. I'm especially interested in ideas for making the process more transparent, safeguarding the private key, and building trust among participants. Right now, I haven’t built a web interface since my main focus has been on the core client and server software. But the client does provide updates on miner stats, estimated BTC payouts if we find a solution right now, and the total search range the pool has tackled. The client is a tweaked version of the KeyHunt software, which was pretty easy to modify for adding the pool features.

** Reserved **

Nice Work. Willing to include

Why are you calling it a "mining" pool? It is a pool but there is no mining, it is just solving a "puzzle" which is not "the Bitcoin Challenge" as you put it. This is just a puzzle or rather a brute forcing game. Also Project Development board is a more appropriate place to post these things (there is a move topic button at the bottom of the page).

It is technically a "de-mining" pool. You are trying to find lost bitcoins that have already been mined, transfer them out as quickly as possible, and construct your signing transaction properly so that some bots can't just fee-snipe your transaction and make it all go to miners as a transaction fee. Although I think, this particular pool only supports address mode.

If you are unaware of the Bitcoin Challenge Puzzles, there is a lot of information about it in this thread. https://bitcointalk.org/index.php?topic=1306983.0 and some basic details here https://privatekeys.pw/puzzles/bitcoin-puzzle-tx I changed the name so it is more appropriate to the task Yes it is just the brute forcing game, and if we all sit and individually brute force the full range in the next 6,000 or so years one of us might get lucky and find it alone.

I have released the first set of compiled clients if anyone is interested in trying and contributing to the testing. https://github.com/jrharp/challengepool.net/releases/tag/v1.0 There is a link to the discord there if anyone has issues, thoughts or suggestions.

How and why should someone trust you to install and run black-box software and believe that your server component does its magic correct, fair and reliable? Your account woke up after little less than six years of no posting in the forum. Hmm... My first impulse was: your justification to remain closed-source is bullshit, but after thinking a bit about it, I see the problem that you need to hide and obscure how client and server communicate work and work done to avoid malicious fake work which would also spoil your database of successfully scanned regions. For obvious reasons it doesn't make much sense for a malicious client to fake work done on submitted regions to be scanned but who says that malicious actors always play by good reasoning. Let's assume a malicious actor has reverse-engineered your client and sabotages your project by responding with fake work done for his scan regions. This would spoil your database of unsuccessful regions done which may lead to never finding a solution for a puzzle. Or worse, the altered client could be lucky to find a solution and claim the withdrawal via slipstream.mara.com for its own, while reporting back to your server an unsuccessful scan of the region, faking no solution found to your server. This would give the malicious actor time until slipstream.mara.com confirms this own transaction. How do you ensure that your unsuccessful (scanned but no solution found) regions database is protected by any means from corruption, loss or anything that would spoil a thorough exhaustive search of a puzzle's private key range? The avoidance of curruption or loss is crucial for such a distributed work scenario! Bad for transparency is also that nobody can check if your server component can construct the withdrawal transaction for slipstream.mara.com in a fair and correct way. Here I suggest that your server at least publishes a "solution found" notification to all clients with a SHA-256 or SHA-384 or SHA-512 hash of the transaction immediately when submitted to slipstream.mara.com, including a timestamp of submission. This way you document and show proof that and what your server has submitted to slipstream.mara.com. Not only it isn't guaranteed that slipstream.mara.com will completely automatically process your transaction but also it will take time for Mara pool to find an own block which should include the non-public transaction. Everybody has to trust slipstream.mara.com to act trustworthy and not benefit somehow on their own to steal a puzzle. You can't reliably check if a concurrent puzzle withdrawal was maliciously done by slipstream.mara.com or someone else who got lucky to find a puzzle's solution.

I'm pretty new to this forum. Are there still unsolved bitcoin challenge puzzles? Where can I read more about them?

This is about one of the oldest "puzzles" on bitcointalk that takes an increasing amount of computing power to solve the subsequent cases or better said to brute force them. You can find the original topic and related discussions here: https://bitcointalk.org/index.php?topic=1306983.0

There are at least 3 public pools that I know of that have already completed a decent amount of ranges, for the 67 challenge / puzzle. I think one is near 4.5-5% (1.4 - 2 million, 41 bit ranges) complete. Each has their own website and an abundance of information. Why are you adjusting / limiting the time for range completion, at 60 seconds?

My layman opinion is that the pools should coordinate each other to at least share the ranges that have already been explored and are empty, so that nobody is waiting for years trying to find those keys while they brute-force the same ranges. Then again, that doesn't seem to be a problem, at least not for whoever found #64, #66, and all of those puzzles with public keys.

One is a solo pool, but once a range is completed by one person, it marks it off for everybody. The other 2 that are shared, use encryption for the ranges. I think the one may know which ranges have been searched, but the other one 100% does not. That was implemented to prevent anyone from spoofing and gathering ranges that haven't been ran yet (including those who have server side access, like admin). I'm not sure why anyone still runs the one pool, as it has duped members before, and will dupe them again lol. I just hope the other shared pool, finds the key this time. It would be best to just have one pool, that has shared and solo setups. I thought about creating one, but other things came up. If you have ever mined, say on 2miners, you have the option of solo or shared. Same concept with this pool, but all ranges completed are marked as searched, regardless if you are hashing for shared or solo. Basically use a -solo flag, or a different port, or something like that.

I am quite happy to share portions of the server code for external validation / improvements.  The problems of the clients (all clients must be considered to be untrusted) I don't really have a bullet proof solution to the problems and am happy to explore options that other people might think of to make it less practical for a client to skim the private key from the pool.  I am happy to add notifications to the workers if a solution is submitted, this is not a difficult thing to adjust in the programs.   The pool checks the balance of the target puzzle address every couple of minutes to confirm that the prize is still in the account.  It has not been implemented yet that if the balance goes to 0 that we shift to the next puzzle.  We would do that if a valid solution was submitted to the pool. I have considered a number of different options of masking / encryption of the search block, however in the end the clients must run the address check with the actual private key hex or they will never return any correct solutions.  In order for that to happen they need to be sent the information that is required to decrypt / unmask the value and are left with the raw hex anyway.  If anyone has any techniques that they think would be assistance to this problem it would be worth exploring. There are a number of things that I would be more then happy to adjust / improve if there is sufficient interest in pursuing the pool.  The share system right now is setup as a proportional share system, each client that completes 1 work increment (WORK_INCREMENT = 10,000,000,000 private keys) gets 1 share.  The current calculation allocates shares to each puzzle independently so if puzzle 67 is solved, shares are logged for 67 and a new count starts for 68.  I do see the merit in carrying over shares if the solution is found by a different party as it would still reward any workers for past work and only reset if the pool finds a solution. The logic for the 60 second work increment is so that it is easer to track progress / update searched ranges / return non responsive work back to the pool. The work is being distributed in a weighted random selection search method.  The basis is that it will try and break up larger unsearched areas into smaller and smaller ranges.  Once the ranges get to be smaller then the requested search size the pool will start returning the smaller ranges to close gaps between completed work.  This process seemed to work well in testing with the easier puzzles. This is the function that does the work assignments, yes I am just using SQLite for the time being as I am the only client, this will be migrated to a different database if/when the need arise. In regards to the solo vs pool, I cannot understand the logic of a solo pool that uses work from other workers?  Its like saying I want to use the pool work but I get the full reward if I am the lucky one to find the key.  A larger reward for the lucky person would make more sense if that was what people are looking for.

I have put together a basic webpage to view the current pool stats as well as lookup your workers via the bitcoin address https://www.challengepool.net/

Thanks I followed your Project on Github, I should be able to try the client out later today.

I've been working on updating the website whenever I get a chance, and I'm excited to announce a new update to the client code! The client is now built to support CCAP version 10.0, which I anticipate will be fully compatible with the upcoming RTX 50 series upon release. Website: https://www.challengepool.net/  Join the discussion on Discord: https://discord.gg/ryD8tChjt7

Oh no... Not another pool... What about 5th pool for RCKangaroo to solve 135?

If anyone is interested, I finally found access to a 5080 and 5090 for speed testing. Looks like the 5080 is about 3,850 Mk/s and the 5090 is about 6,650 Mk/s Comparing to a 4090 at about 4,500 Mk/s its about a 47% increase in KeyHunt. I haven't tried other grid sizes, but both are only using about 50% of the VRAM with the auto grid.

A 4090, at the minimum should get 6,000 MK/s, if not, you need to really optimize your code. Current tests on 5090 put it at almost 9,000 MK/s, but code will need further optimized to take advantage of the new series.