BIP Draft: Testnet 5#2196
Conversation
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Good first showing. I have left a few comments and suggestions.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Good improvements, thanks for the quick response. I gave this another read:
| Assigned: ? | ||
| License: CC0-1.0 | ||
| Discussion: 2026-06-02: https://groups.google.com/g/bitcoindev/c/kGUMTxOvdJA | ||
| Version: 0.1.0 |
There was a problem hiding this comment.
I think the following two additional headers would make sense:
| Version: 0.1.0 | |
| Version: 0.1.0 | |
| Requires: 54 | |
| Replaces: 94 |
|
|
||
| ## Abstract | ||
|
|
||
| A new test network with the goal of replacing [Testnet 4][BIP94]. Testnet 5 removes the difficulty |
There was a problem hiding this comment.
Nit: The abstract starts on a sentence fragment without a verb.
| ## Motivation | ||
|
|
||
| Testnet 4 included mitigations for an issue known as the [block storm attack][block-storms] which could render the | ||
| whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire |
There was a problem hiding this comment.
It’s ambiguous whether "this" refers to the mitigations or the block storms.
| whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire | |
| whole network unusable. Block storm attacks led to a depletion of block subsidies, which made it hard to acquire |
|
|
||
| Testnet 4 included mitigations for an issue known as the [block storm attack][block-storms] which could render the | ||
| whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire | ||
| coins for testing. However, Testnet 4 still retained a modified version of the difficulty exception rule |
There was a problem hiding this comment.
Since much of this paragraph discusses the issues with the difficulty exception, perhaps it should be briefly explained.
| to discussion about changing Testnet 4 to mitigate this issue (see [Bitcointalk][bitcointalk-thread] | ||
| for analysis and discussion). | ||
|
|
||
| In Testnet 5 there is no exception to the PoW rules. This appears to be the logical conclusion, |
There was a problem hiding this comment.
I just had a random thought that I was wondering whether it was considered:
What would happen if blocks mined with the difficulty exception would be forbidden from collecting the subsidy (i.e., could only collect fees)? That would permit users to get blocks if the difficulty had run up, or to mine non-standard transactions, but would remove the incentive to mine blocks for collecting the subsidy. It would not prevent people from creating low-difficulty blocks to deny others from getting them and it might be more complicated than just dropping the exception, though.
| TODO: Mine the block. The values below are placeholders inherited from Testnet 4. They are | ||
| the genesis block's header fields together with the `Message` and `Pubkey` of its coinbase | ||
| transaction. Notes for the miner: |
There was a problem hiding this comment.
I took a look at BIP94 in regard to the meaning of these two fields. It seems to me that the pubkey field is also only implicitly explained there. Looking at the construction, it seems to me that the pubkey field takes the place of the previous block hash in the block header, is that right? I was unable to find out where the message field goes. I thought it would appear in the coinbase field of the coinbase transaction, but I could not find the message string either forward or backward in the block hex.
I would recommend that it be explicitly explained where the pubkey and message field appear in the construction.
There was a problem hiding this comment.
Oooh. Does pubkey go into the P2PK output script? Still confused about the message, though.
3 participants
Following up from the discussion on the mailing list.