Bitcoin Forum

I'm in the process of setting up a new mining pool and will begin testing BTC mining tonight.
I'm renting hashpower via miningrigrentals, but don't have enough to rent more than ~300TH.

I wanted to ask this forum if there is any miners willing to help me mine in the coming 12 hours, so there is a theoretical chance that we will solve even a single block.

Pool supports AsicBoost and fee is 2%. If you want to help add these configurations to your mining setup:

'-a sha256 -o stratum+tcp://stratum.fortunapool.com:3333 -u <YOUR WALLET ADDRESS> -p x'

Please help spread the word to as many people as possible to test the pool properly before making an official launch.

If you find any bugs, or have any feedback you can leave a comment down below!

Thanks guys!

solo? pps? pplns?

what type of pool is it?

If you can't afford to rent enough hashrate to test your pool, then that's a problem to begin with, to find a block in the next 12 hours you will need 2EH worth of power, the current rate on NH is about 15.8BTC per EH per day, so for 2EH and 12 hours that is exactly 15.8btc or $135,880, no way on the planet you are going to get that much hashrate while testing the pool.

Another ugly fact, since you mentioned fees of 2% it means it's not a PPS pool, and it's highly unlikely that anyone will mine on a small PPLNS block unless you would give them more than what the network would pay them, which you don't seem to be able to afford, now if you were to go PPS, then you will need a ton of BTC in reserve, which you don't have judging by what you wrote.

I am sorry if I sound mean, I am not, I am trying to tell you the facts the way they are. sorry.

i would suggest pool testing on smaller coins where difficulty is not so much, for example: DGB or LCC with just 300M diff.

Testnet diff should be low enough to mine with small hashrate.

Just remember that testing in low diff does not test the requirements of the code to properly handle the 64 bit math needed to handle current blocks.

This was a common problem with proxy writers a number of years ago, where their code did not handle, in all steps of the process, more than 32 bits of data.
e.g. the MANY lost blocks (over 20) on slush, in Dec-2015, were caused by this.

Part of my pool testing of miners, as suggested by organofcorti back when the slush issue happened, is to make sure miners are submitting shares higher than 32 bits within the realms of expected probability.
It's a much lower target than a full block, so occurs WAY more often than a block of course, and thus easy for a pool to detect.

It's not a be all and end all test, but certainly closer to knowing your code does work for bitcoin blocks.

Be wary of armchair experts ...