Topic: [Guide] Solo mine testnet bitcoins with bfgminer, Bitcoin Core, and a CPU/GPU (Read 1439 times)

Of course it will repeat on testnet4. But, as I said in another topic, the solution is to improve the code in your Bitcoin Core node, not in your mining equipment. Think about it, and use proper rules, to always work on blocks with minimal difficulty.

Of course it doesn't make any sense. However, as long as testnet rules are quite close to mainnet ones (in both: testnet3 and testnet4), those coins are doomed to get some value over time. And then, it is all about having enough support for more frequent resets.

It is already possible. There are quite frequent block reorgs, but besides that, it works even on testnet3.

There already is a max difficulty, but nobody reached it yet, even on mainnet. Each hash is just a 256-bit number, and if you create SHA-256 hash of almost all zeroes, then you will reach the max.

This one we have as well, currently set into year 2106 or year 2038, depending on Bitcoin Core version (some of them are buggy).

Well, if you reset things more often than every four years, then you have no chance to test any halvings, and then you can permanently set basic block reward into 50 tBTC.

We already have something like that in signet: anyone can just pick a new signet challenge, and it will start a brand new network. And if you pick OP_TRUE, then it is more or less the same as testnet4, but without 20 minute block rule.

Makes you wonder if a very minor change (yeah I know there is no such thing as a minor change) but setting a max difficulty in testnet and known EOL would help.
So yeah mine all you want with whatever ASIC you have as of Jan 1 2025 testnet 4 is going to become testnet 5 and Jan 1 2026 testnet 5 goes away and becomes testnet
And so on.

It's not like the old testnets will stop working just new ones will start.

Not going to happen and there are probably 100s of reasons why it's not a good idea but it's at least a thought.

-Dave

It seems that one or more entities already throw some spare ASICs to mine in Testnet4, hell, for whatever reasons. It takes just one to force others to follow that path and leave everybody else without ASICs behind. Anyway, in a trustless PoW scenario miners can do what they're are able to with their gear, you can't control that. Why wouldn't history of Testnet3 repeat in Testnet4?

Does it make sense to drive difficulty up to levels where only few dare to waste money for energy for a worthless-by-design-and-intention coin like tBTC? I don't think so.

It would be more fun for participants to be able to mine Testnet4 with CPU cycles in a truely decentralized fashion. But that's not gonna work with human mindsets unfortunately. Only if we had an ASIC-resistant hashing algorithm for Testnet4, but then Testnet4 would diverge from Mainnet too much.

Hi, mining on testnet4 worked for me with bfgminer and a bitcoin core testnet4 node, compiled as mentioned in this thread:


and with this .config:


The difficulty is already too high tough that it would make sense to mine on a CPU/GPU.

hi guys,

have u guys tried to mine bitcoin on testnet4?

Since openssl is a dependency, I suppose it already uses that. Furthermore, this isn't nullama's software. I'm pretty sure it was first released (and maintained - last commit in '21) by Luke Dashjr ^[1-2].

[1] https://github.com/luke-jr/bfgminer/
[2] https://en.bitcoin.it/wiki/BFGMiner

I ran it like suggested by nullama just for benchmarking:

16/02/2023

RX6600 (bfgminer):

RX6700XT (cgminer):

I would enjoy seeing what a 4090 can achieve

When you use the benchmark option the difficulty by default is 1. It doesn't connect to any network.

Did you create your own Fork that stays on difficulty 1?

if there's demand now what's really needed is instructions for cpu with AES support. for sure regular sha256() ,openssl, with hardware aes turned on there , is faster than yours now.

That's good to know. How about compiling a list of modern desktop hardware just for fun? Then it could be added to ^[1] the Bitcoin Wiki, which as of now only has very old hardware listed.
I think it would be good to post at least a console output from bfgminer as proof.

[1] https://en.bitcoin.it/wiki/Mining_Hardware_Comparison

---

Very odd. I quickly logged into a VM of mine with 7 cores (underlying CPU is pretty new Intel model boosting to almost 5GHz); the benchmark only results in ~20MH/s (probably due to virtualization), yet still I got an accepted hash after 7 minutes, another 3 minutes later and another one minute later.


I will test on bare-metal hardware with Bitcoin Core on the weekend, as mentioned before. Maybe there is hope for Loyce's 7MH/s second machine (although it makes no sense on paper - even getting accepted hashes that fast with 20MH/s...).

SSE is not supported in an ARM device like the M1.


That's per core, the M1 has 8 cores.

In an Intel CPU:


That's per core, the CPU had 20 cores. Also, I've seen the sse4_64 algo being the fastest at other times in the same CPU.

Note that this is bfgminer, with CPU. This is not supposed to have the latest CPU optimizations enabled as it's not used for that in years, maybe a decade or more.

did you use sse at least? say sse3.1 have some stuff for that. avx too

For comparison purposes a single RX 6600 achieves 1500Mh/s in cgminer/bfgminer

CPU mining absolutely works for testnet with relatively new devices.

Just did a quick benchmark with bfgminer on a mac mini M1(2020 device) with CPU only(you can also use OpenCL to use the GPU), and in less than 5 minutes I got 2 shares over Diff 1:


You can see that it is absolutely possible to find a block when Diff is 1 with a CPU. It's just that it's way less probable than with an ASIC.

If you want to test a device without having to setup a local Bitcoin Core, you can do this:


Also, notice the M1 hashrate hovering around 20Mh/s or so. It should be higher than that because I did the benchmark while using the device at 100% for other intensive tasks that I didn't want to stop.

I think many folks here share this sentiment.

Sure, but if you have it already and need a bunch of testnet BTC, it should work nicely. I will try on the weekend with some modern desktop general-purpose hardware that I can access. I was surprised to see a >100MH/s hashrate on CPUs, since yours only managed single digits. Therefore, I was about to call this guide half-failed (the CPU part), but those benchmarks give me hope.

Don't remind me I should have done that when I first read about Bitcoin, which was years before I joined Bitcointalk.

It's old indeed, but works very well for it's task: pushing bytes to the outside world.
This Xeon CPU is already faster in finding Bitcoin vanity addresses than my laptop GPU.

Buying a CPU just for hashing is a waste of money (and electricity). That's 95W that could be used for better things.

The 10 minute figure is correct:


Indeed, yes. The whole network hash rate in the beginning of 2009 was relatively stable around 4-5MH/s ^[1]. A new CPU from Q1 2009 like the Intel Pentium E5400 ^[2] was already able to output about 2.2MH/s ^[3], so there were literally just 2 CPUs on the whole network for almost a year back then. It somewhat surprises me that more people did not spin up a rig just for fun, but on the other hand the coin was worthless and energy & hardware did cost something.

[1] https://www.coinwarz.com/mining/bitcoin/hashrate-chart/2009
[2] https://ark.intel.com/content/www/us/en/ark/products/40478/intel-pentium-processor-e5400-2m-cache-2-70-ghz-800-mhz-fsb.html
[3] https://bitcointalksearch.org/topic/hash-rate-cpu-comparison-table-1628

---

@LoyceV, after browsing a bit online, it seems like there are modern CPUs now that can compete with something like ETFBitcoin's 100MH/s GPU.
It's just that your CPU is old.. old old..


From 2011 to 2023, well, things changed. An i9-9900K from Q4 2018 even manages over 100MH/s, it seems like. ^[4]
I will verify with some relatively modern Desktop hardware, later myself directly with bfgminer and report back.

Sadly, @nullama's assumption (I guess he assumed that, like myself?) that difficulty=1 means an immediate hit on any hardware, was wrong. However, with a modern computer you should definitely get something, if you have a few hundred MH/s.

[4] https://forum.level1techs.com/t/whats-the-fastest-processor-for-single-threaded-single-process-of-running-sha256sum/157464?page=3

In a way it makes sense: mining on one computer produces one block per 10 minutes. That sounds exactly like the beginning of Bitcoin.

To conclude this: I give up After wasting another week of CPU time without finding a block, I wiped the testnet installation. Using a testnet faucet is much faster if you need some.

Indeed, that's a pity. @nullama may want to edit the original post / title and include the calculations I posted.
It seems that CPUs are too weak even for difficulty=1, and even GPUs may struggle.

An old 1GH/s USB mining stick would take 4 whole seconds to mine a block and a 200MH/s graphics card takes 20 seconds. That's really stretching it, if you ask me, as ASIC miners will have a 20 second head start.

Yeah, that should definitely be possible. Although I don't think it's advised to heat cycle hardware a lot, so maybe it's worth modifying cgminer to monitor the testnet blockchain and switch over whenever the last block approaches 20 min old. The ASIC doesn't care; it just hashes whatever it's given. But that way it stays hot and mines actually valuable BTC whenever the difficulty on testnet is higher than 1.

On the other hand, old / weaker ASICs make you such few sats per day that it's almost not worth the hassle to set this up. I'd just leave Compac F sticks on testnet for a day if I need tBTC and rest of the time on solo pool.

It looks like he used his GPU:

It also looks like my CPU mining is utterly useless I'll give it another week, then I'll wipe it.

For ASICs owners like yourself: would it be possible to only turn it on when the difficulty is 1? Or use it for something else, and then switch to testnet mining when the last block was for instance 19 minutes and 50 seconds ago?

You may be up to something. I don't know why, but I assumed that difficulty=1 meant the hash just had to be smaller than 2²⁵⁶-1.
This is where I was wrong:

Actually, if we use this formula, it appears that with difficulty=1, you need on average 4295032833 or ~4.3GH to find a valid one. So on a 7MH/s machine, that's 613 seconds or 10 minutes. Impossible..


But on the other hand, it can't be right since people here did succeed with CPUs. What if the article is outdated / wrong?

If we work with the figure of 7MH for 1 valid hash, it would mean the minimum network hashrate must have always been over 11.6kH/s; otherwise it wouldn't be possible to mine a block in 10 minutes (11,600*600 ≈ 7,000,000). That seems realistic for 2009. According to the blockchain ^[1], it was in the single-digit Megahash range all the way back in 2009.

Do we know @ETFbitcoin 's hash rate?

^[1] https://www.coinwarz.com/mining/bitcoin/hashrate-chart/2009

---

Quickly using the same formula for a single Compac F, it becomes clear it has much better chances:

With just 300GH/s and difficulty=1, it only takes it 0.0143s to go through those 7 million hashes.
This would also mean that the formula expecting @LoyceV's CPU to take on average 10 minutes, is correct.

It sounds like this could be the reason it doesn't mine any blocks: if it never knows the difficulty is low, it won't find a block at low difficulty.
From your screenshot:
I'm starting to think difficulty=1 doesn't mean it takes picoseconds to mine a block:
That would explain why ASICs still beat any CPU miner as it would take me about a second, while it takes the ASICs a fraction of a millisecond.

With log, I mean the bfgminer log output as shown here.



I am wondering whether it logs / shows whether it found a block at diff 1 here.
Trying to work out whether the software even realizes that 20 minutes have passed, reduces the difficulty to 1, hashes a block candidate and tries to submit it or whether this all doesn't even happen.

Even just seeing how a successfully mined block is shown in this log, would help, since I can only reference my experience with cgminer whose output looks very different.

Did you monitor your CPU miner a bit? I just catched an instance where the last block was 20 minutes ago and bfgminer never adjusted the difficulty setting from its '125M' value. Does it take a bit longer to adjust or what is the cause? Or is it just not reflected in the user interface? I expected it to drop to 1 as soon as the 20 minute mark passed, even if it may not end up being first at submitting something to the network. But it simply didn't budge.



This is Loyce's machine with 7 threads hashing and 1 core free to submit a block quickly.

---

One thing I just realized is that in the screenshot, the I value (BTC per hour) is set to a question mark. So maybe it did quickly submit a block candidate and was waiting to see if it got accepted by the network? Can you post a log screenshot of what it looks like when bfgminer finds a valid block (whether it is accepted by the network or not - you mention 2 stale blocks)?

This is good question. On Bitcoin Wiki, 20 minutes only mentioned since early 2013[1]. But afterwards i found out Gavin Andresen propose this[2] and create pull request some time later[3].


Mining difficulty on testnet keep rising which discourage some people to perform mining, where people with CPU/GPU only expect to earn tBTC from 1 difficulty after 20 minutes.


Probably because now we have separate testing network dedicated for newer Bitcoin feature (e.g. signet and segnet) and in past people attempt to attack/stress Bitcoin testnet by mining with tons of ASIC.

---

[1] https://en.bitcoin.it/w/index.php?title=Testnet&oldid=35502
[2] https://bitcointalksearch.org/topic/m.627957
[3] https://github.com/bitcoin/bitcoin/pull/686

Who decides on those 20 minutes anyway? In Bitcoin, there's no need for exact timestamps. Is this different in testnet?
I checked a few of the latest testnet blocks, and found times between blocks of:
2418404 > 2418405: 20 minutes and 3 seconds.
2418410 > 2418411: 20 minutes and 5 seconds.
2418407 > 2418408: 20 minutes and 8 seconds.

I checked the last 2 days, and to my surprise only 115 blocks per day get mined. I'm surprised because the total block height is much higher than for Bitcoin. I'm also surprised that several people here have mined several blocks per day at difficulty 1, which means that only a few dozen people can do that per day. I'd expect much more people to be mining testnet.

Rough numbers: At 300GH/s and difficulty of 1, I should in theory mine one valid block in 3ps (picoseconds), meanwhile at 6MH/s it would take 166ns (nanoseconds).
However, in a difficulty=1 scenario, the difference of 165997ps should make no difference at all. Network latency to other nodes will probably be in the single to double-digit ms range. For reference: 1ms (which is a really good network latency) are a million ns.

There is a chance that your CPU is overloaded with all cores mining and no core ready to push that packet out to the network asap. Another idea would be making sure that this old CPU miner code doesn't wait for e.g. a whole set of nonce values before returning a valid block or something silly like that. It should return as soon as a block meets the difficulty, but I wouldn't rule out that it waits longer for whatever (legacy?) reason.

I will definitely have a look at your bfgminer config and the bfgminer code, too.

I killed it after a week. I started it again (this morning), and gave n0nce access. Let's see if I missed something.

It's been 4 days, and at 6.33Mh/s, I haven't found a single block. Maybe I did something wrong, or maybe CPU mining is still too slow even when the difficulty is 1. Either way, I gave up for now, and killed the miner. It seems like a waste of CPU. I'll keep Bitcoin Core Testnet running for a while.

hey OP, this works:


...for cgminer usage on AMD GPU - valid 22 december 2022

Also, I've noticed that bfgminer isn't creating proof with more than 8 zeros.

Is there a way to modify so it creates proof with more than 8 zeros?

example:

Proof: 0000000074f7267c7ed96843de88967a43728be514fee31a6b5dc623bb688291
Target: 00000000000000000007f5900000000000000000000000000000000000000000
TrgVal? no (false positive; hash > target)


I looked in bfgminer/miner.c but couldn't manage to change anything to create 19 leading zero proof

Thanks for the tutorial, I'm mining Testnet now! It's CPU only, on a server. Let's see if it catches a block.

The only problem I ran into was at this step:
The error came down to this:
And the solution was easy:

Thank you, but I did that deliberately. I was pointed to this thread from  https://bitcointalksearch.org/topic/what-is-a-good-reference-for-a-getblocktemplate-based-solo-miner-5418942 entitled What is a good reference for a getblocktemplate based solo miner. Hence I was expecting bfgminer could serve that purpose, which does not seem to be the case. But on the other hand it appears that cpuminer might serve the purpose.

You're running bfgminer with different options than what I wrote here. Check those first.

In particular, you're disabling getwork and stratum connectivity:

Try running it without those options

I tried to repeat the procedure, but I ran into some issues.

Note that MYUSER, MYPASS and MYADDR are replaced by their actual values when running the below commands
I'm able to access the node using

So it seem to be able to connect, but if I try with bfgminer
 

While I'm running the above command I observe the following on the console of my node:

Running on the node itself it seem to connect:

Also running cpuminer from the remote computer on the LAN seem to work


Does this mean that cpuminer is working as expected while bfgminer does not. I will leave it running for a few days and see if I'm able to solve a block on the test network.

After almost 4 days, i managed to mine 4 blocks. But due to relative slow internet connection, 2 of them become stale. Overall it's good experience and i got about ~0.05 tBTC, which probably will be used to try few different OPCODES on scripting or simply donate it to tBTC faucet.

On a side note, on 3rd day i tried to mine only with 1 thread CPU since the goal to mine block with difficulty 1. But when i shutdown my PC, i got this error message with >100K occurrence. Quick search on google shows it's due continuous CPU usage for long time, although i'm not 100% sure it's due to bfgminer.

Yeah, I didn't mention it because I thought that was well known for the people reading the Development & Technical Discussion forum. It's basically for people that don't want to depend on faucets to test their projects. Once you know how to do it you can mine some testnet bitcoin for yourself overnight, even if there's no faucets available.

But you're right, it might be worth noting it for people that come here from the outside through a search or a link. Yes, testnet bitcoins are only useful for testing, they don't have any other value, and they can even disappear at any time. That's also why I didn't mention any kind of security for the wallet, because it doesn't matter.

You really should mention that by design the Testnet coins have ZERO monetary value. Purchase and sale of them is strongly discouraged as Testnet and its coins are for testing software -- not making money... Mining them and holding them is also pretty pointless because the Testnet chain is periodically forked to render previously mined Testnet coins unusable.

After a development project is over it is expected that all Testnet coins mined during testing are to be donated back to the Faucets.

Ah, yes, I mentioned it in the previous guide but forgot to mention it here again as bfgminer also expects a legacy address:


Good luck hitting some blocks with a CPU/GPU!, it worked for me but it's noticeably less frequent than using an ASIC, even a tiny USB one like the Compac F.

I managed to compile it after spending some time to find the name of the dependency on my OS. bfgminer doesn't support Bech32 address, but otherwise i didn't experience other problem.

I do not run my computer 24/7, so let's see how much block i mined after 3-7 days.

Following my previous guide about how to solo mine testnet bitcoins with an ASIC and cgminer I'm now presenting a guide on how to do the same but without the need of an ASIC. That means that you'll be able to mine testnet bitcoins with any computer that has a CPU and/or a GPU.

This should work on pretty much any laptop or desktop, even those with the new M1 chips from Apple. Of course the faster the CPU/GPU, the better chances you'll have to hit some blocks.

You might be wondering how is this even possible. The answer is that the difficulty in testnet3 reverts to 1 after 20 minutes have passed with no one finding a block. A difficulty of 1 is so low that any CPU or GPU is capable of hitting a block. Note that this was the difficulty of Bitcoin in the beginning(2009). More details about this can be read here: https://bitcoin.stackexchange.com/questions/18554/how-can-i-find-the-real-difficulty-on-testnet

OK, so let's make it happen. First, you need to setup Bitcoin Core in the same way as with the other guide. Here's a copy of it for simplicity:

Step 1: Install and run Bitcoin Core

We're going to use the folder ~/bitcoin_testnet to save everything so that it's easy to remove once you're done and to keep things simple. You can of course use a different path if you want.

Inside ~/bitcoin_testnet create a folder called data:


Download the Bitcoin Core for your platform into ~/bitcoin_testnet/ and extract it there.

Now let's prepare the configuration file. Create a text file named bitcoin_testnet.conf in ~/bitcoin_testnet/ and put these content in it:


The thing that you need to understand here is that you're setting up the Bitcoin node to run in testnet, and you're defining an RPC port(5000 in this case, can be anything), user and password, and whitelisting a specific IP to connect to your node(YOUR_MINER_IP). You'll need these details and your Bitcoin node IP later when connecting from bfgminer.

You can now start running your Bitcoin node by doing the following(make sure to change user to your actual user):


If you want, you can keep this running in the background with screen:


You can then see what's happening with:


To detach the screen, simply press Ctrl-A and then Ctrl-D. You'll be back in the console, and the command will continue running in the background.

Step 2: Install and run bfgminer

Since cgminer removed the CPU/GPU functionality a long time ago, we're going to use bfgminer. You need to compile it from source code to activate these features, so that's what we're going to do. First let's install some dependencies:


Now we're ready to get, configure, and make bfgminer with support for CPU and GPU mining. Also note that we need to update the git: sources to https: in the .gitmodules file, otherwise it won't work. I'm using sed here to do this, but you can of course do it manually if you prefer.


After it finished the build, you can now simply start mining your testnet bitcoins:


And that's it. Your computer should now be mining with the CPU and the GPU using OpenCL. Leave it overnight and you'll probably see some testnet bitcoins in your address.

Some questions you might have:

Q: Can I use only the GPU?

A: You can use one or the other instead of both by simply not adding it to the command (i.e. just use -S opencl:auto for GPU only or just use -S cpu:auto for CPU only).

Q: Why are there two(or more) pools in the dashboard?

A: If you are running another instance of Bitcoin Core in the local machine bfgminer will try to mine there as well. If you don't want that to happen, simply add --no-local-bitcoin to the command.

Q: Can I use a Raspberry Pi?

A: Actually yes, it should work with CPU mining, but extremely slow. You might get lucky though.