[bitcoindev] [BIP Draft] Testnet 5

Bitcoin Development Mailinglist
 help / color / mirror / Atom feed

* [bitcoindev] [BIP Draft] Testnet 5
@ 2026-06-02 11:24 'Pol Espinasa' via Bitcoin Development Mailing List
  2026-06-02 14:25 ` José Edil Guimarães de Medeiros
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: 'Pol Espinasa' via Bitcoin Development Mailing List @ 2026-06-02 11:24 UTC (permalink / raw)
  To: bitcoindev@googlegroups.com


[-- Attachment #1.1.1: Type: text/plain, Size: 878 bytes --]

Dear list,
I am sharing a BIP draft for a new Testnet5.
People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.

You can find the full text to read and comment on in the following draft PR: https://github.com/fjahr/bips/pull/2
Feel free to leave inline comments there or respond here on the list.




Pol

-- 
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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com.

[-- Attachment #1.1.2.1: Type: text/html, Size: 2049 bytes --]

[-- Attachment #1.2: publickey - polespinasa@protonmail.com - 0x44205759.asc --]
[-- Type: application/pgp-keys, Size: 856 bytes --]

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 11:24 [bitcoindev] [BIP Draft] Testnet 5 'Pol Espinasa' via Bitcoin Development Mailing List
@ 2026-06-02 14:25 ` José Edil Guimarães de Medeiros
       [not found]   ` <5e9rybLioivQv7knRGX4xCLZffObV0RGjf2DP0-0wC-K9BRTfjV2GsWUjUlYnOw7EYRDVGA4ERPqoCGynGmNQXNLRy_mhvwdITuBR2t1rJs=@protonmail.com>
  2026-06-02 15:02 ` Saint Wenhao
  2026-06-05  9:35 ` Anthony Towns
  2 siblings, 1 reply; 11+ messages in thread
From: José Edil Guimarães de Medeiros @ 2026-06-02 14:25 UTC (permalink / raw)
  To: Pol Espinasa; +Cc: bitcoindev

[-- Attachment #1: Type: text/html, Size: 4342 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

[parent not found: <5e9rybLioivQv7knRGX4xCLZffObV0RGjf2DP0-0wC-K9BRTfjV2GsWUjUlYnOw7EYRDVGA4ERPqoCGynGmNQXNLRy_mhvwdITuBR2t1rJs=@protonmail.com>]

* Re: [bitcoindev] [BIP Draft] Testnet 5
       [not found]   ` <5e9rybLioivQv7knRGX4xCLZffObV0RGjf2DP0-0wC-K9BRTfjV2GsWUjUlYnOw7EYRDVGA4ERPqoCGynGmNQXNLRy_mhvwdITuBR2t1rJs=@protonmail.com>
@ 2026-06-03 21:55     ` Edil Guimarães de Medeiros
  0 siblings, 0 replies; 11+ messages in thread
From: Edil Guimarães de Medeiros @ 2026-06-03 21:55 UTC (permalink / raw)
  To: Antoine Poinsot; +Cc: Pol Espinasa, bitcoindev

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

Hi Antoine,


> However a risk that the network becomes temporarily unusable does not
> justify introducing yet another band-aid that would inevitably make it
> permanently unusable.
>

Agree.


> Moreover, i think we are in a better position nowadays to deal with such a
> situation than we were 15 years ago when that happened on testnet1.
>

Yes, I expect some people to contribute some hash rate to unstuck a
testnet5 chain (I would be willing to contribute), but I'm not so sure that
will be enough.
Anyhow, I gave this scenario some thought and came to the conclusion that
the odds of it happening (big miner increasing difficulty on purpose and
leaving) would be pretty low.

Yet, it doesn't address the problem of coins getting value (which I still
think is unsolvable given a pretty stable network).
Not the biggest concern to me, just that this will be an argument anytime
soon.

-- 
Edil

-- 
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/CANJiN3KUW8K5mAyoekzYFyBf3jtnsTxW8LfwvUq7K5FDs-XR7Q%40mail.gmail.com.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 11:24 [bitcoindev] [BIP Draft] Testnet 5 'Pol Espinasa' via Bitcoin Development Mailing List
  2026-06-02 14:25 ` José Edil Guimarães de Medeiros
@ 2026-06-02 15:02 ` Saint Wenhao
  2026-06-02 15:29   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
                     ` (2 more replies)
  2026-06-05  9:35 ` Anthony Towns
  2 siblings, 3 replies; 11+ messages in thread
From: Saint Wenhao @ 2026-06-02 15:02 UTC (permalink / raw)
  To: Pol Espinasa; +Cc: bitcoindev@googlegroups.com

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

> I am sharing a BIP draft for a new Testnet5.

Interesting. Does it mean, that testnet4 fixes won't be done?
https://batmanbytes.github.io/testnet4-softfork/

> For the Pubkey field, use a recent Bitcoin mainnet block hash.

Do you mean taking the hash of the block, and using it as x-value for a
public key? Then, it could be potentially spendable, if it would be a valid
secp256k1 point, and people would send more coins to it, or unspendable, if
it would be outside of the curve. For example:

spendable:
0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084
OP_CHECKSIG
unspendable:
02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae
OP_CHECKSIG
unspendable:
00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG

Also, if the size of the stack push would be different than 33 or 65 bytes,
then it would be unspendable (for example if it would take 32 bytes, like
block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if
it would start with OP_RETURN).

> Difficulty: 0x1d00ffff

I wonder, how quickly it would be listed on exchanges, and traded. Because
historically, new testnets were launched, when that happened. But today,
new coins are listed faster, than they are replaced. Which would give the
creator with any ASIC an incentive, to mine initial 30k or so blocks, keep
them for a while, and then sell for BTCs, when the coin will be listed.

Also, I wonder if testnet5 will have any premine. Previous attempt to
create testnet5: https://bitcointalk.org/index.php?topic=5543921

> Testnet 5 also does not apply the difficulty exception rule from Testnet
3 or Testnet 4 requires.

It would be nice to simplify the code, and remove that rule completely from
sources, but it would probably take a while to deprecate testnet3 and
testnet4.

wt., 2 cze 2026 o 13:27 'Pol Espinasa' via Bitcoin Development Mailing List
<bitcoindev@googlegroups.com> napisał(a):

> Dear list,
>
> I am sharing a BIP draft for a new Testnet5.
> People are complaining about Testnet4 being difficult to use, the new
> testnet also works as a miner playground for BIP54, we are killing two
> birds with one stone.
>
> You can find the full text to read and comment on in the following draft
> PR: https://github.com/fjahr/bips/pull/2
> Feel free to leave inline comments there or respond here on the list.
>
>
> Pol
>
> --
> 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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%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/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 15:02 ` Saint Wenhao
@ 2026-06-02 15:29   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
  2026-06-02 16:22   ` Garlo Nicon
  2026-06-02 16:37   ` 'Pol Espinasa' via Bitcoin Development Mailing List
  2 siblings, 0 replies; 11+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-06-02 15:29 UTC (permalink / raw)
  To: Saint Wenhao; +Cc: Pol Espinasa, bitcoindev@googlegroups.com

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

