Published on: 2019-03-07T19:44:23+00:00
In an email exchange between Luke Dashjr and Matt Corallo, Matt requested the assignment of a BIP number for a proposed soft fork to improve Bitcoin's security. Luke suggested including a Backward Compatibility section and opening a bips repo PR after discussion on the ML. One of the proposed changes is making non-standard signature hash types invalid to limit the potential signature hashes used per-input and improve caching efficiency. Additionally, caching the just-before-the-last-byte sighash midstate and hashing only the last byte when checking signatures was suggested.Luke sought clarity on what exactly was being removed with regards to the spec change. He emphasized the importance of fixing the timewarp vulnerability, which could be exploited by miners to inflate the currency supply maliciously or create extension blocks through forking. Although extension blocks are generally discouraged, the arguments in favor of timewarp-based inter-block-time reductions also apply to extension blocks.The proposal states that transactions smaller than 65 bytes without witness data will now be considered invalid, and the rationale for this change will explain why the size doesn't count the witness. It is strongly recommended that SPV clients enforce the new nTime rules to avoid following potential forks since miners currently only enforce increasing timestamps against the median-timestamp-of-last-11-blocks.The proposal acknowledges that several early-stage proposals, such as Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP as they are likely to only apply to SegWit scripts. The defined sighash type byte rule only applies to current signature-checking opcodes, as any new signature-checking is expected to be implemented through the introduction of new opcodes.Matt Corallo requested a BIP number for a proposed soft fork to enhance Bitcoin's security in a message on the Bitcoin Development mailing list. The proposal includes changes like making non-standard signature hash types invalid and enforcing strict rules on transaction timestamps to prevent time-warp attacks. It also notes that early-stage proposals such as Schnorr signatures, Taproot, Graftroot, and MAST are not expected to interact with the changes in this BIP. A Backward Compatibility section is needed, and a bips repo PR should be opened after discussion on the ML. The proposal recommends SPV clients enforce the new nTime rules to avoid following potential forks.The Great Consensus Cleanup is a Bitcoin Improvement Proposal (BIP) aiming to simplify Bitcoin implementations, improve validation times, and address various vulnerabilities. The proposal suggests allowing timestamps on difficulty-adjustment blocks to go backwards by 600 seconds, fixing the long-standing "timewarp" inflation vulnerability without rendering existing mining hardware unusable. It also proposes making certain transaction sizes invalid to resolve vulnerabilities related to malleation in merkle tree construction.The BIP will be deployed using "version bits" BIP9 with the name "cleanups," using bit 3 as the activation signal, with different start times for mainnet and testnet. However, it may result in the activation of the new soft-fork rules coinciding with the scheduled block-subsidy halving. The BIP author argues that fixing the timewarp vulnerability is crucial because exploiting it could lead to malicious inflation of the currency supply by miners or forking through extension blocks, which is not an ideal approach.Bitcoin Improvement Proposal 118 (BIP 118) proposes the activation of Taproot, a new address format and signature scheme aimed at improving privacy and flexibility of Bitcoin transactions. The proposal suggests using BIP 141 (Segregated Witness) and BIP 143 (Transaction Signature Verification for Version 0 Witness Program) as activation methods. It also includes changes like reducing valid scriptSigs to the minimal set of operations generating any stack state, disabling non-canonical sighash types, and allowing nTime to go backward by 600 seconds to prevent attacks and simplify analysis.The proposal mentions that several early-stage proposals, including Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP, except for the sighash type byte rule. The authors recommend implementing BIP 9 to ensure miner upgrade prior to activation and express gratitude to various individuals for their helpful feedback and the entire Bitcoin Protocol Development Community.The reference implementation for the proposal can be found on Github at Bitcoin Core Pull #15482. The proposal provides references to other resources, including the difficulty adjustment algorithm in Bitcoin, the issues related to leaf nodes in the transaction merkle tree, and official stratum specifications.
Updated on: 2023-08-02T00:35:59.132988+00:00