Unbreaking testnet4

Unbreaking testnet4
2025-03-18 21:34 ` Melvin Carvalho
                   ` (6 more replies)
  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-18 14:29 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

Hi,

Testnet4 was rolled out a year ago to address the shortcomings of testnet3. One of those shortcomings was the difficulty reset creating havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As a result, testnet4 is similarly creating havoc. [2]

The goal of testnet is to mimic the Bitcoin mainnet. This is why it is useful to have in addition to a more control testing environment such as Signet.

The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop. But you cannot have your cake and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed on both count: it neither mimics mainnet nor allows developers to mine active blocks on their laptop.

I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01. I picked a date well in the future to minimize disruption. This leaves enough time for a patch to be reviewed, merged, included in the next major Bitcoin Core release, backported to previous releases and adopted by the infrastructure running on testnet4. That should be enough for a test network.

Let me know what you think,
Antoine

[0] https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
[1] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
[2] [https://fork.observer](https://fork.observer/) - pick the network on the top right corner

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 3441 bytes --]

 permalink raw reply	[|nested]
2025-03-18 21:34 ` 
                   ` 
  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-18 14:29 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

Hi,

Testnet4 was rolled out a year ago to address the shortcomings of testnet3. One of those shortcomings was the difficulty reset creating havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As a result, testnet4 is similarly creating havoc. [2]

The goal of testnet is to mimic the Bitcoin mainnet. This is why it is useful to have in addition to a more control testing environment such as Signet.

The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop. But you cannot have your cake and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed on both count: it neither mimics mainnet nor allows developers to mine active blocks on their laptop.

I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01. I picked a date well in the future to minimize disruption. This leaves enough time for a patch to be reviewed, merged, included in the next major Bitcoin Core release, backported to previous releases and adopted by the infrastructure running on testnet4. That should be enough for a test network.

Let me know what you think,
Antoine

[0] https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
[1] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
[2] [https://fork.observer](https://fork.observer/) - pick the network on the top right corner

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 3441 bytes --]

 permalink raw reply	[|nested]
* 
  2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-03-19  7:01 `  " Garlo Nicon
                   ` 
  6 siblings, 0 replies; 31+ messages in thread
From: Melvin Carvalho @ 2025-03-18 21:34 UTC (permalink / raw)
  To: Antoine Poinsot;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

út 18. 3. 2025 v 22:24 odesílatel 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> napsal:

> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
>

+1 I think this is a great idea.  I can dedicate some resources to it, such
as review, running a node, contributing some hash, if necessary, and a
decentralized faucet (that anyone can run) that I've been working on


> Antoine
>
> [0]
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYhKwsLHfv0gYQYZ9MnDVPyQTN6jAfzShaKkS%3Dk2fDfMq0A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4911 bytes --]

^ permalink raw reply	[|nested] 31+ messages in thread
2025-03-19  7:01 ` [bitcoindev] " Garlo Nicon

  2025-03-19  8:43     ` Garlo Nicon
  
From: Sjors Provoost @ 2025-03-19  7:56 UTC (permalink / raw)
  To: Bitcoin Development Mailing List;  Garlo Nicon



> Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlonicon@gmail•com> het volgende geschreven:
> 
> > I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01.
> 
> You can do that in a soft-fork way. Just rejecting blocks with difficulty=1, and requiring always a block with the true network difficulty, is a valid soft-fork.

Unfortunately it's a hard-fork.

> So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to "false", when block time will be greater than unix time "1767225600", then you will get a valid soft-fork.


The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new block MUST have difficulty 1.  A block with the real difficulty will be rejected.

This is because in general the block nBits value, which announces how much work the block has, must have an exact value. It can't be higher.

In validation.cpp we have this:

if (block.nBits != GetNextWorkRequired(pindexPrev, &block, consensusParams))
    return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER, "bad-diffbits", "incorrect proof of work");

Inside GetNextWorkRequired there is the testnet exception rule, which Antoine proposes to drop:

 if (params.fPowAllowMinDifficultyBlocks) {
    // Special difficulty rule for testnet:
    // If the new block's timestamp is more than 2* 10 minutes
    // then allow mining of a min-difficulty block.
    if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)
        return nProofOfWorkLimit;
    else
       ... (same difficulty as last block, unless it's a retarget)

The code comment is misleading, "allow" should be "require".

- Sjors

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/688E575D-C370-4D7D-A6DB-11E0B56710B1%40sprovoost.nl.


 permalink raw reply	[|nested]
* 
  2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
  2025-03-18 21:34 ` Melvin Carvalho

  2025-03-19  7:56   ` [bitcoindev] " Sjors Provoost
  2025-03-19  8:32 ` 
                   ` 
  6 siblings, 1 reply; 31+ messages in thread
From: Garlo Nicon @ 2025-03-19  7:01 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3522 bytes --]

> I propose to fix this by removing the difficulty reset rule from testnet4 
through a flag day hard fork on 2026-01-01.

You can do that in a soft-fork way. Just rejecting blocks with 
difficulty=1, and requiring always a block with the true network 
difficulty, is a valid soft-fork.

To better see that, you can imagine, what would happen, if someone would 
apply difficulty adjustment rule on mainnet. Then, it would be possible to 
temporarily mine a block on a CPU, see it confirmed by your node (and 
rejected by the rest of the network), and then, when the next real block 
would appear, your client would automatically switch to a stronger chain 
(and then, those CPU-mined blocks would be truly worthless).

So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to 
"false", when block time will be greater than unix time "1767225600", then 
you will get a valid soft-fork. Non-upgraded clients could then still see 
some CPU-mined blocks, but they will disappear, if the hashrate majority 
will support your changes, and then old clients will automatically follow 
your chain. Also note that a single ASIC block can reorg a lot of CPU-mined 
blocks, so it is always guaranteed, that this change will be 
chainwork-compatible.

wtorek, 18 marca 2025 o 22:24:49 UTC+1 Antoine Poinsot napisał(a):

> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of 
> testnet3. One of those shortcomings was the difficulty reset creating 
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As 
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is 
> useful to have in addition to a more control testing environment such as 
> Signet.
>
> The given rationale for a difficulty reset was to let developers 
> occasionally mine blocks on their laptop. But you cannot have your cake and 
> eat it too: either the network is permissionless (PoW) or you assign 
> identities and privileges to some (Signet). By trying to do both at the 
> same time testnet4 created a loophole for abuse. As a result it failed on 
> both count: it neither mimics mainnet nor allows developers to mine active 
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4 
> through a flag day hard fork on 2026-01-01. I picked a date well in the 
> future to minimize disruption. This leaves enough time for a patch to be 
> reviewed, merged, included in the next major Bitcoin Core release, 
> backported to previous releases and adopted by the infrastructure running 
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
> Antoine
>
> [0] 
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vP...@mail.gmail.com 
> <https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
> [1] 
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5238 bytes --]

^ permalink raw reply	[|nested] 31+ messages in thread
2025-03-19  7:56   ` [bitcoindev] " Sjors Provoost

  
From: Garlo Nicon @ 2025-03-19  8:43 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]

It seems you are right. However, this rule is based on block timestamps, 
which gives me another idea: what about simply invalidating a block, if the 
block time difference is bigger than 20 minutes? Because that's what ASIC 
miners would want to do anyway, to reorg a long chain of CPU-mined blocks: 
if the difficulty is 12345678, and you can see hundreds of blocks with 
difficulty 1, then a single block with difficulty 12345678 will reorg all 
of these CPU-mined blocks in a single shot.

By the way: if we are entering a hard-fork territory, and if testnet4 coins 
are traded, then what about switching to testnet5 with new rules instead?

And also, in case of any forks, there is a question, how many miners will 
actually support new changes. Because in case of new timewarp rules, we saw 
hundreds of blocks being reorged, because some ASIC miners didn't upgrade 
their code: https://github.com/bitcoin/bitcoin/issues/30786

And even when mempool.space upgraded their code, a few weeks after that, I 
could still see some ASIC nodes in the wild, which were mining on the wrong 
branch, and with just a CPU, it was possible to fork them once every 2016 
blocks, for a few hundred blocks.

środa, 19 marca 2025 o 08:59:26 UTC+1 Sjors Provoost napisał(a):

>
>
> > Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlo...@gmail•com> het 
> volgende geschreven:
> > 
> > > I propose to fix this by removing the difficulty reset rule from 
> testnet4 through a flag day hard fork on 2026-01-01.
> > 
> > You can do that in a soft-fork way. Just rejecting blocks with 
> difficulty=1, and requiring always a block with the true network 
> difficulty, is a valid soft-fork.
>
> Unfortunately it's a hard-fork.
>
> > So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to 
> "false", when block time will be greater than unix time "1767225600", then 
> you will get a valid soft-fork.
>
>
> The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new 
> block MUST have difficulty 1. A block with the real difficulty will be 
> rejected.
>
> This is because in general the block nBits value, which announces how much 
> work the block has, must have an exact value. It can't be higher.
>
> In validation.cpp we have this:
>
> if (block.nBits != GetNextWorkRequired(pindexPrev, &block, 
> consensusParams))
> return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER, 
> "bad-diffbits", "incorrect proof of work");
>
> Inside GetNextWorkRequired there is the testnet exception rule, which 
> Antoine proposes to drop:
>
> if (params.fPowAllowMinDifficultyBlocks) {
> // Special difficulty rule for testnet:
> // If the new block's timestamp is more than 2* 10 minutes
> // then allow mining of a min-difficulty block.
> if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + 
> params.nPowTargetSpacing*2)
> return nProofOfWorkLimit;
> else
> ... (same difficulty as last block, unless it's a retarget)
>
> The code comment is misleading, "allow" should be "require".
>
> - Sjors

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4198 bytes --]

 permalink raw reply	[|nested]
2025-03-19  8:32 ` Sjors Provoost

  
From: Melvin Carvalho @ 2025-03-19  9:11 UTC (permalink / raw)
  To: Sjors Provoost
  Cc: 'Antoine Poinsot' via Bitcoin Development Mailing List,
	Antoine Poinsot

