Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
Replies inline. On 3/7/19 10:44 AM, Luke Dashjr wrote: On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote: I'd like to ask the BIP editor to assign a BIP number. Needs a Backward Compatibility section, and should have a bips repo PR opened after discussion on the ML. Oops, I guess most of the "Discussion" section can just be moved into a "Backwards Compatibility" section. Will do before PR'ing. * The 4th change (making non-standard signature hash types invalid) may be worth discussing. In order to limit the number of potential signature hashes which could be used per-input (allowing us to cache them to avoid re-calculation), we can disable non-standard sighash types. Alternatively, however, most of the same effect could be achieved by caching the just-before-the-last-byte sighash midstate and hashing only the last byte when a checking signatures. Still, them having been non-standard for many years makes me doubt there is much risk involved in disabling them, and I don't see much potential use-case for keeping them around so I'd like to just remove them. I don't understand what is being removed here. This refers to the following spec change: If the sighash type byte (ie last byte in a signature being evaluated during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY]) is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script execution fails. This does not apply to 0-length signature stack elements. As for why the timewarp vulnerability should (IMO rather obviously) be fixed, it seems rather clear that the only potential use for exploiting it would be either to inflate the currency supply maliciously by miners or to fork in what amounts to extension blocks. As for why extension blocks are almost certainly not the right approach to such changes, its likely worth reading this old post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510 .html While I agree that extension blocks are typically a bad choice, I'm not sure the argument really applies to forward blocks. (That being said, I find forward blocks overcomplicated and probably not a reason to avoid this.) I agree they are somewhat separate ideas, but the arguments in that thread apply equally to timewarp-based inter-block-time reductions. If you want to discuss it further, I'd suggest a new thread. * Transactions smaller than 65 bytes when serialized without witness data are invalid. Rationale should include the reason(s) why the size doesn't count the witness here. Will add. ** Note that miners today only enforce increasing timestamps against the median-timestamp-of-last-11-blocks, so miners who do not upgrade may mine a block which violates this rule at the beginning of a difficulty window if the last block in a difficulty window has a timestamp in the future. Thus, it is strongly recommended that SPV clients enforce the new nTime rules to avoid following any potential forks which occur. This should probably be moved outside Discussion. (Perhaps to the missing Backward Compatibility section?) * There are several early-stage proposals which may affect the execution of scripts, including proposals such as Schnorr signatures, Taproot, Graftroot, and MAST. These proposals are not expected to have any interaction with the changes in this BIP, as they are likely to only apply to SegWit scripts, which are not covered by any of the new rules except for the sighash type byte rule. Thus, the sighash type byte rule defined above only applies to *current* signature-checking opcodes, as any new signature-checking is likely to be implemented via the introduction of new opcodes. It's not clear that new opcodes will necessarily always be used. Probably would be good to clarify the "non-Segwit or witness v0 only" rule in the Specification section. Note that you inherently have to use a new opcode for such things - the non-standard type bytes *are* defined and define a sighash/signature, they can't be simply redefined to a new sighash/signature type in a soft fork. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote: > I'd like to ask the BIP editor to assign a BIP number. Needs a Backward Compatibility section, and should have a bips repo PR opened after discussion on the ML. > * The 4th change (making non-standard signature hash types invalid) > may be worth discussing. In order to limit the number of potential > signature hashes which could be used per-input (allowing us to cache > them to avoid re-calculation), we can disable non-standard sighash > types. Alternatively, however, most of the same effect could be achieved > by caching the just-before-the-last-byte sighash midstate and hashing > only the last byte when a checking signatures. Still, them having been > non-standard for many years makes me doubt there is much risk involved > in disabling them, and I don't see much potential use-case for keeping > them around so I'd like to just remove them. I don't understand what is being removed here. > As for why the timewarp vulnerability should (IMO rather obviously) be > fixed, it seems rather clear that the only potential use for exploiting > it would be either to inflate the currency supply maliciously by miners > or to fork in what amounts to extension blocks. As for why extension > blocks are almost certainly not the right approach to such changes, its > likely worth reading this old post: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510 >.html While I agree that extension blocks are typically a bad choice, I'm not sure the argument really applies to forward blocks. (That being said, I find forward blocks overcomplicated and probably not a reason to avoid this.) > * Transactions smaller than 65 bytes when serialized without witness > data are invalid. Rationale should include the reason(s) why the size doesn't count the witness here. > ** Note that miners today only enforce increasing timestamps against the > median-timestamp-of-last-11-blocks, so miners who do not upgrade may > mine a block which violates this rule at the beginning of a difficulty > window if the last block in a difficulty window has a timestamp in the > future. Thus, it is strongly recommended that SPV clients enforce the > new nTime rules to avoid following any potential forks which occur. This should probably be moved outside Discussion. (Perhaps to the missing Backward Compatibility section?) > * There are several early-stage proposals which may affect the execution > of scripts, including proposals such as Schnorr signatures, Taproot, > Graftroot, and MAST. These proposals are not expected to have any > interaction with the changes in this BIP, as they are likely to only > apply to SegWit scripts, which are not covered by any of the new rules > except for the sighash type byte rule. Thus, the sighash type byte rule > defined above only applies to *current* signature-checking opcodes, as > any new signature-checking is likely to be implemented via the > introduction of new opcodes. It's not clear that new opcodes will necessarily always be used. Probably would be good to clarify the "non-Segwit or witness v0 only" rule in the Specification section. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
The following is a proposed BIP to soft-fork out some oddities in the current Bitcoin consensus rules, resolving several vulnerabilities, in addition to fixing the timewarp vulnerability. I'd like to ask the BIP editor to assign a BIP number. The latest version of the BIP can be found at https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-.mediawiki (a text copy is included below). Some things that may be worth discussing: * Note that the activation times in this BIP may result in the activation of the new soft-fork rules on the same block as the scheduled block-subsidy halving. Sadly, avoiding this either requires a significantly compressed BIP activation time (which may result in the rules not activating for benign reasons) or beginning the activation process significantly into the future. * The BIP proposes allowing timestamps on the difficulty-adjustment block to go backwards by 600 seconds which has the nice property of making the difficulty-adjustment algorithm target almost exactly one block per 600 seconds in the worst-case (where miners are attempting to exploit the timewarp attack), while avoiding any potential hardware bricking (assuming upgrades on the part of mining pools). Alternatively, some have proposed allowing the time to go backwards 7200 seconds, which introduces some small level of inflation in the case of a miner attack (though much less than we've had historically simply due to the rapidly growing hashrate) but avoids any requirements for upgrades as the existing 7200-second-in-the-future check implies miners will only ever build on blocks for which they can set the next timestamp to their current time. * The 4th change (making non-standard signature hash types invalid) may be worth discussing. In order to limit the number of potential signature hashes which could be used per-input (allowing us to cache them to avoid re-calculation), we can disable non-standard sighash types. Alternatively, however, most of the same effect could be achieved by caching the just-before-the-last-byte sighash midstate and hashing only the last byte when a checking signatures. Still, them having been non-standard for many years makes me doubt there is much risk involved in disabling them, and I don't see much potential use-case for keeping them around so I'd like to just remove them. As for why the timewarp vulnerability should (IMO rather obviously) be fixed, it seems rather clear that the only potential use for exploiting it would be either to inflate the currency supply maliciously by miners or to fork in what amounts to extension blocks. As for why extension blocks are almost certainly not the right approach to such changes, its likely worth reading this old post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510.html BIP: Layer: Consensus (soft fork) Title: The Great Consensus Cleanup Author: Matt Corallo Status: Draft Type: Standards Track Created: 2019-01-28 License: PD ==Abstract== This BIP defines a set of consensus changes which reduce the complexity of Bitcoin implementations and improve worst-case validation times, fixing a number of long-standing vulnerabilities. ==Motivation== BIP 143 significantly improved certain aspects of Bitcoin's consensus rules, key to this being changes to the format of the data which is hashed and signed in CHECKSIG operations during script execution. However, several improvements were left for later forks to avoid bloating the original activation with unrelated changes. This BIP seeks to make some of these changes as well as a few other simplifications. Specifically, this BIP proposes the following changes: * Worst-case validation time for non-BIP 143 transactions has long been considered a significant vulnerability. To address this, both OP_CODESEPARATOR in non-BIP 143 scripts and FindAndDelete fail script validation, among other cleanups. This drastically reduces worst-case validation time for non-BIP 143 transactions by enabling Signature Hash caching on a per-input basis. While validation time of large, simple non-BIP 143 transactions can still be excessively high on their own, removing these multipliers goes a long way towards resolving the issue. * By further restricting nTime fields on difficulty adjustment blocks, we propose fixing the long-standing "timewarp" inflation vulnerability in Bitcoin's difficulty adjustment without risking existing mining hardware becoming unusable. This limits the worst-case difficulty adjustment target in case of attack from the current exponential growth, to once every roughly 600 seconds. Note that no change in default behavior is proposed, keeping the existing target of one block every ~600.6 seconds[1] in the common case (ie we limit the attack scenario to about a 0.1% inflation rate, much smaller than the historical inflation rate due to rapid hashrate growth). * Several vulnerabilities