Hi,

On Tuesday, June 2nd, 2026 at 11:05 AM, Saint Wenhao <saintwenhao@gmail.com> wrote:

>> I am sharing a BIP draft for a new Testnet5.
>
> Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/

I for one believe we are better off ripping the band-aid and starting fresh than trying to pile up more workarounds.

>> For the Pubkey field, use a recent Bitcoin mainnet block hash.
>
> Do you mean taking the hash of the block, and using it as x-value for a public key? Then, it could be potentially spendable, if it would be a valid secp256k1 point, and people would send more coins to it, or unspendable, if it would be outside of the curve. For example:
>
> spendable: 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
> unspendable: 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae OP_CHECKSIG
> unspendable: 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
>
> Also, if the size of the stack push would be different than 33 or 65 bytes, then it would be unspendable (for example if it would take 32 bytes, like block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if it would start with OP_RETURN).
>
>> Difficulty: 0x1d00ffff
>
> I wonder, how quickly it would be listed on exchanges, and traded. Because historically, new testnets were launched, when that happened. But today, new coins are listed faster, than they are replaced. Which would give the creator with any ASIC an incentive, to mine initial 30k or so blocks, keep them for a while, and then sell for BTCs, when the coin will be listed.
>
> Also, I wonder if testnet5 will have any premine. Previous attempt to create testnet5: https://bitcointalk.org/index.php?topic=5543921
>
>> Testnet 5 also does not apply the difficulty exception rule from Testnet 3 or Testnet 4 requires.
>
> It would be nice to simplify the code, and remove that rule completely from sources, but it would probably take a while to deprecate testnet3 and testnet4.
>
> wt., 2 cze 2026 o 13:27 'Pol Espinasa' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> napisał(a):
>
>> Dear list,
>>
>> I am sharing a BIP draft for a new Testnet5.
>> People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.
>>
>> You can find the full text to read and comment on in the following draft PR: https://github.com/fjahr/bips/pull/2
>> Feel free to leave inline comments there or respond here on the list.
>>
>> Pol
>>
>> --
>> 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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com.
>
> --
> 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/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com.

-- 
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/Note5jyeHB1BStZ3AMHw2aYjj8KmOuSO7wl8FAAEj8lzo9PFX6972iUY6iWbcG0VidvpgRbw-gh1dZTC3DTlELA3pjANhz_1WLW7P1KiXL4%3D%40protonmail.com.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 15:02 ` Saint Wenhao
  2026-06-02 15:29   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2026-06-02 16:22   ` Garlo Nicon
  2026-06-02 16:48     ` 'Pol Espinasa' via Bitcoin Development Mailing List
  2026-06-02 16:37   ` 'Pol Espinasa' via Bitcoin Development Mailing List
  2 siblings, 1 reply; 11+ messages in thread
From: Garlo Nicon @ 2026-06-02 16:22 UTC (permalink / raw)
  To: Saint Wenhao; +Cc: Pol Espinasa, bitcoindev@googlegroups.com

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

> coins being too difficult to mine without a lot of hash rate

It could be easily solved, if blocks with regular difficulty would replace
the min-difficulty ones. Because the current rule forces all miners, with
CPUs, GPUs, ASICs, or anything else, to produce a min-difficulty block
after 20 minutes. However, there are many different ways to handle that.
For example: after 20 minutes, block with any difficulty could be accepted,
but could be reorged by stronger miners later. Then, the network would
never be stuck.

Or: to discourage mining low-difficulty blocks, the amount of the coinbase
could be adjusted, proportionally to the difficulty. You don't have
hashpower, to mine a block with 1M difficulty, and receive 50 tBTC? No
problem, mine million times easier block, get 5k tBTC for testing, and do
your tests. If stronger miner will appear, they will have a chance to reorg
you, but the same is true in testnet3 and testnet4.

> I wonder if the goal of having a clone of mainnet with worthless coins is
even possible.

Currently, even signet coins are traded for mainnet BTCs, so probably not.
By the way: I wonder, if there are any tests, where testnets like testnet3
or testnet4 are still needed. Because most things can be covered by regtest
and signet. And if someone needs to test mining, then coins can be locked
to a Proof of Work in many ways, and then, miners could claim them, by
solving such puzzle. And it works even on mainnet, all you need is using
OP_SIZE on a DER signature, to reach an arbitrary difficulty:
https://github.com/adambor/btc-pow-locked-outputs/

