BIP Draft: Testnet 5

[fjahr]

Following up from the discussion on the mailing list.

[murchandamus]

Good first showing. I have left a few comments and suggestions.

[murchandamus]

Good improvements, thanks for the quick response. I gave this another read:

[murchandamus]

I think the following two additional headers would make sense:

Suggested change

	Version: 0.1.0
	Version: 0.1.0
	Requires: 54
	Replaces: 94

[murchandamus]

Nit: The abstract starts on a sentence fragment without a verb.

[murchandamus]

It’s ambiguous whether "this" refers to the mitigations or the block storms.

Suggested change

	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

[murchandamus]

Since much of this paragraph discusses the issues with the difficulty exception, perhaps it should be briefly explained.

[murchandamus]

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.

[StevenSteiner]

Yet another band-aid fix, I fear. Way better off fresh and "right" from the start.

There are other ways to earn coins besides Block Rewards, using a difficulty exploit. Perhaps even more disruptive.

I also agree with the more complicated.

[stwenhao]

What would happen if blocks mined with the difficulty exception would be forbidden from collecting the subsidy (i.e., could only collect fees)?

Then, coins will be burned, and ASIC miners will have an incentive to reorg them. To prevent that, additional coins could be simply timelocked to some future block number, then stronger miners won't have an incentive to reorg them, and will simply collect them later instead.

Anyway, the idea to decrease the coinbase reward, proportionally to the Proof of Work in the block header, is not new. But it makes things more complicated, and there are other ways, like pay to Proof of Work scripts, which could be used to achieve the same things, without messing up with consensus rules.

Also, the scenario, where the chain would halt, because of not enough miners, could happen on the mainnet as well, so it would be good, if test network would behave in a similar way, to let someone try to deal with that problem, and prepare a solution for mainnet as well.

[murchandamus]

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.

[murchandamus]

Oooh. Does pubkey go into the P2PK output script? Still confused about the message, though.

[stwenhao]

I guess it could be just some x-value pubkey, equal to the mainnet block hash. For example: https://mempool.space/address/0200000000000000000001ae18e25b101d485505283d8d8e67771e1d865acbfece (and then, getting the private key for the Genesis Block would be impossible, if the secp256k1 point would be invalid, or would be as hard, as breaking secp256k1, if it would turn out to be a valid point, like 04 00000000000000000001AE18E25B101D485505283D8D8E67771E1D865ACBFECE 0E007A49956DB6EF8251FADDB106C649250FD5E5EEE9E875C88F62EACF3473D4 is in this case).