Requesting Testnet4 tBTC

[BlackHatCoiner]

Test coins are weird: some of them are free, some of them are burned.

Both the "free" and the "burned" link to the same transaction. I get that the coinbase reward is burned, because it is sent to OP_RETURN, but where are the free coins?

Of course, for CPU-based mining, some modifications are needed, but I think grinding coins with bitcoin-util should still be possible. I will think about some kind of such implementation.

What's the recommended way to mine testnet4 with CPU? Is it possible directly from Core with generatetoaddress? And, is there mining software for testnet that is configurable with GPUs?

[LoyceV]

Test coins are weird: some of them are free, some of them are burned.

Both the "free" and the "burned" link to the same transaction.

They have different txids:
"free": 8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf
"burned": c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf

[vjudeu]

Can you explain this one?

Those coins were sent to OP_TRUE. Which means, that anyone could sweep them, as it was done here: https://mempool.space/testnet4/tx/09096e1e6fb31f33f3de40b9a1d76908e565e9646e5aed4e0813e0a2a799fc4c

As you can see, no signatures were provided.

Similar case was in https://mempool.space/testnet4/tx/3a72c025a8995fe94af9ec00d61046f55fe18133ebb98f290f81aa68f3bc8fc1
The previous script was simply OP_TRUE, but that one was P2WSH, with OP_TRUE, which made it standard.

Both the "free" and the "burned" link to the same transaction.

Huh?

First link: https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf
Second link: https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf

They are different. But yes, those free coins are now taken, so you have to find something else.

What's the recommended way to mine testnet4 with CPU?

The easiest way is to make two small changes in the source code, and just recompile it. But there are also other ways.

Is it possible directly from Core with generatetoaddress?

Yes, if your Bitcoin Core implementation will always give you the block template, moved forward by 20 minutes.

And, is there mining software for testnet that is configurable with GPUs?

You have regular Bitcoin Core node. You can connect CPUs, GPUs, FPGAs, ASICs, whatever. The most difficult part is to get the block header, which has the minimal difficulty. For example, if you call "getblocktemplate", you should see this:

Code:

$ ./bitcoin-cli -testnet4 getblocktemplate '{"rules": ["segwit"]}'
{
  "capabilities": [
    "proposal"
  ],
  "version": 536870912,
  "rules": [
    "csv",
    "!segwit",
    "taproot"
  ],
  "vbavailable": {
  },
  "vbrequired": 0,
  "previousblockhash": "00000000000000308df706a8736dfe78eee7cea416adc1dc5bfcf4bc11202f6c",
  "transactions": [
    {
      "data": "020000000001047ce0d3213f28576ae83c57b920f4e20538d5e6d4e07ca488385aa0f1931e64110000000000fdffffff248aa47fdced15c751d2d300f1cb31ffef9d2f3a49215f6532104a1c78038f410100000000fdffffffb40af33649e7adf8e7efd2b1f01a2bee16ba1586b1a4e572b3c18f47d98f598e0000000000fdffffff2aad614089f83012a5975c807eb903fdb3ee83c843a6612186de6290c79520ce0100000000fdffffff02534d09000000000017a9145902315224c25891835b6821cd1cdc551de83238870e800a00000000001976a91498bde795388b03245d24953077dab58b24a7293488ac024730440220492f752d2b5ed7e0f0315ae1a6bd801488d88ffe340dfe9601b8918463bdfb0f022038a58690c81d4b071ac723936087af0317b2f226483e76b08c99ed7191ddef6d012102685699ed77f94e735d50f82eb4c11d40b864becb9743de95abf7ef8f29445d6c0247304402203704695217a419dce8c47cfa1bf206cf17f73a9c61b86b364f5b4c0c4371ddcb02207a2730ac55198033d4559a1ddf937f842c77e74026423d39a8441199fd8af57d012103be9522eaa49f32cd3eb559ea3c3187b3559043a720ceda1a215ac3405b40cce00247304402200b4e0ba529ad8c4568144fb081d3cb737b11af330fe03951d48787beef37761602201323dea016586094b45002a78dcceb4ad25eb48cf0341fd99727230648dc00da012103780699159f1a6f5242348bc8d61f58d3bd7b00c78a0d40fd7f2e57a178b379690247304402205fb3f7174e98b469d707246e3d62913066ae23bd17fc5429978500dd9508d009022049d2abcd23e3c78244b6cc9a8563ca783fda57d080b81ac4bd0af9359650418b012102d9e9ddd6c2ea0dc6c057a04e50e8d0915e9cd01c0e96b9502b04da269dd43dcca9a20000",
      "txid": "ff162dc6fcf24922a43662e445f7a0ddaec61dece249f4e01364696802bd9aee",
      "hash": "ecaba0fa0b919a167fbeee188ae394822e8e2e26d779df4c4132093fc7642797",
      "depends": [
      ],
      "fee": 605,
      "sigops": 8,
      "weight": 1390
    },
    {
      "data": "0200000000010295698b94fc9021b4b2a62dbb11e23acde77acf48ce8ce027332e81df15d4f7810000000000fdffffffecd68f83a2c9b4c76f6ec81990423ecad0bf5a513f58bb6e6f69e6872e6da2ee0200000000fdffffff020e800a00000000001976a914ff47820227d99093460b37f9616091a7ddb3e56688ac534d09000000000017a914ca2943e61732f9efd9cdf561c23fde303da03791870247304402205906443248e791515dad9bd35faccd3f07c88dc85a87c7eddc7b949419baea1902203beec98f1ff929b03641f45f1ee360e23e5ad20f9a0d7ef33fccb7e9918509da0121032a9c67647bf7d3b1ccf1965af9fd177c1abab097c0cbd5aaa59c195c7f07736302473044022034a08ba1de8e51bd59391682052c003a1360f10cd6e8b7353f10315afa27227202201c52da6a6e9813633153ffb711a95241b04c794e35029d1e26ef1553e6029aa50121032566f685bf194f85fa25617adbbaa174d2ef463d1ff9500d6704523243ada098a9a20000",
      "txid": "fb743188fee53fb54e4a839a176e37d74209a5eaf0df20513e16005147a7c5a3",
      "hash": "80e7071bac1b5ac08a8ddfe4c13dc29e0c1d7063a884de9703e51b28fb71ad9f",
      "depends": [
      ],
      "fee": 255,
      "sigops": 6,
      "weight": 848
    },
    {
      "data": "02000000000101d4c733a3d78574af8a5f8242f036f0529b8cdf049504f532f3cb4376a53876950100000000fdffffff03f70100000000000022512010397b2d4a2d4a67d55ccaee88c0e8e92c7f38aeebf4ca0e40499962586309a9ec030000000000002251205ae432a8aa5e7aa98d47c74a28390db89edec262d4e2ca1f6b41704495c01d4bb28a070000000000225120d2912b91d0802aa584f4c8ff364f9bb2d5af103368fef4c61584b34f1f081f8b01407848bd0612823ee11f6153ac354f91238cf9c9db66a60a234fbf1f43d3749228e1a1475eae46f66cf5606f262be605383268fe608ab25cb7c0458684cba6149c00000000",
      "txid": "9e5fd8b8a6d206db9117852e9fecb54a1792be229c09c004912e9f2d455d49b1",
      "hash": "464504217e5bcd3ddce9d6db8adc1ac3f65af434cfc6e1094ae03e6420b9ced5",
      "depends": [
      ],
      "fee": 197,
      "sigops": 0,
      "weight": 788
    },
    {
      "data": "02000000000101b1495d452d9f2e9104c0099c22be92174ab5ec9f2e851791db06d2a6b8d85f9e0000000000fdffffff014a01000000000000225120d2912b91d0802aa584f4c8ff364f9bb2d5af103368fef4c61584b34f1f081f8b03406bbe431da4a0931ee616f95c5f00d4ac4ed3828abd2b46c029a11ea5b2cc0ab1eae3bab0ee977409deaa1b598f5fdb5e4a4ec740b7cacc7960cf77fe139d6e0bab206a11672055d3ad2b612dc3372a7101f402816920842ce10c1aeeff3de093c72fac0063036f7264010118746578742f706c61696e3b636861727365743d7574662d38004c647b2270223a22736e73222c226f70223a22757064617465222c226e616d65223a2268657265222c22706572736f6e616c5f6e616d65223a2279697a68656e66656e67222c22706572736f6e616c5f64657363223a2231323334203837363520313638227d6821c16a11672055d3ad2b612dc3372a7101f402816920842ce10c1aeeff3de093c72f00000000",
      "txid": "7f551414f35e270415de3199396c93a097fd65264e805b2d0213c08c6bcfaa85",
      "hash": "bb8c41b018f6c4539102be484c5ad1326adf1ab152a58e6d123c78f0f896943d",
      "depends": [
        3
      ],
      "fee": 173,
      "sigops": 0,
      "weight": 650
    },
    {
      "data": "0200000002df830a452b60b91173357cd5bdb326f880f88b385ab97b950f26e8bc5a2a941e000000006a4730440220096855154d1fcdfc6dab47daac98579924f334bb444c735d0bfa75b009511872022074de7516dc8618c50173be6d15030774d18a6cbfcf508f1f2c9893a1980ffda70121026261f23b0f4f8009fd41437b547a3e50f4fddf34e8eeeb9524151d79e0f8c4ccfdffffff2efe099bcb6a8240891fd0f1ac2b4b79d00d20a36490901f7fd4d02f533bba17010000006a47304402202fec5222ad4bb68992f5edd0185bbfce61aadf03b12875993335adc461596f73022038bfe361f226548743bb7f56f827012221e7317796ace2199835795d89a828b60121030b0b57615595a0fcd04d466ab85313cd6369f07e9028c76b6f54d9fac1a8bbc4fdffffff03e71b050000000000160014386a025c6618718f6d12f605f169f4da380269842ee607000000000017a914f52cb69f975a79e9ad6be43b4f2ad5a3c8d7d56187534d090000000000160014134e35380abc71a8f678fcc49ccb5fd95e1bc7cba9a20000",
      "txid": "1a739e3ece13dd70b9e2d7184e31609e158ba0f8962a5eea76bf6c1d5579ae7b",
      "hash": "1a739e3ece13dd70b9e2d7184e31609e158ba0f8962a5eea76bf6c1d5579ae7b",
      "depends": [
      ],
      "fee": 398,
      "sigops": 0,
      "weight": 1592
    }
  ],
  "coinbaseaux": {
  },
  "coinbasevalue": 5000001628,
  "longpollid": "00000000000000308df706a8736dfe78eee7cea416adc1dc5bfcf4bc11202f6c324",
  "target": "00000000ffff0000000000000000000000000000000000000000000000000000",
  "mintime": 1724919762,
  "mutable": [
    "time",
    "transactions",
    "prevblock"
  ],
  "noncerange": "00000000ffffffff",
  "sigoplimit": 80000,
  "sizelimit": 4000000,
  "weightlimit": 4000000,
  "curtime": 1724920984,
  "bits": "1d00ffff",
  "height": 41642,
  "default_witness_commitment": "6a24aa21a9ed9392f1fe90c4f596eda2d286bba00dc8e2d66c0ec049783f9893f11043575063"
}

As you can see, "bits" field is set into "1d00ffff", and the time of the block is pushed forward. If you can see the real difficulty instead, then your CPU miner will try to mine a block with that difficulty, and will probably fail to do that on time.

In general, I can see two options:

1. Modifying Bitcoin Core.
2. Having unmodified Bitcoin Core, getting original block template, and modifying it in your mining software, or just before passing it to your mining software.

I think it is easier to recompile Bitcoin Core, but it is possible to get for example some 80-byte block header, and then write some code, to replace block time and difficulty, and then pass it into some mining software. Also, mining with Bitcoin Core is easier, because then you don't have to worry about dumping the whole block, making a proper Segwit commitment, and so on.

[BlackHatCoiner]

I could swear that both these links sent me to the same transaction. SMF bug? ... Anyway, thanks, I'll try to mine a block and let you know.

[LoyceV]

If you can get it right, then you can mine blocks with the minimal difficulty, and we can go further. This simple exercise is what I started with, long time ago, when I was curious, how to mine blocks with Bitcoin Core.

This worked:

Code:

{
  "hash": "0000000085550338d113b883f211c87c7aa3e045ba6e03bae855ea884d1a1be7",
  "confirmations": 1,
  "height": 1,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "20bb379fd28f090730ac2d207b92c6e95c69dfa48a8118577edb20e068c9a65d",
  "time": 1724929784,
  "mediantime": 1724929784,
  "nonce": 157273468,
  "bits": "1d00ffff",
  "difficulty": 1,
  "chainwork": "0000000000000000000000000000000000000000000000000000000200020002",
  "nTx": 1,
  "previousblockhash": "000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943",
  "strippedsize": 225,
  "size": 225,
  "weight": 900,
  "tx": [
    "20bb379fd28f090730ac2d207b92c6e95c69dfa48a8118577edb20e068c9a65d"
  ]
}

3. Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum.

If this is ELI5, I may need ELI4....

[vjudeu]

If this is ELI5, I may need ELI4....

If you can get a single block, after the Genesis Block, then it means, that you have enough computing power, to mine on testnet4.

Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum.

Those code changes are simple:

1. Go to "src/chain.h".
2. CTRL+F "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60;"
3. Replace it with: "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 20 * 60 * 60;"
4. Save changes.

5. Go to "src/node/miner.cpp".
6. CTRL+F "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};"
7. Replace it with: "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, pindexPrev->GetBlockTime() + consensusParams.nPowTargetSpacing*2 + 1)};".
8. Save changes.

As I said: you can do that, and recompile Bitcoin Core, then all "generateXYZ" commands will give you easier blocks. The alternative is to not touch Bitcoin Core at all, but then, you have to extract the whole block, save it somewhere, replace time and difficulty, and then pass your 80-byte header to your mining software. But for me, recompiling Bitcoin Core is easier.

Long time ago, when I started, I simply used "generatetoaddress" command manually, and modified my system clock, to set it 20 minutes after the last block.

This is another way, if you don't want to touch your source code. You can simply set your system clock 20 minutes into the future. But then:

1. You will get some warnings, that "your clock is different, than in other nodes".
2. It will work only for a single block. When you mine it, then you won't mine a second block on top of that, because you will need to move your time again, 20 more minutes forward, or you will be mining with the real difficulty.
3. If any other CPU miner will produce a block, then you will mine again with the real difficulty.
4. Your browser will tell you, that HTTPS connection is insecure, because your system time will be set differently.
5. Other programs, or even your Operating System, may try to update your time, and set it automatically, if you don't disable it.

So, by manually tweaking your system clock, and using unmodified Bitcoin Core, you can mine a block or two, but it quickly becomes tedious.

But of course, if you have nothing else, then you can start with that. If you change your system clock manually, and then restart Bitcoin Core, you should be able to mine a block on your CPU, if your block template will give you "1d00ffff".

[LoyceV]

If this is ELI5, I may need ELI4....

If you can get a single block, after the Genesis Block, then it means, that you have enough computing power, to mine on testnet4.

Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum.

Those code changes are simple:

1. Go to "src/chain.h".
2. CTRL+F "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60;"
3. Replace it with: "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 20 * 60 * 60;"
4. Save changes.

5. Go to "src/node/miner.cpp".
6. CTRL+F "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};"
7. Replace it with: "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, pindexPrev->GetBlockTime() + consensusParams.nPowTargetSpacing*2 + 1)};".
8. Save changes.

Thanks, I got this far. But after compiling, it doesn't seem to know "testnet4":

Code:

./bitcoind --testnet4 -prune=25000
Error: Error parsing command line arguments: Invalid parameter --testnet4

This was after I used https://github.com/fjahr/bitcoin/tree/2024-04-testnet-4-fix so not what I expected.

[garlonicon]

Maybe the author changed that branch in the meantime. Now, you can just clone the official code from https://github.com/bitcoin/bitcoin/ from the master branch, because things are already merged.

Also:

This branch is 360 commits behind bitcoin/bitcoin:master.

So, I guess using official code is better now. At the time of writing, it was not yet merged, so there was no other way.

Or: you can also use https://github.com/bitcoin/bitcoin/tree/28.x because this is what you can get, if you download release candidate for v28. But usually I just stick with the master.

Edit:

Code:

./bitcoind --testnet4 -prune=25000

A single dash in -testnet4, not --testnet4.

[LoyceV]

Or: you can also use https://github.com/bitcoin/bitcoin/tree/28.x because this is what you can get, if you download release candidate for v28. But usually I just stick with the master.

I'll try this next, thanks.

Edit:

Code:

./bitcoind --testnet4 -prune=25000

A single dash in -testnet4, not --testnet4.

Both work. Bitcoin Core isn't so picky. That's why I got sloppy with the dashes.

[vjudeu]

Invalid parameter --testnet4

Which version? Both master and v28.0 should have it.

Code:

$ ./bitcoind --version
Bitcoin Core version v28.0.0rc1
Copyright (C) 2009-2024 The Bitcoin Core developers

Please contribute if you find Bitcoin Core useful. Visit
<https://bitcoincore.org/> for further information about the software.
The source code is available from <https://github.com/bitcoin/bitcoin>.

This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>

[LoyceV]

Invalid parameter --testnet4

Which version? Both master and v28.0 should have it.

I'm not even sure anymore. I now used https://github.com/bitcoin/bitcoin/tree/28.x and that works. I have enough testnet4 coins to give them away until the end of days

One more question: how do I get one of those cute little Miner tags "LoyceV was here" (just like Portland.HODL)? That would be a cool thing to have before I turn this off again I tried Googling it, but couldn't find it.

[garlonicon]

how do I get one of those cute little Miner tags "LoyceV was here"

Do you want to get only some message, or something special? Usually, I just change the code, for example:

Code:

// Create coinbase transaction.
CMutableTransaction coinbaseTx;
coinbaseTx.vin.resize(1);
coinbaseTx.vin[0].prevout.SetNull();
CAmount nFeesWithSubsidy = nFees + GetBlockSubsidy(nHeight, chainparams.GetConsensus());
if(nFeesWithSubsidy<=10*1000*COIN)
{
    coinbaseTx.vout.resize(1);
    coinbaseTx.vout[0].scriptPubKey = scriptPubKeyIn;
    coinbaseTx.vout[0].nValue = nFeesWithSubsidy;
}
else
{
    coinbaseTx.vout.resize(1);
    coinbaseTx.vout[0].scriptPubKey = scriptPubKeyIn;
    coinbaseTx.vout[0].nValue = 10*1000*COIN;
}
coinbaseTx.vin[0].scriptSig = CScript() << nHeight << ParseHex("4c6f79636556207761732068657265");

After "nHeight", you can add any Script in "src/node/miner.cpp", recompile it, and then restart your node. But of course, if you don't want to touch the client, then there are other options. Usually, some mining client has something called "coinbaseaux" or similar. For "LoyceV was here", it would be "4c6f79636556207761732068657265" (sometimes you have to specify it in hex, sometimes not, probably you should try it in regtest first, to be sure).

Edit: Let's see: https://mempool.space/testnet/tx/5e739e2a69fe22f8b3f7536c35cbb710ddb725e5660f3996e902ee6eeb36c21a

[LoyceV]

Code:

coinbaseTx.vin[0].scriptSig = CScript() << nHeight << ParseHex("4c6f79636556207761732068657265");

After "nHeight", you can add any Script in "src/node/miner.cpp", recompile it, and then restart your node. But of course, if you don't want to touch the client, then there are other options. Usually, some mining client has something called "coinbaseaux" or similar. For "LoyceV was here", it would be "4c6f79636556207761732068657265" (sometimes you have to specify it in hex, sometimes not, probably you should try it in regtest first, to be sure).

Thanks, that (kinda) worked. It still shows the Miner as unknown, but it has a Coinbase tag:

I don't know why there's ] and | in front.

[garlonicon]

I don't know why there's ] and | in front.

Because of block height, which is mandatory, since BIP-34. And because mempool.space decodes block height as ASCII, it is what it is.

Also note, that there are more mining pools, marked as "Unknown". The list of tags is probably centrally managed by mempool.space, so you can ask them about it. Or try to format it in the same way as "wiz" did.

[BlackHatCoiner]

Is it possible to run bitcoin-cli generatetoaddress in multiple threads? I wrote a C program which calls 12 forks, each having its own thread, but it doesn't get all the CPU power. It's strange; it only takes 33% of the CPU. (My total threads are 12.)

Code:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

void* runner(void* param);

int main(int argc, char** argv)
{
	int i, num_threads = sysconf(_SC_NPROCESSORS_ONLN);
	printf("Num of available threads: %d\n", num_threads);

	pthread_t* threads = malloc(num_threads * sizeof(pthread_t));
	int* thread_ids = malloc(num_threads * sizeof(int));

	for(i = 0; i < num_threads; i++){
			thread_ids[i] = i;	
			if(pthread_create(&threads[i], NULL, runner, &thread_ids[i]) != 0){
				perror("pthread_create failed");
				free(threads);
				free(thread_ids);
			}
		
	
	}
	
	for(i = 0; i < num_threads; i++){
		pthread_join(threads[i], NULL);
	}

	free(threads);
	free(thread_ids);

	printf("All threads have finished execution\n");

	return 0;
}

void* runner(void* param)
{

	printf("thread %d is running...\n", *(int*)param);
	pid_t pid = fork();
    if (pid == 0) {
        // In child process: execute the command
        execl("./bitcoin-cli", "bitcoin-cli", "--testnet4", "generatetoaddress", "1", "<ADDRESS>", "10000000", NULL);
        // If execl fails
        perror("execl failed");
        exit(1);
    } else if (pid > 0) {
        // In parent process: wait for the child process to finish
        int status;
        waitpid(pid, &status, 0);
    } else {
        perror("fork failed");
    }
	
	return NULL;	
}

Everything seems to be executing properly:

Code:

$ ./exec2
Num of available threads: 12
thread 0 is running...
thread 1 is running...
thread 2 is running...
thread 3 is running...
thread 4 is running...
thread 5 is running...
thread 6 is running...
thread 7 is running...
thread 9 is running...
thread 8 is running...
thread 11 is running...
thread 10 is running...
[
]
[
]
[
]
[
]
[
]
[
]
[
]
[
]
[
]
[
]
[
]
[
]
All threads have finished execution

I know that there is already some CPU mining software out there for multiple-thread mining, but I want to write my own. It's also made for testing purposes, since we're in testnet.

[LoyceV]

Is it possible to run bitcoin-cli generatetoaddress in multiple threads? I wrote a C program which calls 12 forks, each having its own thread, but it doesn't get all the CPU power. It's strange; it only takes 33% of the CPU. (My total threads are 12.)

Here, it tops off at 400.0% CPU (so 4 cores). I'm not sure how useful it is though: sometimes different threads find the same block, and sometimes they find different blocks.

[BlackHatCoiner]

Here, it tops off at 400.0% CPU (so 4 cores).

In Linux Mint, CPU usage goes up to 100%. If you have 12 cores, and the program uses 8.3% of the CPU, it means it uses 1 core. If it uses 33%, it means it uses 4 cores. So, it perhaps depends on the architecture of the OS. (I guess that the fact that it's using the same number of cores in both of us, is a good sign.)

I'm not sure how useful it is though: sometimes different threads find the same block, and sometimes they find different blocks.

That's a problem, indeed. You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason. An extra nonce field in generatetoaddress would solve this problem.

Edit: Just solved the same block four times

Code:

$ ./exec2
Num of available threads: 12
thread 0 is running...
thread 1 is running...
thread 2 is running...
thread 3 is running...
thread 4 is running...
thread 5 is running...
thread 6 is running...
thread 7 is running...
thread 8 is running...
thread 9 is running...
thread 10 is running...
thread 11 is running...
[
  "00000000f095255ea490763a99f02b2adfae1f2ca4df708db02fa5a1777b4217"
]
[
  "00000000f095255ea490763a99f02b2adfae1f2ca4df708db02fa5a1777b4217"
]
[
  "00000000f095255ea490763a99f02b2adfae1f2ca4df708db02fa5a1777b4217"
]
[
  "00000000f095255ea490763a99f02b2adfae1f2ca4df708db02fa5a1777b4217"
]

[LoyceV]

You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason.

That's easy to fix:

Code:

address=$(shuf -n1 addresses.txt)

Even better if you get a new address each time after finding a block.

[BlackHatCoiner]

Added --debug=http, and here's what I get:

Code:

2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37146
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37174
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37162
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37180
2024-08-31T15:50:25Z CreateNewBlock(): block weight: 896 txs: 0 fees: 0 sigops 400
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37192
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37208
2024-08-31T15:50:25Z CreateNewBlock(): block weight: 896 txs: 0 fees: 0 sigops 400
2024-08-31T15:50:25Z CreateNewBlock(): block weight: 896 txs: 0 fees: 0 sigops 400
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37216
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37218
2024-08-31T15:50:25Z CreateNewBlock(): block weight: 896 txs: 0 fees: 0 sigops 400
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37224
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37238
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37254
2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37260

It uses only 4 cores, because it calls CreateNewBlock() only 4 times, whereas I'm calling it 12. (It does receive all 12 requests though.) There has to be an internal function in Bitcoin Core which blocks me from running CreateNewBlock more than 4 times in parallel.

BTW, another problem is mempool. For some reason, it's empty to me. (And that's why I mine empty blocks.)

[vjudeu]

Is it possible to run bitcoin-cli generatetoaddress in multiple threads?

Yes, sure, bitcoin-util has the "grind" command, which does exactly that. The hardest part is getting 80-byte block header, and passing it correctly. But if you can:

1. Dump the whole block.
2. Extract the block header.
3. Pass that header to bitcoin-util.
4. Submit mined block to the network.

Then it can work. But currently, I had some cases, where I had six future blocks in a row, and then needed to slow down my miners, so I am not planning to get more power out of it, because after passing two hours limit, the risk of getting your block reorged is increased (because if you don't re-submit your block properly, then it won't be broadcasted automatically, if you mine it too fast).

You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason.

It can be simpler than that. See bitcoin-util implementation (or just use it, by passing your block headers there). If you have nonces from 1 to 100, and you have two threads, then the first thread can check 1,3,5,7, and the second one can check 2,4,6,8, at the same time. Then, you have "i+=2" in both cases, and you use "i=startRange+threadId" as a starting point.

Just solved the same block four times

Yes, for that reason, I use a different address in each generatetoaddress call, or assign different range of nonces for each call.