So, are there any use cases, where testnet5 is needed, and signet cannot be
used?

wt., 2 cze 2026 o 17:05 Saint Wenhao <saintwenhao@gmail.com> napisał(a):

> > I am sharing a BIP draft for a new Testnet5.
>
> Interesting. Does it mean, that testnet4 fixes won't be done?
> https://batmanbytes.github.io/testnet4-softfork/
>
> > For the Pubkey field, use a recent Bitcoin mainnet block hash.
>
> Do you mean taking the hash of the block, and using it as x-value for a
> public key? Then, it could be potentially spendable, if it would be a valid
> secp256k1 point, and people would send more coins to it, or unspendable, if
> it would be outside of the curve. For example:
>
> spendable:
> 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084
> OP_CHECKSIG
> unspendable:
> 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae
> OP_CHECKSIG
> unspendable:
> 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
>
> Also, if the size of the stack push would be different than 33 or 65
> bytes, then it would be unspendable (for example if it would take 32 bytes,
> like block hashes, and would be followed by OP_CHECKSIG, to invalidate it,
> or if it would start with OP_RETURN).
>
> > Difficulty: 0x1d00ffff
>
> I wonder, how quickly it would be listed on exchanges, and traded. Because
> historically, new testnets were launched, when that happened. But today,
> new coins are listed faster, than they are replaced. Which would give the
> creator with any ASIC an incentive, to mine initial 30k or so blocks, keep
> them for a while, and then sell for BTCs, when the coin will be listed.
>
> Also, I wonder if testnet5 will have any premine. Previous attempt to
> create testnet5: https://bitcointalk.org/index.php?topic=5543921
>
> > Testnet 5 also does not apply the difficulty exception rule from Testnet
> 3 or Testnet 4 requires.
>
> It would be nice to simplify the code, and remove that rule completely
> from sources, but it would probably take a while to deprecate testnet3 and
> testnet4.
>
> wt., 2 cze 2026 o 13:27 'Pol Espinasa' via Bitcoin Development Mailing
> List <bitcoindev@googlegroups.com> napisał(a):
>
>> Dear list,
>>
>> I am sharing a BIP draft for a new Testnet5.
>> People are complaining about Testnet4 being difficult to use, the new
>> testnet also works as a miner playground for BIP54, we are killing two
>> birds with one stone.
>>
>> You can find the full text to read and comment on in the following draft
>> PR: https://github.com/fjahr/bips/pull/2
>> Feel free to leave inline comments there or respond here on the list.
>>
>>
>> Pol
>>
>> --
>> 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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%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/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%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/CAN7kyNiH_8hnBmxBR8rPc%2BwYwbKPRy51yif3jRXofHbFFKsSgQ%40mail.gmail.com.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 16:22   ` Garlo Nicon
@ 2026-06-02 16:48     ` 'Pol Espinasa' via Bitcoin Development Mailing List
  0 siblings, 0 replies; 11+ messages in thread
From: 'Pol Espinasa' via Bitcoin Development Mailing List @ 2026-06-02 16:48 UTC (permalink / raw)
  To: Garlo Nicon; +Cc: Saint Wenhao, bitcoindev@googlegroups.com


[-- Attachment #1.1.1: Type: text/plain, Size: 6378 bytes --]

Hi Garlo,

> So, are there any use cases, where testnet5 is needed, and signet cannot be used?"


Yes, as per the BIP text: "However, signet does not allow miners to test that their software reliably follows the rules of BIP 54. Testnet 5 provides a testing environment for this."

You want to test the same software that you are aiming to run on mainnet, not a modified version that allows you to solve some PoW puzzles. Also, you want to test enforcement of consensus rules on block creation and validation, and check interaction with other nodes and miners.


Pol

On Tuesday, June 2nd, 2026 at 6:23 PM, Garlo Nicon garlonicon@gmail.com wrote:

> > coins being too difficult to mine without a lot of hash rate
> 

> It could be easily solved, if blocks with regular difficulty would replace the min-difficulty ones. Because the current rule forces all miners, with CPUs, GPUs, ASICs, or anything else, to produce a min-difficulty block after 20 minutes. However, there are many different ways to handle that. For example: after 20 minutes, block with any difficulty could be accepted, but could be reorged by stronger miners later. Then, the network would never be stuck.
> 

> Or: to discourage mining low-difficulty blocks, the amount of the coinbase could be adjusted, proportionally to the difficulty. You don't have hashpower, to mine a block with 1M difficulty, and receive 50 tBTC? No problem, mine million times easier block, get 5k tBTC for testing, and do your tests. If stronger miner will appear, they will have a chance to reorg you, but the same is true in testnet3 and testnet4.
> 

> > I wonder if the goal of having a clone of mainnet with worthless coins is even possible.
> 

> Currently, even signet coins are traded for mainnet BTCs, so probably not. By the way: I wonder, if there are any tests, where testnets like testnet3 or testnet4 are still needed. Because most things can be covered by regtest and signet. And if someone needs to test mining, then coins can be locked to a Proof of Work in many ways, and then, miners could claim them, by solving such puzzle. And it works even on mainnet, all you need is using OP_SIZE on a DER signature, to reach an arbitrary difficulty: https://github.com/adambor/btc-pow-locked-outputs/
> 

> So, are there any use cases, where testnet5 is needed, and signet cannot be used?
> 

> wt., 2 cze 2026 o 17:05 Saint Wenhao saintwenhao@gmail.com napisał(a):
> 

> > > I am sharing a BIP draft for a new Testnet5.
> > 

> > Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/
> > 

> > > For the Pubkey field, use a recent Bitcoin mainnet block hash.
> > 

> > Do you mean taking the hash of the block, and using it as x-value for a public key? Then, it could be potentially spendable, if it would be a valid secp256k1 point, and people would send more coins to it, or unspendable, if it would be outside of the curve. For example:
> > 

> > spendable: 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
> > unspendable: 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae OP_CHECKSIG
> > unspendable: 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
> > 

> > Also, if the size of the stack push would be different than 33 or 65 bytes, then it would be unspendable (for example if it would take 32 bytes, like block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if it would start with OP_RETURN).
> > 

> > > Difficulty: 0x1d00ffff
> > 

> > I wonder, how quickly it would be listed on exchanges, and traded. Because historically, new testnets were launched, when that happened. But today, new coins are listed faster, than they are replaced. Which would give the creator with any ASIC an incentive, to mine initial 30k or so blocks, keep them for a while, and then sell for BTCs, when the coin will be listed.
> > 

> > Also, I wonder if testnet5 will have any premine. Previous attempt to create testnet5: https://bitcointalk.org/index.php?topic=5543921
> > 

> > > Testnet 5 also does not apply the difficulty exception rule from Testnet 3 or Testnet 4 requires.
> > 

> > It would be nice to simplify the code, and remove that rule completely from sources, but it would probably take a while to deprecate testnet3 and testnet4.
> > 

> > wt., 2 cze 2026 o 13:27 'Pol Espinasa' via Bitcoin Development Mailing List bitcoindev@googlegroups.com napisał(a):
> > 

> > > Dear list,
> > > I am sharing a BIP draft for a new Testnet5.
> > > People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.
> > > 

> > > You can find the full text to read and comment on in the following draft PR: https://github.com/fjahr/bips/pull/2
> > > Feel free to leave inline comments there or respond here on the list.
> > > 

> > > Pol
> > > 

> > > --
> > > 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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com.
> > 

> > --
> > 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/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com.

-- 
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/ZjV9FwOf2ShRUaaQWs6LZoHTDjbF8WmfmDptSF3x-V6rNducvUu7IRoXKfz7ZYnkxX9b4r8rIsKXcpMTgVNA7QS8qALJqCYEVRyaXrmwaXA%3D%40protonmail.com.

[-- Attachment #1.1.2.1: Type: text/html, Size: 7920 bytes --]

[-- Attachment #1.2: publickey - polespinasa@protonmail.com - 0x44205759.asc --]
[-- Type: application/pgp-keys, Size: 856 bytes --]

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 15:02 ` Saint Wenhao
  2026-06-02 15:29   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
  2026-06-02 16:22   ` Garlo Nicon
@ 2026-06-02 16:37   ` 'Pol Espinasa' via Bitcoin Development Mailing List
  2 siblings, 0 replies; 11+ messages in thread
From: 'Pol Espinasa' via Bitcoin Development Mailing List @ 2026-06-02 16:37 UTC (permalink / raw)
  To: Saint Wenhao; +Cc: bitcoindev@googlegroups.com


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

Hi,


On Tuesday, June 2nd, 2026 at 5:02 PM, Saint Wenhao <saintwenhao@gmail.com> wrote:

> > I am sharing a BIP draft for a new Testnet5.
>
> Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/

They won't (or at least it is not what we are proposing here), I agree with Antoine that a fresh start is better than just pile up workarounds.
Sometimes the cure is worse than the disease.

> > For the Pubkey field, use a recent Bitcoin mainnet block hash.
>
> Do you mean taking the hash of the block, and using it as x-value for a public key? Then, it could be potentially spendable, if it would be a valid secp256k1 point, and people would send more coins to it, or unspendable, if it would be outside of the curve. For example:
>
> spendable: 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
> unspendable: 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae OP_CHECKSIG
> unspendable: 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
>
> Also, if the size of the stack push would be different than 33 or 65 bytes, then it would be unspendable (for example if it would take 32 bytes, like block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if it would start with OP_RETURN).

yes, as per the original text in the draft: "the output is provably unspendable". The idea comes from: https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093516015, https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2095786951, https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2099974737


> > Difficulty: 0x1d00ffff
>
> I wonder, how quickly it would be listed on exchanges, and traded. Because historically, new testnets were launched, when that happened. But today, new coins are listed faster, than they are replaced. Which would give the creator with any ASIC an incentive, to mine initial 30k or so blocks, keep them for a while, and then sell for BTCs, when the coin will be listed.

That is a risk, but I personally don't think there is any real solution for that. It is impossible to avoid people selling coins.
I hope the risk of resetting the network or starting a new one (as we did multiple times, and we are suggesting here) is enough for coins to not have "much" value.

> Also, I wonder if testnet5 will have any premine. Previous attempt to create testnet5: https://bitcointalk.org/index.php?topic=5543921

It will not, using a mainnnet block hash in the Pubkey field acts as an anti-premine-commitment.

> > Testnet 5 also does not apply the difficulty exception rule from Testnet 3 or Testnet 4 requires.
>
> It would be nice to simplify the code, and remove that rule completely from sources, but it would probably take a while to deprecate testnet3 and testnet4.

I agree that might take time, but that is a node client implementation detail :)

> wt., 2 cze 2026 o 13:27 'Pol Espinasa' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> napisał(a):
>
> > Dear list,
> > I am sharing a BIP draft for a new Testnet5.
> > People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.
> >
> > You can find the full text to read and comment on in the following draft PR: https://github.com/fjahr/bips/pull/2
> > Feel free to leave inline comments there or respond here on the list.
> >
> >
> >
> >
> > Pol
> >
> > --
> > 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/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com.

-- 
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/FJTfAMGEfN5PH0phIMiQ--jMyFCzpSHQpZb8eg8ZMVKFqTMZtzjYrPz2qB6HIvAl81ZSuMCH88i3_B_vYcCmhmi8laRxbgOtFEBh0h24GK8%3D%40protonmail.com.

[-- Attachment #1.2: publickey - polespinasa@protonmail.com - 0x44205759.asc --]
[-- Type: application/pgp-keys, Size: 856 bytes --]

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-02 11:24 [bitcoindev] [BIP Draft] Testnet 5 'Pol Espinasa' via Bitcoin Development Mailing List
  2026-06-02 14:25 ` José Edil Guimarães de Medeiros
  2026-06-02 15:02 ` Saint Wenhao
@ 2026-06-05  9:35 ` Anthony Towns
  2026-06-07 21:52   ` 'Fabian' via Bitcoin Development Mailing List
  2 siblings, 1 reply; 11+ messages in thread
From: Anthony Towns @ 2026-06-05  9:35 UTC (permalink / raw)
  To: Pol Espinasa; +Cc: bitcoindev@googlegroups.com

On Tue, Jun 02, 2026 at 11:24:18AM +0000, 'Pol Espinasa' via Bitcoin Development Mailing List wrote:
> I am sharing a BIP draft for a new Testnet5.
> People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.

+1 in general, but some notes:

This seems slightly contradictory:

a)

>> Testnet 5 follows the same consensus rules as mainnet with the following exception.
>>
>> ### BIP 54 activation
>>
>> The rules specified in [BIP 54 version 1.0.0][BIP54] are active on
>> Testnet 5 from Genesis.

b)

>> ### Consensus Rules
>>
>> All consensus rules active on mainnet as of May 2026 are enforced
>> from Genesis, the most recent of these being the Taproot softfork.

The "enforce BIP 54" part should just be under consensus rules, afaics.

I think "are active .. from Genesis" is perhaps not great, and the BIP
54 rules should apply to block 1 and above only? Otherwise, applying the
timestamp rule to block 0 per-BIP 54 doesn't seem coherent (it depends
on the timestamps of block -1 and block -2015), and the coinbase locktime
rule likewise would require setting the genesis block's locktime to -1.

>> the output is provably unspendable and it acts as an anti-pre-mine
>> commitment.

I'd argue that, economically, a pre-mine (or initial allocation/auction,
whatever you want to call it) is probably helpful for a testnet rather
than harmful, in that it provides a potentially large pool of coins that
can immediately be used for testing, and to suppress the scarcity/value
of mined coins. Not a blocker, just my opinion. Not pre-mining is probably
the most defensible position from a regulatory POV, however.

I think being demonstrably willing to regularly create new testnet
versions is probably also a good way of avoiding testnet coins becoming
particularly valuable/expensive; so even if the technical reasons for a
new testnet weren't compelling, that might be a good reason to do so on
its own. It's been about two years since testnet4 launched, which seems
like an okay cadence, if it were to actually become a regular thing.

Rather than dropping immediately to min-difficulty, having the difficulty
drop by 50% every 120 minutes or similar could be a reasonable approach
if it turns out, in practice that difficulty gets pushed very high by a
miner testing new hardware, then block creation stalls for a long period,
preventing difficulty from adjusting downward. Seems like something to
defer to testnet6, though. (Could perhaps also just grab the dynamic
difficulty adjustment logic that BCH/etc settled on, if something along
these lines is necessary)

>> - Other parameters (`Difficulty: 0x1d00ffff`, `Version: 1`) should
>>   match Testnet 4.

That "difficulty" value is probably better described as "maximum target's
nBits", since it corresponds with "difficulty: 1" per "getblockheader".

Taking 0x1d00ffff as an integer gives ~486M compared with current
mainnet difficulty of ~138T, or testnet4's current difficulty of ~1239M,
so I think interpreting it as an actual difficulty wouldn't actually be
terrible, apart from perhaps rounding issues when converting it back to
the corresponding nBits.

However, I think with a low initial difficulty like this you get a
pre-mine in effect anyway. For example, if there's a single modern
antminer (U3S23H claims 1160TH/s) pointed at testnet5 initially, then,
only counting the hashing, it should take about 50 minutes to mine the
first 20k blocks (ie 400 blocks per second on average) and 1M tBTC,
pushing the difficulty up to 1M, and then another 2 days to mine the
next 3 retarget periods for another 6k blocks and 300k tBTC, pushing
difficulty up to 67M, after which blocks start taking more than a trivial
amount of time.

So I think increasing the minimum difficulty would make sense,
personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
difficulty=16M would make sense? At a difficulty of 1M you need about
6 BitAxe Gammas (at 1.2TH/s each) to keep the network at 10m/block,
at a difficulty of 16M you'd need ~100 BitAxe Gammas. At testnet4's
difficulty=1239M you need ~7400 BitAxe Gammas or ~30 S23's (at 305TH/s)
for comparison. BIP323 nVersion rolling plus potentially a couple of nTime
increments should be enough to get a valid hash at up to 16M difficulty,
I think.

If min difficulty were 16M, and the entire hashrate of testnet4 switched
over to testnet5 immediately, then blocks would initially come out every
8s, 31s, 124s and block spacing would be ~equalised against the 10 minute
target after about 4 days, 6048 blocks, and 300k tBTC. Min difficulty of
1M would make that take ~1h longer (with an initial phase of 0.5s blocks
then 2s blocks), adding 4032 blocks, and 200k tBTC to the pseudo-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/aiKYWu7Osn5hIJFP%40erisian.com.au.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-05  9:35 ` Anthony Towns
@ 2026-06-07 21:52   ` 'Fabian' via Bitcoin Development Mailing List
  2026-06-09 21:53     ` Murch
  0 siblings, 1 reply; 11+ messages in thread
From: 'Fabian' via Bitcoin Development Mailing List @ 2026-06-07 21:52 UTC (permalink / raw)
  To: Anthony Towns; +Cc: Pol Espinasa, bitcoindev@googlegroups.com

Hi AJ,

Thanks for the detailed feedback! Pol and I have coordinated on the
main points below and I have just pushed an update to the draft
accordingly.

> The "enforce BIP 54" part should just be under consensus rules,
> afaics.

I agree that this was contradictory. The Specification now no longer
frames BIP 54 as an exception but as a change relative to mainnet,
and the Consensus Rules section now mentions BIP 54 as well. I kept
the BIP 54 section under Specification since it is the main thing
the BIP describes and without it there would not really be a
Specification section which seems to contradict BIP 3 which makes the
section mandatory.

> I think "are active .. from Genesis" is perhaps not great, and the
> BIP 54 rules should apply to block 1 and above only?

Right, it now says "from block 1" throughout.

> I'd argue that, economically, a pre-mine (or initial
> allocation/auction, whatever you want to call it) is probably
> helpful for a testnet rather than harmful

I see the potential upside you are referring to but think it is
outweighed but bigger issues in practice. Any sort of pre-mine
would invite controversy and could create unnecessary headaches
for those involved that nobody is keen to take on. And this seems
unavoidable no matter how big the logistical effort would be to
distribute these coins as fairly as possible. As you say, not
pre-mining is the most defensible position so we are not going
to take this on.

> Rather than dropping immediately to min-difficulty, having the
> difficulty drop by 50% every 120 minutes or similar could be a
> reasonable approach

May be worth exploring if Testnet 5 runs into these issues but would
also introduce additional complexity which is why we are deferring
it to a potential future testnet as you suggested yourself.

> That "difficulty" value is probably better described as "maximum
> target's nBits"

Fixed, the field is now labeled nBits.

> So I think increasing the minimum difficulty would make sense,
> personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
> difficulty=16M would make sense?

We adopted 0x1a0fffff (~1M) in the draft now. This was discussed in
Testnet 4 already but collided with the difficulty exception which
had more conceptual support at the time. We preferred 1M over 16M
since it already significantly dampens quick mining of large numbers
of blocks shortly after launch while a handful of at-home miners or
a single (older) ASIC can still keep the network usable. It seems
to strike a good balance.

Fabian


On Friday, June 5th, 2026 at 12:27 PM, Anthony Towns <aj@erisian.com.au> wrote:

> On Tue, Jun 02, 2026 at 11:24:18AM +0000, 'Pol Espinasa' via Bitcoin Development Mailing List wrote:
> > I am sharing a BIP draft for a new Testnet5.
> > People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.
> 
> +1 in general, but some notes:
> 
> 
> 
> This seems slightly contradictory:
> 
> a)
> 
> >> Testnet 5 follows the same consensus rules as mainnet with the following exception.
> >>
> >> ### BIP 54 activation
> >>
> >> The rules specified in [BIP 54 version 1.0.0][BIP54] are active on
> >> Testnet 5 from Genesis.
> 
> b)
> 
> >> ### Consensus Rules
> >>
> >> All consensus rules active on mainnet as of May 2026 are enforced
> >> from Genesis, the most recent of these being the Taproot softfork.
> 
> The "enforce BIP 54" part should just be under consensus rules, afaics.
> 
> I think "are active .. from Genesis" is perhaps not great, and the BIP
> 54 rules should apply to block 1 and above only? Otherwise, applying the
> timestamp rule to block 0 per-BIP 54 doesn't seem coherent (it depends
> on the timestamps of block -1 and block -2015), and the coinbase locktime
> rule likewise would require setting the genesis block's locktime to -1.
> 
> 
> 
> >> the output is provably unspendable and it acts as an anti-pre-mine
> >> commitment.
> 
> I'd argue that, economically, a pre-mine (or initial allocation/auction,
> whatever you want to call it) is probably helpful for a testnet rather
> than harmful, in that it provides a potentially large pool of coins that
> can immediately be used for testing, and to suppress the scarcity/value
> of mined coins. Not a blocker, just my opinion. Not pre-mining is probably
> the most defensible position from a regulatory POV, however.
> 
> I think being demonstrably willing to regularly create new testnet
> versions is probably also a good way of avoiding testnet coins becoming
> particularly valuable/expensive; so even if the technical reasons for a
> new testnet weren't compelling, that might be a good reason to do so on
> its own. It's been about two years since testnet4 launched, which seems
> like an okay cadence, if it were to actually become a regular thing.
> 
> 
> 
> Rather than dropping immediately to min-difficulty, having the difficulty
> drop by 50% every 120 minutes or similar could be a reasonable approach
> if it turns out, in practice that difficulty gets pushed very high by a
> miner testing new hardware, then block creation stalls for a long period,
> preventing difficulty from adjusting downward. Seems like something to
> defer to testnet6, though. (Could perhaps also just grab the dynamic
> difficulty adjustment logic that BCH/etc settled on, if something along
> these lines is necessary)
> 
> 
> 
> >> - Other parameters (`Difficulty: 0x1d00ffff`, `Version: 1`) should
> >>   match Testnet 4.
> 
> That "difficulty" value is probably better described as "maximum target's
> nBits", since it corresponds with "difficulty: 1" per "getblockheader".
> 
> Taking 0x1d00ffff as an integer gives ~486M compared with current
> mainnet difficulty of ~138T, or testnet4's current difficulty of ~1239M,
> so I think interpreting it as an actual difficulty wouldn't actually be
> terrible, apart from perhaps rounding issues when converting it back to
> the corresponding nBits.
> 
> However, I think with a low initial difficulty like this you get a
> pre-mine in effect anyway. For example, if there's a single modern
> antminer (U3S23H claims 1160TH/s) pointed at testnet5 initially, then,
> only counting the hashing, it should take about 50 minutes to mine the
> first 20k blocks (ie 400 blocks per second on average) and 1M tBTC,
> pushing the difficulty up to 1M, and then another 2 days to mine the
> next 3 retarget periods for another 6k blocks and 300k tBTC, pushing
> difficulty up to 67M, after which blocks start taking more than a trivial
> amount of time.
> 
> So I think increasing the minimum difficulty would make sense,
> personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
> difficulty=16M would make sense? At a difficulty of 1M you need about
> 6 BitAxe Gammas (at 1.2TH/s each) to keep the network at 10m/block,
> at a difficulty of 16M you'd need ~100 BitAxe Gammas. At testnet4's
> difficulty=1239M you need ~7400 BitAxe Gammas or ~30 S23's (at 305TH/s)
> for comparison. BIP323 nVersion rolling plus potentially a couple of nTime
> increments should be enough to get a valid hash at up to 16M difficulty,
> I think.
> 
> If min difficulty were 16M, and the entire hashrate of testnet4 switched
> over to testnet5 immediately, then blocks would initially come out every
> 8s, 31s, 124s and block spacing would be ~equalised against the 10 minute
> target after about 4 days, 6048 blocks, and 300k tBTC. Min difficulty of
> 1M would make that take ~1h longer (with an initial phase of 0.5s blocks
> then 2s blocks), adding 4032 blocks, and 200k tBTC to the pseudo-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/aiKYWu7Osn5hIJFP%40erisian.com.au.
> 

-- 
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/DJs9JYTbROCHQIg0XGSnLLI1edzOYp0i3i96a_YFXuxqmhZq8nYyhHq5_upeVXcu-gPiOZHMzChmCOSBVe3kOk5pdlxDYWNFvtRy5JX89bo%3D%40protonmail.com.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoindev] [BIP Draft] Testnet 5
  2026-06-07 21:52   ` 'Fabian' via Bitcoin Development Mailing List
@ 2026-06-09 21:53     ` Murch
  0 siblings, 0 replies; 11+ messages in thread
From: Murch @ 2026-06-09 21:53 UTC (permalink / raw)
  To: bitcoindev

Hi Fabian and Pol,

It sounds like your proposal is already getting some interest and 
improvement suggestions. Please feel free to open a PR when you’re happy 
with your initial draft.

Cheers,
Murch

On 2026-06-07 14:52, 'Fabian' via Bitcoin Development Mailing List wrote:
> Hi AJ,
>
> Thanks for the detailed feedback! Pol and I have coordinated on the
> main points below and I have just pushed an update to the draft
> accordingly.
>
>> The "enforce BIP 54" part should just be under consensus rules,
>> afaics.
> I agree that this was contradictory. The Specification now no longer
> frames BIP 54 as an exception but as a change relative to mainnet,
> and the Consensus Rules section now mentions BIP 54 as well. I kept
> the BIP 54 section under Specification since it is the main thing
> the BIP describes and without it there would not really be a
> Specification section which seems to contradict BIP 3 which makes the
> section mandatory.
>
>> I think "are active .. from Genesis" is perhaps not great, and the
>> BIP 54 rules should apply to block 1 and above only?
> Right, it now says "from block 1" throughout.
>
>> I'd argue that, economically, a pre-mine (or initial
>> allocation/auction, whatever you want to call it) is probably
>> helpful for a testnet rather than harmful
> I see the potential upside you are referring to but think it is
> outweighed but bigger issues in practice. Any sort of pre-mine
> would invite controversy and could create unnecessary headaches
> for those involved that nobody is keen to take on. And this seems
> unavoidable no matter how big the logistical effort would be to
> distribute these coins as fairly as possible. As you say, not
> pre-mining is the most defensible position so we are not going
> to take this on.
>
>> Rather than dropping immediately to min-difficulty, having the
>> difficulty drop by 50% every 120 minutes or similar could be a
>> reasonable approach
> May be worth exploring if Testnet 5 runs into these issues but would
> also introduce additional complexity which is why we are deferring
> it to a potential future testnet as you suggested yourself.
>
>> That "difficulty" value is probably better described as "maximum
>> target's nBits"
> Fixed, the field is now labeled nBits.
>
>> So I think increasing the minimum difficulty would make sense,
>> personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
>> difficulty=16M would make sense?
> We adopted 0x1a0fffff (~1M) in the draft now. This was discussed in
> Testnet 4 already but collided with the difficulty exception which
> had more conceptual support at the time. We preferred 1M over 16M
> since it already significantly dampens quick mining of large numbers
> of blocks shortly after launch while a handful of at-home miners or
> a single (older) ASIC can still keep the network usable. It seems
> to strike a good balance.
>
> Fabian
>
>
> On Friday, June 5th, 2026 at 12:27 PM, Anthony Towns <aj@erisian.com.au> wrote:
>
>> On Tue, Jun 02, 2026 at 11:24:18AM +0000, 'Pol Espinasa' via Bitcoin Development Mailing List wrote:
>>> I am sharing a BIP draft for a new Testnet5.
>>> People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.
>> +1 in general, but some notes:
>>
>>
>>
>> This seems slightly contradictory:
>>
>> a)
>>
>>>> Testnet 5 follows the same consensus rules as mainnet with the following exception.
>>>>
>>>> ### BIP 54 activation
>>>>
>>>> The rules specified in [BIP 54 version 1.0.0][BIP54] are active on
>>>> Testnet 5 from Genesis.
>> b)
>>
>>>> ### Consensus Rules
>>>>
>>>> All consensus rules active on mainnet as of May 2026 are enforced
>>>> from Genesis, the most recent of these being the Taproot softfork.
>> The "enforce BIP 54" part should just be under consensus rules, afaics.
>>
>> I think "are active .. from Genesis" is perhaps not great, and the BIP
>> 54 rules should apply to block 1 and above only? Otherwise, applying the
>> timestamp rule to block 0 per-BIP 54 doesn't seem coherent (it depends
>> on the timestamps of block -1 and block -2015), and the coinbase locktime
>> rule likewise would require setting the genesis block's locktime to -1.
>>
>>
>>
>>>> the output is provably unspendable and it acts as an anti-pre-mine
>>>> commitment.
>> I'd argue that, economically, a pre-mine (or initial allocation/auction,
>> whatever you want to call it) is probably helpful for a testnet rather
>> than harmful, in that it provides a potentially large pool of coins that
>> can immediately be used for testing, and to suppress the scarcity/value
>> of mined coins. Not a blocker, just my opinion. Not pre-mining is probably
>> the most defensible position from a regulatory POV, however.
>>
>> I think being demonstrably willing to regularly create new testnet
>> versions is probably also a good way of avoiding testnet coins becoming
>> particularly valuable/expensive; so even if the technical reasons for a
>> new testnet weren't compelling, that might be a good reason to do so on
>> its own. It's been about two years since testnet4 launched, which seems
>> like an okay cadence, if it were to actually become a regular thing.
>>
>>
>>
>> Rather than dropping immediately to min-difficulty, having the difficulty
>> drop by 50% every 120 minutes or similar could be a reasonable approach
>> if it turns out, in practice that difficulty gets pushed very high by a
>> miner testing new hardware, then block creation stalls for a long period,
>> preventing difficulty from adjusting downward. Seems like something to
>> defer to testnet6, though. (Could perhaps also just grab the dynamic
>> difficulty adjustment logic that BCH/etc settled on, if something along
>> these lines is necessary)
>>
>>
>>
>>>> - Other parameters (`Difficulty: 0x1d00ffff`, `Version: 1`) should
>>>>    match Testnet 4.
>> That "difficulty" value is probably better described as "maximum target's
>> nBits", since it corresponds with "difficulty: 1" per "getblockheader".
>>
>> Taking 0x1d00ffff as an integer gives ~486M compared with current
>> mainnet difficulty of ~138T, or testnet4's current difficulty of ~1239M,
>> so I think interpreting it as an actual difficulty wouldn't actually be
>> terrible, apart from perhaps rounding issues when converting it back to
>> the corresponding nBits.
>>
>> However, I think with a low initial difficulty like this you get a
>> pre-mine in effect anyway. For example, if there's a single modern
>> antminer (U3S23H claims 1160TH/s) pointed at testnet5 initially, then,
>> only counting the hashing, it should take about 50 minutes to mine the
>> first 20k blocks (ie 400 blocks per second on average) and 1M tBTC,
>> pushing the difficulty up to 1M, and then another 2 days to mine the
>> next 3 retarget periods for another 6k blocks and 300k tBTC, pushing
>> difficulty up to 67M, after which blocks start taking more than a trivial
>> amount of time.
>>
>> So I think increasing the minimum difficulty would make sense,
>> personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
>> difficulty=16M would make sense? At a difficulty of 1M you need about
>> 6 BitAxe Gammas (at 1.2TH/s each) to keep the network at 10m/block,
>> at a difficulty of 16M you'd need ~100 BitAxe Gammas. At testnet4's
>> difficulty=1239M you need ~7400 BitAxe Gammas or ~30 S23's (at 305TH/s)
>> for comparison. BIP323 nVersion rolling plus potentially a couple of nTime
>> increments should be enough to get a valid hash at up to 16M difficulty,
>> I think.
>>
>> If min difficulty were 16M, and the entire hashrate of testnet4 switched
>> over to testnet5 immediately, then blocks would initially come out every
>> 8s, 31s, 124s and block spacing would be ~equalised against the 10 minute
>> target after about 4 days, 6048 blocks, and 300k tBTC. Min difficulty of
>> 1M would make that take ~1h longer (with an initial phase of 0.5s blocks
>> then 2s blocks), adding 4032 blocks, and 200k tBTC to the pseudo-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/aiKYWu7Osn5hIJFP%40erisian.com.au.
>>

-- 
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/ed49cb11-f7f7-4385-8b87-b5192385b06d%40murch.one.


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-06-09 23:09 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-02 11:24 [bitcoindev] [BIP Draft] Testnet 5 'Pol Espinasa' via Bitcoin Development Mailing List
2026-06-02 14:25 ` José Edil Guimarães de Medeiros
     [not found]   ` <5e9rybLioivQv7knRGX4xCLZffObV0RGjf2DP0-0wC-K9BRTfjV2GsWUjUlYnOw7EYRDVGA4ERPqoCGynGmNQXNLRy_mhvwdITuBR2t1rJs=@protonmail.com>
2026-06-03 21:55     ` Edil Guimarães de Medeiros
2026-06-02 15:02 ` Saint Wenhao
2026-06-02 15:29   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-02 16:22   ` Garlo Nicon
2026-06-02 16:48     ` 'Pol Espinasa' via Bitcoin Development Mailing List
2026-06-02 16:37   ` 'Pol Espinasa' via Bitcoin Development Mailing List
2026-06-05  9:35 ` Anthony Towns
2026-06-07 21:52   ` 'Fabian' via Bitcoin Development Mailing List
2026-06-09 21:53     ` Murch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox