Quote
I was more curious about how Bitcoin Core would handle that.
ASIC miners will just reorg them. Here is how: https://github.com/bitcoin/bitcoin/pull/31117 
Topic: Requesting Testnet4 tBTC - page 2. (Read 2333 times)
The question is why only one of the systems monopolizes the minting, or at least mines 99% of the CPU mined blocks.
My guess is future price speculation, or maybe just wanting to hold the record of owning most testnet coins 
Quote
Could it be that he has launched dozens of testnet4 nodes, all connected and broadcasting his blocks at the same time?
That would make sense, but doesn't work with my theory of running 2 different systems. I haven't checked if the blocks that get replaced also mined to the same address, or to a different address. I'll keep an eye on that for a while on memspace: the moment the latest block gets replaced, I'll know the answer.Quote
I guess the result is the same. Testers can't acquire tBTC by mining them.
I was more curious about how Bitcoin Core would handle that.I'm curious what this is all about:
(source)
Why would this even need funding? 
I think 2 "systems" are replacing each other's last block. Check my logs (grep 'new best')
The question is why only one of the systems monopolizes the minting, or at least mines 99% of the CPU mined blocks. Could it be that he has launched dozens of testnet4 nodes, all connected and broadcasting his blocks at the same time?Quote
It would be interesting to see what happens if not 2, but 200 "systems" would be doing this.
I guess the result is the same. Testers can't acquire tBTC by mining them. Block 50000 (A) becomes stale, another block 50000 (call it block A') replaces my block A, and another one is mined on top of that block (call it block B').
I think 2 "systems" are replacing each other's last block. Check my logs (grep 'new best'):Code:
2024-10-30T07:37:22Z UpdateTip: new best=0000000000bf226668eebab806a5d0bcaa429a69bcd1db96e81b99231025def8 height=52815 version=0x2281c000 log2_work=71.508189 tx=910183 date='2024-10-30T08:57:20Z' progress=1.000000 cache=199.1MiB(35111txo)
2024-10-30T07:37:22Z UpdateTip: new best=00000000008b7f827817f480a234a45db35bad26fc818b1b3ddc4486a886e1a1 height=52816 version=0x23142000 log2_work=71.508189 tx=910203 date='2024-10-30T09:17:21Z' progress=1.000000 cache=199.1MiB(35129txo)
2024-10-30T07:37:22Z UpdateTip: new best=000000000097c57f97856851424c98b41b386f5f8f06d754fa75853b9f79844b height=52817 version=0x22184000 log2_work=71.508189 tx=910232 date='2024-10-30T09:37:22Z' progress=1.000000 cache=199.1MiB(35158txo)
2024-10-30T07:57:23Z UpdateTip: new best=000000000087ffcdf82f94ab6491dfb93c89b0d12de6373aff2057a411995130 height=52818 version=0x23b8e000 log2_work=71.508189 tx=910276 date='2024-10-30T09:57:23Z' progress=1.000000 cache=199.1MiB(35226txo)
2024-10-30T08:17:24Z UpdateTip: new best=0000000000c0d93d5b1d12d139e52d8815eaec0a5ada7ad9280ff7bba040a2e5 height=52819 version=0x21220000 log2_work=71.508189 tx=910322 date='2024-10-30T10:17:24Z' progress=1.000000 cache=199.2MiB(35435txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000087ffcdf82f94ab6491dfb93c89b0d12de6373aff2057a411995130 height=52818 version=0x23b8e000 log2_work=71.508189 tx=910276 date='2024-10-30T09:57:23Z' progress=1.000000 cache=199.1MiB(35227txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000035ed59fc3e42e536a49feb64350dfb9a40556db2c52898f6eb0841 height=52819 version=0x20396000 log2_work=71.508189 tx=910322 date='2024-10-30T10:17:24Z' progress=1.000000 cache=199.2MiB(35436txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000040921cbbc6397caa75167939a8cf590d9cee672c5e689e5959095a height=52820 version=0x24486000 log2_work=71.508189 tx=910336 date='2024-10-30T10:37:25Z' progress=1.000000 cache=199.2MiB(35524txo)
2024-10-30T08:41:21Z UpdateTip: new best=0000000000000010ecfb38bab6cc7a1fdb9f58ef124cb0b335072657949a2bb7 height=52821 version=0x2ba9a000 log2_work=71.508637 tx=910338 date='2024-10-30T08:57:21Z' progress=1.000000 cache=199.2MiB(35526txo)
2024-10-30T08:41:22Z UpdateTip: new best=0000000000a9c6707e0ea0156f34b9af5244fa3912893207be870d9ff2e596d5 height=52822 version=0x27ef4000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35527txo)
2024-10-30T08:41:26Z UpdateTip: new best=0000000000000010ecfb38bab6cc7a1fdb9f58ef124cb0b335072657949a2bb7 height=52821 version=0x2ba9a000 log2_work=71.508637 tx=910338 date='2024-10-30T08:57:21Z' progress=1.000000 cache=199.2MiB(35527txo)
2024-10-30T08:41:26Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35528txo)
2024-10-30T08:41:26Z UpdateTip: new best=0000000000526a014e4bb89cc21f2e65362e8601d74370d8e4791aaba0c31db3 height=52823 version=0x235a6000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35529txo)
2024-10-30T08:41:27Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35529txo)
2024-10-30T08:41:27Z UpdateTip: new best=0000000000e9bb7ab6a772aa9067a32f80d7aa74200c2cb6c0e88d3fab611e60 height=52823 version=0x22a9a000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35530txo)
2024-10-30T08:41:27Z UpdateTip: new best=00000000002c150329462592865f7e45f1530294049411fc18a3180cd8bf1261 height=52824 version=0x22cc0000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=0000000000e9bb7ab6a772aa9067a32f80d7aa74200c2cb6c0e88d3fab611e60 height=52823 version=0x22a9a000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000009f3f5320c8b5973d5449ff10b67ec5eb398ae5a909eb291e7e19af height=52823 version=0x23a04000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000001c1abd1fe3af4c6e3be09f307e37f9b2d303900d0b4aa5418c9922 height=52824 version=0x20282000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35532txo)
2024-10-30T08:41:28Z UpdateTip: new best=000000000067b058e19e6fa67ce4a4ea06a9f4fb423831779fdb3af68ad7baf9 height=52825 version=0x20d54000 log2_work=71.508637 tx=910342 date='2024-10-30T10:17:25Z' progress=1.000000 cache=199.2MiB(35533txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000001c1abd1fe3af4c6e3be09f307e37f9b2d303900d0b4aa5418c9922 height=52824 version=0x20282000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35535txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000006db2ea043f1cf2c4712c174b80aede29c88c5d75584b1c70269576 height=52825 version=0x21360000 log2_work=71.508637 tx=910342 date='2024-10-30T10:17:25Z' progress=1.000000 cache=199.2MiB(35536txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000006cb38e7b150bf8467aa15614de675cbb25c2093ef9512ced2ab9a2 height=52826 version=0x25624000 log2_work=71.508637 tx=910343 date='2024-10-30T10:37:26Z' progress=1.000000 cache=199.2MiB(35537txo)
2024-10-30T08:57:27Z UpdateTip: new best=000000000034b44adbfa99b6b4bfb1afa14553762474559d93d9eefd1ef544bb height=52827 version=0x208aa000 log2_work=71.508637 tx=910369 date='2024-10-30T10:57:27Z' progress=1.000000 cache=199.2MiB(35621txo)
My logs start with latest=52819.2024-10-30T07:37:22Z UpdateTip: new best=00000000008b7f827817f480a234a45db35bad26fc818b1b3ddc4486a886e1a1 height=52816 version=0x23142000 log2_work=71.508189 tx=910203 date='2024-10-30T09:17:21Z' progress=1.000000 cache=199.1MiB(35129txo)
2024-10-30T07:37:22Z UpdateTip: new best=000000000097c57f97856851424c98b41b386f5f8f06d754fa75853b9f79844b height=52817 version=0x22184000 log2_work=71.508189 tx=910232 date='2024-10-30T09:37:22Z' progress=1.000000 cache=199.1MiB(35158txo)
2024-10-30T07:57:23Z UpdateTip: new best=000000000087ffcdf82f94ab6491dfb93c89b0d12de6373aff2057a411995130 height=52818 version=0x23b8e000 log2_work=71.508189 tx=910276 date='2024-10-30T09:57:23Z' progress=1.000000 cache=199.1MiB(35226txo)
2024-10-30T08:17:24Z UpdateTip: new best=0000000000c0d93d5b1d12d139e52d8815eaec0a5ada7ad9280ff7bba040a2e5 height=52819 version=0x21220000 log2_work=71.508189 tx=910322 date='2024-10-30T10:17:24Z' progress=1.000000 cache=199.2MiB(35435txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000087ffcdf82f94ab6491dfb93c89b0d12de6373aff2057a411995130 height=52818 version=0x23b8e000 log2_work=71.508189 tx=910276 date='2024-10-30T09:57:23Z' progress=1.000000 cache=199.1MiB(35227txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000035ed59fc3e42e536a49feb64350dfb9a40556db2c52898f6eb0841 height=52819 version=0x20396000 log2_work=71.508189 tx=910322 date='2024-10-30T10:17:24Z' progress=1.000000 cache=199.2MiB(35436txo)
2024-10-30T08:37:25Z UpdateTip: new best=000000000040921cbbc6397caa75167939a8cf590d9cee672c5e689e5959095a height=52820 version=0x24486000 log2_work=71.508189 tx=910336 date='2024-10-30T10:37:25Z' progress=1.000000 cache=199.2MiB(35524txo)
2024-10-30T08:41:21Z UpdateTip: new best=0000000000000010ecfb38bab6cc7a1fdb9f58ef124cb0b335072657949a2bb7 height=52821 version=0x2ba9a000 log2_work=71.508637 tx=910338 date='2024-10-30T08:57:21Z' progress=1.000000 cache=199.2MiB(35526txo)
2024-10-30T08:41:22Z UpdateTip: new best=0000000000a9c6707e0ea0156f34b9af5244fa3912893207be870d9ff2e596d5 height=52822 version=0x27ef4000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35527txo)
2024-10-30T08:41:26Z UpdateTip: new best=0000000000000010ecfb38bab6cc7a1fdb9f58ef124cb0b335072657949a2bb7 height=52821 version=0x2ba9a000 log2_work=71.508637 tx=910338 date='2024-10-30T08:57:21Z' progress=1.000000 cache=199.2MiB(35527txo)
2024-10-30T08:41:26Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35528txo)
2024-10-30T08:41:26Z UpdateTip: new best=0000000000526a014e4bb89cc21f2e65362e8601d74370d8e4791aaba0c31db3 height=52823 version=0x235a6000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35529txo)
2024-10-30T08:41:27Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35529txo)
2024-10-30T08:41:27Z UpdateTip: new best=0000000000e9bb7ab6a772aa9067a32f80d7aa74200c2cb6c0e88d3fab611e60 height=52823 version=0x22a9a000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35530txo)
2024-10-30T08:41:27Z UpdateTip: new best=00000000002c150329462592865f7e45f1530294049411fc18a3180cd8bf1261 height=52824 version=0x22cc0000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=0000000000e9bb7ab6a772aa9067a32f80d7aa74200c2cb6c0e88d3fab611e60 height=52823 version=0x22a9a000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000001f4b611bb00cdfd72af34a4cbd7c7c22f71cf2f5bcd1e4a9ceea51 height=52822 version=0x26a52000 log2_work=71.508637 tx=910339 date='2024-10-30T09:17:22Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000009f3f5320c8b5973d5449ff10b67ec5eb398ae5a909eb291e7e19af height=52823 version=0x23a04000 log2_work=71.508637 tx=910340 date='2024-10-30T09:37:23Z' progress=1.000000 cache=199.2MiB(35531txo)
2024-10-30T08:41:28Z UpdateTip: new best=00000000001c1abd1fe3af4c6e3be09f307e37f9b2d303900d0b4aa5418c9922 height=52824 version=0x20282000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35532txo)
2024-10-30T08:41:28Z UpdateTip: new best=000000000067b058e19e6fa67ce4a4ea06a9f4fb423831779fdb3af68ad7baf9 height=52825 version=0x20d54000 log2_work=71.508637 tx=910342 date='2024-10-30T10:17:25Z' progress=1.000000 cache=199.2MiB(35533txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000001c1abd1fe3af4c6e3be09f307e37f9b2d303900d0b4aa5418c9922 height=52824 version=0x20282000 log2_work=71.508637 tx=910341 date='2024-10-30T09:57:24Z' progress=1.000000 cache=199.2MiB(35535txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000006db2ea043f1cf2c4712c174b80aede29c88c5d75584b1c70269576 height=52825 version=0x21360000 log2_work=71.508637 tx=910342 date='2024-10-30T10:17:25Z' progress=1.000000 cache=199.2MiB(35536txo)
2024-10-30T08:41:30Z UpdateTip: new best=00000000006cb38e7b150bf8467aa15614de675cbb25c2093ef9512ced2ab9a2 height=52826 version=0x25624000 log2_work=71.508637 tx=910343 date='2024-10-30T10:37:26Z' progress=1.000000 cache=199.2MiB(35537txo)
2024-10-30T08:57:27Z UpdateTip: new best=000000000034b44adbfa99b6b4bfb1afa14553762474559d93d9eefd1ef544bb height=52827 version=0x208aa000 log2_work=71.508637 tx=910369 date='2024-10-30T10:57:27Z' progress=1.000000 cache=199.2MiB(35621txo)
Then: 52819 gets replaced, new best 52822.
Then: 52822 gets replaced, new best 52823.
Then: 52823 gets replaced, new best 52824.
This keeps going like this. And tb1q2dsc94zq40nwnz27w5rxljwllutnwjtlxk44fz is almost always the winner. Last blocks mined to this address: 1-6, 8-16, 19-22.
It would be interesting to see what happens if not 2, but 200 "systems" would be doing this. That means 200 new blocks all fighting the block propagation wars at the exact same moment
I think I finally realized what this ckpool huckster does and monopolizes the minting.
- If he sees my competing block, he stales his previous block, so that he can invalidate mine, and mines on top of the other that he keeps in secret. I don't understand how this replaces my chain, since both chains have an equal chainwork, but every time that I've tried to broadcast my block, and do exactly what he does, his previous block (the one I'm building on top) suddenly becomes stale (according to mempool.space), another one replaces it, and a new block is mined on top of that new.
To give you an example:
So now, I'm left with a chain of equal chainwork with him. What decides the correct chain is the Portland guy, who'll send us to the past, and here's the tricky part: The moment the ckpool guy sees Portland's block, he quickly mines 4 blocks in sequence, immediately, each with 20 min + 1 sec time difference. This is the core advantage, because I cannot mine 4 blocks that fast with my CPU, so his chain becomes the correct one.
This is what I understand from my viewpoint. Maybe garlonicon or vjudeu know better.
- If he sees my competing block, he stales his previous block, so that he can invalidate mine, and mines on top of the other that he keeps in secret. I don't understand how this replaces my chain, since both chains have an equal chainwork, but every time that I've tried to broadcast my block, and do exactly what he does, his previous block (the one I'm building on top) suddenly becomes stale (according to mempool.space), another one replaces it, and a new block is mined on top of that new.
To give you an example:
- Last block is 50000 (call it A), and mined by ckpool miner.
- I mine block 50001 (call it B), with timestamp 20 min + 1 sec into the future, but do not broadcast it yet.
- 20 minutes pass, and I broadcast my block with submitblock, run by another node, which runs Bitcoin Core v28.
- Block 50000 (A) becomes stale, another block 50000 (call it block A') replaces my block A, and another one is mined on top of that block (call it block B').
So now, I'm left with a chain of equal chainwork with him. What decides the correct chain is the Portland guy, who'll send us to the past, and here's the tricky part: The moment the ckpool guy sees Portland's block, he quickly mines 4 blocks in sequence, immediately, each with 20 min + 1 sec time difference. This is the core advantage, because I cannot mine 4 blocks that fast with my CPU, so his chain becomes the correct one.
This is what I understand from my viewpoint. Maybe garlonicon or vjudeu know better.
1. Check your difficulty, if it is not 0x1d00ffff, then it is unlikely, that you will get it on your CPU.
It's 1.Code:
getdifficulty
1
1
Quote
2. You should get at least some stale blocks, which will then be quickly reverted by ASIC miners.
I do "mine", they're just not propagated, or cannot reach mempool.space. To me, this means that nodes refuse to accept them, even though they are valid and 20 min + 1 sec into the future. Let me give you an example. Currently, chain tip is block 52712:
Code:
getblock 00000000000a608c151be0caf1d9b30a6b9d01399c0c5d83588de8b928f7c06e
{
"hash": "00000000000a608c151be0caf1d9b30a6b9d01399c0c5d83588de8b928f7c06e",
"confirmations": 1,
"height": 52712,
"version": 538828800,
"versionHex": "201de000",
"merkleroot": "f4b01c1a140af0ee83630ae25f8ada809f05a86019a9786ae8d17cee2cd90942",
"time": 1730214980,
"mediantime": 1730211376,
"nonce": 355271026,
"bits": "1d00ffff",
"difficulty": 1,
"chainwork": "0000000000000000000000000000000000000000000000b57bfd148cea09e921",
"nTx": 35,
"previousblockhash": "00000000005e1a4fdd3747afe69b4bd5ffb97a5d8868e35282accb856a67c141",
"strippedsize": 36245,
"size": 97439,
"weight": 206174,
"tx": [
"ef930b7848bf91fef8cd0de918d1484db44b1a4c367277defbf332a3977cb27d",
"d45a87e5712d92cca6507244e6ce9f9048ac889f35844252c46871706c0df64d",
"6602414c0438366e904e35d44fb1f660c9eeb3fad1303229409bbc2f7883518d",
"c4e9b178a1f463bdb34700d79561b59934a53e87b1a69e97705d19d6bb03c3e9",
"34780e250e2f3f9467bf89a144a9ea96d02f6111d6591a88653ac36aca3c5216",
"db8247444bfdd663a18ad8831da4faf2f4527e7ddf3107ea92f299d13c2e7b3e",
"dee89a8490179457508fe7cdfa6af04ca6ac51f2ab47d4c112362bf486b0b346",
"ddb89384503205cd4cfb777c25de2751edc7099da25a7d69170e4f665211ebc9",
"f9fb949839f4f63c7813bed75519b8769c242dea0820ed707fe5ba7e6327c065",
"d00c6ce0c52b9ab8bbb376b2fc4a90e7e2859c4e91bd839d2f8623789a057908",
"ca113e7a7f41929740f8a7988ec0ad529bfc2b1b4e86ab5be0a4958e7ce70f5b",
"d4d771bb6f78a44c034053a0c60b469e231354de220798c9260f561e0058d0c0",
"6f1713a67127241aa6a0894563e3834558564647902d0be92f9b191bc4bb85d5",
"8714d257f99e6de5af387b9e56e3c81a60955049688ff9268ee60234b79a37bd",
"01d729720ff20ba313c5cb976d1b867f71535e382535c86feea42d0e5583a23f",
"20d32496e40fdc543f8078d782f06997ebd9918148a8063e3eedb6e599a708f4",
"eef9447aae5b4d8d407204f0e81b3efbfb8127f65461d8d6ad2f316261a27802",
"a4be54b8cfbc508849b7e19bf3be4aa319091fdb7f91971d5889a9128be49b15",
"604655083f30e0c95afaa92f71e19e8b0a0a53dbb06f6768666de377fa875aee",
"6ebb7a29261543407ffcb2c3ae91f7e6e1e96ae1aa5458860a22205e9d984d15",
"0d13e06fb390ff6c2038ca06727d76c9a121bf8668590667ecd88851d9518cb5",
"3cef2fa1830050d11d23d03602b2ff518c7c5eebbc810c9b68d3b495aa565b94",
"f3934d98d4bf682ea0d27f8a2516ea6c7905bce294b230b0e4d3253937734c08",
"eff35edcf9d36387d0ad188c26d7d5b9e7112d87542eaa83deae588f0c477707",
"91fceae9cbe226bfdf773c78ed79579b8956059370128f4d060aacaa44b9a0fe",
"ddf4f28b935820a255125781f3e64356f741b7afc730a699c94fdc788376f70b",
"c705d5910c2b6d22cab0f7ec79425dba5384475777dc20958fd3b37bbba12f35",
"5d055533109c50fbbd58283bf05bfab6437d1e1fd41c066cbc9c31aea6777448",
"1ccd97166be6245ff7604f83b88e78e09501da3e61489b861799f2fe415b034b",
"5c5bb16e678625faace6b650d40e58e570ea3a6276a4893986d1907d06029d5c",
"f51194632b157a5681363c40f21055e57ef990a29a0619d575f5d9cfd35f9b61",
"2d249b536408b10dc5a02830f939fb50abf859137e5179b26ed4157a6481666a",
"76c46caeaf550d482e355bb1aa0d3ea6096f75b0fc9406ccfd9884c3d0ae2682",
"527e0069ed4833a06bf937e7244a2f55673cf2410067329fa880b0eff0d7aba4",
"f88b04822a1ac37d9c58384cf2969a4edc92a36093f502f4fa97cc40c2a3c2d0"
]
}
{
"hash": "00000000000a608c151be0caf1d9b30a6b9d01399c0c5d83588de8b928f7c06e",
"confirmations": 1,
"height": 52712,
"version": 538828800,
"versionHex": "201de000",
"merkleroot": "f4b01c1a140af0ee83630ae25f8ada809f05a86019a9786ae8d17cee2cd90942",
"time": 1730214980,
"mediantime": 1730211376,
"nonce": 355271026,
"bits": "1d00ffff",
"difficulty": 1,
"chainwork": "0000000000000000000000000000000000000000000000b57bfd148cea09e921",
"nTx": 35,
"previousblockhash": "00000000005e1a4fdd3747afe69b4bd5ffb97a5d8868e35282accb856a67c141",
"strippedsize": 36245,
"size": 97439,
"weight": 206174,
"tx": [
"ef930b7848bf91fef8cd0de918d1484db44b1a4c367277defbf332a3977cb27d",
"d45a87e5712d92cca6507244e6ce9f9048ac889f35844252c46871706c0df64d",
"6602414c0438366e904e35d44fb1f660c9eeb3fad1303229409bbc2f7883518d",
"c4e9b178a1f463bdb34700d79561b59934a53e87b1a69e97705d19d6bb03c3e9",
"34780e250e2f3f9467bf89a144a9ea96d02f6111d6591a88653ac36aca3c5216",
"db8247444bfdd663a18ad8831da4faf2f4527e7ddf3107ea92f299d13c2e7b3e",
"dee89a8490179457508fe7cdfa6af04ca6ac51f2ab47d4c112362bf486b0b346",
"ddb89384503205cd4cfb777c25de2751edc7099da25a7d69170e4f665211ebc9",
"f9fb949839f4f63c7813bed75519b8769c242dea0820ed707fe5ba7e6327c065",
"d00c6ce0c52b9ab8bbb376b2fc4a90e7e2859c4e91bd839d2f8623789a057908",
"ca113e7a7f41929740f8a7988ec0ad529bfc2b1b4e86ab5be0a4958e7ce70f5b",
"d4d771bb6f78a44c034053a0c60b469e231354de220798c9260f561e0058d0c0",
"6f1713a67127241aa6a0894563e3834558564647902d0be92f9b191bc4bb85d5",
"8714d257f99e6de5af387b9e56e3c81a60955049688ff9268ee60234b79a37bd",
"01d729720ff20ba313c5cb976d1b867f71535e382535c86feea42d0e5583a23f",
"20d32496e40fdc543f8078d782f06997ebd9918148a8063e3eedb6e599a708f4",
"eef9447aae5b4d8d407204f0e81b3efbfb8127f65461d8d6ad2f316261a27802",
"a4be54b8cfbc508849b7e19bf3be4aa319091fdb7f91971d5889a9128be49b15",
"604655083f30e0c95afaa92f71e19e8b0a0a53dbb06f6768666de377fa875aee",
"6ebb7a29261543407ffcb2c3ae91f7e6e1e96ae1aa5458860a22205e9d984d15",
"0d13e06fb390ff6c2038ca06727d76c9a121bf8668590667ecd88851d9518cb5",
"3cef2fa1830050d11d23d03602b2ff518c7c5eebbc810c9b68d3b495aa565b94",
"f3934d98d4bf682ea0d27f8a2516ea6c7905bce294b230b0e4d3253937734c08",
"eff35edcf9d36387d0ad188c26d7d5b9e7112d87542eaa83deae588f0c477707",
"91fceae9cbe226bfdf773c78ed79579b8956059370128f4d060aacaa44b9a0fe",
"ddf4f28b935820a255125781f3e64356f741b7afc730a699c94fdc788376f70b",
"c705d5910c2b6d22cab0f7ec79425dba5384475777dc20958fd3b37bbba12f35",
"5d055533109c50fbbd58283bf05bfab6437d1e1fd41c066cbc9c31aea6777448",
"1ccd97166be6245ff7604f83b88e78e09501da3e61489b861799f2fe415b034b",
"5c5bb16e678625faace6b650d40e58e570ea3a6276a4893986d1907d06029d5c",
"f51194632b157a5681363c40f21055e57ef990a29a0619d575f5d9cfd35f9b61",
"2d249b536408b10dc5a02830f939fb50abf859137e5179b26ed4157a6481666a",
"76c46caeaf550d482e355bb1aa0d3ea6096f75b0fc9406ccfd9884c3d0ae2682",
"527e0069ed4833a06bf937e7244a2f55673cf2410067329fa880b0eff0d7aba4",
"f88b04822a1ac37d9c58384cf2969a4edc92a36093f502f4fa97cc40c2a3c2d0"
]
}
As you can see time is 1730214980. Therefore, my block should have a timestamp of 1730214980+1201=1730216181.
My CPU miner solves the block, and I must run submitblock in 17:36:21:
Code:
000000206ec0f728b9e88d58835d0c9c39019d6b0ab3d9f1cae01b158c600a00000000009fb9e68f0fac5d0f17f05ffb1761043cd351cfe651a2ab337dec3214472e4453f5002167ffff001d029cef750a01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0403e9cd00ffffffff023128062a01000000160014343fca89c852788c087728070f294e80ce72fe4a0000000000000000266a24aa21a9eda53a8bfb254f15e6748b54555bf9ec196b8006a21a0961f5d2907862d02a0b4800000000020000000001024b1b13f4b1167d6159fd498992ad046f8f71ec5755fe4198cab7ac92e45ceb7702000000171600142b1c280d00e83c08c23eee73718a52a23919c281fdffffff11819d9591fab2aa26148d05e9fee0cf07cf14be6b72682ecc4d0554c7f28b8700000000171600148b319b19690f5fba5266b88f2e77ed91d7db06b2fdffffff02a7e3050000000000160014301472af85131eaa85510f40f2fc403bb6922d2c11c509000000000017a914f1d1a421b077afe7b3e7230466c57993ceec514f870247304402204d07f0641dab54de757fb7ed38c08a951028ef0e4b837128d19e6a49b703873b02207720d1a0842f0b8bbdf17da91143e7a5dbeb32e082ac42259edf556e465d1faf01210352d80243ffb02f13b666b8c9fdc9c269fe4d56409f46d824a6a456bf89ac107402473044022063a749abf2e4f7844debebf6ca921cf11248f6b0485760406136d9822b64cbf0022077a761fab18be627b6927020bf0bbce1fabc6bf00e773faa23730f1ba59f5abc012102cd0704a37c755c899013146152bf516c4ebc504322b7b6db9598e720071c51dddfcd0000020000000001028b1b0bf2c1f0e5bdeee4ba6af448f90cff9d7994654c28fd80eb1238af0d2ca60000000000fdffffff84ac0ce43bba7e0b7eda6efc7c265f5e27c1406c7dd874d4a479b7cde5a375ca0200000000fdffffff02a7e3050000000000160014d890ec475d12c18f64d282b9e41661ad67e94848be6a0700000000001976a9141d5368003c0105793cbafaa6b1e8dfff7e62ce2688ac0247304402202012342a05765e719372b2545bcffe44f804a128493d55426f8becdef1512e36022048144d08564d62ea6ebaea596c761a22f0aebaaed40995bca15522ca5bfe98d8012103c3f8f175b8c601fb3aaef7fd237bee1757794964bfe8aa7b047c2030891ade6e0247304402207281521f5c79db8b6388616485b080f0dad6dbe9d45fbe4099d9f71b01360108022071bbda98db277c2adaf8328600b3ef5453e32de6a15c3f32f6af3c30fd2ade640121027c7ab07c5e25e5d261c0b390072f117d00bb741bd4c38e4b67040e5108b9bf4890cd0000020000000001029bf403cb4e06a460b514d77cb3964bde34112b84514f4624fd587489851d024f0000000000ffffffff9bf403cb4e06a460b514d77cb3964bde34112b84514f4624fd587489851d024f0100000000ffffffff018e400f0000000000225120090b425f74f67c3ccf1bef78659330074af0ad8653447d858dae0a5c2f0af0930140e6d8cb52189b975c4983b06ce798d13f1e8aac28fd76fbd94d86664dbb1a71b7834c5b352b7e12f8d152abe149530fdcfaa215055c5e6df1d1b69f562d66af24014051c6c33b82325721b2540aca16f7e549822fddd8848c3324735fee2b996244df0b0b7204cfe20d34c1df9de3d4ecadd47f768b1ecf3f86ec71ee09d947abf9d900000000020000000001024afe21818c5ea45c9a52dfd5c3e86f2deff68e1bb11ecdb700368af19c0954b30100000000fdffffff38081d223d857966fc08f1c1e22bff2455878e5ed35a66c3f8e23c42f04bc6940200000000fdffffff0311c50900000000001600142f8e4a5a1a76efe69a40474edf842965aab9f6a21a740b00000000001976a9144e4bd56d56514aa6ed1d6badafe559a494cf6cf588ac6cab0200000000001600143f568886b0e3f002c573c0249c3deb11c5bd1f6b02473044022055dd3dbf7bb8be5e6efab9cfa3e5d02ba29f1b25c7228d9d33f2b75b2b2b1a7802205f315897aa8f471e3ea9e287669d3b9c68cdbabe917111b0fc34e0184335ab71012102e428935fe9e292b8b9db4d345c1d5a1ce251b8ee80de10e3d9fc20132112113d02473044022058bae9b88c4032955833731e9dfb94078d4ebaee2c1841bcf9b7e87f2544ff5f022046459f2a54bc8d078a5039eab5cf71bf0ff424b61d09ea36ac219ebd681b698e0121020a7f1ac657131971bcc040889c12bb94a4b54c5821c8cc449c3883f235bbeb77e8cd0000020000000001014b035b41fef29917869b48613eda0195e0788eb8834f60f75f24e66b1697cd1c0100000000fdffffff02bca11adf0000000022512079c7a0a6de781f0bc0d0db2a3c937790007d1a3d3b402035500d9d26c54d73166f590000000000002251205d74e18e951e315e52a2300aaf50825a6cbe5889bcfa5db0dd72d54b46d3778f0247304402202d9f6f820e09c70baf85e2e046e5c17b72e906a2aad4872463fabf65e0e819bb0220086e0d9fe36341d5b362c8e3bfb2182c5b69f46df350f8105dbf1a23200f5da20121020c4f97ff62523697d7a228edf66ffdedfc99c9a4e231abd7fd696b5a8ce4d6c1e8cd000002000000000101619b5fd3cfd9f575d519069aa290f97ee55510f2403c3681567a152b639411f50000000000fdffffff023cc645de00000000225120ac2c4eb73f57698c22ac54730845bfb5923067da079e6273311b76396d4b4dea8958000000000000225120f826634640274f10f7a4da1aed2b74ea9e66aee465c3778d132767ab07ee9f8902473044022045cd7284922e266aa60847a6a0dfd953bd6539664d69f15c148fedc850abf12402203f70f09c6ce7ca3e2ab6691fdaa2ed9ccbc4210d0690f829e553acdbd6bf0470012103ab9b6bc285948a47e1aa1edc314fb3205f4e7f4c70e8c5203a7bdbf7fd0824fae8cd000002000000000101457acff6d889593f54a4d9f2b82277fb5ddf834c9b2e6a4e739eda982f2e593d0000000000ffffffff0220a1070000000000225120090b425f74f67c3ccf1bef78659330074af0ad8653447d858dae0a5c2f0af093d49e070000000000225120090b425f74f67c3ccf1bef78659330074af0ad8653447d858dae0a5c2f0af0930140d8ba354ab181c78c737c8be0ec9c48440fdf22856ee8c1ee9cf6972d0b83d666c8373ba26c98c0bb97df8c7597ce8ac8da932acb6f63eaef4038b74e3a43e5030000000002000000000101eb4c0b58aabeeb49710975ba9b9b3f1a6b0cbb1304dc7b052b8ab0ca1197aed80100000000fdffffff01328601000000000016001401897a6e1b87840f60ca25c58e6cd4c683cfbf760247304402207b68cfc1c709acff9700a5074da8ca1d87757a4ab2c4fb62bf15acbc85a8e46c022075f0da5647bb82668bce50147fd6186d56edb0c38427d84573a1b13cd70f6ae60121031b5f60e7ea14b7011781bccb1fbd6cd87106057f707b062e6e4b6d0d0e3fdb6de8cd000002000000000101e10e8a5a92a3d632fa0736bd2c60453d6bcd3b75d8b9c8f61c30ee75fdb62ea40000000000fdffffff01c4850100000000001600144f38d126565c60b66c4dc2ca18cf556558f6759f024730440220064853892e6c1465b51ac84d22a9937d4b546066a71a6cfe2998d67ce0e5976f02207162c72b3bf25bc2809b23099b674520a7dbe98ef78098923db97a88aa618d7d0121026e59afa1d2d7206bac38e8ee3818be585e3dc22a33799c9ba27d983289140bd6e8cd0000
Just tried. Received "inconclusive" again, and ckpool miner claimed it again: https://mempool.space/testnet4/block/0000000000f483d86815e9546d61990e476255690ea339b5c7004fcf14fd012d.
Edit: Nevermind, this time Portland mined again with normal difficulty and the ckpool miner mined another 4 after him, but the logic applies even when this doesn't happen.
Quote
I have been trying since yesterday to mine a block, but no luck
1. Check your difficulty, if it is not 0x1d00ffff, then it is unlikely, that you will get it on your CPU.2. You should get at least some stale blocks, which will then be quickly reverted by ASIC miners.
3. If the difficulty is high, the last block, for adjusting the new difficulty, takes a lot of time, because CPUs cannot mine it. For example: once it took 4 hours, instead of 10 minutes. Maybe with the new, higher difficulty, it takes even longer.
Quote
But, I didn't do anything manually.
Because even if you use Bitcoin Core alone, then still, sometimes you may be just lucky enough, to get your block faster, than anyone else.Quote
but the next one should be 20 minutes + 1 sec later
It doesn't have to be. Any ASIC can put any time, up to 2 hours in the future, or in the past, relatively to the current time.Quote
And then the next blocks are broadcasted at the same time (I was watching it live), each with 20 minutes + 1 sec timestamp difference.
Exactly. Everyone is mining two hours in the future. Then, some "honest" miner puts the current time, and then, CPU miners are moving it back to the future.Quote
Did Portland.HODL mine them with normal difficulty (diff>1), and then the ckpool miner took advantage of it?
Yes, Portland.HODL is mining blocks with real network difficulty. And when they put the real time, then next miners are taking advantage of that, and pushing everything again two hours into the future. Which means, that the more ASIC blocks are there, the more opportunities are there, to mine the same timestamps multiple times, which is why you have >80% blocks with minimal difficulty.Quote
Is it possible to discard my last mined block which was not propagated to the network?
If you didn't mine anything else on top of it, then use "preciousblock", and pick someone else's block. Or: you can also use "invalidateblock", but then, the rest of the network won't see your blocks later. And: if your blocks are valid, then you always have a chance, to trigger a deeper reorg, because after each block, you have a new chance, to propagate your chain tip faster than others. 
garlonicon, I have been trying since yesterday to mine a block, but no luck. I don't know how I did it last time with block 52398, but I noticed that it was mined exactly 20 minutes + 1 sec after the previous one, and the same time before the next one. But, I didn't do anything manually. Could it be that it simply happened? What are the chances?
BTW, check this block, and the next three: https://mempool.space/testnet4/block/00000000007f544df2da77f06dd1a95629101c25fe81a7eced910711ab1a7c92. It has a timestamp of "2024-10-29 14:36:09", but the next one should be 20 minutes + 1 sec later, while it is "2024-10-29 13:36:07". And then the next blocks are broadcasted at the same time (I was watching it live), each with 20 minutes + 1 sec timestamp difference.
Did Portland.HODL mine them with normal difficulty (diff>1), and then the ckpool miner took advantage of it? I just don't get it.
Edit: Is it possible to discard my last mined block which was not propagated to the network? My node keeps it, and I want to discard it so I can retry without mining on top of a block that is soon to be not in the most worked chain. I have only achieved this by deleting the chain and resyncing.
BTW, check this block, and the next three: https://mempool.space/testnet4/block/00000000007f544df2da77f06dd1a95629101c25fe81a7eced910711ab1a7c92. It has a timestamp of "2024-10-29 14:36:09", but the next one should be 20 minutes + 1 sec later, while it is "2024-10-29 13:36:07". And then the next blocks are broadcasted at the same time (I was watching it live), each with 20 minutes + 1 sec timestamp difference.
Did Portland.HODL mine them with normal difficulty (diff>1), and then the ckpool miner took advantage of it? I just don't get it.
Edit: Is it possible to discard my last mined block which was not propagated to the network? My node keeps it, and I want to discard it so I can retry without mining on top of a block that is soon to be not in the most worked chain. I have only achieved this by deleting the chain and resyncing.
Is invalidateblock what you are looking to do?
https://bitcoin.stackexchange.com/questions/124242/what-is-the-role-of-invalidateblock-rpc-command-and-are-there-any-possible-tra
Although at this point the TN4 blockchain is small enough that it probably took me longer to type this then it would to re-sync from a local node assuming fast hardware.
-Dave
garlonicon, I have been trying since yesterday to mine a block, but no luck. I don't know how I did it last time with block 52398, but I noticed that it was mined exactly 20 minutes + 1 sec after the previous one, and the same time before the next one. But, I didn't do anything manually. Could it be that it simply happened? What are the chances?
BTW, check this block, and the next three: https://mempool.space/testnet4/block/00000000007f544df2da77f06dd1a95629101c25fe81a7eced910711ab1a7c92. It has a timestamp of "2024-10-29 14:36:09", but the next one should be 20 minutes + 1 sec later, while it is "2024-10-29 13:36:07". And then the next blocks are broadcasted at the same time (I was watching it live), each with 20 minutes + 1 sec timestamp difference.
Did Portland.HODL mine them with normal difficulty (diff>1), and then the ckpool miner took advantage of it? I just don't get it.
Edit: Is it possible to discard my last mined block which was not propagated to the network? My node keeps it, and I want to discard it so I can retry without mining on top of a block that is soon to be not in the most worked chain. I have only achieved this by deleting the chain and resyncing.
BTW, check this block, and the next three: https://mempool.space/testnet4/block/00000000007f544df2da77f06dd1a95629101c25fe81a7eced910711ab1a7c92. It has a timestamp of "2024-10-29 14:36:09", but the next one should be 20 minutes + 1 sec later, while it is "2024-10-29 13:36:07". And then the next blocks are broadcasted at the same time (I was watching it live), each with 20 minutes + 1 sec timestamp difference.
Did Portland.HODL mine them with normal difficulty (diff>1), and then the ckpool miner took advantage of it? I just don't get it.
Edit: Is it possible to discard my last mined block which was not propagated to the network? My node keeps it, and I want to discard it so I can retry without mining on top of a block that is soon to be not in the most worked chain. I have only achieved this by deleting the chain and resyncing.
Quote
Shouldn't this command give me a block template with timestamp=1256804525?
To mine a valid block, you have to stick to the Median Time Past rule. Which means, that the timestamp of your block has to be greater, than the median time of the past 11 blocks. If it is not, then your block is invalid.Quote
For some reason, it gives me curtime=1730198133
It is 20 minutes and 1 second greater, than the time of the previous block. It is the smallest value, which allows you to CPU-mine it. If you would put a smaller value, you would mine with ASICs difficulty.And if you use an unmodified client, then you will get the current time here, which will almost always mean, that you will be mining with ASIC difficulty.
Quote
Just now it changed to 1730199334
1730199334-1730198133=1201 (20 minutes and 1 second)
Shouldn't this command give me a block template with timestamp=1256804525?
For some reason, it gives me curtime=1730198133, no matter how many times I run it, which means it's neither the current UNIX timestamp (updated every second).
PS: I'm really bad with JSON arguments.
Edit: Just now it changed to 1730199334.
Code:
getblocktemplate '{"rules": ["segwit"], "curtime":1256804525}'
{
"capabilities": [
"proposal"
],
"version": 536870912,
"rules": [
"csv",
"!segwit",
"taproot"
],
"vbavailable": {
},
"vbrequired": 0,
"previousblockhash": "00000000008b9664fa426565154be2efe722befeaa0d12ca4f650515efac9c82",
"transactions": [
{
"data": "02000000000103368186ade9763ab8b709510c45e37d8e658cacad877752ebd7943f630cd8fbef0000000000fdffffffceada9452e408035f8c54cd8d065fa166bfc4083cb7122a1849886587a27d0c40100000000fdffffff27bad148a29d06426f864e9e960f800d06e2174a9ac52f816fa4393df53fca7a0100000000fdffffff02ba9a0e000000000017a914c27862ebe84891b7805460dfe97d72c56ce584b787560b0800000000001600148d133bfc6e5d92911debd97e085c2ad5837cbfd802473044022005ffea6435d53a4de103330e0911243a4744999b1b31bd383e15e464dda02d6f022021319be0673a6e886f792d63719deaea0261549ea265d10bdd80eb1604ec79570121020d5d0086ea2b61855a7aa91d3c9fbcd06a63ea1df5b3ee834e8188b63628a30f0247304402202c8defb26a7b023a9907dd68bafe0da43d18d17f94573b60ee30899f164e057602206ee909775b2c1e144bc29a0654ad1e8e002434e944cf418172c9550e67cad22c0121030769ea108f50adfe754af5bc39c72969856d29373b8bb7546b5d1fe21db972e502473044022031b5f237b5737bc89e2a982ff3812e33c8db0cd7c98d267afc5f39a1e081a0c1022002739255960ecb35e4589d0cfe97ce046814e4f3f5c531e489181e58ecde7069012103fafe0d4064daf524038271b9cdf0e1a9f2f60c4310538f9f0a9b889fe9789d12bccd0000",
"txid": "a41b661daf4cc182409e328ddae6a470a4d90251c67b7e7dc604ba1b86fc80bf",
"hash": "2e66680a31d22cdfa7258e4e73290eb9f88ab355ab352bb8353449e589030789",
"depends": [
],
"fee": 11124,
"sigops": 3,
"weight": 1107
},
{
"data": "020000000001025d140f62f53730ce372236a7840d238d5b7e8ae35a59fe177543acacf923789e0000000000fdffffff882084bf4983b4279e49b8bccfb57af2057cf73484da3e81b91333dff70768460000000000fdffffff02ba9a0e00000000001976a914c3f81de188b3dcbecef44617ac23c5238b26e18288ac560b08000000000016001491a94f250466a383e7f499524fbd9630f89977f8024730440220292978b5733cbede15e314b13e8be8204fb8a48ccd0b175133136765266f818902204f3c6161d6a46596b0d7e98ac45049d44f1968525fc68853e463e91c5f3b57ee0121032a4b2ad275eaaf10cefb8ba4fe7f0d218c37c662a61bbe097633107fc1a782c70247304402202a2fe41529037eec9cc1a2eb1309a1619c0e6bc275783d2b3cc8a4aa621dcda002203ffbc67e319b63e142965703ed1a537e5779203d85738082c84fcf1d04535105012103a31349b51f38eeb7d94970cc61644dc364980f24d5aae5a06b26c2fd66632058bccd0000",
"txid": "26937964d0746960449bbbfdae1c0ac4b26cf9fe6b11e54431aaee6a7ff8b489",
"hash": "b5573e757761015a97b4bde5aea7de8f243a0b092bd61f6c5df59ff65badc980",
"depends": [
],
"fee": 8279,
"sigops": 6,
"weight": 844
},
{
"data": "02000000000102fe5f138a38444350e2db577f1e7d8c864609ee0ea29827a3363ceb5b38ccde0801000000171600140244ae059c86144e3715dda29471518091f69e21fdffffffd99d7c43b5210c634bcd44ea6e9167b0537d60d6bfe7af40c37659e0368ccf3c000000001716001412a1eb2543c57b8f8d895a5d995cf47e6ff8dedefdffffff03e26a080000000000160014c9d405208bfa1d6f48bb929b34745930cb2f22e9fde704000000000016001481595bd61b954edc3084fe13bbf7210b197ff272ba9a0e000000000017a9149d3af4379356074dd29ba47fee26f674316baf2787024730440220326000f7bb7b211f3a8f3259017af0f1b440aeab2280e14456d2ce24d2aa05d30220757fc62d386b1c791805f80f33a8150b795a3057989007bdb3e1802f09c75db401210232fd2acaee76997f7d4d1a18b5ea21405568d96ab29e8a34270a9a6142ba60f402473044022002c10134d2c036513b9d6caa4ee9bf68e1d03c3dfe0513cee82e51df6d94603e022025c21d5c11c36597084a48524bb3b93fc64304d0e856a35332bb9eca5bdb0afe012102c41f953c1c7985e9388c8434ddef328712a973a691128c0ee6402c52b7eb5500a5cd0000",
"txid": "4c00cdd88c010f30673fe15ac645026be78a13ce3269f5df80723923fba58630",
"hash": "027fa920f09093e4480957404b88f285008ebffd7f28fb88873e4acf0db5cf10",
"depends": [
],
"fee": 286,
"sigops": 2,
"weight": 1144
}
],
"coinbaseaux": {
},
"coinbasevalue": 5000019689,
"longpollid": "00000000008b9664fa426565154be2efe722befeaa0d12ca4f650515efac9c82158",
"target": "00000000ffff0000000000000000000000000000000000000000000000000000",
"mintime": 1730190928,
"mutable": [
"time",
"transactions",
"prevblock"
],
"noncerange": "00000000ffffffff",
"sigoplimit": 80000,
"sizelimit": 4000000,
"weightlimit": 4000000,
"curtime": 1730198133,
"bits": "1d00ffff",
"height": 52669,
"default_witness_commitment": "6a24aa21a9ed524f04fbd1aea9ee9ede54e8af1d44f91c968ed5c0233b3e5d25482355107df6"
}
{
"capabilities": [
"proposal"
],
"version": 536870912,
"rules": [
"csv",
"!segwit",
"taproot"
],
"vbavailable": {
},
"vbrequired": 0,
"previousblockhash": "00000000008b9664fa426565154be2efe722befeaa0d12ca4f650515efac9c82",
"transactions": [
{
"data": "02000000000103368186ade9763ab8b709510c45e37d8e658cacad877752ebd7943f630cd8fbef0000000000fdffffffceada9452e408035f8c54cd8d065fa166bfc4083cb7122a1849886587a27d0c40100000000fdffffff27bad148a29d06426f864e9e960f800d06e2174a9ac52f816fa4393df53fca7a0100000000fdffffff02ba9a0e000000000017a914c27862ebe84891b7805460dfe97d72c56ce584b787560b0800000000001600148d133bfc6e5d92911debd97e085c2ad5837cbfd802473044022005ffea6435d53a4de103330e0911243a4744999b1b31bd383e15e464dda02d6f022021319be0673a6e886f792d63719deaea0261549ea265d10bdd80eb1604ec79570121020d5d0086ea2b61855a7aa91d3c9fbcd06a63ea1df5b3ee834e8188b63628a30f0247304402202c8defb26a7b023a9907dd68bafe0da43d18d17f94573b60ee30899f164e057602206ee909775b2c1e144bc29a0654ad1e8e002434e944cf418172c9550e67cad22c0121030769ea108f50adfe754af5bc39c72969856d29373b8bb7546b5d1fe21db972e502473044022031b5f237b5737bc89e2a982ff3812e33c8db0cd7c98d267afc5f39a1e081a0c1022002739255960ecb35e4589d0cfe97ce046814e4f3f5c531e489181e58ecde7069012103fafe0d4064daf524038271b9cdf0e1a9f2f60c4310538f9f0a9b889fe9789d12bccd0000",
"txid": "a41b661daf4cc182409e328ddae6a470a4d90251c67b7e7dc604ba1b86fc80bf",
"hash": "2e66680a31d22cdfa7258e4e73290eb9f88ab355ab352bb8353449e589030789",
"depends": [
],
"fee": 11124,
"sigops": 3,
"weight": 1107
},
{
"data": "020000000001025d140f62f53730ce372236a7840d238d5b7e8ae35a59fe177543acacf923789e0000000000fdffffff882084bf4983b4279e49b8bccfb57af2057cf73484da3e81b91333dff70768460000000000fdffffff02ba9a0e00000000001976a914c3f81de188b3dcbecef44617ac23c5238b26e18288ac560b08000000000016001491a94f250466a383e7f499524fbd9630f89977f8024730440220292978b5733cbede15e314b13e8be8204fb8a48ccd0b175133136765266f818902204f3c6161d6a46596b0d7e98ac45049d44f1968525fc68853e463e91c5f3b57ee0121032a4b2ad275eaaf10cefb8ba4fe7f0d218c37c662a61bbe097633107fc1a782c70247304402202a2fe41529037eec9cc1a2eb1309a1619c0e6bc275783d2b3cc8a4aa621dcda002203ffbc67e319b63e142965703ed1a537e5779203d85738082c84fcf1d04535105012103a31349b51f38eeb7d94970cc61644dc364980f24d5aae5a06b26c2fd66632058bccd0000",
"txid": "26937964d0746960449bbbfdae1c0ac4b26cf9fe6b11e54431aaee6a7ff8b489",
"hash": "b5573e757761015a97b4bde5aea7de8f243a0b092bd61f6c5df59ff65badc980",
"depends": [
],
"fee": 8279,
"sigops": 6,
"weight": 844
},
{
"data": "02000000000102fe5f138a38444350e2db577f1e7d8c864609ee0ea29827a3363ceb5b38ccde0801000000171600140244ae059c86144e3715dda29471518091f69e21fdffffffd99d7c43b5210c634bcd44ea6e9167b0537d60d6bfe7af40c37659e0368ccf3c000000001716001412a1eb2543c57b8f8d895a5d995cf47e6ff8dedefdffffff03e26a080000000000160014c9d405208bfa1d6f48bb929b34745930cb2f22e9fde704000000000016001481595bd61b954edc3084fe13bbf7210b197ff272ba9a0e000000000017a9149d3af4379356074dd29ba47fee26f674316baf2787024730440220326000f7bb7b211f3a8f3259017af0f1b440aeab2280e14456d2ce24d2aa05d30220757fc62d386b1c791805f80f33a8150b795a3057989007bdb3e1802f09c75db401210232fd2acaee76997f7d4d1a18b5ea21405568d96ab29e8a34270a9a6142ba60f402473044022002c10134d2c036513b9d6caa4ee9bf68e1d03c3dfe0513cee82e51df6d94603e022025c21d5c11c36597084a48524bb3b93fc64304d0e856a35332bb9eca5bdb0afe012102c41f953c1c7985e9388c8434ddef328712a973a691128c0ee6402c52b7eb5500a5cd0000",
"txid": "4c00cdd88c010f30673fe15ac645026be78a13ce3269f5df80723923fba58630",
"hash": "027fa920f09093e4480957404b88f285008ebffd7f28fb88873e4acf0db5cf10",
"depends": [
],
"fee": 286,
"sigops": 2,
"weight": 1144
}
],
"coinbaseaux": {
},
"coinbasevalue": 5000019689,
"longpollid": "00000000008b9664fa426565154be2efe722befeaa0d12ca4f650515efac9c82158",
"target": "00000000ffff0000000000000000000000000000000000000000000000000000",
"mintime": 1730190928,
"mutable": [
"time",
"transactions",
"prevblock"
],
"noncerange": "00000000ffffffff",
"sigoplimit": 80000,
"sizelimit": 4000000,
"weightlimit": 4000000,
"curtime": 1730198133,
"bits": "1d00ffff",
"height": 52669,
"default_witness_commitment": "6a24aa21a9ed524f04fbd1aea9ee9ede54e8af1d44f91c968ed5c0233b3e5d25482355107df6"
}
For some reason, it gives me curtime=1730198133, no matter how many times I run it, which means it's neither the current UNIX timestamp (updated every second).
PS: I'm really bad with JSON arguments.
Edit: Just now it changed to 1730199334.
Quote
Have you modified the bitcoin-util code?
You don't need to modify it. This tool is mining blocks, according to the difficulty, which you will put in the block header.Edit: Also note that bitcoin-util can mine any block headers. Which means, that it can mine your own Genesis Block. And it can also mine random 80 bytes. You decide, what data you will put there. It just takes any 80 bytes, and executes double SHA-256 on that. Also, I recommend reading the code for bitcoin-util alone, because it is very short and simple: https://github.com/bitcoin/bitcoin/blob/master/src/bitcoin-util.cpp
You can apply my code changes
Have you modified the bitcoin-util code? Up until this point, I was using your modified version of Bitcoin Core, but I was mining with cpuminer-opt. Quote
Why would the miner reorg himself?
I guess you have two miners in the same pool, and they compete with each other. Because even if you are mining alone, then if you have more than one independent mining setup, then you can also reorg yourself.Quote
I do not see how I can dictate the timestamp.
You can apply my code changes, then it will always give you the time, which is moved 20 minutes and 1 second to the future, from the previous block. Or: you can use the original client, and then modify the time, and the difficulty from the response (because you cannot request it).
This is strange.
This block is stale, but mined by the ckpool miner: https://mempool.space/testnet4/block/000000000035758a1fa11fd5d1f05a1457ff233a45d10466072f508d9e2d8cee.
This one is what replaced it, by the ckpool miner again: https://mempool.space/testnet4/block/0000000000fbeb2ec4cb84c6611d492628a1a8ff52b710667e12363c57997a7e.
Why would the miner reorg himself?
But, in the parameters, I can only see these as acceptable arguments:
This block is stale, but mined by the ckpool miner: https://mempool.space/testnet4/block/000000000035758a1fa11fd5d1f05a1457ff233a45d10466072f508d9e2d8cee.
This one is what replaced it, by the ckpool miner again: https://mempool.space/testnet4/block/0000000000fbeb2ec4cb84c6611d492628a1a8ff52b710667e12363c57997a7e.
Why would the miner reorg himself?
if you explore a block template, then you notice, that it contains everything you need.
I do not see how I can dictate the timestamp. In the results, there is a mintime field, with this description:Code:
"mintime" : xxx, (numeric) The minimum timestamp appropriate for the next block time, expressed in UNIX epoch time
But, in the parameters, I can only see these as acceptable arguments:
Code:
Arguments:
1. template_request (json object, required) Format of the template
{
"mode": "str", (string, optional) This must be set to "template", "proposal" (see BIP 23), or omitted
"capabilities": [ (json array, optional) A list of strings
"str", (string) client side supported feature, 'longpoll', 'coinbasevalue', 'proposal', 'serverlist', 'workid'
...
],
"rules": [ (json array, required) A list of strings
"segwit", (string, required) (literal) indicates client side segwit support
"str", (string) other client side supported softfork deployment
...
],
"longpollid": "str", (string, optional) delay processing request until the result would vary significantly from the "longpollid" of a prior template
"data": "hex", (string, optional) proposed block data to check, encoded in hexadecimal; valid only for mode="proposal"
}
1. template_request (json object, required) Format of the template
{
"mode": "str", (string, optional) This must be set to "template", "proposal" (see BIP 23), or omitted
"capabilities": [ (json array, optional) A list of strings
"str", (string) client side supported feature, 'longpoll', 'coinbasevalue', 'proposal', 'serverlist', 'workid'
...
],
"rules": [ (json array, required) A list of strings
"segwit", (string, required) (literal) indicates client side segwit support
"str", (string) other client side supported softfork deployment
...
],
"longpollid": "str", (string, optional) delay processing request until the result would vary significantly from the "longpollid" of a prior template
"data": "hex", (string, optional) proposed block data to check, encoded in hexadecimal; valid only for mode="proposal"
}
Quote
How do I create my own block header from scratch?
You call "getblocktemplate", and Bitcoin Core gives you everything you need, to form a full block.Quote
Is there a Bitcoin Core command which creates me the 80-bytes given input parameters?
There were in the past, but they are now deprecated. Now, you pass the whole block template into your mining software, which then constructs it, based on that. But: if you explore a block template, then you notice, that it contains everything you need.Quote
What if none of the 2^32 nonces is correct?
Then, you just try a different block header, until you hit it. In case of ASIC-mined blocks, checking all 2^32 nonces takes them just some seconds, and most of the time, they use something called "extraNonce", which is just a value, pushed on the stack. Which is why when you explore their coinbase transactions, you can see this extraNonce, set to some 32-bit value (which will then give you a block with 64 leading zero bits).Also, for the same reason, ASIC miners grind their timestamps, and block versions, which was called in the past "ASIC boost", because it is faster to modify a block header, than the coinbase transaction, and recalculate the merkle root. And also, some people wanted to fix it, by allowing to put non-zero bits in places, like "previous block hash", where you will always have some zeroes, and based on difficulty, this space could be potentially used for additional bits.
Quote
Sorry for the loaded questions
No problem. Testnets are created mainly to test mining, because everything else can be easily tested from a user perspective, if you have other networks like signet. So, it is natural to ask about mining in testnets. Yes, try "bitcoin-util grind". It will allow you to CPU-mine absolutely any block headers, you just put some 80 bytes there, and you will get some 80 bytes back, with the right nonce (if it exists).
- How do I create my own block header from scratch? I checked the specifications in learnmeabitcoin, but this is for main net, and for example, version bits are not the same. Is there a Bitcoin Core command which creates me the 80-bytes given input parameters?
- What if none of the 2^32 nonces is correct?
Sorry for the loaded questions, but Bitcoin Core is mountain of information, and I have never mined beyond for typical testing.
Quote
Is there a mining software which can take block timestamp as an input value?
Yes, try "bitcoin-util grind". It will allow you to CPU-mine absolutely any block headers, you just put some 80 bytes there, and you will get some 80 bytes back, with the right nonce (if it exists).Quote
The ckpool miner not only does keep the block for 20 minutes before sending it, but his timestamp is also 20 minutes plus a second into the future.
Yes, because you first mine a block with future timestamp, and then you broadcast it, at the right time. If you would mine it with earlier timestamp than that, then you would need to meet the real network difficulty. Which is also, why ASIC miners increase inflation, when they put the current time in their blocks (because then, the current time can be rolled back, according to the MTP rule, and the same timestamp can be reached again by CPU miners).
Is there a mining software which can take block timestamp as an input value? The ckpool miner not only does keep the block for 20 minutes before sending it, but his timestamp is also 20 minutes plus a second into the future. I cannot try submitting a block without having it mined to 20 min + 1 sec into the future beforehand.
I've been searching in the source code of cpuminer-opt for quite some time now, but can't find anything. It's difficult to understand, because it's in C.
I've been searching in the source code of cpuminer-opt for quite some time now, but can't find anything. It's difficult to understand, because it's in C.
Quote
it returns "null"
Quote
3. You avoid all kind of "already seen block, nothing to be done" cases, where your own node will do nothing, because it already has that particular block.
If you send a block to your own node, which already has it, then it does nothing.Quote
Why is it inconclusive?
Let's see the code: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mining.cpp#L1057Quote
Code:
static RPCHelpMan submitblock()
{
//...
bool new_block;
auto sc = std::make_shared(block.GetHash());
CHECK_NONFATAL(chainman.m_options.signals)->RegisterSharedValidationInterface(sc);
bool accepted = miner.processNewBlock(blockptr, /*new_block=*/&new_block);
CHECK_NONFATAL(chainman.m_options.signals)->UnregisterSharedValidationInterface(sc);
if (!new_block && accepted) {
return "duplicate";
}
if (!sc->found) {
return "inconclusive";
}
return BIP22ValidationResult(sc->state);
},
};
}
{
//...
bool new_block;
auto sc = std::make_shared
CHECK_NONFATAL(chainman.m_options.signals)->RegisterSharedValidationInterface(sc);
bool accepted = miner.processNewBlock(blockptr, /*new_block=*/&new_block);
CHECK_NONFATAL(chainman.m_options.signals)->UnregisterSharedValidationInterface(sc);
if (!new_block && accepted) {
return "duplicate";
}
if (!sc->found) {
return "inconclusive";
}
return BIP22ValidationResult(sc->state);
},
};
}
Or: maybe you are trying to submit a block too early to the node, when it is "not yet valid". Because you have a valid block, some CPU miners have a valid block, some ASIC miners have a valid block, and first-seen-safe rule is applied. And because the block difficulty is equal to one in "86% cases", then the final winner is announced, when the block with the real difficulty appears.
Jump to: