Topic: Requesting Testnet4 tBTC - page 6. (Read 2333 times)
I'm sorry to bother you. Do you have any extra tbtc on testnet4? If you have any, can you give us some for testing? We are implementing a lending project for BTC, ord (runes, nft, brc-20) on the l1 network. The address is tb1pzpkzz0hlqa63cz43j5azw27343ddxy6zcfsr7j50fa9neq8uzkwql5gjpd
Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value.
Just like I've speculated about it on real Bitcoin, I think here the ordinal spam also comes from only one person. That explains why all transactions are in the same style, and start and stop at the same time too. 
I'm not sure what's the best thread, so I'll just post it here: testnet3's mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time.
Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value.
Amazingly, that means testnet3 can now actually be used again for testing 
Although i wonder how easy is it to obtain testnet3 coins now (aside from mining). Tesnet faucet was abused on many occurrence.
Quote
Amazingly, that means testnet3 can now actually be used again for testing
Not only that. It also means, that mining testnet3 is now less profitable, and switching into testnet4 is a better idea. But a short while before that, it was the opposite, when it was not certain, if testnet4 will be reorged or not. Now we know, that those, who consider 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 as a valid block, are simply mining coins, which will vanish, after upgraded ASICs will mine an alternative chain, on top of 0000000000000016be66ab39af9f97e1294080c94d0a34cc304e391794a481bd.In general, we are about to see at least 360 blocks reorg, at the time of writing. I guess it could be 500 blocks reorg, or even 1000 blocks reorg, depending on how many people will mine blocks, when using some older version.
Quote
testnet3's mempool is currently empty
It's nothing new. There are waves of transactions: sometimes mempools are full, sometimes they are empty. And the cost to fill up the whole 300 MB is quite low.And note that even if mempool.space shows you a fully filled mempool, then it doesn't mean, that you have to pay that much. For example: if some CPU mining node is just starting up, then it could have an empty mempool, and fetching all of those transactions in P2P way is quite slow process, and if you can see a low block health, then it doesn't always mean censorship: it could mean as well, that this particular miner just turned on its node, and it was turned off recently, for whatever reason. And during that time, you can get your transactions confirmed cheaper, if you send it to that particular node. Which means that again: the default fee estimation is far from being optimal, because it doesn't consider such details.
Quote
that means testnet3 can now actually be used again for testing
You can always mine future blocks, and prioritize your own transactions. And you can pay zero fee in your own transactions, if you are a miner. And even if there is some opportunity cost, then statistically, sometimes blocks are not fully filled, and in a general case, it makes a lot of sense to send and mine your own transactions with a low feerate (also because if you use less than 1000 sat/kvB, then you can "cancel" that easier, in case of mistakes).Also note, that if you want to mine some coins, then you can do that on signet, too: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937
I'm not sure what's the best thread, so I'll just post it here: testnet3's mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time.
Amazingly, that means testnet3 can now actually be used again for testing
Amazingly, that means testnet3 can now actually be used again for testing
By the way, I think what happened here is that someone tried to CPU mine coins on testnet by setting their clock > 20 minutes into the future.
Such a block would be accepted by all nodes (upgrade or not). But v28 nodes then require the next block to be >10 minutes in the future, whereas before they would allow 1 hour and 50 minutes in the past (which includes the present).
v28.0rc1 contains a fix for the Bitcoin Core miner code (getblocktemplate, etc) that ensures timestamps are adjusted: https://github.com/bitcoin/bitcoin/issues/30614
---
Update: the above invalidateblock / reconsiderblock sequence won't work.
The only way to get an upgraded node to re-check the timewarp rules is:
Such a block would be accepted by all nodes (upgrade or not). But v28 nodes then require the next block to be >10 minutes in the future, whereas before they would allow 1 hour and 50 minutes in the past (which includes the present).
v28.0rc1 contains a fix for the Bitcoin Core miner code (getblocktemplate, etc) that ensures timestamps are adjusted: https://github.com/bitcoin/bitcoin/issues/30614
---
Update: the above invalidateblock / reconsiderblock sequence won't work.
The only way to get an upgraded node to re-check the timewarp rules is:
Code:
bitcoind -tesnet4 -reindex
The timewarp attack mitigation for testnet4 requires the first block of a new difficulty adjustment period to have a timestamp later than that of the last block of the previous period.
Initially there was a 7200 second (2 hour) grace period. This was changed to 600 seconds (10 minutes) two weeks ago: https://github.com/bitcoin/bitcoin/pull/30647 (matching the original Great Consensus Cleanup proposal).
This change is effectively a soft fork on testnet4, but with no activation mechanism.
Anyone who runs the v28.0rc1 release candidate, or a very recent master, will enforce it. Anyone who runs an older version won't enforce it.
My guess is that most miners on testnet4 haven't updated yet. Even if they did that today, the node won't automatically go back to validate old blocks.
If enough miners switch to v28.0(rc...) and call `invalidateblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` followed by `reconsiderblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` they will reject the block at height 42336. This will lead to a one day reorg, or more if it's done later.
An alternative approach would be to change Bitcoin Core to enforce the modified timewarp rule from a certain flag height in the future, but that seems like a lot of complexity for a test network that hasn't even been released yet.
As an aside: the SegWit soft fork did have a mechanism for handling this situation. If a user upgrade their pre-segwit node to a segwit node sometime after activation, it would roll back the chain and check everything again.
Initially there was a 7200 second (2 hour) grace period. This was changed to 600 seconds (10 minutes) two weeks ago: https://github.com/bitcoin/bitcoin/pull/30647 (matching the original Great Consensus Cleanup proposal).
This change is effectively a soft fork on testnet4, but with no activation mechanism.
Anyone who runs the v28.0rc1 release candidate, or a very recent master, will enforce it. Anyone who runs an older version won't enforce it.
My guess is that most miners on testnet4 haven't updated yet. Even if they did that today, the node won't automatically go back to validate old blocks.
If enough miners switch to v28.0(rc...) and call `invalidateblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` followed by `reconsiderblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` they will reject the block at height 42336. This will lead to a one day reorg, or more if it's done later.
An alternative approach would be to change Bitcoin Core to enforce the modified timewarp rule from a certain flag height in the future, but that seems like a lot of complexity for a test network that hasn't even been released yet.
As an aside: the SegWit soft fork did have a mechanism for handling this situation. If a user upgrade their pre-segwit node to a segwit node sometime after activation, it would roll back the chain and check everything again.
Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain.
I take it BIP 94 is enabled already by default. I read bip-0094.mediawiki:Quote
To protect against the time warp attack, the following rule proposed as part of The Great Consensus Cleanup[5] is enforced: "The nTime field of each block whose height, mod 2016, is 0 must be greater than or equal to the nTime field of the immediately prior block minus 600. For the avoidance of doubt, such blocks must still comply with existing Median-Time-Past nTime restrictions."
I won't claim to understand it entirely, but it looks like the problem arose because 21*2016=42336. And that block gets rejected.But, if that's the default, how come most nodes continue nonetheless? I guess this does explain why mining 20 minutes in the future is no longer possible.
Quote
So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing.
I guess this is the path to go. I don't want it to be stuck until someone changes something.Code:
vi test/functional/mining_basic.py
MAX_TIMEWARP = 1200
src/consensus/consensus.h
static constexpr int64_t MAX_TIMEWARP = 1200;
Quote
I think the 20 * 60 * 60 code changes did #3 by default, right?
It starts with #3, and then, it rejects your own blocks, which is the same, what happens, if you run out of two hours. By changing from 2 to 20 hours, you just accept more blocks, but in general, if they are CPU-mined, then there is a huge risk, that they will be reorged.Quote
But then why doesn't it find new blocks anymore after block 42335?
Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain.So: do you want to disable 600 seconds rule?
Quote
Code:
if (consensusParams.enforce_BIP94) {
// Height of block to be mined.
const int height{pindexPrev->nHeight + 1};
if (height % consensusParams.DifficultyAdjustmentInterval() == 0) {
nNewTime = std::max(nNewTime, pindexPrev->GetBlockTime() - MAX_TIMEWARP);
}
} For now, I simply use some version without those timewarp protections. I don't know, what will happen after block 42335: maybe the current chain will be reorged, or maybe it will be grandfathered in, and the activation of all BIP 94 rules will come later. Who knows, time will tell.
So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing.
I started my default bitcoin-qt on testnet4:
I know it's testnet, but doesn't this mean it's broken? Could it be the code changes that removed the "block storm" created something unexpected, that makes standard nodes unable to keep syncing?
I've been wondering for a while what happens if most Bitcoin miners adjust their clock to the future.
Doesn't that mean you'd have to adjust your code to mine 2 blocks starting from the previous block, instead of mining on top of the 1:59:59-ahead block? So it requires more code changes, right?
@garlonicon's signature: I still can't wrap my head around dealing with private keys in descriptor wallets, so brainwallets aren't really an option at the moment. I'll give it a try when Electrum supports testnet4.
It turns out I did mine block 42335. How come multiple nodes can't get passed this block?
Code:
Number of blocks left: Unknown. Syncying Headers (42335, 99.8%)...
Quote
Shouldn't it reorg on it's own to follow the longest chain?
Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.Quote
it has someone who mines a block 2 hours ahead all the time
Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged.Quote
So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets.
Do I get it right that this only works on testnet because of the difficulty drop after 20 minutes? Wouldn't it be better to change the default rules, let's say the difficulty drops only after 3 hours, so normal mining isn't affected? Or reduce the time difference between miners to no more than 10 minutes instead of 2 hours?Quote
Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks.
Thanks for the explanation. I'm still amazed people have been burning ASIC power on testnet for years.@garlonicon's signature: I still can't wrap my head around dealing with private keys in descriptor wallets, so brainwallets aren't really an option at the moment. I'll give it a try when Electrum supports testnet4.
It turns out I did mine block 42335. How come multiple nodes can't get passed this block?
Quote
it has someone who mines a block 2 hours ahead all the time
Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged. So, if some CPU miner will send one block with "20 minutes 1 second", and second block with "40 minutes 2 seconds", then those two blocks will knock out that "1 hour 59 minutes 59 seconds" block.So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets.
Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks.
Quote
Shouldn't it reorg on it's own to follow the longest chain?
Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.Quote
So you'll kinda need to "manually" keep track and upload them?
Only those, which are above two hours. And only if you use different settings, than most of the network. Because if 99% nodes would use 20 hours rule, then it would be "de facto standard", and if the heaviest chainwork would be there, then 2 hours rule would simply be lifted. Because there is no centralized source of time: if you have a brand new node, and it tries to download the whole chain history, it doesn't know, if the chain with 2^70 chainwork contains many years of history, or are there just two 2^69 blocks, with today's timestamp (and a lot of smaller ones, to adjust the difficulty).Quote
I just wanted to feel the fun of mining blocks that I missed out of in 2009
After reaching two hours limit, you have those options:1. Stick to two hours rule, and stop mining, waiting for some ASIC block, to put the current time.
2. Stick to two hours rule, and still try to mine something, but with ASIC difficulty on CPU, which will likely just burn that power for nothing.
3. Produce a secret, longer chain, and do your testing, knowing that after a while, a new ASIC block will come, and destroy your chain (but in the meantime, you will have a fully working playground, to test non-standard transactions, mining power, or anything else).
Also note, that when there was almost no competition, and we were mining CPU blocks alone, or with a few friends, or when it was "my first node vs my second node" or even "garlonicon's node vs vjudeu's node" then we didn't need to think about all of those consequences, and implications of those rules. But now, when more bitcointalk users will try CPU mining, we will probably encounter more issues, than we found, when we were alone, or with some small, closed and well-coordinated group of friends. We simply didn't put enough CPU power, to test some corner cases, like "more than 51% of blocks, mined by CPUs".
To sum up: it is nice to see some competition: if more bitcointalk users will start mining testnet coins, then maybe some people will get some knowledge, for example "how hard is to CPU-mine things at difficulty one".
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.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
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:
(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.
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". 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).
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
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
What happened here?
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. 
Added --debug=http, and here's what I get:
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.)
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
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.)
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. 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"
]
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"
]
Jump to: