Published on: 2016-02-10T05:16:56+00:00
Bitcoin developer Matt Corallo has proposed changes to increase the extranonce space in mining, which would allow for more transaction data in the blockchain. He suggests passing a mask of nonce bytes to ASICs and rearranging the block to include additional nonce space. However, these changes are incompatible with Luke-Jr's soft-hardfork approach. Corallo also recommends making merge-mining easier and splitting the proof of work between miners and pool operators to reduce hard forks visible to lightweight clients.The Bitcoin community is discussing increasing the extranonce space to simplify mining control and move complexity back into Bitcoin Core. The proposal includes adding nonce space in the first compression function and increasing the minimum difficulty. However, some believe this adds unnecessary complexity. These changes would enable greater ASIC speeds and increased dynamic extranonce space.In an email thread, Corallo proposes increasing the extranonce space available for ASICs by setting a maximum number of bytes. Changing the minimum difficulty to six 0-bytes would reserve more space for extranonce rolling. Luke agrees with the proposal and sees no reason not to increase the minimum difficulty at the same time.The discussion also explores potential changes to Bitcoin mining hardware to reduce required logic. Suggestions include allowing the first four bytes of the previous block hash field to contain any value, which could optimize brute forcing the SHA256 midstate. However, there are concerns about strong incentives to use the version field as nonce space. Another suggestion is using leading non-zero bytes of the prevhash as additional nonce. The author concludes that closer examination of midstate optimization is necessary.A hard fork proposal is being discussed in the context of segwit. The proposal includes changing the segregated witness discount from 75% to 50%, setting the block size limit to 1.5MB, and allowing for a maximum block size of 3MB with a "network-upgraded" block size of roughly 2.1MB. The aim is to decrease the worst-case scenario while keeping the total size in line with network capacity. The proposal also addresses cost and validation concerns by limiting non-segwit inputs and potentially implementing a per-transaction limit for MAX_BLOCK_SIGOPS. Additionally, it suggests allowing any value in the first four bytes of the previous block hash field to make hardware production more competitive.To prevent significant cost blowups in transaction validation, there are restrictions on non-segwit inputs. However, this move has raised concerns about disrupting services and invalidating time-locked transactions. Other limitations, such as scriptPubKeys being limited to 100 bytes and no OP_CODESEPARATOR allowed, have also raised concerns regarding native multisig.In another email thread, Corallo proposes a hard fork outline in the context of segwit. The segregated witness discount would be changed from 75% to 50%, and the block size limit set to 1.5MB. This would result in a maximum block size of 3MB and a "network-upgraded" block size of roughly 2.1MB. Additional limits would be placed on the size of non-segwit transactions, and the first four bytes of the previous block hash field could contain any value. The proposal aims to balance efficient block space usage, low fees, and network security.The author argues that Bitcoin scaling is not an emergency and highlights mining centralization and privacy as more pressing concerns. They suggest a hard fork could be used to enforce decentralized mining pools and express concern about rising transaction fees. They provide links for further information on what constitutes a qualifying emergency and suggestions for addressing mining centralization.In a separate discussion, Simon Liu questions the rationale for offering a discount from segregated witness. Peter Todd responds that UTXO set space is more expensive for the network, leading to the discount. He emphasizes the need to consider engineering decisions and proposes a miner vote threshold for hard forks.The segregated witness discount has been changed from 75% to 50%, and the block size limit set at 1.5MB, resulting in a maximum block size of 3MB. The purpose is to offer a discount on script data while maintaining a limited maximum block size. The rationale for the discount and specific boundary limits are unclear. These changes aim to balance efficient block space usage, low fees, and network security.Bitcoin developers are discussing a hard fork to address mining centralization and privacy challenges. Hard forks should only occur in response to a major crisis agreed upon by all participants. The community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Technical planning is crucial to avoid risks and protect value. Suggestions include adding decentralization pressure and switching MAX_BLOCK_SIGOPS to a per-transaction limit. Hard forks must address real threats facing Bitcoin.The Bitcoin community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Implementing SegWit and planning for a safe hard fork is essential.
Updated on: 2023-08-01T17:47:24.948210+00:00