Published on: 2012-07-24T08:22:25+00:00
The writer of the email argues that using nonces to increase scalability in pools may have long-term consequences. They suggest upgrading the pool or encouraging users to migrate to p2pool as a more sustainable solution. The writer questions whether a powerful server-class machine can keep up with work generation for BitForce SC devices and emphasizes the need for powerful machines to run a node eventually.Peter suggests having more nonce space with less merkle calculation to ease the workload on the pool server. This would involve reducing the number of unique transaction/coinbase sets that need to be held onto for checking old work when a solution is returned. Mike questions the necessity of more nonce bits, wondering if it is a workaround for a performance bottleneck elsewhere.In response, Peter provides details on the amount of nonce required and proposed changes for version 2 blocks. These changes would include adding the block height to the coinbase and a 1-byte version number with a 3-byte extranonce. The email also includes contact information for Peter Vessenes, CEO of CoinLab.The context discusses the need for additional nonce bits in the Bitcoin block header. The author calculates that 7 bytes of nonce would be required, equivalent to 72 petahashes or 72,000 terahashes. However, the author questions the necessity of adding more nonce bits. They wonder if a multi-core CPU can handle the merkle root re-calculation while keeping an ASIC miner fed, or if there is another performance bottleneck that needs to be addressed.On July 23, 2012, Gavin Andresen proposed bumping the coinbase transaction version number to 2 instead of the block version. However, this would require every new block to compute the percentage of the last 1,000 blocks that support the new version. There may be a problem if aggressively pruning spent transactions starts. Luke-Jr suggested using the block version as an extra nonce, which could be used by ASIC miners running at 1 TH/s per rig before the end of 2012. Jeff noticed that block 190192 has version==2 without a valid block height in the coinbase, but since it's in a part of the chain with zero other version==2 blocks, the height-in-the-coinbase rule will not be enforced.The proposal to increase the block version number to 2 is related to the coinbase transaction, not the block itself. The issue with bumping the coinbase transaction version is that it requires computing the percentage of the last 1,000 blocks that support the new version during the rollout. This can be done by storing the last 1,000 coinbases in memory or fetching them from disk. However, this may become a problem if spent transactions are aggressively pruned and the coinbase from 900 blocks back gets spent and pruned.An alternative proposal is to use the block version number as an extra nonce to accommodate the increasing number of ASIC miners. This can be done by giving 3 of the 4 block version bytes as a simple extranonce. The changes for version 2 blocks would include having the height in the coinbase and a 1-byte version number with a 3-byte extranonce. There was also an issue raised regarding block 190192 having version==2 without a valid block height in the coinbase. It was suspected that this may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. However, the rules state that the height-in-the-coinbase rule will only be enforced when the chain has a super-majority, and since block 190192 is in a part of the chain with zero other version==2 blocks, the rule will not be enforced.It has been suggested that the block version number could be used as an "extra nonce" due to the anticipated increase in ASIC miners. The proposal is to use the block version for this purpose. While the current block height in coinbase addition proposes using block version 2, the protocol change is to the coinbase transaction itself. Therefore, it has been suggested to bump the coinbase transaction version number to 2 instead. There is also an issue with block 190192 having a version of 2 without a valid block height in the coinbase, which may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. To address this, an exception would be required if the version==2 marker is used, and moving the version==2 to the coinbase transaction version would allow whoever makes the transaction to set the version number instead of it coming from bitcoind and the coinbase transaction coming from P2Pool or other software.
Updated on: 2023-08-01T03:48:43.547829+00:00