Requesting Testnet4 tBTC - page 7. | Bitcointalksearch.org

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: garlonicon on September 02, 2024, 02:39:29 AM

Quote

And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.

I didn't think my mining power was causing it (but I can't be sure). I'm recompiled an unedited Bitcoin Core:

Code:

2024-09-02T07:52:57Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=0
2024-09-02T07:52:58Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=1
2024-09-02T07:53:04Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=2
2024-09-02T07:53:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=3
2024-09-02T07:53:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=4
2024-09-02T07:53:13Z P2P peers available. Skipped DNS seeding.
2024-09-02T07:53:13Z dnsseed thread exit
2024-09-02T07:53:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=5
2024-09-02T07:53:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=6
2024-09-02T07:53:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=7
2024-09-02T07:53:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=8
2024-09-02T07:53:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=9
2024-09-02T07:53:26Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=10
2024-09-02T07:53:27Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=11
2024-09-02T07:53:28Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=12
2024-09-02T07:53:34Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=13
2024-09-02T07:53:35Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=14
2024-09-02T07:53:35Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=15
2024-09-02T07:53:36Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=16
2024-09-02T07:53:37Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=17
2024-09-02T07:53:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=18
2024-09-02T07:53:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=19
2024-09-02T07:53:44Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=21
2024-09-02T07:53:45Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=23
2024-09-02T07:53:46Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=26
2024-09-02T07:54:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=28
2024-09-02T07:54:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=29
2024-09-02T07:54:16Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=31
2024-09-02T07:54:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=33
2024-09-02T07:54:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=34
2024-09-02T07:54:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=35
2024-09-02T07:54:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=36
2024-09-02T07:54:31Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=37
2024-09-02T07:54:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=38
2024-09-02T07:54:49Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=39
2024-09-02T07:54:49Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=40
2024-09-02T07:54:51Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=41
2024-09-02T07:54:57Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=42
2024-09-02T07:54:58Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=43
2024-09-02T07:54:59Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=44

Some nodes are stuck at 42335, most are at 42397. Shouldn't it reorg on it's own to follow the longest chain?

Quote from: garlonicon on September 02, 2024, 02:39:29 AM

I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that.

At the moment, testnet3 doesn't have 6 blocks in the future, it has someone who mines a block 2 hours ahead all the time:
Image loading...

(source)

The ones with the long Coinbase tag look like ASIC miners. The ones with the short Coinbase tag have a Timestamp about 2 hours in the future. It looks like the ASIC Timestamp is also ahead, but less.
It looks like this 2 hour ahead thing blocks your code changes.

garlonicon

copper member

Activity: 944

Merit: 2257

Quote

And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.

Also, if you mine any block, which is moved forward beyond those two hours, then when it will fall back into two hours window (because time is naturally moving forward), then you probably have to re-submit such block, because it won't be submitted automatically.

So yes, in general, if you are further than two hours in the future, then there is a huge risk of mining a chain, which will be reorged anyway. But: if you want to measure your mining power, then you need some way of doing that, and by having a secret, longer chain, you can measure, how many of your CPU-mined blocks will be reorged, when a single ASIC block will appear. And also, if you have a GUI version, then you will see all of those blocks as "stale" or "generated, not confirmed", or something like that.

Quote

Mempool.space is at block 42391 already.

The funny thing is that if you have a full P2P node, then you should also notice, that mempool.space is not some centralized source of truth anymore. If you have only CPU blocks in conflicting chains, then you should probably see, on top of which chain, you have more chainwork, and more ASIC blocks. Because for example, I thought that "mempool.space confirmed? Then safe", but I stopped thinking in that way, when I successfully reorged mempool.space, and when ASIC miners started to build new blocks on top of my history, and not theirs. If you are a node runner, then you are really P2P peer, and you should focus on chainwork, and not "just some centralized block explorer".

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: vjudeu on September 01, 2024, 11:37:27 PM

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).

~~Someone figured out how to break~~ Something broke garlonicon's code changes. My node is stuck on block 42335:

Code:

2024-09-02T05:25:52Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999425 cache=0.3MiB(16txo)
2024-09-02T05:25:52Z 0 block-relay-only anchors will be tried for connections.
2024-09-02T05:25:52Z init message: Starting network threadsâ¦
2024-09-02T05:25:52Z dnsseed thread start
2024-09-02T05:25:52Z Waiting 300 seconds before querying DNS seeds.
2024-09-02T05:25:52Z net thread start
2024-09-02T05:25:52Z addcon thread start
2024-09-02T05:25:52Z opencon thread start
2024-09-02T05:25:52Z msghand thread start
2024-09-02T05:25:52Z UpdateTip: new best=00000000ccf137e3823d03c9f23c1623ae3ce25fe29048e31674cfe4d3e47a98 height=42335 version=0x20000000 log2_work=70.828749 tx=781367 date='2024-09-01T21:49:09

This was after I restarted it.

Checking older logfiles, this happened last night:

Code:

2024-09-02T02:06:09Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:06:09Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:12:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 16722 seconds ago)
2024-09-02T02:22:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17352 seconds ago)
2024-09-02T02:33:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17982 seconds ago)
2024-09-02T02:43:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18612 seconds ago)
2024-09-02T02:54:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19242 seconds ago)
2024-09-02T03:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T03:04:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19872 seconds ago)
2024-09-02T03:15:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20502 seconds ago)
2024-09-02T03:25:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21132 seconds ago)
2024-09-02T03:36:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21762 seconds ago)
2024-09-02T03:46:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 22392 seconds ago)
2024-09-02T03:57:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23022 seconds ago)
2024-09-02T04:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T04:07:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23652 seconds ago)
2024-09-02T04:18:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 24282 seconds ago)
2024-09-02T04:28:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 24912 seconds ago)
2024-09-02T04:39:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 25542 seconds ago)
2024-09-02T04:49:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 26172 seconds ago)
2024-09-02T05:00:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 26802 seconds ago)
2024-09-02T05:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T05:10:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 27432 seconds ago)
2024-09-02T05:21:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 28062 seconds ago)
2024-09-02T05:24:59Z tor: Thread interrupt
2024-09-02T05:24:59Z Shutdown: In progress...
2024-09-02T05:24:59Z addcon thread exit
2024-09-02T05:24:59Z torcontrol thread exit
2024-09-02T05:24:59Z msghand thread exit
2024-09-02T05:24:59Z net thread exit
2024-09-02T05:25:02Z opencon thread exit
2024-09-02T05:25:02Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat started
2024-09-02T05:25:02Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2024-09-02T05:25:02Z scheduler thread exit
2024-09-02T05:25:02Z Writing 39 mempool transactions to file...
2024-09-02T05:25:02Z Writing 0 unbroadcast transactions to file.
2024-09-02T05:25:02Z Dumped mempool: 0.000s to copy, 0.029s to dump, 13558 bytes dumped to file
2024-09-02T05:25:02Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T05:25:06Z Shutdown: done

As far as I understand the code changes, it changes the "window" from 2 to 20 hours. And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

I wiped the testnet4 blockchain and restarted it, with the same result:

Code:

2024-09-02T07:07:59Z UpdateTip: new best=00000000a5b18671cb77a85ed98cf64a3a9f97d3c5a3f661465f6bbe1e97a250 height=42327 version=0x20000000 log2_work=70.827931 tx=781321 date='2024-09-01T21:08:13Z' progress=0.999277 cache=75.7MiB(589834txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000000e2daf4ee59372be354ac640a9e6686794f6ac68254b8d451c height=42328 version=0x2f296000 log2_work=70.828095 tx=781328 date='2024-09-01T20:51:02Z' progress=0.999257 cache=75.7MiB(589837txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000e853d1dd75ac2a1c424d6c90730897038074d85a0c374a73ac2322e9 height=42329 version=0x20000000 log2_work=70.828095 tx=781332 date='2024-09-01T21:11:03Z' progress=0.999281 cache=75.7MiB(589835txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004cd3ea3324d8bdfdf64eda9ef324e27103cfa98afcbd9bb65e height=42330 version=0x323a8000 log2_work=70.828258 tx=781342 date='2024-09-01T21:06:38Z' progress=0.999275 cache=75.7MiB(589834txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004c3233c6a02aed84e01aef09fc0c1bd74615d0bbd19e32eb92 height=42331 version=0x20000000 log2_work=70.828422 tx=781348 date='2024-09-01T21:11:50Z' progress=0.999282 cache=75.7MiB(589832txo)
2024-09-02T07:07:59Z UpdateTip: new best=0000000000000000b7059720cb0394af824c1eff5139c7d7396c51145ea5692c height=42332 version=0x2d752000 log2_work=70.828585 tx=781355 date='2024-09-01T21:21:38Z' progress=0.999293 cache=75.7MiB(589837txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000b5108be963a280da486ee21860bfdc931af42564c6a165d8dcfb387a height=42333 version=0x20000000 log2_work=70.828585 tx=781359 date='2024-09-01T21:41:39Z' progress=0.999318 cache=75.7MiB(589836txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999302 cache=75.7MiB(589839txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000542792e54a720567ba66157d48cdae7bfd01c1b678d0f07a2ed56e99 height=42335 version=0x20000000 log2_work=70.828749 tx=781367 date='2024-09-01T21:49:09Z' progress=0.999327 cache=75.7MiB(589843txo)
2024-09-02T07:08:17Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42391, peer=19

Mempool.space is at block 42391 already.

What happened here?

vjudeu

copper member

Activity: 909

Merit: 2314

Quote

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).

Quote

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.

Quote

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

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.)

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: BlackHatCoiner on August 31, 2024, 09:32:52 AM

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

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: LoyceV on August 31, 2024, 09:12:08 AM

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.)

Quote from: LoyceV on August 31, 2024, 09:12:08 AM

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 Cheesy

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

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: BlackHatCoiner on August 31, 2024, 07:43:55 AM

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

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

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
#include
#include
#include
#include
#include

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", "

", "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.

garlonicon

copper member

Activity: 944

Merit: 2257

Quote

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.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: garlonicon on August 30, 2024, 02:18:50 AM

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:
Image loading...

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

garlonicon

copper member

Activity: 944

Merit: 2257

Quote

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

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: vjudeu on August 30, 2024, 12:35:45 AM

Quote

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 Cheesy

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.

vjudeu

copper member

Activity: 909

Merit: 2314

Quote

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
for further information about the software.
The source code is available from .

This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: garlonicon on August 29, 2024, 12:23:09 PM

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.

Quote

Edit:

Quote

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.

garlonicon

copper member

Activity: 944

Merit: 2257

~~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:

Quote

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:

Quote

Code:

./bitcoind --testnet4 -prune=25000

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

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: vjudeu on August 29, 2024, 07:01:57 AM

Quote

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.

Quote

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(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch(NodeClock::now()))};"
7. Replace it with: "int64_t nNewTime{std::max(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.

vjudeu

copper member

Activity: 909

Merit: 2314

Quote

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.

Quote

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(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch(NodeClock::now()))};"
7. Replace it with: "int64_t nNewTime{std::max(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.

Quote

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

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: vjudeu on August 05, 2024, 12:27:41 PM

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"
]
}

Quote from: garlonicon on August 05, 2024, 11:53:39 AM

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

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

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.

Topic: Requesting Testnet4 tBTC - page 7. (Read 2713 times)