Testnet4 Mining (Discussion)

[stwenhao]

That means the CPU will earn 50*6*24/60/100M = 0.0000012 coins per day. That's not enough to test anything, as long as there are ASIC miners active.

Not enough? 120 satoshis per day is not enough to test things? Currently in mainnet there are faucets, which can give you two satoshis per hour. Which means 48 satoshis per day, if you don't sleep, don't eat, and claim them 24/7. And you have to collect at least 30k satoshis, to make some on-chain transaction, and actually see them transferred to your wallet.

And let's count the effort needed for mining a single satoshi on mainnet:

Code:

block hash: 00000000000000000000f8b5e98983fea1af3b4c7c0612f8fe35338c97ee2af2
block reward: 316,015,349 satoshis
CPU target: 00000000ffff0000000000000000000000000000000000000000000000000000
difficulty HEX: 1077fc04eac82 (hex division of CPU target by block hash)
difficulty decimal: 289,720,245,333,122
CPU block reward: 0.00000109 satoshi

See? CPU miners would need around one million blocks, to claim a single on-chain satoshi, if it would be counted proportionally to the mainnet difficulty.

Also note, that if CPU miners would be able to mine testnet blocks, but just claim a lower block reward, then they would include their own transactions in their own blocks, so minimal network fees will not be a problem. And reducing the block reward in CPU blocks should remove the incentive to mine so many of them (and doing it is a valid soft-fork).

[LoyceV]

After 20 minutes, CPU miners should also get a smaller block reward than usual. If the difficulty drops from 1,000,000 into 1, then the total block reward (with fees) should also drop for example from 50,0100,0000 satoshis into just 5,001 satoshis. And the rest of the block reward can be timelocked into some future block number (so that ASIC miners will get it), or simply burned (which is easier to implement).

I like it: burn it! Don't keep it for future ASIC miners, that will complicate things and might still be gamed by mining CPU blocks to increase the next ASIC block reward. Just burn it. In a healthy testnet, that 20 minute timer shouldn't trigger very often, so the few burned coins don't matter much, but at least it solves the problem of not finding blocks when a large miner quits.

Not in the last 14 transactions.

They look like they are including transactions(?). Block #75374 and down atm have transactions.

That's only "Coinbase (Newly Generated Coins)", nothing else. There are thousands of transactions waiting.

[BayAreaCoins]

Not in the last 14 transactions.

They look like they are including transactions(?). Block #75374 and down atm have transactions.

That's only "Coinbase (Newly Generated Coins)", nothing else. There are thousands of transactions waiting.

Again, I don't see thousands of transactions waiting,

Next Block
Median fee   ~0 sat/vB$0.00
Fee span   1 - 100 sat/vB
Total fees   ‎0.02 tBTC $0.00
Transactions   261

and I see the blocks with normal faucet transactions and even a few of ours.

Last one I see we sent out just confirmed(?):  https://mempool.space/testnet4/tx/623cd4d17a5148bb0ec28782ac34561d10fa089db3aa88393fb43f7265e56020

Might as well be waiting on high difficulty blocks than waiting for the empty folks to not be empty.

Weird that https://mempool.space/testnet4/address/tb1q2dsc94zq40nwnz27w5rxljwllutnwjtlxk44fz is mining empty... they are *huge*, I think they normally mine transactions, and their rewards don't move.

[LoyceV]

Again, I don't see thousands of transactions waiting,

Mempool sees them:

Last one I see we sent out just confirmed(?):  https://mempool.space/testnet4/tx/623cd4d17a5148bb0ec28782ac34561d10fa089db3aa88393fb43f7265e56020

It's still unconfirmed according to your link. We're probably just looking at different Forks:

(source: fork-observer)

[stwenhao]

Mempool sees them:

Because some spammers send their transactions to block explorers, but nowhere else. And then, some people can for example tell you, that "you have to pay more fees", or that "we need a bigger block size". But in reality, when you run your own node, you will see much less transactions, than you can see on mempool.space.

We're probably just looking at different Forks:

Note that there are many blocks at the same height. Which means, that reorgs are frequent, but they are not deep. So, in practice, confirmations are counted "horizontally", and not "vertically" in this chart. If you have block number 12,345 in 10 different versions, then after seeing block 12,346, you will have just a single block reorged, and not 10.

[LoyceV]

Because some spammers send their transactions to block explorers, but nowhere else.

Shouldn't the block explorer's node share those transactions with other nodes too?

Note that there are many blocks at the same height. Which means, that reorgs are frequent, but they are not deep.

In my screenshot above, I see 6 different chain tips. Depending on which one continues, the reorg may or may not be more than just one block. When I look at my public log, I see this (with many similar entries above that):

Code:

2025-03-31T09:25:09Z UpdateTip: new best=000000003abbf2f640acc26a3fc5970eb43ef5586981fddbc1c2ba5abf021233 height=75377 version=0x20000000 log2_work=73.000019 tx=8878565 date='2025-03-31T10:45:07Z' progress=1.000000 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000380961e8de9135ca31b48eaa953cd6d97ca9f458033f1de79c844d5b height=75376 version=0x20000000 log2_work=73.000019 tx=8878564 date='2025-03-31T10:25:06Z' progress=1.000000 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000002e39a2569ea3c502637419c56bb50ae6c87daba2594a0169c1b85a18 height=75375 version=0x20000000 log2_work=73.000019 tx=8878563 date='2025-03-31T10:05:05Z' progress=1.000000 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000034d3cdc0e6e5106884a64fff47e7fb2f6c201f8adbaca40793267ab5 height=75374 version=0x20000000 log2_work=73.000019 tx=8878562 date='2025-03-31T09:45:04Z' progress=1.000000 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000003fa2280617b4ee89081b87c9dabe90c0427724de1ff8f0192baa9e3c height=75373 version=0x20000000 log2_work=73.000019 tx=8878561 date='2025-03-31T09:25:03Z' progress=1.000000 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000000151a9e6f49574a0e3009c4c22da0bb954e0f581335b76572d9bbb48 height=75372 version=0x20000000 log2_work=73.000019 tx=8878560 date='2025-03-31T09:05:02Z' progress=0.999998 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000012b000d0a59d6524007722caac1b12dacf0b34cf9d496bfd3682ff3b height=75371 version=0x20000000 log2_work=73.000019 tx=8878559 date='2025-03-31T08:45:01Z' progress=0.999996 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000232ad9ff27c3ff09c874a4b6155dcb5dbd98c17564de6d6e08454d35 height=75370 version=0x20000000 log2_work=73.000019 tx=8878558 date='2025-03-31T08:25:00Z' progress=0.999994 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000022fa69950e66afe15ab24d8539421ed4989bf745c39e6037d67e8105 height=75369 version=0x20000000 log2_work=73.000019 tx=8878557 date='2025-03-31T08:04:59Z' progress=0.999991 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000006231ddb56d39afb04b384aecd6106b176f3d7fbe8105cfa062d0384 height=75368 version=0x20000000 log2_work=73.000019 tx=8878556 date='2025-03-31T07:44:58Z' progress=0.999989 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000034995cb60ef024eec07172ffd3bce401f7a78be9a5fe56b0cb8494cb height=75367 version=0x20000000 log2_work=73.000019 tx=8878555 date='2025-03-31T07:24:57Z' progress=0.999987 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000006ec212f71761cde50c21c69c531c505a6dd558da3fe1fa571c23c85 height=75366 version=0x20000000 log2_work=73.000019 tx=8878554 date='2025-03-31T07:04:56Z' progress=0.999985 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000000fc74130f5c9785a971ba2486f5a0b9156e98ac279f13a359beeb02 height=75365 version=0x20000000 log2_work=73.000019 tx=8878553 date='2025-03-31T06:44:55Z' progress=0.999983 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000002175977c9c2e7176c4844379c579985843f03ba729b64ed0608beb06 height=75364 version=0x20000000 log2_work=73.000019 tx=8878552 date='2025-03-31T06:24:54Z' progress=0.999981 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000024933163bbe989a6ea2b4b8770faabdc9051bb10e068027e97794648 height=75363 version=0x20000000 log2_work=73.000019 tx=8878551 date='2025-03-31T06:04:53Z' progress=0.999979 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000065439f631aaa3faf43507866f0362ba360094bdaf7220d9eea2ccc7 height=75362 version=0x20000000 log2_work=73.000019 tx=8878550 date='2025-03-31T05:44:52Z' progress=0.999977 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000002266ce6944de7663f4416f73c5e44904166633bd16c7435d888f3597 height=75361 version=0x20000000 log2_work=73.000019 tx=8878549 date='2025-03-31T05:24:51Z' progress=0.999974 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000e727d3881aa584260a6d728be1e8297d1cc5d4bdf783d44bf342b85b height=75360 version=0x20000000 log2_work=73.000019 tx=8878548 date='2025-03-31T05:04:50Z' progress=0.999972 cache=646.7MiB(3270451txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000000024b18c74ee6923b5240092f7193932b4416eaaa1633681e61ad7c height=75359 version=0x200fe000 log2_work=73.000019 tx=8878516 date='2025-03-31T04:44:49Z' progress=0.999970 cache=646.7MiB(3270416txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000419762ade2438db392eebd7ab770a98398deef355188640138418301 height=75360 version=0x20000000 log2_work=73.000019 tx=8878552 date='2025-03-31T05:04:50Z' progress=0.999972 cache=646.7MiB(3270457txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000d28d5c5ad0b4edac5652b985a63a77d1252a6969646f7b8542fbe70c height=75361 version=0x20000000 log2_work=73.000019 tx=8878789 date='2025-03-31T05:24:51Z' progress=0.999974 cache=646.7MiB(3270874txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000094d0d2a29f8efc0e816bd554211b80b6253eaa35905d50b8b9626225 height=75362 version=0x20000000 log2_work=73.000019 tx=8878984 date='2025-03-31T05:44:52Z' progress=0.999977 cache=646.7MiB(3271181txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000529551392d1cbe00be9ddce911e9c5137705981f20254c0c8fcd3310 height=75363 version=0x20000000 log2_work=73.000019 tx=8879133 date='2025-03-31T06:04:53Z' progress=0.999979 cache=646.7MiB(3271456txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000004f6b56a90a1436b9b29e9c8b569e4f268dcdfbc36fb8293bb01f1a99 height=75364 version=0x20000000 log2_work=73.000019 tx=8879281 date='2025-03-31T06:24:54Z' progress=0.999981 cache=646.7MiB(3271727txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000de5b8905ad099aba8f71fa205dd4769a0e22ac43ece2edb749a1d616 height=75365 version=0x20000000 log2_work=73.000019 tx=8879456 date='2025-03-31T06:44:55Z' progress=0.999983 cache=646.7MiB(3271960txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000219df0c9290e25244490bae49bd4bd06db163e9a8a8f3e106e9c2545 height=75366 version=0x20000000 log2_work=73.000019 tx=8879880 date='2025-03-31T07:04:56Z' progress=0.999985 cache=646.6MiB(3272183txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000065e597456391345b93343b891d345adaef8c525b2505072085d65483 height=75367 version=0x20000000 log2_work=73.000019 tx=8880033 date='2025-03-31T07:24:57Z' progress=0.999987 cache=646.6MiB(3272495txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000fa7449851000b48ad1f4b6ada6f9a57b3e23fc3f0a5b7677a7241dcb height=75368 version=0x20000000 log2_work=73.000019 tx=8880330 date='2025-03-31T07:44:58Z' progress=0.999989 cache=646.6MiB(3272970txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000057a4d5bf877f697cd851ae3cdfa236bc2279c82b914d6963ae8b8df0 height=75369 version=0x20000000 log2_work=73.000019 tx=8880642 date='2025-03-31T08:04:59Z' progress=0.999991 cache=646.6MiB(3273551txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000004789b75fc435507b6d7a41f64b50af59591b0b579b67b4a5f6f8381e height=75370 version=0x20000000 log2_work=73.000019 tx=8880889 date='2025-03-31T08:25:00Z' progress=0.999994 cache=646.7MiB(3273959txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000000f865e9e8178e7ae4d40dd3937a826f5bc12dbae1453c06f468c793d height=75371 version=0x20000000 log2_work=73.000019 tx=8881119 date='2025-03-31T08:45:01Z' progress=0.999996 cache=646.7MiB(3274350txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000002c55dda3e8e8f50564b139c925a1cc026b425f9aee78ccec7eb35280 height=75372 version=0x20000000 log2_work=73.000019 tx=8881447 date='2025-03-31T09:05:02Z' progress=0.999998 cache=646.7MiB(3274908txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000b3b04a3b25df838e364c2abe18dbc103336d3fcbc9038c45fe930e49 height=75373 version=0x20000000 log2_work=73.000019 tx=8881841 date='2025-03-31T09:25:03Z' progress=1.000000 cache=646.7MiB(3275621txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000c2d2b60ba3471597f878696c722aaa288bd5d9b04d01401b14f9735f height=75374 version=0x20000000 log2_work=73.000019 tx=8882097 date='2025-03-31T09:45:04Z' progress=1.000000 cache=646.8MiB(3276101txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000030d0ff580fbb3fcfd5073560c401f3e4dd1ad83f17c9a644c5df80bf height=75375 version=0x20000000 log2_work=73.000019 tx=8882455 date='2025-03-31T10:05:05Z' progress=1.000000 cache=646.8MiB(3276734txo)
2025-03-31T09:25:09Z UpdateTip: new best=00000000a0e62e7b34b6d108c094c6a084d14fe8093931bdb3c35bf95d415afc height=75376 version=0x20000000 log2_work=73.000019 tx=8882741 date='2025-03-31T10:25:06Z' progress=1.000000 cache=646.8MiB(3277274txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000000841399041e6cc73981af825a972676f187ac35ebe17d7812fcbf9d5 height=75377 version=0x20000000 log2_work=73.000019 tx=8882996 date='2025-03-31T10:45:07Z' progress=1.000000 cache=646.8MiB(3277785txo)
2025-03-31T09:25:09Z UpdateTip: new best=000000006265064219fe0e5e54241c660f6f3ac5628df11f3e1854631efd1710 height=75378 version=0x20000000 log2_work=73.000019 tx=8883148 date='2025-03-31T11:05:08Z' progress=1.000000 cache=646.8MiB(3278083txo)
2025-03-31T09:25:09Z UpdateTip: new best=0000000048712789235face9f237dc7da2e28283032ce8229709d985e5582af1 height=75379 version=0x20000000 log2_work=73.000019 tx=8883397 date='2025-03-31T11:25:09Z' progress=1.000000 cache=646.9MiB(3278658txo)

It goes from block 75377 down to 75359, which is an 18 block reorg.

[stwenhao]

Shouldn't the block explorer's node share those transactions with other nodes too?

They should. But their code has some bugs, so their nodes don't propagate transactions correctly. Which means, that you can trick some users, which don't have their own nodes.

And you can confirm it, if you compare some transactions, and check, if they are present only in mempool.space, or are they also shared with other block explorers. Or: you can explore some blocks, mined by some miners and see, how they confirm some latest transactions, but don't confirm something, which is hanging in mempool.space for months (because their nodes never saw these transactions, and if you manually rebroadcast them, then they will be suddenly confirmed in the next block, made by that miner).

By the way: first you can check, if your node can see them. By using "getblocktemplate", or trying some mempool-related commands, you should get some stats. For example:

Code:

CreateNewBlock(): block weight: 62714 txs: 55 fees: 120605 sigops 617
CreateNewBlock(): block weight: 74564 txs: 65 fees: 131955 sigops 660
CreateNewBlock(): block weight: 800829 txs: 708 fees: 43674152 sigops 3189
CreateNewBlock(): block weight: 1282660 txs: 1134 fees: 114552301 sigops 4879

Or: you can also check some transactions manually, if your node has them, by checking a particular transaction ID.

It goes from block 75377 down to 75359, which is an 18 block reorg.

Sure, but if you observe only ASIC blocks, then you will see, that the whole chain is quite stable. And if CPU blocks will be rejected in the future testnet, then you can focus on ASIC-only blocks to see, how stable the network really is. Because ASIC miners can pick any chain. If you have some ASIC, then you can always mine a new block, on top of the latest ASIC block, and then, you will always just throw away a lot of CPU-mined blocks (but of course, it is not done by default by the client, because reorging a chain on purpose is considered "an attack", so developers obviously didn't implement it in the default client).

And also, if CPU-mined blocks will be simply banned, then the network will get "stuck" more often. Now, testnet4 is only blocked once per 2016 blocks, because then, only ASICs can finish a given difficulty period.

Edit:

log2_work=73.000019

See? The chainwork stays exactly the same, when rounded into six digits. So, I guess all blocks from your logs are just CPU-mined blocks. And if there are no ASIC blocks in between, then all of that traffic will simply disappear, if CPU-mined blocks will be banned.

[BayAreaCoins]

Again, I don't see thousands of transactions waiting,

Mempool sees them:

Last one I see we sent out just confirmed(?):  https://mempool.space/testnet4/tx/623cd4d17a5148bb0ec28782ac34561d10fa089db3aa88393fb43f7265e56020

It's still unconfirmed according to your link. We're probably just looking at different Forks:
...

This is what my Mempool looks like right now and what it looked like while I was posting:



Also, I see 53 confirmations now... it must just be some Testnet fuckery.

[mikeywith]

@BayAreaCoins

Testnet people need a pool that pays for shares found.  A CPU will still be able to submit valid shares easily and quickly receive a small amount of Bitcoin Testnet.

This approach would be useless for many developers. While it might be sufficient for payment gateways or wallets, anything mining-related requires the full experience of constructing a block and making it part of the blockchain. Developers need to learn how to properly create valid blocks, handle orphaned blocks, and manage other essential aspects of mining. Simply receiving coins or sending work via Stratum doesn't provide the hands-on experience needed to understand these critical processes.

True. After 20 minutes, CPU miners should also get a smaller block reward than usual.

You guys are assuming that if the difficulty drops to 1, it means a CPU miner is going to solve a block. This is not true. As long as an ASIC miner exists in the testnet ecosystem, CPU miners have little to no chance. Even in the rare event that a CPU miner beats the ASIC miner, the ASIC miner will simply overtake them by mining more blocks and forcing a reorg. In reality, not a single CPU miner stands a chance.

I appreciate the discussion and the ideas you're all suggesting, but I feel like we're not on the same page. It's worth clearing up some confusion. We have two major issues in testnet—so which one are we trying to solve?

Problem 1: CPU miners can no longer mine on testnet.

Proposal A: Algorithm change from SHA-256 to something else

Pros:

This immediately eliminates all ASICs and allows small developers with CPUs and GPUs to mine on testnet.

Cons:

Changing the algorithm is a major decision, and It makes a large part of the test environment significantly different from the mainnet.

Proposal B: Reset the network every X blocks

Pros:

Eliminates the incentive to hoard testnet coins, since ASICs are power-hungry, it's unlikely that people will waste resources mining a coin that disappears in a few days. In theory, this could be highly effective against ASIC dominance.

Cons:

It alters testnet slightly, making it non-identical to the mainnet (but not as drastically as Proposal A). This also assumes that abusers mine testnet coins for their value rather than for fun. If they're doing it for fun, this proposal won’t stop them.

Proposal C: Do nothing
Pros:

No changes to the code are needed.

Cons:

Developers without enough funding, or those in locations where running an ASIC isn’t feasible, won't be able to test.

My preference:
Try Proposal B for a while. If it fails, roll back and let Proposal C handle it.

Problem 2: Block reorgs caused by malicious miners

Proposal A: Remove the difficulty reset and tet the difficulty grow.

Over time, this will make block reorgs extremely expensive, discouraging abuse.

Proposal B: Establish a community-driven consensus

Testnet developers should form a community that reaches an agreement outside of the code, if a miner is found abusing the system via reorgs, they can be collectively ignored, even if they have the longest chain.

I'll leave the pros and cons for you guys to discuss, along with any other proposals to address these issues.






 

[NotFuzzyWarm]

My vote would be for Proposal B: Reset the network every X blocks

IMHO removing ALL value to tbtc coins is the best thing because the problem is being caused from them having value by being exchangable for other coins including BTC. Since the exchange(s) involved in selling them can't be shut down then making them truly worthless should remove all financial incentive to pay for running ASIC's.

That would leave folks running ASIC's just to fuck with testnet 'because they can'. To fight against those assholes, perhaps establish a very low maximum found blocks per minute limit from any one IP address? Exceed the limit and the node is ignored for say a week.

[mikeywith]

That would leave folks running ASIC's just to fuck with testnet 'because they can'. To fight against those assholes, perhaps establish a very low maximum found blocks per minute limit from any one IP address? Exceed the limit and the node is ignored for say a week.

Yes, both issues can be solved on a "social level", 5-10 devs can meet here and decide to run their own blockchain, I assume, just a simple modification bitcoin.conf using "connect" not "whitelist".

# #connect=NotFuzzyWarm
# #connect=Xperson

This way, your node won't talk to any other node, the other devs do the same, and you now have a complete experience of testnet without some arshole abusing it, if Xperson starts doing shit, just remove them.

Obivouslly, your transactions won't be visible on block expolers like mempool, but you are supposed to be a dev, you shouldn't be asking mempool about a transaction when you are running your own node, testnet as the name suggest is just for "testing", when you are done with your wallet, miner, pool or whatever software, you hit mainnet.

[stwenhao]

Even in the rare event that a CPU miner beats the ASIC miner, the ASIC miner will simply overtake them by mining more blocks and forcing a reorg.

What is the point in getting for example 5k satoshis, where you can get 50 coins instead? And what is the point of burning or locking for example 49.99995000 coins, when you mine CPU blocks on ASIC? If ASIC miners will continue mining CPU blocks, and getting only a bunch of satoshis, then the consensus will simply evolve into a huge Proof of Burn, and ASIC miners will lose a huge opportunity of making much more coins, by mining stronger blocks.

And you can empirically see, that existing ASIC miners don't reorg a long chains of CPU-mined blocks, no matter who mined them. For example: if ASIC miners would really want to lower the network difficulty, and mine more blocks, then they would always reorg all CPU-mined blocks, and then, you would have no CPU-mined blocks in the whole 2016 block period.

Instead, you can see, that ASICs mine roughly 1/6th of blocks, so around 336/2016 blocks, even though a single ASIC block can throw away millions of CPU-mined blocks.

And also note, that after 2016 blocks, when the difficulty is adjusted, ASIC miners are strictly required to push the network forward. If only CPU miners are mining, then during the nearest difficulty adjustment, they are all stuck.

Algorithm change from SHA-256 to something else

Why? ASICs are optimized to just mining 80-byte block headers. Just changing the size of the hashed message will instantly eliminate a lot of ASICs. For example: grabbing coins from https://mempool.space/testnet4/address/tb1qk3endeq6x0xj4pjt4zwag8wf3a629rzqr8jxd7jnmlac902wa5ysqxm9wt requires checking around 2^16 SHA-256 hashes, and nobody even tried to get it.

If they're doing it for fun, this proposal won’t stop them.

Sure, but judging by some statistics from centralized exchanges, many people are not mining for fun, but just for profit, like it is the case in many other altcoins.

And now, some people even consider testnets as just regular altcoins, so testnet5, testnet6, and so on, will also be traded, if consensus rules will be similar: https://bitcointalk.org/index.php?topic=5536825.0

Developers without enough funding, or those in locations where running an ASIC isn’t feasible, won't be able to test.

Developers already have their own network called "signet", where they produce 100% blocks, because all of them are signed. And if someone wants to test things, and preserve CPU mining, then that developer is simply releasing its own signet.

And even on signets, you can test decentralized mining to some extent, if you just lock some coins on Proof of Work scripts, like it was done here: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937

[mikeywith]

Even in the rare event that a CPU miner beats the ASIC miner, the ASIC miner will simply overtake them by mining more blocks and forcing a reorg.

What is the point in getting for example 5k satoshis, where you can get 50 coins instead? And what is the point of burning or locking for example 49.99995000 coins, when you mine CPU blocks on ASIC? If ASIC miners will continue mining CPU blocks, and getting only a bunch of satoshis, then the consensus will simply evolve into a huge Proof of Burn, and ASIC miners will lose a huge opportunity of making much more coins, by mining stronger blocks.

Let's do some math, with the 500M difficult that testnet4 reached to, let's say I have an S19 pro with 100th, if I attempt to mine a 500M diff vs 1 diff block

Time to find a block in seconds = Hashrate Difficulty×2 ^32/ hashrate
for 500M diff it would be 6 hours
for 1 diff it would be 0.00004295 seconds

which means, for a period of 6 hours I can mine 502,912,800 blocks which is 502,912,800 * 0.00005000 btc = 25145.64 btc vs 50 btc, obviously, i won't be able to mine that many blocks, but it doesn't matter what figures you plot in,  that is 50190% more profit in mining 1 diff blocks than mining 500M blocks.

And you can empirically see, that existing ASIC miners don't reorg a long chains of CPU-mined blocks, no matter who mined them. For example: if ASIC miners would really want to lower the network difficulty, and mine more blocks, then they would always reorg all CPU-mined blocks, and then, you would have no CPU-mined blocks in the whole 2016 block period.

I think he indeed is forcing reogrs on all blocks that don't belong to him, you can see that the majority of blocks found on testnet4 are 20 mins + 1 second of 1 diff block followed by a high diff block.


let's take a look at block 75456, the whole set of 1 diff block preceeding it had a 20 min + 1 second in the time stamp, obivously a reorg of an entire set mined in secret, it's also clear that he was mining into the future, because the very next block found by Mara has a timestmap of ‎2025-04-01 05:06:44 while block 75456 was  06:46:48  now let's move past Mara's block


75458 > diff 1 > miner  44fz timestamp 05:26:45 (exactly 20 mins and 1 second from Mara's block)
75459 > diff 1 >  miner rlk5 timestamp 05:46:46 ( exactly 20 mins and 1 second)obviosuly this guy just mined 75456 earlier with a timestamp of 06:46:48 before 05:06:44 lol
75460 > diff 1 > miner rlk5 timestamp  06:06:47 (again)
75461 > diff 1 > miner 44fz timestamp  06:26:48 (//)
75462 > diff 1 > miner  44fz timestamp  06:46:49 (//)
75462 >
to
75478 > with timestamp of 12:07:05  is all miner rlk5 with 20 mins + 1 second

75479 > high diff > miner m7r4 timestamp 12:05:56 >

guess what who mined the next dozen blocks? again it's 44fz with 20 mins + 1 second then rlk5 took over for another dozen blocks before m7r4 mined a high-diff block, you can clearly see that miner rlk5 and 44fz (probably the same user) are mining difficulty 1 blocks in secret and only revealing them when they reach a full difficulty adjustment point.

Since these miners are keeping blocks hidden until the last moment, they can reorg any blocks mined by others, this pattern can't be random, it also makes no sense that while diff is actually 1, only a single miner manages to find a streak of blocks before anyone else, other miners do find blocks but are being reorged because they ain't playing dirty.

You can go to any random point in time and see the same pattern repeat with 1,2 btc addresses.

[LoyceV]

Let's do some math, with the 500M difficult that testnet4 reached to, let's say I have an S19 pro with 100th, if I attempt to mine a 500M diff vs 1 diff block

Time to find a block in seconds = Hashrate Difficulty×2 ^32/ hashrate
for 500M diff it would be 6 hours

Now do the same, but build on top of the last ASIC block instead of the CPU blocks. Just ignore them, and wipe them out. If all ASIC miners would do that, less blocks are found and the difficulty drops at the next adjustment.

If you have some ASIC, then you can always mine a new block, on top of the latest ASIC block, and then, you will always just throw away a lot of CPU-mined blocks (but of course, it is not done by default by the client, because reorging a chain on purpose is considered "an attack", so developers obviously didn't implement it in the default client).

I get that developers didn't include this option by default, but how hard would it be to implement this as an ASIC miner? As for the "attack" part: is attacking an attack still an attack?

[stwenhao]

that is 50190% more profit in mining 1 diff blocks than mining 500M blocks

1. You cannot mine blocks faster than six per second, even on regtest.
2. Time difference between CPU blocks will be at least 20 minutes, so after six blocks, everything else will be rejected by the rest of the network (because of two hours rule).
3. Everyone else will have a huge incentive, to bring back all coins you burned, by reorging all of them, with a single ASIC block.
4. After 2016 blocks, you will be forced to mine a new block with ASIC difficulty.

If all ASIC miners would do that, less blocks are found and the difficulty drops at the next adjustment.

Exactly. If ASICs mine only 1/6th of blocks in two weeks, then they are mining with artificially raised difficulty. Because all CPU-mined blocks are counted in the same way, as ASIC blocks are, during difficulty adjustment: you have just 2016 last blocks, no matter how much effort was required to produce them.

Which means, that ASIC miners have an incentive to throw away CPU-mined blocks, no matter who produced them, because by doing so, they can lower the difficulty, and bring it back to the real level.

how hard would it be to implement this as an ASIC miner?

Well, you would need to secretly produce your block, on top of something in the past. Which means, that for example your "getblocktemplate" would need to point to the block 123,456, and collect everything, what happened in blocks from 123,457, up to the latest block, and your current mempool of unconfirmed transactions.

Things like "invalidateblock" and "reconsiderblock" could help, but then, other nodes will automatically disconnect, if you stop accepting the same CPU-mined blocks, as they did. Which means, that probably having an honest node, getting enough information out of it, and then submitting the block is the way to go.

is attacking an attack still an attack?

It is like killing the killer, or extinguishing fire with fire. The real solution would solve the problem in a way, where acting honestly will be the most profitable. And now, that assumption is broken in testnet, because if you use the original software, then you are in a worse position, than attackers are. Which means, that people will craft their own code for getting as many blocks as they can, and none of that will be public, as long as developers won't adjust the new consensus for testnet5.

[LoyceV]

Well, you would need to secretly produce your block, on top of something in the past. Which means, that for example your "getblocktemplate" would need to point to the block 123,456, and collect everything, what happened in blocks from 123,457, up to the latest block, and your current mempool of unconfirmed transactions.

I kinda forgot you indeed need to keep track of newer blocks, in case another ASIC also produces a new block. It would be a lot easier if all ASIC miners would just ignore all CPU blocks.

Would this work? If the 20 minutes before the difficulty drops is increased to 3 hours, it's still enough to keep the blockchain going even if a large miners stops mining, although it's going to be only 8 blocks per day. But it largely reduces the low difficulty abuse. It would probably still be possible to change the clock 2 hours and mine an easy block after just 1 hour without ASIC block, but it's better than 6 easy blocks right after each ASIC block.
TL;DR: turn 20 minutes into 3 hours, see what happens

[stwenhao]

in case another ASIC also produces a new block

Not only because of that, but also because some CPU miners may include non-standard transactions, and you may be interested in collecting fees from them (especially if someone will put a standard transaction with tasty fees, as a CPFP of some non-standard transaction with zero fees). Of course, you can always just mine an empty block on the proper height, and don't care about fees, but I assume you want to confirm things, which were previously confirmed.

So, if block 123,456 is confirmed, and you want to reorg everything from block 123,457 forward, then you should collect everything from CPU blocks, and put into your mempool (which "invalidateblock" does, but it also disconnects you from honest nodes, because then they don't see the same chain tip as you want to work with). And then, if you have your regular mempool, and all transactions confirmed by CPUs, then it should give you the maximum possible coinbase reward.

It would be a lot easier if all ASIC miners would just ignore all CPU blocks.

In the current consensus, you cannot ignore CPU-mined blocks, but you can reorg them with a single ASIC block (because if ASIC difficulty is 1,000,000, then you can reorg up to 1,000,000 CPU-mined blocks in a single shot).

But yes, the current plan from the mailing list is to hard-fork the network to the state, where mining blocks with CPU difficulty will be blocked. Which is equivalent to just releasing testnet5 with new rules, and with premine of all current testnet4 blocks.

turn 20 minutes into 3 hours, see what happens

This is hard-fork. But it is quite likely, that there will be no CPU-mined blocks in this case, or they will occur very rarely. You can explore the mainnet chain, and count all instances, where the time between blocks was bigger than 3 hours, to estimate, how many such cases we could have in your testnet.

[LoyceV]

You can explore the mainnet chain, and count all instances, where the time between blocks was bigger than 3 hours, to estimate, how many such cases we could have in your testnet.

I'd expect it to happen more often on testnet, as it's more likely to have a large part of the hashrate suddenly disappear. But it shouldn't happen a lot, which kinda is the point

[stwenhao]

for a period of 6 hours I can mine 502,912,800 blocks which is 502,912,800 * 0.00005000 btc = 25145.64 btc vs 50 btc

Maybe I should be more precise: if the difficulty is for example 502,912,800 for 6 hours (which means 13,969,800 for 10 minutes), then you could see for example 13,969,800 as the network difficulty, which means 50,0000,0000 satoshis divided by 13,969,800, so 357 satoshis per block, not 5,000. If the difficulty is 1M, then it is divided by 1M, but if it raises into 4M, then obviously, the amount is also divided by 4M, and so on, and so forth. Which means, that in practice, CPU miners will often get no new coins at all, but they would be able to confirm non-standard transactions. Maybe to simplify things, all CPU-mined blocks should just get zero block reward, and always burn all coins, to make it simpler (but maybe it is a good idea to give CPU miners some faucet-like amounts anyway, or something around the dust limit, just to make it enough for testing, but not enough for trading).

And also, "for a period of 6 hours" is strictly combined with "20 minute distance to trigger a rule", which means 18 blocks per 6 hours in practice, so even if it is really 5k sats, it means only getting 90k sats, not 25k coins. Because obviously, if the difficulty is for example set to 13,969,800 per 10 minutes, then you can of course actually mine 13,969,800 blocks with minimal difficulty, but then, timestamps inside blocks will be so far in the future, that no client would even try to download your chain.

Edit: I also thought about something else, but I don't have a strong opinion on that yet: declaring any difficulty in range from 1 to the real one. Which means, that the network could just accept any difficulty, picked by the miner, and allowed coinbase amount would be proportional to the declared difficulty.

I don't know exactly, where miners would find their equilibrium in that case, but then, it would be possible to let miners decide, how many coins they want to take. Some would pick 1/5th of the real difficulty, and get 10 tBTC, instead of 50 tBTC, and others would pick 1/50th, and get just 1 tBTC. And of course, amounts would be rounded down, so by picking too easy targets, it could be possible to get no new coins at all, and just burn everything.

But this particular idea is easier to implement in output scripts, based on Proof of Work, than actual block headers (because then, miners can work independently on different targets, and be rewarded accordingly, without constantly reorging each other).

[mikeywith]

1. You cannot mine blocks faster than six per second, even on regtest.

Why is that? are you talking about network/resources constraints? Where did you get the 6 seconds from? It takes roughly 150ms to validate and construct a block according to Kano's own observation which is based on thousands and thousands of blocks on mainnet, and that also takes into account dealing with mempool and removing old transactions and what not, which means if you were to ignore mempool altogether and even header verification since the previous block is yours anyway, you could be mining at a much faster rate than that.

Again, most of that doesn't matter, I will just mine 1 diff blocks as "fast" as my resources allow me and I would still make more BTC than mining high diff block, when I can no longer do that, i start looking for a high diff share, as soon as I can go back to 1 diff blocks i will, what will stop ASIC miners from doing just that?

2. Time difference between CPU blocks will be at least 20 minutes, so after six blocks, everything else will be rejected by the rest of the network (because of the 2 hours rule).

They won't be rejected, the 2 hours rule is not a part of the consensus unlike what most people think, those blocks are NOT invalid, they are just not accepted by default, they will be accepted eventually when the node's adjusted time moves into the future, that chain which is 2 hours into the future will still be longest chain if the "abuser is building faster", if I propogate a block with a timestamp of  15:00 while your adjusted network time is 13:00 your node will ignore it, but if I propogate the same exact block 1 minute later, it will be accepted,

4. After 2016 blocks, you will be forced to mine a new block with ASIC difficulty.

Fine by me, again, I'll mine high diff blocks when I have to and mine 1 diff blocks when I can since it's more profitable.