[-- Attachment #1: Type: text/plain, Size: 4093 bytes --]

st 19. 3. 2025 v 10:04 odesílatel Sjors Provoost <sjors@sprovoost•nl>
napsal:

> Antoine Poinsot wrote:
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
>
> Let me clarify why developers can't mine on their own laptop with testnet4.
>
> The way you would do that is to move your computer clock forward by 20
> minutes (or use faketime), at which point the difficulty drops to 1. You
> would then mine your (presumably non-standard transaction) and broadcast it
> to the network.
>
> This is also the strategy used to acquire more testnet coins if you don't
> have an ASIC and don't want to use a faucet.
>
> On testnet3 the latter wasn't very productive because at height 4 million
> the block subsidy is under 10k sats.
>
> But on testnet4 every block yields 50 tBTC. So several people try to mine
> such a block, leading to the many parallel forks.
>
> If you're a developer trying to mine a non-standard transaction, you have
> to be fast, well connected and lucky to be the first block picked up by the
> rest of the network.
>
> But why mine just one if you can mine many?
>
> Some CPU miners are now mining as many testnet4 blocks as they can by
> bumping their clock 20 minutes not just once, but several times in a row.
> Until they run against the limit other nodes put on how far a block can be
> in the future, namely two hours. So when a real difficulty block appears,
> you may see 5 blocks on top of it instantly.
>
> This behavior is even worse from the point of view of a developer trying
> to mine a non-standard transaction. Because the tip of your node is always
> going to be about two hours in the future, when you mine on top of that by
> moving your clock even further, it will be rejected by your peers.
>
> So this use case of CPU mining non-standard transactions is simply dead as
> long as this behaviour exists. We might as well reduce code complexity.
>
> That said, testnet will never mimic mainnet. It has no value, or worse,
> very little value. So the incentives are different, which leads to
> different behavior. That's a whack-a-mole game, which we should probably
> not dedicate time to.
>

The question I’ve had for some time is why spoofed blocks on testnet4 come
in batches of:

- 6 blocks
-20-minute intervals
- A maximum lead time of 2 hours

If these values were set for early Bitcoin network reasons, would it make
sense to tweak them for testnet4 to improve functionality? Reducing the
maximum lead from 2 hours to 1 hour and limiting batches to 3 blocks
instead of 6 seems like it could mitigate some of the observed issues while
maintaining testnet’s purpose.

Would this be feasible?


>
> - Sjors
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl
> <https://groups.google.com/d/msgid/bitcoindev/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYhLNTbA%3DqMuQ5W63jxwUoa2%2Bmpn020NC31JqGzbk0wPF-A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5463 bytes --]

 permalink raw reply	[|nested]
* 
  2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
  2025-03-18 21:34 ` Melvin Carvalho
  2025-03-19  7:01 ` [bitcoindev] " Garlo Nicon

  2025-03-19  9:11   ` Melvin Carvalho
  2025-03-19 17:03 ` 
                   ` 
  6 siblings, 1 reply; 31+ messages in thread
From: Sjors Provoost @ 2025-03-19  8:32 UTC (permalink / raw)
  To: 'Antoine Poinsot' via Bitcoin Development Mailing List
  Cc: Antoine Poinsot

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

Antoine Poinsot wrote:

> The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop. But you cannot have your cake and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed on both count: it neither mimics mainnet nor allows developers to mine active blocks on their laptop.

Let me clarify why developers can't mine on their own laptop with testnet4.

The way you would do that is to move your computer clock forward by 20 minutes (or use faketime), at which point the difficulty drops to 1. You would then mine your (presumably non-standard transaction) and broadcast it to the network.

This is also the strategy used to acquire more testnet coins if you don't have an ASIC and don't want to use a faucet.

On testnet3 the latter wasn't very productive because at height 4 million the block subsidy is under 10k sats.

But on testnet4 every block yields 50 tBTC. So several people try to mine such a block, leading to the many parallel forks. 

If you're a developer trying to mine a non-standard transaction, you have to be fast, well connected and lucky to be the first block picked up by the rest of the network.

But why mine just one if you can mine many?

Some CPU miners are now mining as many testnet4 blocks as they can by bumping their clock 20 minutes not just once, but several times in a row. Until they run against the limit other nodes put on how far a block can be in the future, namely two hours. So when a real difficulty block appears, you may see 5 blocks on top of it instantly.

This behavior is even worse from the point of view of a developer trying to mine a non-standard transaction. Because the tip of your node is always going to be about two hours in the future, when you mine on top of that by moving your clock even further, it will be rejected by your peers.

So this use case of CPU mining non-standard transactions is simply dead as long as this behaviour exists. We might as well reduce code complexity.

That said, testnet will never mimic mainnet. It has no value, or worse, very little value. So the incentives are different, which leads to different behavior. That's a whack-a-mole game, which we should probably not dedicate time to.

- Sjors


 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl.

[-- Attachment #2: Type: text/html, Size: 3788 bytes --]

^ permalink raw reply	[|nested] 31+ messages in thread
* 
  2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (2 preceding siblings ...)
  2025-03-19  8:32 ` Sjors Provoost

  2025-03-20 18:58 ` 
                   ` 
  6 siblings, 0 replies; 31+ messages in thread
From: bitcoin-dev-ml.void867 via Bitcoin Development Mailing List @ 2025-03-19 17:03 UTC (permalink / raw)
  Cc: Bitcoin Development Mailing List

> The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop.

Your suggestion to unbreak testnet4 makes sense. The need to mine a
non-standard consensus-valid transaction is satisfied as long as there
is a single miner who is willing to accept and mine it. Ideally such
transactions could be submitted on a public interface with some kind
of DoS protection.

Best, void867

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/174240385333.6.13961685190897668632.642902301%40slmail.me.


^ permalink raw reply	[|nested] 31+ messages in thread
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (4 preceding siblings ...)
  2025-03-20 18:58 ` Melvin Carvalho

  2025-03-24  7:00   ` Garlo Nicon
  2025-03-24 12:25   ` Murch
  2025-05-05 22:25 ` [bitcoindev] " Greg Maxwell
  
From: Murch @ 2025-03-21 21:20 UTC (permalink / raw)
  To: bitcoindev


[-- Attachment #1.1: Type: text/plain, Size: 1101 bytes --]

Hey Antoine and everyone,

What you suggest makes sense to me. Since the 20-minute difficulty 
exception is now exploited perpetually, it doesn’t serve its intended 
purpose of allowing developers to mine themselves a few coins easily or 
confirm their own non-standard transactions. In that case, it would be 
better to not have it at all.

On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing 
List wrote:
 > I propose to fix this by removing the difficulty reset rule from
 > testnet4 through a flag day hard fork on 2026-01-01.

I would suggest to pick a date that’s not a holiday in many places to 
avoid disrupting people’s holiday, how about 2026-01-01 instead?

Cheers,
Murch

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5c13e130-aaa2-4866-be26-7498100e868b%40murch.one.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-03-21 21:20 ` Murch

  2025-03-31  7:32     ` Saint Wenhao
  2025-03-24 12:25   ` Murch
  
From: Garlo Nicon @ 2025-03-24  7:00 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]

> The given rationale for a difficulty reset was to let developers 
occasionally mine blocks on their laptop.

It is technically possible to allow CPU users to get some coins, if they 
provide some Proof of Work.

Example Script: "OP_SIZE 60 OP_LESSTHAN OP_VERIFY 
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 
OP_CHECKSIG".

Related topic: 
https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937

And because this method is network-independent, and can be deployed 
anywhere (all testnets, mainnet, signet, regtest, doesn't matter), then it 
is probably a good idea to disable 20 minute rule, that way or another.

poniedziałek, 24 marca 2025 o 02:29:17 UTC+1 Murch napisał(a):

> Hey Antoine and everyone,
>
> What you suggest makes sense to me. Since the 20-minute difficulty 
> exception is now exploited perpetually, it doesn’t serve its intended 
> purpose of allowing developers to mine themselves a few coins easily or 
> confirm their own non-standard transactions. In that case, it would be 
> better to not have it at all.
>
> On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing 
> List wrote:
> > I propose to fix this by removing the difficulty reset rule from
> > testnet4 through a flag day hard fork on 2026-01-01.
>
> I would suggest to pick a date that’s not a holiday in many places to 
> avoid disrupting people’s holiday, how about 2026-01-01 instead?
>
> Cheers,
> Murch
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/85db9980-f6c9-48d8-a650-c69f16cd835fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2428 bytes --]

 permalink raw reply	[|nested]
2025-03-21 21:20 ` Murch
  2025-03-24  7:00   ` Garlo Nicon

  2025-03-24 13:57     ` 'Antoine Poinsot' via Bitcoin Development Mailing List
  
From: Murch @ 2025-03-24 12:25 UTC (permalink / raw)
  To: bitcoindev


[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]

Errr, I wrote the same date as you, but I meant a week later, 2026-01-08 
instead.

-Murch

On 2025-03-21 14:20, Murch wrote:
> Hey Antoine and everyone,
> 
> What you suggest makes sense to me. Since the 20-minute difficulty 
> exception is now exploited perpetually, it doesn’t serve its intended 
> purpose of allowing developers to mine themselves a few coins easily or 
> confirm their own non-standard transactions. In that case, it would be 
> better to not have it at all.
> 
> On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing 
> List wrote:
>  > I propose to fix this by removing the difficulty reset rule from
>  > testnet4 through a flag day hard fork on 2026-01-01.
> 
> I would suggest to pick a date that’s not a holiday in many places to 
> avoid disrupting people’s holiday, how about 2026-01-01 instead?
> 
> Cheers,
> Murch
> 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-03-24 12:25   ` Murch

  2025-04-27 11:44       ` Saint Wenhao
  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-24 13:57 UTC (permalink / raw)
  To: Murch;  bitcoindev

Good point on not having the flag day on a holiday. One or two weeks sounds good to me.




On Monday, March 24th, 2025 at 8:25 AM, Murch <murch@murch•one> wrote:

> 
> 
> Errr, I wrote the same date as you, but I meant a week later, 2026-01-08
> instead.
> 
> -Murch
> 
> On 2025-03-21 14:20, Murch wrote:
> 
> > Hey Antoine and everyone,
> > 
> > What you suggest makes sense to me. Since the 20-minute difficulty
> > exception is now exploited perpetually, it doesn’t serve its intended
> > purpose of allowing developers to mine themselves a few coins easily or
> > confirm their own non-standard transactions. In that case, it would be
> > better to not have it at all.
> > 
> > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
> > List wrote:
> > 
> > > I propose to fix this by removing the difficulty reset rule from
> > > testnet4 through a flag day hard fork on 2026-01-01.
> > 
> > I would suggest to pick a date that’s not a holiday in many places to
> > avoid disrupting people’s holiday, how about 2026-01-01 instead?
> > 
> > Cheers,
> > Murch
> 
> 
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/vgcVopNpWCowIGaIpVgjsCWyTMjxVKoWtRdDVnTNrM8tYPjKtC6MJ6S-2KxIYdJYgAhG8iNPig-xijwd7DtAm6tHN3T3xgIMUNUSTBYvT_A%3D%40protonmail.com.


 permalink raw reply	[|nested]
2025-03-24  7:00   ` Garlo Nicon

  
From: Saint Wenhao @ 2025-03-31  7:32 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]

> But on testnet4 every block yields 50 tBTC. So several people try to mine 
such a block, leading to the many parallel forks.

What about lowering the coinbase block reward (with fees), if the 
difficulty was resetted? For example: if the real difficulty is equal to 
1,000,000, and some CPU miner got 50.01 tBTC, then that miner could simply 
receive 5,001 satoshis instead. And the rest of the block reward can be 
just timelocked to the future block number, or simply burned (which is 
easier to implement).

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/896cdecf-6b73-4f50-aa0f-aafb02c93ff8n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1160 bytes --]

 permalink raw reply	[|nested]
2025-03-24 13:57     ` 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-04-27 22:49         ` Jameson Lopp
  
From: Saint Wenhao @ 2025-04-27 11:44 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4546 bytes --]

What about introducing demurrage in testnet5 consensus rules?

Testnet coins were supposed to be worthless. But it failed in both testnet3 
and testnet4. In the meanwhile, signet was introduced, to make a more 
stable test network. However, signing blocks was listed on wiki page 
https://en.bitcoin.it/wiki/Prohibited_changes as something, that "Require 
unanimous consent". And, as the history can tell us, people still wanted to 
test mining anyway, which is why testnet3 and testnet4 have much more 
chainwork than signet (and when it comes to signet, sending 
signed-but-unmined blocks to the miners was never implemented, so they had 
no chance to provide more hashing power).

Another kind of change on the list, that would require consent, was 
increasing the total number of coins beyond 21 million. But then, testing 
supply limits would be harder, and it could cause integer overflows in some 
cases. But: in all test networks, including testnet3, testnet4, and signet, 
there was never a problem of "not enough coins for miners", so that change 
probably wouldn't solve any problems (and seeing it in action would take 
years anyway; testnet4 is still far from the first halving, and it is 
traded anyway, so that change won't fix it).

Then, we have the third option, which was not yet tried in test networks: 
demurrage. There are two main options: burning coins, or re-assigning them 
to someone else. To make a soft-fork out of it, re-assigning would be 
backward-incompatible, so it is probably easier to just implement burning, 
and just treat all coins older than N blocks in the same way, as OP_RETURN, 
by simply invalidating transactions spending them on consensus level.

Also, when it comes to maintaining testnet nodes, if it would be possible 
to automatically remove things from the UTXO set, then it would make 
Initial Blockchain Download easier, just because new nodes wouldn't need to 
synchronize everything, if old coins would be automatically invalidated. In 
practice, all nodes could be just running in pruned mode all the time, and 
everything beyond the pruning point, could be simply ignored on consensus 
level (which would also prevent the UTXO set from exploding). And then, if 
we would keep for example the last 2,016 blocks, then the whole chain would 
never take more than 2016 * 4 MB = 8.064 GB of storage, and that's all we 
would need to send during Initial Blockchain Download to other nodes.

poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):

> Good point on not having the flag day on a holiday. One or two weeks 
> sounds good to me.
>
>
>
>
> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote:
>
> > 
> > 
> > Errr, I wrote the same date as you, but I meant a week later, 2026-01-08
> > instead.
> > 
> > -Murch
> > 
> > On 2025-03-21 14:20, Murch wrote:
> > 
> > > Hey Antoine and everyone,
> > > 
> > > What you suggest makes sense to me. Since the 20-minute difficulty
> > > exception is now exploited perpetually, it doesn’t serve its intended
> > > purpose of allowing developers to mine themselves a few coins easily or
> > > confirm their own non-standard transactions. In that case, it would be
> > > better to not have it at all.
> > > 
> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
> > > List wrote:
> > > 
> > > > I propose to fix this by removing the difficulty reset rule from
> > > > testnet4 through a flag day hard fork on 2026-01-01.
> > > 
> > > I would suggest to pick a date that’s not a holiday in many places to
> > > avoid disrupting people’s holiday, how about 2026-01-01 instead?
> > > 
> > > Cheers,
> > > Murch
> > 
> > 
> > --
> > You received this message because you are subscribed to the Google 
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to bitcoindev+...@googlegroups•com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5671 bytes --]

 permalink raw reply	[|nested]
2025-04-27 11:44       ` Saint Wenhao

  2025-04-28  6:11           ` Saint Wenhao
  
From: Jameson Lopp @ 2025-04-27 22:49 UTC (permalink / raw)
  To: Saint Wenhao;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 5683 bytes --]

On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao <saintwenhao@gmail•com> wrote:

> What about introducing demurrage in testnet5 consensus rules?
>
In general it seems desirable for a testnet to be as close as possible to
mainnet's rules. Demurrage might be asking a bit much in terms of deviation.

I'd suggest simply disabling the halving logic and making it a perpetual 50
TBTC issuance. At that rate, it would still take ~8 years or so to surpass
the 21M limit and I'd think that testnets should be reset more frequently
than that.

>
> Testnet coins were supposed to be worthless. But it failed in both
> testnet3 and testnet4. In the meanwhile, signet was introduced, to make a
> more stable test network. However, signing blocks was listed on wiki page
> https://en.bitcoin.it/wiki/Prohibited_changes as something, that "Require
> unanimous consent". And, as the history can tell us, people still wanted to
> test mining anyway, which is why testnet3 and testnet4 have much more
> chainwork than signet (and when it comes to signet, sending
> signed-but-unmined blocks to the miners was never implemented, so they had
> no chance to provide more hashing power).
>
> Another kind of change on the list, that would require consent, was
> increasing the total number of coins beyond 21 million. But then, testing
> supply limits would be harder, and it could cause integer overflows in some
> cases. But: in all test networks, including testnet3, testnet4, and signet,
> there was never a problem of "not enough coins for miners", so that change
> probably wouldn't solve any problems (and seeing it in action would take
> years anyway; testnet4 is still far from the first halving, and it is
> traded anyway, so that change won't fix it).
>
> Then, we have the third option, which was not yet tried in test networks:
> demurrage. There are two main options: burning coins, or re-assigning them
> to someone else. To make a soft-fork out of it, re-assigning would be
> backward-incompatible, so it is probably easier to just implement burning,
> and just treat all coins older than N blocks in the same way, as OP_RETURN,
> by simply invalidating transactions spending them on consensus level.
>
> Also, when it comes to maintaining testnet nodes, if it would be possible
> to automatically remove things from the UTXO set, then it would make
> Initial Blockchain Download easier, just because new nodes wouldn't need to
> synchronize everything, if old coins would be automatically invalidated. In
> practice, all nodes could be just running in pruned mode all the time, and
> everything beyond the pruning point, could be simply ignored on consensus
> level (which would also prevent the UTXO set from exploding). And then, if
> we would keep for example the last 2,016 blocks, then the whole chain would
> never take more than 2016 * 4 MB = 8.064 GB of storage, and that's all we
> would need to send during Initial Blockchain Download to other nodes.
>
> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):
>
>> Good point on not having the flag day on a holiday. One or two weeks
>> sounds good to me.
>>
>>
>>
>>
>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote:
>>
>> >
>> >
>> > Errr, I wrote the same date as you, but I meant a week later,
>> 2026-01-08
>> > instead.
>> >
>> > -Murch
>> >
>> > On 2025-03-21 14:20, Murch wrote:
>> >
>> > > Hey Antoine and everyone,
>> > >
>> > > What you suggest makes sense to me. Since the 20-minute difficulty
>> > > exception is now exploited perpetually, it doesn’t serve its intended
>> > > purpose of allowing developers to mine themselves a few coins easily
>> or
>> > > confirm their own non-standard transactions. In that case, it would
>> be
>> > > better to not have it at all.
>> > >
>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development
>> Mailing
>> > > List wrote:
>> > >
>> > > > I propose to fix this by removing the difficulty reset rule from
>> > > > testnet4 through a flag day hard fork on 2026-01-01.
>> > >
>> > > I would suggest to pick a date that’s not a holiday in many places to
>> > > avoid disrupting people’s holiday, how about 2026-01-01 instead?
>> > >
>> > > Cheers,
>> > > Murch
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Bitcoin Development Mailing List" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to bitcoindev+...@googlegroups•com.
>> > To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXcmD8fEpL9Sqqwt6EfwtdjG%2BAaqk%2BpgSBhPmaVT3gEw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7178 bytes --]

 permalink raw reply	[|nested]
2025-04-27 22:49         ` Jameson Lopp

  2025-04-28 10:45             ` Jameson Lopp
       [not found]             ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
  
From: Saint Wenhao @ 2025-04-28  6:11 UTC (permalink / raw)
  To: Jameson Lopp;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 7225 bytes --]

> Demurrage might be asking a bit much in terms of deviation.

If that's the case, then why signing all blocks in signet is not "too
much"? Or why unlimited supply is not "too much"? All of these changes were
put in the same basket of "Require unanimous consent", so why one kind of
change is better or worse than the others? All of them deviates from the
mainnet, and we probably wouldn't want anything like that on the original
chain anyway.

> I'd think that testnets should be reset more frequently than that.

Then why don't we put any kind of reset logic into testnet5 consensus
rules? Because when nothing like that is present, then testnets can
potentially run forever. Testnet3 is becoming an altcoin, and new testnets
will also be, if no significant changes will be made. Signet is not traded
yet, mainly because of centralized mining, but there already are
centralized altcoin federations, so it may change in the future.

And again, the word "reset" should be replaced by "abandon", unless you
really want to reorganize the whole old chain of some existing testnet, by
producing a stronger alternative chain in testnet5, which would replace the
old network in a backward-compatible way, by mining everything on top of
the same Genesis Block, and eventually producing a bigger chainwork.

pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameson.lopp@gmail•com> napisał(a):

>
>
> On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao <saintwenhao@gmail•com>
> wrote:
>
>> What about introducing demurrage in testnet5 consensus rules?
>>
> In general it seems desirable for a testnet to be as close as possible to
> mainnet's rules. Demurrage might be asking a bit much in terms of deviation.
>
> I'd suggest simply disabling the halving logic and making it a perpetual
> 50 TBTC issuance. At that rate, it would still take ~8 years or so to
> surpass the 21M limit and I'd think that testnets should be reset more
> frequently than that.
>
>>
>> Testnet coins were supposed to be worthless. But it failed in both
>> testnet3 and testnet4. In the meanwhile, signet was introduced, to make a
>> more stable test network. However, signing blocks was listed on wiki page
>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that
>> "Require unanimous consent". And, as the history can tell us, people still
>> wanted to test mining anyway, which is why testnet3 and testnet4 have much
>> more chainwork than signet (and when it comes to signet, sending
>> signed-but-unmined blocks to the miners was never implemented, so they had
>> no chance to provide more hashing power).
>>
>> Another kind of change on the list, that would require consent, was
>> increasing the total number of coins beyond 21 million. But then, testing
>> supply limits would be harder, and it could cause integer overflows in some
>> cases. But: in all test networks, including testnet3, testnet4, and signet,
>> there was never a problem of "not enough coins for miners", so that change
>> probably wouldn't solve any problems (and seeing it in action would take
>> years anyway; testnet4 is still far from the first halving, and it is
>> traded anyway, so that change won't fix it).
>>
>> Then, we have the third option, which was not yet tried in test networks:
>> demurrage. There are two main options: burning coins, or re-assigning them
>> to someone else. To make a soft-fork out of it, re-assigning would be
>> backward-incompatible, so it is probably easier to just implement burning,
>> and just treat all coins older than N blocks in the same way, as OP_RETURN,
>> by simply invalidating transactions spending them on consensus level.
>>
>> Also, when it comes to maintaining testnet nodes, if it would be possible
>> to automatically remove things from the UTXO set, then it would make
>> Initial Blockchain Download easier, just because new nodes wouldn't need to
>> synchronize everything, if old coins would be automatically invalidated. In
>> practice, all nodes could be just running in pruned mode all the time, and
>> everything beyond the pruning point, could be simply ignored on consensus
>> level (which would also prevent the UTXO set from exploding). And then, if
>> we would keep for example the last 2,016 blocks, then the whole chain would
>> never take more than 2016 * 4 MB = 8.064 GB of storage, and that's all we
>> would need to send during Initial Blockchain Download to other nodes.
>>
>> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):
>>
>>> Good point on not having the flag day on a holiday. One or two weeks
>>> sounds good to me.
>>>
>>>
>>>
>>>
>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote:
>>>
>>> >
>>> >
>>> > Errr, I wrote the same date as you, but I meant a week later,
>>> 2026-01-08
>>> > instead.
>>> >
>>> > -Murch
>>> >
>>> > On 2025-03-21 14:20, Murch wrote:
>>> >
>>> > > Hey Antoine and everyone,
>>> > >
>>> > > What you suggest makes sense to me. Since the 20-minute difficulty
>>> > > exception is now exploited perpetually, it doesn’t serve its
>>> intended
>>> > > purpose of allowing developers to mine themselves a few coins easily
>>> or
>>> > > confirm their own non-standard transactions. In that case, it would
>>> be
>>> > > better to not have it at all.
>>> > >
>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development
>>> Mailing
>>> > > List wrote:
>>> > >
>>> > > > I propose to fix this by removing the difficulty reset rule from
>>> > > > testnet4 through a flag day hard fork on 2026-01-01.
>>> > >
>>> > > I would suggest to pick a date that’s not a holiday in many places
>>> to
>>> > > avoid disrupting people’s holiday, how about 2026-01-01 instead?
>>> > >
>>> > > Cheers,
>>> > > Murch
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "Bitcoin Development Mailing List" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to bitcoindev+...@googlegroups•com.
>>> > To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 8943 bytes --]

 permalink raw reply	[|nested]
2025-04-28  6:11           ` Saint Wenhao

  2025-04-28 11:59               ` 'emsit' via Bitcoin Development Mailing List
  2025-04-28 12:47               ` Sjors Provoost
       [not found]             ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
  
From: Jameson Lopp @ 2025-04-28 10:45 UTC (permalink / raw)
  To: Saint Wenhao;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 7998 bytes --]

On Mon, Apr 28, 2025 at 2:11 AM Saint Wenhao <saintwenhao@gmail•com> wrote:

> > Demurrage might be asking a bit much in terms of deviation.
>
> If that's the case, then why signing all blocks in signet is not "too
> much"?
>

Because signet isn't testnet? It gives up permissionless block creation in
return for predictability.


> Or why unlimited supply is not "too much"?
>

It might be, but it might not be, given that the point of testnet is for
coins to be free for developers to acquire and use without fear of
financial loss. Thus scarcity isn't really an inviolable property of
testnet.


> All of these changes were put in the same basket of "Require unanimous
> consent", so why one kind of change is better or worse than the others? All
> of them deviates from the mainnet, and we probably wouldn't want anything
> like that on the original chain anyway.
>
> > I'd think that testnets should be reset more frequently than that.
>
> Then why don't we put any kind of reset logic into testnet5 consensus
> rules? Because when nothing like that is present, then testnets can
> potentially run forever. Testnet3 is becoming an altcoin, and new testnets
> will also be, if no significant changes will be made. Signet is not traded
> yet, mainly because of centralized mining, but there already are
> centralized altcoin federations, so it may change in the future.
>
>
Encoding an "end of life date" into testnets is actually an interesting
idea worth discussing. As far as I'm aware it's never been done before on
any network.

And again, the word "reset" should be replaced by "abandon", unless you
> really want to reorganize the whole old chain of some existing testnet, by
> producing a stronger alternative chain in testnet5, which would replace the
> old network in a backward-compatible way, by mining everything on top of
> the same Genesis Block, and eventually producing a bigger chainwork.
>
> pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameson.lopp@gmail•com>
> napisał(a):
>
>>
>>
>> On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao <saintwenhao@gmail•com>
>> wrote:
>>
>>> What about introducing demurrage in testnet5 consensus rules?
>>>
>> In general it seems desirable for a testnet to be as close as possible to
>> mainnet's rules. Demurrage might be asking a bit much in terms of deviation.
>>
>> I'd suggest simply disabling the halving logic and making it a perpetual
>> 50 TBTC issuance. At that rate, it would still take ~8 years or so to
>> surpass the 21M limit and I'd think that testnets should be reset more
>> frequently than that.
>>
>>>
>>> Testnet coins were supposed to be worthless. But it failed in both
>>> testnet3 and testnet4. In the meanwhile, signet was introduced, to make a
>>> more stable test network. However, signing blocks was listed on wiki page
>>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that
>>> "Require unanimous consent". And, as the history can tell us, people still
>>> wanted to test mining anyway, which is why testnet3 and testnet4 have much
>>> more chainwork than signet (and when it comes to signet, sending
>>> signed-but-unmined blocks to the miners was never implemented, so they had
>>> no chance to provide more hashing power).
>>>
>>> Another kind of change on the list, that would require consent, was
>>> increasing the total number of coins beyond 21 million. But then, testing
>>> supply limits would be harder, and it could cause integer overflows in some
>>> cases. But: in all test networks, including testnet3, testnet4, and signet,
>>> there was never a problem of "not enough coins for miners", so that change
>>> probably wouldn't solve any problems (and seeing it in action would take
>>> years anyway; testnet4 is still far from the first halving, and it is
>>> traded anyway, so that change won't fix it).
>>>
>>> Then, we have the third option, which was not yet tried in test
>>> networks: demurrage. There are two main options: burning coins, or
>>> re-assigning them to someone else. To make a soft-fork out of it,
>>> re-assigning would be backward-incompatible, so it is probably easier to
>>> just implement burning, and just treat all coins older than N blocks in the
>>> same way, as OP_RETURN, by simply invalidating transactions spending them
>>> on consensus level.
>>>
>>> Also, when it comes to maintaining testnet nodes, if it would be
>>> possible to automatically remove things from the UTXO set, then it would
>>> make Initial Blockchain Download easier, just because new nodes wouldn't
>>> need to synchronize everything, if old coins would be automatically
>>> invalidated. In practice, all nodes could be just running in pruned mode
>>> all the time, and everything beyond the pruning point, could be simply
>>> ignored on consensus level (which would also prevent the UTXO set from
>>> exploding). And then, if we would keep for example the last 2,016 blocks,
>>> then the whole chain would never take more than 2016 * 4 MB = 8.064 GB of
>>> storage, and that's all we would need to send during Initial Blockchain
>>> Download to other nodes.
>>>
>>> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):
>>>
>>>> Good point on not having the flag day on a holiday. One or two weeks
>>>> sounds good to me.
>>>>
>>>>
>>>>
>>>>
>>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote:
>>>>
>>>> >
>>>> >
>>>> > Errr, I wrote the same date as you, but I meant a week later,
>>>> 2026-01-08
>>>> > instead.
>>>> >
>>>> > -Murch
>>>> >
>>>> > On 2025-03-21 14:20, Murch wrote:
>>>> >
>>>> > > Hey Antoine and everyone,
>>>> > >
>>>> > > What you suggest makes sense to me. Since the 20-minute difficulty
>>>> > > exception is now exploited perpetually, it doesn’t serve its
>>>> intended
>>>> > > purpose of allowing developers to mine themselves a few coins
>>>> easily or
>>>> > > confirm their own non-standard transactions. In that case, it would
>>>> be
>>>> > > better to not have it at all.
>>>> > >
>>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development
>>>> Mailing
>>>> > > List wrote:
>>>> > >
>>>> > > > I propose to fix this by removing the difficulty reset rule from
>>>> > > > testnet4 through a flag day hard fork on 2026-01-01.
>>>> > >
>>>> > > I would suggest to pick a date that’s not a holiday in many places
>>>> to
>>>> > > avoid disrupting people’s holiday, how about 2026-01-01 instead?
>>>> > >
>>>> > > Cheers,
>>>> > > Murch
>>>> >
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> Groups "Bitcoin Development Mailing List" group.
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to bitcoindev+...@googlegroups•com.
>>>> > To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to bitcoindev+unsubscribe@googlegroups•com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_dfaBQJDXu%3DurRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 10438 bytes --]

 permalink raw reply	[|nested]
[not found]             ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>

  
From: pithosian @ 2025-04-28 11:48 UTC (permalink / raw)
  To: bitcoindev

On Sun, 27 Apr 2025 22:54:54 +0000 (UTC)
Jameson Lopp <jameson.lopp@gmail•com> wrote:
> I'd suggest simply disabling the halving logic and making it a
> perpetual 50 TBTC issuance. At that rate, it would still take ~8
> years or so to surpass the 21M limit and I'd think that testnets
> should be reset more frequently than that.

On Mon, 28 Apr 2025 11:06:55 +0000 (UTC)
Jameson Lopp <jameson.lopp@gmail•com> wrote:
> Encoding an "end of life date" into testnets is actually an
> interesting idea worth discussing. As far as I'm aware it's never
> been done before on any network.
What about having the halving act as a reset? Eg: don't reduce the
mining reward AND disallow spends of UTXOs from before the last halving.

> On Mon, Apr 28, 2025 at 2:11 AM Saint Wenhao <saintwenhao@gmail•com>
> wrote:
> 
> > > Demurrage might be asking a bit much in terms of deviation.
> >
> > If that's the case, then why signing all blocks in signet is not
> > "too much"?
> >
> 
> Because signet isn't testnet? It gives up permissionless block
> creation in return for predictability.
> 
> 
> > Or why unlimited supply is not "too much"?
> >
> 
> It might be, but it might not be, given that the point of testnet is
> for coins to be free for developers to acquire and use without fear of
> financial loss. Thus scarcity isn't really an inviolable property of
> testnet.
> 
> 
> > All of these changes were put in the same basket of "Require
> > unanimous consent", so why one kind of change is better or worse
> > than the others? All of them deviates from the mainnet, and we
> > probably wouldn't want anything like that on the original chain
> > anyway.
> >
> > > I'd think that testnets should be reset more frequently than that.
> >
> > Then why don't we put any kind of reset logic into testnet5
> > consensus rules? Because when nothing like that is present, then
> > testnets can potentially run forever. Testnet3 is becoming an
> > altcoin, and new testnets will also be, if no significant changes
> > will be made. Signet is not traded yet, mainly because of
> > centralized mining, but there already are centralized altcoin
> > federations, so it may change in the future.
> >
> >
> Encoding an "end of life date" into testnets is actually an
> interesting idea worth discussing. As far as I'm aware it's never
> been done before on any network.
> 
> And again, the word "reset" should be replaced by "abandon", unless
> you
> > really want to reorganize the whole old chain of some existing
> > testnet, by producing a stronger alternative chain in testnet5,
> > which would replace the old network in a backward-compatible way,
> > by mining everything on top of the same Genesis Block, and
> > eventually producing a bigger chainwork.
> >
> > pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameson.lopp@gmail•com>
> > napisał(a):
> >
> >>
> >>
> >> On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao
> >> <saintwenhao@gmail•com> wrote:
> >>
> >>> What about introducing demurrage in testnet5 consensus rules?
> >>>
> >> In general it seems desirable for a testnet to be as close as
> >> possible to mainnet's rules. Demurrage might be asking a bit much
> >> in terms of deviation.
> >>
> >> I'd suggest simply disabling the halving logic and making it a
> >> perpetual 50 TBTC issuance. At that rate, it would still take ~8
> >> years or so to surpass the 21M limit and I'd think that testnets
> >> should be reset more frequently than that.
> >>
> >>>
> >>> Testnet coins were supposed to be worthless. But it failed in both
> >>> testnet3 and testnet4. In the meanwhile, signet was introduced,
> >>> to make a more stable test network. However, signing blocks was
> >>> listed on wiki page https://en.bitcoin.it/wiki/Prohibited_changes
> >>> as something, that "Require unanimous consent". And, as the
> >>> history can tell us, people still wanted to test mining anyway,
> >>> which is why testnet3 and testnet4 have much more chainwork than
> >>> signet (and when it comes to signet, sending signed-but-unmined
> >>> blocks to the miners was never implemented, so they had no chance
> >>> to provide more hashing power).
> >>>
> >>> Another kind of change on the list, that would require consent,
> >>> was increasing the total number of coins beyond 21 million. But
> >>> then, testing supply limits would be harder, and it could cause
> >>> integer overflows in some cases. But: in all test networks,
> >>> including testnet3, testnet4, and signet, there was never a
> >>> problem of "not enough coins for miners", so that change probably
> >>> wouldn't solve any problems (and seeing it in action would take
> >>> years anyway; testnet4 is still far from the first halving, and
> >>> it is traded anyway, so that change won't fix it).
> >>>
> >>> Then, we have the third option, which was not yet tried in test
> >>> networks: demurrage. There are two main options: burning coins, or
> >>> re-assigning them to someone else. To make a soft-fork out of it,
> >>> re-assigning would be backward-incompatible, so it is probably
> >>> easier to just implement burning, and just treat all coins older
> >>> than N blocks in the same way, as OP_RETURN, by simply
> >>> invalidating transactions spending them on consensus level.
> >>>
> >>> Also, when it comes to maintaining testnet nodes, if it would be
> >>> possible to automatically remove things from the UTXO set, then
> >>> it would make Initial Blockchain Download easier, just because
> >>> new nodes wouldn't need to synchronize everything, if old coins
> >>> would be automatically invalidated. In practice, all nodes could
> >>> be just running in pruned mode all the time, and everything
> >>> beyond the pruning point, could be simply ignored on consensus
> >>> level (which would also prevent the UTXO set from exploding). And
> >>> then, if we would keep for example the last 2,016 blocks, then
> >>> the whole chain would never take more than 2016 * 4 MB = 8.064 GB
> >>> of storage, and that's all we would need to send during Initial
> >>> Blockchain Download to other nodes.
> >>>
> >>> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot
> >>> napisał(a):
> >>>
> >>>> Good point on not having the flag day on a holiday. One or two
> >>>> weeks sounds good to me.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one>
> >>>> wrote:
> >>>>
> >>>> >
> >>>> >
> >>>> > Errr, I wrote the same date as you, but I meant a week later,
> >>>> 2026-01-08
> >>>> > instead.
> >>>> >
> >>>> > -Murch
> >>>> >
> >>>> > On 2025-03-21 14:20, Murch wrote:
> >>>> >
> >>>> > > Hey Antoine and everyone,
> >>>> > >
> >>>> > > What you suggest makes sense to me. Since the 20-minute
> >>>> > > difficulty exception is now exploited perpetually, it
> >>>> > > doesn’t serve its
> >>>> intended
> >>>> > > purpose of allowing developers to mine themselves a few coins
> >>>> easily or
> >>>> > > confirm their own non-standard transactions. In that case,
> >>>> > > it would
> >>>> be
> >>>> > > better to not have it at all.
> >>>> > >
> >>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin
> >>>> > > Development
> >>>> Mailing
> >>>> > > List wrote:
> >>>> > >
> >>>> > > > I propose to fix this by removing the difficulty reset
> >>>> > > > rule from testnet4 through a flag day hard fork on
> >>>> > > > 2026-01-01.
> >>>> > >
> >>>> > > I would suggest to pick a date that’s not a holiday in many
> >>>> > > places
> >>>> to
> >>>> > > avoid disrupting people’s holiday, how about 2026-01-01
> >>>> > > instead?
> >>>> > >
> >>>> > > Cheers,
> >>>> > > Murch
> >>>> >
> >>>> >
> >>>> > --
> >>>> > You received this message because you are subscribed to the
> >>>> > Google
> >>>> Groups "Bitcoin Development Mailing List" group.
> >>>> > To unsubscribe from this group and stop receiving emails from
> >>>> > it,
> >>>> send an email to bitcoindev+...@googlegroups•com.
> >>>> > To view this discussion visit
> >>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
> >>>>
> >>>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Bitcoin Development Mailing List" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> >>> send an email to bitcoindev+unsubscribe@googlegroups•com.
> >>> To view this discussion visit
> >>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com
> >>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> >>> .
> >>>
> >>
> 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250428114858.46B477C1126%40smtp.postman.i2p.


 permalink raw reply	[|nested]
2025-04-28 10:45             ` Jameson Lopp

  2025-04-28 12:47               ` Sjors Provoost
  
From: 'emsit' via Bitcoin Development Mailing List @ 2025-04-28 11:59 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 9733 bytes --]

I think that the idea of expiring testnet coins would kill faucets. So 
getting some coins would become even harder.
My faucet doesn't work based on donations. What I distribute I had to mine 
myself (ideally in the early days, when the difficulty was lower). And 
since I’ve been running the faucet for more than 10 years, I can say that 
only a very small portion of testnet BTC ever returns to the faucet, and it 
was like that even before people started trading it.
It's better for people to keep their testnet coins for future use rather 
than later struggling to find ways to get more. Not everyone can mine. I 
myself had to rent mining power.
Back in the day, I used to give away 1-2 BTC per withdrawal — there were 
enough coins, and nobody cared about them. But in recent years, demand has 
skyrocketed, supplies have shrunk, and withdrawals became more frequent. 
Some people started abusing faucets, and it’s still happening today, which 
is why my current withdrawal limit is set to 0.001-0.002 per request.

Even though testnet4 is new and the block reward is 50 BTC, it hasn’t 
solved the shortage problem because most mined coins aren't publicly 
available.
And even if some faucet had plenty of them, it would still only offer a 
very small withdrawal amount, because people would immediately start 
abusing it to profit.

Dátum: pondelok 28. apríla 2025, čas: 13:06:38 UTC+2, odosielateľ: Jameson 
Lopp

> On Mon, Apr 28, 2025 at 2:11 AM Saint Wenhao <saint...@gmail•com> wrote:
>
>> > Demurrage might be asking a bit much in terms of deviation.
>>
>> If that's the case, then why signing all blocks in signet is not "too 
>> much"? 
>>
>
> Because signet isn't testnet? It gives up permissionless block creation in 
> return for predictability.
>  
>
>> Or why unlimited supply is not "too much"? 
>>
>
> It might be, but it might not be, given that the point of testnet is for 
> coins to be free for developers to acquire and use without fear of 
> financial loss. Thus scarcity isn't really an inviolable property of 
> testnet.
>  
>
>> All of these changes were put in the same basket of "Require unanimous 
>> consent", so why one kind of change is better or worse than the others? All 
>> of them deviates from the mainnet, and we probably wouldn't want anything 
>> like that on the original chain anyway.
>>
>
>>
>> > I'd think that testnets should be reset more frequently than that.
>>
>> Then why don't we put any kind of reset logic into testnet5 consensus 
>> rules? Because when nothing like that is present, then testnets can 
>> potentially run forever. Testnet3 is becoming an altcoin, and new testnets 
>> will also be, if no significant changes will be made. Signet is not traded 
>> yet, mainly because of centralized mining, but there already are 
>> centralized altcoin federations, so it may change in the future.
>>
>>
> Encoding an "end of life date" into testnets is actually an interesting 
> idea worth discussing. As far as I'm aware it's never been done before on 
> any network. 
>
> And again, the word "reset" should be replaced by "abandon", unless you 
>> really want to reorganize the whole old chain of some existing testnet, by 
>> producing a stronger alternative chain in testnet5, which would replace the 
>> old network in a backward-compatible way, by mining everything on top of 
>> the same Genesis Block, and eventually producing a bigger chainwork.
>>
>
>> pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameso...@gmail•com> napisał(a):
>>
>>>
>>>
>>> On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao <saint...@gmail•com> 
>>> wrote:
>>>
>>>> What about introducing demurrage in testnet5 consensus rules?
>>>>
>>> In general it seems desirable for a testnet to be as close as possible 
>>> to mainnet's rules. Demurrage might be asking a bit much in terms of 
>>> deviation.
>>>
>>> I'd suggest simply disabling the halving logic and making it a perpetual 
>>> 50 TBTC issuance. At that rate, it would still take ~8 years or so to 
>>> surpass the 21M limit and I'd think that testnets should be reset more 
>>> frequently than that.
>>>
>>>>
>>>> Testnet coins were supposed to be worthless. But it failed in both 
>>>> testnet3 and testnet4. In the meanwhile, signet was introduced, to make a 
>>>> more stable test network. However, signing blocks was listed on wiki page 
>>>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that 
>>>> "Require unanimous consent". And, as the history can tell us, people still 
>>>> wanted to test mining anyway, which is why testnet3 and testnet4 have much 
>>>> more chainwork than signet (and when it comes to signet, sending 
>>>> signed-but-unmined blocks to the miners was never implemented, so they had 
>>>> no chance to provide more hashing power).
>>>>
>>>> Another kind of change on the list, that would require consent, was 
>>>> increasing the total number of coins beyond 21 million. But then, testing 
>>>> supply limits would be harder, and it could cause integer overflows in some 
>>>> cases. But: in all test networks, including testnet3, testnet4, and signet, 
>>>> there was never a problem of "not enough coins for miners", so that change 
>>>> probably wouldn't solve any problems (and seeing it in action would take 
>>>> years anyway; testnet4 is still far from the first halving, and it is 
>>>> traded anyway, so that change won't fix it).
>>>>
>>>> Then, we have the third option, which was not yet tried in test 
>>>> networks: demurrage. There are two main options: burning coins, or 
>>>> re-assigning them to someone else. To make a soft-fork out of it, 
>>>> re-assigning would be backward-incompatible, so it is probably easier to 
>>>> just implement burning, and just treat all coins older than N blocks in the 
>>>> same way, as OP_RETURN, by simply invalidating transactions spending them 
>>>> on consensus level.
>>>>
>>>> Also, when it comes to maintaining testnet nodes, if it would be 
>>>> possible to automatically remove things from the UTXO set, then it would 
>>>> make Initial Blockchain Download easier, just because new nodes wouldn't 
>>>> need to synchronize everything, if old coins would be automatically 
>>>> invalidated. In practice, all nodes could be just running in pruned mode 
>>>> all the time, and everything beyond the pruning point, could be simply 
>>>> ignored on consensus level (which would also prevent the UTXO set from 
>>>> exploding). And then, if we would keep for example the last 2,016 blocks, 
>>>> then the whole chain would never take more than 2016 * 4 MB = 8.064 GB of 
>>>> storage, and that's all we would need to send during Initial Blockchain 
>>>> Download to other nodes.
>>>>
>>>> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):
>>>>
>>>>> Good point on not having the flag day on a holiday. One or two weeks 
>>>>> sounds good to me. 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote: 
>>>>>
>>>>> > 
>>>>> > 
>>>>> > Errr, I wrote the same date as you, but I meant a week later, 
>>>>> 2026-01-08 
>>>>> > instead. 
>>>>> > 
>>>>> > -Murch 
>>>>> > 
>>>>> > On 2025-03-21 14:20, Murch wrote: 
>>>>> > 
>>>>> > > Hey Antoine and everyone, 
>>>>> > > 
>>>>> > > What you suggest makes sense to me. Since the 20-minute difficulty 
>>>>> > > exception is now exploited perpetually, it doesn’t serve its 
>>>>> intended 
>>>>> > > purpose of allowing developers to mine themselves a few coins 
>>>>> easily or 
>>>>> > > confirm their own non-standard transactions. In that case, it 
>>>>> would be 
>>>>> > > better to not have it at all. 
>>>>> > > 
>>>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development 
>>>>> Mailing 
>>>>> > > List wrote: 
>>>>> > > 
>>>>> > > > I propose to fix this by removing the difficulty reset rule from 
>>>>> > > > testnet4 through a flag day hard fork on 2026-01-01. 
>>>>> > > 
>>>>> > > I would suggest to pick a date that’s not a holiday in many places 
>>>>> to 
>>>>> > > avoid disrupting people’s holiday, how about 2026-01-01 instead? 
>>>>> > > 
>>>>> > > Cheers, 
>>>>> > > Murch 
>>>>> > 
>>>>> > 
>>>>> > -- 
>>>>> > You received this message because you are subscribed to the Google 
>>>>> Groups "Bitcoin Development Mailing List" group. 
>>>>> > To unsubscribe from this group and stop receiving emails from it, 
>>>>> send an email to bitcoindev+...@googlegroups•com. 
>>>>> > To view this discussion visit 
>>>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one. 
>>>>>
>>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Bitcoin Development Mailing List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to bitcoindev+...@googlegroups•com.
>>>> To view this discussion visit 
>>>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com 
>>>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 13551 bytes --]

 permalink raw reply	[|nested]
2025-04-28 10:45             ` Jameson Lopp
  2025-04-28 11:59               ` 'emsit' via Bitcoin Development Mailing List

  2025-04-28 13:33                 ` Saint Wenhao
  2025-04-28 18:15                 ` Saint Wenhao
  
From: Sjors Provoost @ 2025-04-28 12:47 UTC (permalink / raw)
  To: Bitcoin Development Mailing List;  Saint Wenhao, Jameson Lopp

Jameson Lopp wrote:

> Encoding an "end of life date" into testnets is actually an interesting idea worth discussing. As far as I'm aware it's never been done before on any network. 

Keep in mind that testnet-specific code has to live right next to, even inside of, mainnet consensus code. We want the change to be as simple as possible, so as to not accidentally break mainnet.

Unless and until coin expiration is something we're seriously considering for mainnet, we'd rather not implement it for testnet.

This particular idea probably requires a lot of changes all over the place (consensus, mempool, wallet) because it breaks the assumption that coins don't expire.


Something I've proposed in person a few times, is to double the coins every halving. In terms of code, it boils down to changing GetBlockSubsidy:

CAmount nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
If (consensusParams.inflation) {
    // Except on testnet5
    nSubsidy <<= halvings;
} else {
  nSubsidy >>= halvings;
}

This will eventually overflow, but that seems fine for a testnet. Along with the timewarp fix, the network might even grind to a halt in 2106, long before we overflow 64 bit numbers.

Rust Bitcoin [0] currently refuses amounts above 21 million BTC, but they would have many years to fix that.


Strong inflation has been battle tested by governments around the world for millennia as a way to discourage saving.

- Sjors

[0] https://github.com/rust-bitcoin/rust-bitcoin/issues/4273

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8E819BCF-EEAE-4F10-89A1-FA3FDE0F67E3%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-04-28 12:47               ` Sjors Provoost

  2025-04-28 18:15                 ` Saint Wenhao
  
From: Saint Wenhao @ 2025-04-28 13:33 UTC (permalink / raw)
  To: Sjors Provoost;  Bitcoin Development Mailing List, Jameson Lopp

[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]

> because it breaks the assumption that coins don't expire

Technically, they can expire, if the client can see some chain
reorganization. And it is something to think about: if the consensus will
force miners to go back to some previous block height, and produce a
stronger, alternative chain, then such testnet would automatically perform
full chain reorganization, wired into its consensus rules. And then, coins
would expire in a backward-compatible way, while also battle testing full
chain reorganization (which may need testing anyway, for other reasons,
like checkpoints).

> This will eventually overflow, but that seems fine for a testnet.

As far as I remember, there were some additional limits, introduced after
Value Overflow Incident, for example that a single UTXO cannot hold more
than 21 million coins:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_check.cpp#L29

```
    // Check for negative or overflow output values (see CVE-2010-5139)
    CAmount nValueOut = 0;
    for (const auto& txout : tx.vout)
    {
        if (txout.nValue < 0)
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-vout-negative");
        if (txout.nValue > MAX_MONEY)
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-vout-toolarge");
        nValueOut += txout.nValue;
        if (!MoneyRange(nValueOut))
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-txouttotal-toolarge");
    }
```

Which means that in practice, instead of seeing huge or overflowed amounts
in UTXOs, we will probably see a lot of repeated entries in the UTXO set,
holding MAX_MONEY each.

pon., 28 kwi 2025 o 14:47 Sjors Provoost <sjors@sprovoost•nl> napisał(a):

> Jameson Lopp wrote:
>
> > Encoding an "end of life date" into testnets is actually an interesting
> idea worth discussing. As far as I'm aware it's never been done before on
> any network.
>
> Keep in mind that testnet-specific code has to live right next to, even
> inside of, mainnet consensus code. We want the change to be as simple as
> possible, so as to not accidentally break mainnet.
>
> Unless and until coin expiration is something we're seriously considering
> for mainnet, we'd rather not implement it for testnet.
>
> This particular idea probably requires a lot of changes all over the place
> (consensus, mempool, wallet) because it breaks the assumption that coins
> don't expire.
>
>
> Something I've proposed in person a few times, is to double the coins
> every halving. In terms of code, it boils down to changing GetBlockSubsidy:
>
> CAmount nSubsidy = 50 * COIN;
> // Subsidy is cut in half every 210,000 blocks which will occur
> approximately every 4 years.
> If (consensusParams.inflation) {
>     // Except on testnet5
>     nSubsidy <<= halvings;
> } else {
>   nSubsidy >>= halvings;
> }
>
> This will eventually overflow, but that seems fine for a testnet. Along
> with the timewarp fix, the network might even grind to a halt in 2106, long
> before we overflow 64 bit numbers.
>
> Rust Bitcoin [0] currently refuses amounts above 21 million BTC, but they
> would have many years to fix that.
>
>
> Strong inflation has been battle tested by governments around the world
> for millennia as a way to discourage saving.
>
> - Sjors
>
> [0] https://github.com/rust-bitcoin/rust-bitcoin/issues/4273

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOJuWPDH7n2UMwYOhOZ%3DuxD6_taagyi23iTKEw_2seGyiw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4822 bytes --]

 permalink raw reply	[|nested]
2025-04-28 12:47               ` Sjors Provoost
  2025-04-28 13:33                 ` Saint Wenhao

  2025-04-28 18:50                   ` Sjors Provoost
  
From: Saint Wenhao @ 2025-04-28 18:15 UTC (permalink / raw)
  To: Sjors Provoost, Bitcoin Development Mailing List, Jameson Lopp

[-- Attachment #1: Type: text/plain, Size: 5844 bytes --]

> Which means that in practice, instead of seeing huge or overflowed
amounts in UTXOs, we will probably see a lot of repeated entries in the
UTXO set, holding MAX_MONEY each.

Now I applied "doubling" patch in my local regtest, and I can confirm it.
After 2849 blocks, when trying to mine block number 2850, the UTXO amount
exceeded 21 million coins, and then it failed.

```
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=16d1899aba71f27e7e527f559db7472cbf18f80c2da7e26acb3c2b8476651c54
height=2847
2025-04-28T17:45:39Z UpdateTip: new
best=16d1899aba71f27e7e527f559db7472cbf18f80c2da7e26acb3c2b8476651c54
height=2847 version=0x20000000 log2_work=12.475733 tx=2848
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2847txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=1c639e9656dcea7c2c8c694d27bc9dd82bd327bc8c95c4be1d5ec576c99638fe
height=2848
2025-04-28T17:45:39Z UpdateTip: new
best=1c639e9656dcea7c2c8c694d27bc9dd82bd327bc8c95c4be1d5ec576c99638fe
height=2848 version=0x20000000 log2_work=12.476240 tx=2849
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2848txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=1e119d36bcd683d4ff2d10c63b60d33431fd141be5cd20d3b0fd074f036b409a
height=2849
2025-04-28T17:45:39Z UpdateTip: new
best=1e119d36bcd683d4ff2d10c63b60d33431fd141be5cd20d3b0fd074f036b409a
height=2849 version=0x20000000 log2_work=12.476746 tx=2850
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2849txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z [error] TestBlockValidity: Consensus::CheckBlock:
bad-txns-vout-toolarge, Transaction check failed (tx hash
5802b7370153f8c415fcf689bda204adebe4483c306110ae33a35a88a593d495)
2025-04-28T17:49:41Z CreateNewBlock(): block weight: 808 txs: 0 fees: 0
sigops 400
2025-04-28T17:49:41Z [error] TestBlockValidity: Consensus::CheckBlock:
bad-txns-vout-toolarge, Transaction check failed (tx hash
f9a54543470144efc33e975d02f44188a7a0d88c16fb997018e33b4e66244f37)
```

And it also failed immediately, after calling "getblocktemplate".

However, after manually crafting a block with 21 million coins, it
succeeded:

$ ./bitcoin-cli -regtest getblock
627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b 0
000000209a406b034f07fdb0d320cde51b14fd3134d3603bc6102dffd483d6bc369d111e9d347f2c3a7114151cdc93c9cccc2f6ce64cf7c1b71bb454d005202c9140d413d5bf0f68ffff7f200200000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0402220b00ffffffff020040075af07507000451024e730000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000

2025-04-28T18:06:27Z Saw new header
hash=627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b
height=2850
2025-04-28T18:06:27Z UpdateTip: new
best=627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b
height=2850 version=0x20000000 log2_work=12.477252 tx=2851
date='2025-04-28T17:50:13Z' progress=1.000000 cache=0.5MiB(2850txo)

Which means, that after reaching 21 million coins, that kind of UTXOs will
be produced forever. And I guess it won't be even possible to send more
coins than that in a single transaction, which means, that we are quite
safe from any kinds of overflows, but we are not safe from flooding the
UTXO set with max coin amounts.

pon., 28 kwi 2025 o 14:47 Sjors Provoost <sjors@sprovoost•nl> napisał(a):

> Jameson Lopp wrote:
>
> > Encoding an "end of life date" into testnets is actually an interesting
> idea worth discussing. As far as I'm aware it's never been done before on
> any network.
>
> Keep in mind that testnet-specific code has to live right next to, even
> inside of, mainnet consensus code. We want the change to be as simple as
> possible, so as to not accidentally break mainnet.
>
> Unless and until coin expiration is something we're seriously considering
> for mainnet, we'd rather not implement it for testnet.
>
> This particular idea probably requires a lot of changes all over the place
> (consensus, mempool, wallet) because it breaks the assumption that coins
> don't expire.
>
>
> Something I've proposed in person a few times, is to double the coins
> every halving. In terms of code, it boils down to changing GetBlockSubsidy:
>
> CAmount nSubsidy = 50 * COIN;
> // Subsidy is cut in half every 210,000 blocks which will occur
> approximately every 4 years.
> If (consensusParams.inflation) {
>     // Except on testnet5
>     nSubsidy <<= halvings;
> } else {
>   nSubsidy >>= halvings;
> }
>
> This will eventually overflow, but that seems fine for a testnet. Along
> with the timewarp fix, the network might even grind to a halt in 2106, long
> before we overflow 64 bit numbers.
>
> Rust Bitcoin [0] currently refuses amounts above 21 million BTC, but they
> would have many years to fix that.
>
>
> Strong inflation has been battle tested by governments around the world
> for millennia as a way to discourage saving.
>
> - Sjors
>
> [0] https://github.com/rust-bitcoin/rust-bitcoin/issues/4273

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOL3gH6zhmNyiKLenqoiM9mydsxs3XExxJX1ZSVvOmX2bA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6698 bytes --]

 permalink raw reply	[|nested]
2025-04-28 18:15                 ` Saint Wenhao

  
From: Sjors Provoost @ 2025-04-28 18:50 UTC (permalink / raw)
  To: Saint Wenhao;  Bitcoin Development Mailing List, Jameson Lopp


> Op 28 apr 2025, om 20:15 heeft Saint Wenhao <saintwenhao@gmail•com> het volgende geschreven:
> 
> > Which means that in practice, instead of seeing huge or overflowed amounts in UTXOs, we will probably see a lot of repeated entries in the UTXO set, holding MAX_MONEY each.
> 
> Now I applied "doubling" patch in my local regtest, and I can confirm it. After 2849 blocks, when trying to mine block number 2850, the UTXO amount exceeded 21 million coins, and then it failed.

Thanks, that's useful feedback.

Note that in regtest the nSubsidyHalvingInterval is 150 blocks instead of 210,000 for mainnet and the current testnets, so the problem happens 1,400 times faster. On an actual testnet5 this would happen at block 3,999,000 instead, which is 75 years from now.

[...]

> However, after manually crafting a block with 21 million coins, it succeeded:

In the unlikely event this hypothetical testnet would still be around, we could modify the miner code to not go over this limit.

- Sjors 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/80B4FDA8-900E-479F-97B7-EE2AB37D0231%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (5 preceding siblings ...)
  2025-03-21 21:20 ` Murch

  2025-05-06 11:48   ` Saint Wenhao
  
From: Greg Maxwell @ 2025-05-05 22:25 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4002 bytes --]

On Tuesday, March 18, 2025 at 9:24:49 PM UTC Antoine Poinsot wrote:

Hi,
Testnet4 was rolled out a year ago to address the shortcomings of testnet3. 
One of those shortcomings was the difficulty reset creating havoc. [0] In 
spite of this a similar rule was adopted for testnet4. [1] As a result, 
testnet4 is similarly creating havoc. [2]
The goal of testnet is to mimic the Bitcoin mainnet. This is why it is 
useful to have in addition to a more control testing environment such as 
Signet.
The given rationale for a difficulty reset was to let developers 
occasionally mine blocks on their laptop. But you cannot have your cake and 
eat it too: either the network is permissionless (PoW) or you assign 
identities and privileges to some (Signet). By trying to do both at the 
same time testnet4 created a loophole for abuse. As a result it failed on 
both count: it neither mimics mainnet nor allows developers to mine active 
blocks on their laptop.
I propose to fix this by removing the difficulty reset rule from testnet4 
through a flag day hard fork on 2026-01-01. I picked a date well in the 
future to minimize disruption. This leaves enough time for a patch to be 
reviewed, merged, included in the next major Bitcoin Core release, 
backported to previous releases and adopted by the infrastructure running 
on testnet4. That should be enough for a test network.


Part of the root cause is violations of the gentleman's agreement to not 
trade testnet coins for money, this results in predictable chaos with 
people sniping the low difficulty blocks. Some believed that resetting 
alone would discourage the conduct, but even if it had (it hadn't people 
are selling them now) it was still likely that people would hoard up coins 
just in case they became tradable in the future.

There is a simple fix for this which doesn't result in an operating 
difference from Bitcoin, just an economic one.   Hard fork in an 
ultramassive premine, as large as possible but what stays with existing 
value overflow logic. (so maybe an additional 21 million testnet btc?).

This also resolves the 'actual developers can't get coins problem' and if 
someone starts trading tnbct for money, whomever has the premine wallet 
should feel feel to sell into it what they can.  Once they run out of coins 
it'll be time for another testnet reset.

It may just not be possible to prevent degens from trading tn coins for 
money, -- I mean consider the altcoins that some people spend money on :),  
there is basically no low bar on how crappy you can make a cryptocurrency 
where some scammer won't try to sell it to some fool.  But what can't be 
prevented can at least be turned into a benefit.

Compared to things like just rigging the subsidy to continue forever-- 
that's a bigger consensus change compared to bitcoin, and I think it 
doesn't have the right incentive surface... some of the most popular 
altcoins have endless inflation and people still use them.  Instead you 
want the failure mode to be "if you do trade this for money, most of the 
profits end up going to support a developer or development, rather than 
whatever jerk decided to trick people into paying for it". :)

Feel free to suggest yourself as the custodian of the premine.  Or it could 
be some anonymous party if there is a concern that they'll be pestered for 
handouts.  There should be a general expectation that the custodian of the 
premine will use it for the betterment of Bitcoin development,  but if it's 
found that they're not-- solution is just another reset. :)



-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/afb749b2-bdb8-4b2a-84ec-b703a64ad765n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4740 bytes --]

 permalink raw reply	[|nested]
2025-05-05 22:25 ` [bitcoindev] " Greg Maxwell

  2025-05-09 13:07     ` Garlo Nicon
  
From: Saint Wenhao @ 2025-05-06 11:48 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 6729 bytes --]

> Some believed that resetting alone would discourage the conduct,

I wonder, why many people keep saying "reset", when in practice, the old
network is just "abandoned", and nothing is really "resetted". We would
have a true reset, if a new testnet would lead to the full chain
reorganization of the old chain. And this thing never happened, all
previous testnets were just abandoned, as they were, and there were just
not enough people, willing to keep old networks alive.

> Hard fork in an ultramassive premine

Well, if testnet4 will be "fixed" by doing a hard-fork on top of existing
chain, then it would be equivalent to releasing testnet5 with "premine" of
all testnet4 blocks.

> so maybe an additional 21 million testnet btc?

Using doublings, instead of halvings, is future-proof. Because then, if
someone will continue using such test network forever, then later, it would
release 21 million coins per block (which would be roughly equivalent to
having a superchain, where you can peg one altcoin per 10 minutes).

> if someone starts trading tnbct for money, whomever has the premine
wallet should feel feel to sell into it what they can

In practice, trading will start, when the first version of the official
wallet will be released. It was the case in testnet4: when it was possible
to mine new coins, only when you created your own binary from the source
code, then there were only devs, and some skilled users. However, when it
was officially supported in a new Core version, then it was quickly listed
on centralized exchanges, and a lot of people dumped all of their test
coins, and walked away with real BTCs.

> the custodian of the premine will use it for the betterment of Bitcoin
development,  but if it's found that they're not-- solution is just another
reset

Which means, that Bitcoin developers will turn into altcoin developers,
where they will release new altcoins called "testnets", only to dump all of
them, and get BTCs out of it.

wt., 6 maj 2025 o 01:40 Greg Maxwell <gmaxwell@gmail•com> napisał(a):

> On Tuesday, March 18, 2025 at 9:24:49 PM UTC Antoine Poinsot wrote:
>
> Hi,
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
>
> Part of the root cause is violations of the gentleman's agreement to not
> trade testnet coins for money, this results in predictable chaos with
> people sniping the low difficulty blocks. Some believed that resetting
> alone would discourage the conduct, but even if it had (it hadn't people
> are selling them now) it was still likely that people would hoard up coins
> just in case they became tradable in the future.
>
> There is a simple fix for this which doesn't result in an operating
> difference from Bitcoin, just an economic one.   Hard fork in an
> ultramassive premine, as large as possible but what stays with existing
> value overflow logic. (so maybe an additional 21 million testnet btc?).
>
> This also resolves the 'actual developers can't get coins problem' and if
> someone starts trading tnbct for money, whomever has the premine wallet
> should feel feel to sell into it what they can.  Once they run out of coins
> it'll be time for another testnet reset.
>
> It may just not be possible to prevent degens from trading tn coins for
> money, -- I mean consider the altcoins that some people spend money on :),
> there is basically no low bar on how crappy you can make a cryptocurrency
> where some scammer won't try to sell it to some fool.  But what can't be
> prevented can at least be turned into a benefit.
>
> Compared to things like just rigging the subsidy to continue forever--
> that's a bigger consensus change compared to bitcoin, and I think it
> doesn't have the right incentive surface... some of the most popular
> altcoins have endless inflation and people still use them.  Instead you
> want the failure mode to be "if you do trade this for money, most of the
> profits end up going to support a developer or development, rather than
> whatever jerk decided to trick people into paying for it". :)
>
> Feel free to suggest yourself as the custodian of the premine.  Or it
> could be some anonymous party if there is a concern that they'll be
> pestered for handouts.  There should be a general expectation that the
> custodian of the premine will use it for the betterment of Bitcoin
> development,  but if it's found that they're not-- solution is just another
> reset. :)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/afb749b2-bdb8-4b2a-84ec-b703a64ad765n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/afb749b2-bdb8-4b2a-84ec-b703a64ad765n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2BfsUtx%3DF%3DZLZVq%3DFJfrgHv8NnKsjmoVS8LLVU78zjKDw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7943 bytes --]

 permalink raw reply	[|nested]
2025-05-06 11:48   ` Saint Wenhao

  2025-05-12  5:21       ` Anthony Towns
       [not found]       ` <20250512110323.B14F27C0B49@smtp.postman.i2p>
  
From: Garlo Nicon @ 2025-05-09 13:07 UTC (permalink / raw)
  To: Saint Wenhao;  Greg Maxwell, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 9055 bytes --]

> Hard fork in an ultramassive premine, as large as possible but what stays
with existing value overflow logic. (so maybe an additional 21 million
testnet btc?).

Why hard-forking anything? The starting difficulty is set to 1, and it
raises to 4 almost instantly, when testnet creators are mining the first
coins. Which means, that difficulty 1 is ridiculously easy to work with,
when you have any ASICs. If you combine it with the idea of fake
timestamps, then you can produce a really long initial chain, which will
start in 2009, and up to 2025, it will produce almost the same amount of
blocks as mainnet. All of that can have a soft-forked-in differences
between blocks of 10 minutes, after which you can bring the real
timestamps, and raise the difficulty to the proper level.

Which means, that instead of "premine", you can use "ninja-mine", and
achieve pretty much the same end result.

> In practice, trading will start, when the first version of the official
wallet will be released.

In that case, developers can generate some artificial chain with faked
timestamps, then mine some stronger blocks on top of that, and then release
a client with such changes. No changing of coins limits needed, and
ninja-mine is better than premine, because you wouldn't need to change the
code that much, but only eventually put a checkpoint, where you would want
to have a "genesis" block, for example at height 900,000, with some
coinbase message, timestamped with some hash from the mainnet.

wt., 6 maj 2025 o 17:25 Saint Wenhao <saintwenhao@gmail•com> napisał(a):

> > Some believed that resetting alone would discourage the conduct,
>
> I wonder, why many people keep saying "reset", when in practice, the old
> network is just "abandoned", and nothing is really "resetted". We would
> have a true reset, if a new testnet would lead to the full chain
> reorganization of the old chain. And this thing never happened, all
> previous testnets were just abandoned, as they were, and there were just
> not enough people, willing to keep old networks alive.
>
> > Hard fork in an ultramassive premine
>
> Well, if testnet4 will be "fixed" by doing a hard-fork on top of existing
> chain, then it would be equivalent to releasing testnet5 with "premine" of
> all testnet4 blocks.
>
> > so maybe an additional 21 million testnet btc?
>
> Using doublings, instead of halvings, is future-proof. Because then, if
> someone will continue using such test network forever, then later, it would
> release 21 million coins per block (which would be roughly equivalent to
> having a superchain, where you can peg one altcoin per 10 minutes).
>
> > if someone starts trading tnbct for money, whomever has the premine
> wallet should feel feel to sell into it what they can
>
> In practice, trading will start, when the first version of the official
> wallet will be released. It was the case in testnet4: when it was possible
> to mine new coins, only when you created your own binary from the source
> code, then there were only devs, and some skilled users. However, when it
> was officially supported in a new Core version, then it was quickly listed
> on centralized exchanges, and a lot of people dumped all of their test
> coins, and walked away with real BTCs.
>
> > the custodian of the premine will use it for the betterment of Bitcoin
> development,  but if it's found that they're not-- solution is just another
> reset
>
> Which means, that Bitcoin developers will turn into altcoin developers,
> where they will release new altcoins called "testnets", only to dump all of
> them, and get BTCs out of it.
>
> wt., 6 maj 2025 o 01:40 Greg Maxwell <gmaxwell@gmail•com> napisał(a):
>
>> On Tuesday, March 18, 2025 at 9:24:49 PM UTC Antoine Poinsot wrote:
>>
>> Hi,
>> Testnet4 was rolled out a year ago to address the shortcomings of
>> testnet3. One of those shortcomings was the difficulty reset creating
>> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
>> a result, testnet4 is similarly creating havoc. [2]
>> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
>> useful to have in addition to a more control testing environment such as
>> Signet.
>> The given rationale for a difficulty reset was to let developers
>> occasionally mine blocks on their laptop. But you cannot have your cake and
>> eat it too: either the network is permissionless (PoW) or you assign
>> identities and privileges to some (Signet). By trying to do both at the
>> same time testnet4 created a loophole for abuse. As a result it failed on
>> both count: it neither mimics mainnet nor allows developers to mine active
>> blocks on their laptop.
>> I propose to fix this by removing the difficulty reset rule from testnet4
>> through a flag day hard fork on 2026-01-01. I picked a date well in the
>> future to minimize disruption. This leaves enough time for a patch to be
>> reviewed, merged, included in the next major Bitcoin Core release,
>> backported to previous releases and adopted by the infrastructure running
>> on testnet4. That should be enough for a test network.
>>
>>
>> Part of the root cause is violations of the gentleman's agreement to not
>> trade testnet coins for money, this results in predictable chaos with
>> people sniping the low difficulty blocks. Some believed that resetting
>> alone would discourage the conduct, but even if it had (it hadn't people
>> are selling them now) it was still likely that people would hoard up coins
>> just in case they became tradable in the future.
>>
>> There is a simple fix for this which doesn't result in an operating
>> difference from Bitcoin, just an economic one.   Hard fork in an
>> ultramassive premine, as large as possible but what stays with existing
>> value overflow logic. (so maybe an additional 21 million testnet btc?).
>>
>> This also resolves the 'actual developers can't get coins problem' and if
>> someone starts trading tnbct for money, whomever has the premine wallet
>> should feel feel to sell into it what they can.  Once they run out of coins
>> it'll be time for another testnet reset.
>>
>> It may just not be possible to prevent degens from trading tn coins for
>> money, -- I mean consider the altcoins that some people spend money on :),
>> there is basically no low bar on how crappy you can make a cryptocurrency
>> where some scammer won't try to sell it to some fool.  But what can't be
>> prevented can at least be turned into a benefit.
>>
>> Compared to things like just rigging the subsidy to continue forever--
>> that's a bigger consensus change compared to bitcoin, and I think it
>> doesn't have the right incentive surface... some of the most popular
>> altcoins have endless inflation and people still use them.  Instead you
>> want the failure mode to be "if you do trade this for money, most of the
>> profits end up going to support a developer or development, rather than
>> whatever jerk decided to trick people into paying for it". :)
>>
>> Feel free to suggest yourself as the custodian of the premine.  Or it
>> could be some anonymous party if there is a concern that they'll be
>> pestered for handouts.  There should be a general expectation that the
>> custodian of the premine will use it for the betterment of Bitcoin
>> development,  but if it's found that they're not-- solution is just another
>> reset. :)
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/afb749b2-bdb8-4b2a-84ec-b703a64ad765n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/afb749b2-bdb8-4b2a-84ec-b703a64ad765n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2BfsUtx%3DF%3DZLZVq%3DFJfrgHv8NnKsjmoVS8LLVU78zjKDw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2BfsUtx%3DF%3DZLZVq%3DFJfrgHv8NnKsjmoVS8LLVU78zjKDw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAN7kyNiWimDXDV5xT8MCZTvKzrunjfMDDOtTYcmKdQNN1z7Lsg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 10565 bytes --]

 permalink raw reply	[|nested]
2025-05-09 13:07     ` Garlo Nicon

       [not found]       ` <20250512110323.B14F27C0B49@smtp.postman.i2p>
  
From: Anthony Towns @ 2025-05-12  5:21 UTC (permalink / raw)
  To: Garlo Nicon;  Saint Wenhao, Greg Maxwell, Bitcoin Development Mailing List

> > Hard fork in an ultramassive premine, as large as possible but what stays
> > with existing value overflow logic. (so maybe an additional 21 million
> > testnet btc?).

The existing logic gives errors if:

  * a single input of a tx (ie a coin in the utxo set), or the sum of inputs to
    a txn, is outside the range 0-21M (bad-txns-inputvalues-outofrange)

  * a single output of a tx is outside the range 0-21M
    (bad-txns-vout-negative or bad-txns-vout-toolarge)

  * the sum of the outputs of a single tx is outside the range 0-21M
    (bad-txns-txouttotal-toolarge)

  * the fee paid by a single tx is outside the range 0-21M
    (bad-txns-fee-outofrange)

  * a block's fees go outside the range 0-21M
    (bad-txns-accumulated-fee-outofrange)

Keeping the total supply under 21M seems nicer than having txs that
spend real utxos be able to hit these errors (eg, by combining
the premine utxo at 21M with a coinbase reward of 50 and hitting
bad-txns-inputvalues-outofrange).

That's pretty easy to achieve: just have the initial premine be half the
supply (eg), and also cut the halvening time in half (so 10.5M premine,
105,000 blocks in a halving). Or you could have halvenings every 6 months
(26250 blocks), and have an 18.375M premine, or whatever.

You could also consider premining (almost) the entire supply, and have
the block reward be entirely fees (almost) immediately after that, but I
think there's value in making it possible to obtain coins for testing in
a permissionless, anonymous and relatively low-latency manner, for which
PoW is great. Might also be annoying for empty blocks to pay a reward of
exactly 0, so if miners included their address in the coinbase tx like
normal, they'd be creating a 0 valued utxo, and probably never spend it.

I had a quick poke at what code to allow for chains with premines might
look like here:

  https://github.com/ajtowns/bitcoin/commits/202505-premine/

About 11 lines of code to implement the logic.

If this approach made the testnet difficulty reset logic obsolete
(ie, a testnet with just PoW and a premine turns out to work fine),
that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks
and enforce_BIP94 logic. Presumably a PoW-only testnet could also have
its min-difficulty bumped from 1 to 65536 or more, since it seems like
a single Bitaxe can still maintain the chain at that difficulty.

The idea of this approach is that when establishing a premined testnet,
you would:

 a) first define the chain, with a new genesis, etc; then set
    nSubsidyHalvingInterval=105000 and premine=10'500'000*COIN or similar,
    but leave premine_block_hash=0

 b) build the node software, and mine block 1 to the premine address.

 c) set premine_block_hash to block 1's hash. publish the code with the
    genesis block and block 1 hash, so that the public can mine as of
    block 2.

 d) once 100 blocks have been mined, split the premine up amongst
    devs, faucets, wallet maintainers, user groups, a managed endowment
    for future testers, whatever.

On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:
> Why hard-forking anything? The starting difficulty is set to 1, and it
> raises to 4 almost instantly, when testnet creators are mining the first
> coins. Which means, that difficulty 1 is ridiculously easy to work with,
> when you have any ASICs. If you combine it with the idea of fake
> timestamps,

It's not the number of blocks, but the cumulative work that matters, so to
have a soft reset of testnet3 or testnet4 you'd need to apply more hashing
for the new chain than the existing chains have already received. That's
a fair amount of "wasted" hash: I think mining a more-work chain than
testnet4 would require about the same amount of hash that it would take
to mine ~13 mainnet blocks at the current difficulty, so you'd be giving
up about $4M USD in mainnet block rewards to do it.

In any event, a hard fork is "necessary", as otherwise whenever it
takes 20 minutes or more to find a block, old clients will expect a
lower difficulty than new clients do, so the two wouldn't be compatible
with each other. You could do various things to work around that, but
that's a lot of coding time that could be better spent on improving
things relevant to mainnet, and if you're resetting the chain anyway,
there's not much advantage to it.

> then you can produce a really long initial chain, which will
> start in 2009, and up to 2025, it will produce almost the same amount of
> blocks as mainnet.

A soft fork of testnet3 would start 3rd Feb 2011 (leading to about 750k
blocks vs mainnet's ~900k), and a soft fork of testnet4 would start at
4th May 2024 (leading to about 54k blocks). (These are the timestamps
of the respective genesis blocks)

A disadvantage of doing a premine that way is that users of the chain
need to download and validate thousands of blocks and deal with an equal
number of utxos just to establish the premine; doing that in a single
block with a single utxo (or one utxo for each recipient of the premine)
is quite a bit more efficient.

> Which means, that instead of "premine", you can use "ninja-mine", and
> achieve pretty much the same end result.

I think in general usage "premine" covers both those approaches -- any
time the creator(s) of a chain gets the opportunity to claim/distribute
coins prior to the general public being able to mint new coins by mining
blocks, that's a premine.

Cheers,
aj

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aCGFXI4PRq_eyrEf%40erisian.com.au.


 permalink raw reply	[|nested]
[not found]       ` <20250512110323.B14F27C0B49@smtp.postman.i2p>

  2025-05-12 18:17           ` Saint Wenhao
       [not found]           ` <20250512181809.5705B7C114F@smtp.postman.i2p>
  
From: pithosian @ 2025-05-12 12:05 UTC (permalink / raw)
  To: bitcoindev

Another option is to invert the halving logic on testnet (to what some
newbies occasionally think the halving is on mainnet); don't halve the
subsidy, half the existing supply.

Fix the subsidy:
validation.cpp
  CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&
  consensusParams) { if (consensusParams.fixedSubsidy != 0) {
      return consensusParams.fixedSubsidy;
    }

Then as the last step of processing a block, after its txs have been
applied to chainstate, check if it's a halving block and, if it is
(and some consensus flag is set), halve the value of all existing UTXOs.

The result is:
1. We'd never exceed a 21m coins.
2. We'd disincentivise hoarding.
3. We'd ensure permanent liquidity on testnet.

Updating the entire UTXO set all at once would be pretty expensive,
though, and over enough halvings you'd have a bunch of zero value UTXOs
we may or may not be able to clean up.

On Mon, 12 May 2025 11:03:23 +0000 (UTC)
Anthony Towns <aj@erisian•com.au> wrote:

> > > Hard fork in an ultramassive premine, as large as possible but
> > > what stays with existing value overflow logic. (so maybe an
> > > additional 21 million testnet btc?).  
> 
> The existing logic gives errors if:
> 
>   * a single input of a tx (ie a coin in the utxo set), or the sum of
> inputs to a txn, is outside the range 0-21M
> (bad-txns-inputvalues-outofrange)
> 
>   * a single output of a tx is outside the range 0-21M
>     (bad-txns-vout-negative or bad-txns-vout-toolarge)
> 
>   * the sum of the outputs of a single tx is outside the range 0-21M
>     (bad-txns-txouttotal-toolarge)
> 
>   * the fee paid by a single tx is outside the range 0-21M
>     (bad-txns-fee-outofrange)
> 
>   * a block's fees go outside the range 0-21M
>     (bad-txns-accumulated-fee-outofrange)
> 
> Keeping the total supply under 21M seems nicer than having txs that
> spend real utxos be able to hit these errors (eg, by combining
> the premine utxo at 21M with a coinbase reward of 50 and hitting
> bad-txns-inputvalues-outofrange).
> 
> That's pretty easy to achieve: just have the initial premine be half
> the supply (eg), and also cut the halvening time in half (so 10.5M
> premine, 105,000 blocks in a halving). Or you could have halvenings
> every 6 months (26250 blocks), and have an 18.375M premine, or
> whatever.
> 
> You could also consider premining (almost) the entire supply, and have
> the block reward be entirely fees (almost) immediately after that,
> but I think there's value in making it possible to obtain coins for
> testing in a permissionless, anonymous and relatively low-latency
> manner, for which PoW is great. Might also be annoying for empty
> blocks to pay a reward of exactly 0, so if miners included their
> address in the coinbase tx like normal, they'd be creating a 0 valued
> utxo, and probably never spend it.
> 
> I had a quick poke at what code to allow for chains with premines
> might look like here:
> 
>   https://github.com/ajtowns/bitcoin/commits/202505-premine/
> 
> About 11 lines of code to implement the logic.
> 
> If this approach made the testnet difficulty reset logic obsolete
> (ie, a testnet with just PoW and a premine turns out to work fine),
> that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks
> and enforce_BIP94 logic. Presumably a PoW-only testnet could also have
> its min-difficulty bumped from 1 to 65536 or more, since it seems like
> a single Bitaxe can still maintain the chain at that difficulty.
> 
> The idea of this approach is that when establishing a premined
> testnet, you would:
> 
>  a) first define the chain, with a new genesis, etc; then set
>     nSubsidyHalvingInterval=105000 and premine=10'500'000*COIN or
> similar, but leave premine_block_hash=0
> 
>  b) build the node software, and mine block 1 to the premine address.
> 
>  c) set premine_block_hash to block 1's hash. publish the code with
> the genesis block and block 1 hash, so that the public can mine as of
>     block 2.
> 
>  d) once 100 blocks have been mined, split the premine up amongst
>     devs, faucets, wallet maintainers, user groups, a managed
> endowment for future testers, whatever.
> 
> On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:
> > Why hard-forking anything? The starting difficulty is set to 1, and
> > it raises to 4 almost instantly, when testnet creators are mining
> > the first coins. Which means, that difficulty 1 is ridiculously
> > easy to work with, when you have any ASICs. If you combine it with
> > the idea of fake timestamps,  
> 
> It's not the number of blocks, but the cumulative work that matters,
> so to have a soft reset of testnet3 or testnet4 you'd need to apply
> more hashing for the new chain than the existing chains have already
> received. That's a fair amount of "wasted" hash: I think mining a
> more-work chain than testnet4 would require about the same amount of
> hash that it would take to mine ~13 mainnet blocks at the current
> difficulty, so you'd be giving up about $4M USD in mainnet block
> rewards to do it.
> 
> In any event, a hard fork is "necessary", as otherwise whenever it
> takes 20 minutes or more to find a block, old clients will expect a
> lower difficulty than new clients do, so the two wouldn't be
> compatible with each other. You could do various things to work
> around that, but that's a lot of coding time that could be better
> spent on improving things relevant to mainnet, and if you're
> resetting the chain anyway, there's not much advantage to it.
> 
> > then you can produce a really long initial chain, which will
> > start in 2009, and up to 2025, it will produce almost the same
> > amount of blocks as mainnet.  
> 
> A soft fork of testnet3 would start 3rd Feb 2011 (leading to about
> 750k blocks vs mainnet's ~900k), and a soft fork of testnet4 would
> start at 4th May 2024 (leading to about 54k blocks). (These are the
> timestamps of the respective genesis blocks)
> 
> A disadvantage of doing a premine that way is that users of the chain
> need to download and validate thousands of blocks and deal with an
> equal number of utxos just to establish the premine; doing that in a
> single block with a single utxo (or one utxo for each recipient of
> the premine) is quite a bit more efficient.
> 
> > Which means, that instead of "premine", you can use "ninja-mine",
> > and achieve pretty much the same end result.  
> 
> I think in general usage "premine" covers both those approaches -- any
> time the creator(s) of a chain gets the opportunity to
> claim/distribute coins prior to the general public being able to mint
> new coins by mining blocks, that's a premine.
> 
> Cheers,
> aj
> 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250512120531.1AC1F7C0557%40smtp.postman.i2p.


 permalink raw reply	[|nested]
2025-05-12 12:05         ` pithosian

       [not found]           ` <20250512181809.5705B7C114F@smtp.postman.i2p>
  
From: Saint Wenhao @ 2025-05-12 18:17 UTC (permalink / raw)
  To: pithosian;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 8925 bytes --]

> Updating the entire UTXO set all at once would be pretty expensive,

Not only that. It may also invalidate timelocked signatures, which would be
made around "halving". So, if you would sign something, when block height
will be set to 209,990, and timelock it into 20 blocks, then at block
height 210,010, it would be invalid, because of incorrect amount.

Which means, that stored UTXO amounts should be probably left untouched,
but rather spendability of the coins should be affected. So: if someone
received 50 tBTC, then that person should be able to freely move 25 tBTC
anywhere, but 25 tBTC can be enforced to go directly into transaction fees
(and so on, and so forth, so later it would be splitted into 12.5 spendable
tBTC, and 37.5 tBTC fees).

And then, that kind of fees can be claimed directly by miners, or can be
simply burned, by just not claiming it, if you want to permanently throw it
away from the UTXO set, without leaving any trace.

pon., 12 maj 2025 o 15:50 pithosian <pithosian@i2pmail•org> napisał(a):

> Another option is to invert the halving logic on testnet (to what some
> newbies occasionally think the halving is on mainnet); don't halve the
> subsidy, half the existing supply.
>
> Fix the subsidy:
> validation.cpp
>   CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&
>   consensusParams) { if (consensusParams.fixedSubsidy != 0) {
>       return consensusParams.fixedSubsidy;
>     }
>
> Then as the last step of processing a block, after its txs have been
> applied to chainstate, check if it's a halving block and, if it is
> (and some consensus flag is set), halve the value of all existing UTXOs.
>
> The result is:
> 1. We'd never exceed a 21m coins.
> 2. We'd disincentivise hoarding.
> 3. We'd ensure permanent liquidity on testnet.
>
> Updating the entire UTXO set all at once would be pretty expensive,
> though, and over enough halvings you'd have a bunch of zero value UTXOs
> we may or may not be able to clean up.
>
> On Mon, 12 May 2025 11:03:23 +0000 (UTC)
> Anthony Towns <aj@erisian•com.au> wrote:
>
> > > > Hard fork in an ultramassive premine, as large as possible but
> > > > what stays with existing value overflow logic. (so maybe an
> > > > additional 21 million testnet btc?).
> >
> > The existing logic gives errors if:
> >
> >   * a single input of a tx (ie a coin in the utxo set), or the sum of
> > inputs to a txn, is outside the range 0-21M
> > (bad-txns-inputvalues-outofrange)
> >
> >   * a single output of a tx is outside the range 0-21M
> >     (bad-txns-vout-negative or bad-txns-vout-toolarge)
> >
> >   * the sum of the outputs of a single tx is outside the range 0-21M
> >     (bad-txns-txouttotal-toolarge)
> >
> >   * the fee paid by a single tx is outside the range 0-21M
> >     (bad-txns-fee-outofrange)
> >
> >   * a block's fees go outside the range 0-21M
> >     (bad-txns-accumulated-fee-outofrange)
> >
> > Keeping the total supply under 21M seems nicer than having txs that
> > spend real utxos be able to hit these errors (eg, by combining
> > the premine utxo at 21M with a coinbase reward of 50 and hitting
> > bad-txns-inputvalues-outofrange).
> >
> > That's pretty easy to achieve: just have the initial premine be half
> > the supply (eg), and also cut the halvening time in half (so 10.5M
> > premine, 105,000 blocks in a halving). Or you could have halvenings
> > every 6 months (26250 blocks), and have an 18.375M premine, or
> > whatever.
> >
> > You could also consider premining (almost) the entire supply, and have
> > the block reward be entirely fees (almost) immediately after that,
> > but I think there's value in making it possible to obtain coins for
> > testing in a permissionless, anonymous and relatively low-latency
> > manner, for which PoW is great. Might also be annoying for empty
> > blocks to pay a reward of exactly 0, so if miners included their
> > address in the coinbase tx like normal, they'd be creating a 0 valued
> > utxo, and probably never spend it.
> >
> > I had a quick poke at what code to allow for chains with premines
> > might look like here:
> >
> >   https://github.com/ajtowns/bitcoin/commits/202505-premine/
> >
> > About 11 lines of code to implement the logic.
> >
> > If this approach made the testnet difficulty reset logic obsolete
> > (ie, a testnet with just PoW and a premine turns out to work fine),
> > that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks
> > and enforce_BIP94 logic. Presumably a PoW-only testnet could also have
> > its min-difficulty bumped from 1 to 65536 or more, since it seems like
> > a single Bitaxe can still maintain the chain at that difficulty.
> >
> > The idea of this approach is that when establishing a premined
> > testnet, you would:
> >
> >  a) first define the chain, with a new genesis, etc; then set
> >     nSubsidyHalvingInterval=105000 and premine=10'500'000*COIN or
> > similar, but leave premine_block_hash=0
> >
> >  b) build the node software, and mine block 1 to the premine address.
> >
> >  c) set premine_block_hash to block 1's hash. publish the code with
> > the genesis block and block 1 hash, so that the public can mine as of
> >     block 2.
> >
> >  d) once 100 blocks have been mined, split the premine up amongst
> >     devs, faucets, wallet maintainers, user groups, a managed
> > endowment for future testers, whatever.
> >
> > On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:
> > > Why hard-forking anything? The starting difficulty is set to 1, and
> > > it raises to 4 almost instantly, when testnet creators are mining
> > > the first coins. Which means, that difficulty 1 is ridiculously
> > > easy to work with, when you have any ASICs. If you combine it with
> > > the idea of fake timestamps,
> >
> > It's not the number of blocks, but the cumulative work that matters,
> > so to have a soft reset of testnet3 or testnet4 you'd need to apply
> > more hashing for the new chain than the existing chains have already
> > received. That's a fair amount of "wasted" hash: I think mining a
> > more-work chain than testnet4 would require about the same amount of
> > hash that it would take to mine ~13 mainnet blocks at the current
> > difficulty, so you'd be giving up about $4M USD in mainnet block
> > rewards to do it.
> >
> > In any event, a hard fork is "necessary", as otherwise whenever it
> > takes 20 minutes or more to find a block, old clients will expect a
> > lower difficulty than new clients do, so the two wouldn't be
> > compatible with each other. You could do various things to work
> > around that, but that's a lot of coding time that could be better
> > spent on improving things relevant to mainnet, and if you're
> > resetting the chain anyway, there's not much advantage to it.
> >
> > > then you can produce a really long initial chain, which will
> > > start in 2009, and up to 2025, it will produce almost the same
> > > amount of blocks as mainnet.
> >
> > A soft fork of testnet3 would start 3rd Feb 2011 (leading to about
> > 750k blocks vs mainnet's ~900k), and a soft fork of testnet4 would
> > start at 4th May 2024 (leading to about 54k blocks). (These are the
> > timestamps of the respective genesis blocks)
> >
> > A disadvantage of doing a premine that way is that users of the chain
> > need to download and validate thousands of blocks and deal with an
> > equal number of utxos just to establish the premine; doing that in a
> > single block with a single utxo (or one utxo for each recipient of
> > the premine) is quite a bit more efficient.
> >
> > > Which means, that instead of "premine", you can use "ninja-mine",
> > > and achieve pretty much the same end result.
> >
> > I think in general usage "premine" covers both those approaches -- any
> > time the creator(s) of a chain gets the opportunity to
> > claim/distribute coins prior to the general public being able to mint
> > new coins by mining blocks, that's a premine.
> >
> > Cheers,
> > aj
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/20250512120531.1AC1F7C0557%40smtp.postman.i2p
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2BkKOenBUykQr3foEqW9vdkMsPTdrBFfCgy4SjDKbc74A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 10854 bytes --]

 permalink raw reply	[|nested]
[not found]           ` <20250512181809.5705B7C114F@smtp.postman.i2p>

  
From: pithosian @ 2025-05-12 20:19 UTC (permalink / raw)
  To: Saint Wenhao;  bitcoindev

> Not only that. It may also invalidate timelocked signatures, which
> would be made around "halving".

Good point. I was thinking about just hacking at the UTXO set as it
conceptually seemed to make the change very localized, but timelocks
probably(?) rule the whole approach out.

The freely-spendable amount would be:

amount/2^(targetHeight/halvingBlocks-utxoHeight/halvingBlocks)

Or the bitshift equivalent, where targetHeight is the current height,
or in the case of timelocks, the locked height, but longer
timestamp-based timelocks can't be reasoned about very well with any
'degrading coin' behaviour, and even your presigned, height locked
transaction might not get be confirmed before the next epoch if the
timelock approaches it.

Doesn't modifying spendability have the same problem? When presigning
your timelocked transaction, you need to be aware of the amount you can
actually spend come expiry of the timelock up-front, however the coin
degrades.

It also breaks lightning channels, I think.

On Mon, 12 May 2025 18:18:09 +0000 (UTC)
Saint Wenhao <saintwenhao@gmail•com> wrote:

> > Updating the entire UTXO set all at once would be pretty expensive,
> 
> Not only that. It may also invalidate timelocked signatures, which
> would be made around "halving". So, if you would sign something, when
> block height will be set to 209,990, and timelock it into 20 blocks,
> then at block height 210,010, it would be invalid, because of
> incorrect amount.
> 
> Which means, that stored UTXO amounts should be probably left
> untouched, but rather spendability of the coins should be affected.
> So: if someone received 50 tBTC, then that person should be able to
> freely move 25 tBTC anywhere, but 25 tBTC can be enforced to go
> directly into transaction fees (and so on, and so forth, so later it
> would be splitted into 12.5 spendable tBTC, and 37.5 tBTC fees).
> 
> And then, that kind of fees can be claimed directly by miners, or can
> be simply burned, by just not claiming it, if you want to permanently
> throw it away from the UTXO set, without leaving any trace.
> 
> pon., 12 maj 2025 o 15:50 pithosian <pithosian@i2pmail•org>
> napisał(a):
> 
> > Another option is to invert the halving logic on testnet (to what
> > some newbies occasionally think the halving is on mainnet); don't
> > halve the subsidy, half the existing supply.
> >
> > Fix the subsidy:
> > validation.cpp
> >   CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&
> >   consensusParams) { if (consensusParams.fixedSubsidy != 0) {
> >       return consensusParams.fixedSubsidy;
> >     }
> >
> > Then as the last step of processing a block, after its txs have been
> > applied to chainstate, check if it's a halving block and, if it is
> > (and some consensus flag is set), halve the value of all existing
> > UTXOs.
> >
> > The result is:
> > 1. We'd never exceed a 21m coins.
> > 2. We'd disincentivise hoarding.
> > 3. We'd ensure permanent liquidity on testnet.
> >
> > Updating the entire UTXO set all at once would be pretty expensive,
> > though, and over enough halvings you'd have a bunch of zero value
> > UTXOs we may or may not be able to clean up.
> >
> > On Mon, 12 May 2025 11:03:23 +0000 (UTC)
> > Anthony Towns <aj@erisian•com.au> wrote:
> >
> > > > > Hard fork in an ultramassive premine, as large as possible but
> > > > > what stays with existing value overflow logic. (so maybe an
> > > > > additional 21 million testnet btc?).
> > >
> > > The existing logic gives errors if:
> > >
> > >   * a single input of a tx (ie a coin in the utxo set), or the
> > > sum of inputs to a txn, is outside the range 0-21M
> > > (bad-txns-inputvalues-outofrange)
> > >
> > >   * a single output of a tx is outside the range 0-21M
> > >     (bad-txns-vout-negative or bad-txns-vout-toolarge)
> > >
> > >   * the sum of the outputs of a single tx is outside the range
> > > 0-21M (bad-txns-txouttotal-toolarge)
> > >
> > >   * the fee paid by a single tx is outside the range 0-21M
> > >     (bad-txns-fee-outofrange)
> > >
> > >   * a block's fees go outside the range 0-21M
> > >     (bad-txns-accumulated-fee-outofrange)
> > >
> > > Keeping the total supply under 21M seems nicer than having txs
> > > that spend real utxos be able to hit these errors (eg, by
> > > combining the premine utxo at 21M with a coinbase reward of 50
> > > and hitting bad-txns-inputvalues-outofrange).
> > >
> > > That's pretty easy to achieve: just have the initial premine be
> > > half the supply (eg), and also cut the halvening time in half (so
> > > 10.5M premine, 105,000 blocks in a halving). Or you could have
> > > halvenings every 6 months (26250 blocks), and have an 18.375M
> > > premine, or whatever.
> > >
> > > You could also consider premining (almost) the entire supply, and
> > > have the block reward be entirely fees (almost) immediately after
> > > that, but I think there's value in making it possible to obtain
> > > coins for testing in a permissionless, anonymous and relatively
> > > low-latency manner, for which PoW is great. Might also be
> > > annoying for empty blocks to pay a reward of exactly 0, so if
> > > miners included their address in the coinbase tx like normal,
> > > they'd be creating a 0 valued utxo, and probably never spend it.
> > >
> > > I had a quick poke at what code to allow for chains with premines
> > > might look like here:
> > >
> > >   https://github.com/ajtowns/bitcoin/commits/202505-premine/
> > >
> > > About 11 lines of code to implement the logic.
> > >
> > > If this approach made the testnet difficulty reset logic obsolete
> > > (ie, a testnet with just PoW and a premine turns out to work
> > > fine), that would drop 14 lines of code for the
> > > fPowAllowMinDifficultyBlocks and enforce_BIP94 logic. Presumably
> > > a PoW-only testnet could also have its min-difficulty bumped from
> > > 1 to 65536 or more, since it seems like a single Bitaxe can still
> > > maintain the chain at that difficulty.
> > >
> > > The idea of this approach is that when establishing a premined
> > > testnet, you would:
> > >
> > >  a) first define the chain, with a new genesis, etc; then set
> > >     nSubsidyHalvingInterval=105000 and premine=10'500'000*COIN or
> > > similar, but leave premine_block_hash=0
> > >
> > >  b) build the node software, and mine block 1 to the premine
> > > address.
> > >
> > >  c) set premine_block_hash to block 1's hash. publish the code
> > > with the genesis block and block 1 hash, so that the public can
> > > mine as of block 2.
> > >
> > >  d) once 100 blocks have been mined, split the premine up amongst
> > >     devs, faucets, wallet maintainers, user groups, a managed
> > > endowment for future testers, whatever.
> > >
> > > On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:
> > > > Why hard-forking anything? The starting difficulty is set to 1,
> > > > and it raises to 4 almost instantly, when testnet creators are
> > > > mining the first coins. Which means, that difficulty 1 is
> > > > ridiculously easy to work with, when you have any ASICs. If you
> > > > combine it with the idea of fake timestamps,
> > >
> > > It's not the number of blocks, but the cumulative work that
> > > matters, so to have a soft reset of testnet3 or testnet4 you'd
> > > need to apply more hashing for the new chain than the existing
> > > chains have already received. That's a fair amount of "wasted"
> > > hash: I think mining a more-work chain than testnet4 would
> > > require about the same amount of hash that it would take to mine
> > > ~13 mainnet blocks at the current difficulty, so you'd be giving
> > > up about $4M USD in mainnet block rewards to do it.
> > >
> > > In any event, a hard fork is "necessary", as otherwise whenever it
> > > takes 20 minutes or more to find a block, old clients will expect
> > > a lower difficulty than new clients do, so the two wouldn't be
> > > compatible with each other. You could do various things to work
> > > around that, but that's a lot of coding time that could be better
> > > spent on improving things relevant to mainnet, and if you're
> > > resetting the chain anyway, there's not much advantage to it.
> > >
> > > > then you can produce a really long initial chain, which will
> > > > start in 2009, and up to 2025, it will produce almost the same
> > > > amount of blocks as mainnet.
> > >
> > > A soft fork of testnet3 would start 3rd Feb 2011 (leading to about
> > > 750k blocks vs mainnet's ~900k), and a soft fork of testnet4 would
> > > start at 4th May 2024 (leading to about 54k blocks). (These are
> > > the timestamps of the respective genesis blocks)
> > >
> > > A disadvantage of doing a premine that way is that users of the
> > > chain need to download and validate thousands of blocks and deal
> > > with an equal number of utxos just to establish the premine;
> > > doing that in a single block with a single utxo (or one utxo for
> > > each recipient of the premine) is quite a bit more efficient.
> > >
> > > > Which means, that instead of "premine", you can use
> > > > "ninja-mine", and achieve pretty much the same end result.
> > >
> > > I think in general usage "premine" covers both those approaches
> > > -- any time the creator(s) of a chain gets the opportunity to
> > > claim/distribute coins prior to the general public being able to
> > > mint new coins by mining blocks, that's a premine.
> > >
> > > Cheers,
> > > aj
> > >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to bitcoindev+unsubscribe@googlegroups•com.
> > To view this discussion visit
> > https://groups.google.com/d/msgid/bitcoindev/20250512120531.1AC1F7C0557%40smtp.postman.i2p
> > .
> >

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250512201916.3818A7C1190%40smtp.postman.i2p.


 permalink raw reply	[|nested]