From: Matt Corallo <lf-lists@mattcorallo•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
Date: Thu, 7 Mar 2019 19:44:23 +0000 [thread overview]
Message-ID: <73b04e70-33aa-076c-a3a5-a658a01876c5@mattcorallo.com> (raw)
In-Reply-To: <201903071044.34985.luke@dashjr.org>
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.
next prev parent reply other threads:[~2019-03-07 19:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 21:39 Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
2019-03-07 19:44 ` Matt Corallo [this message]
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 19:50 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-08 18:35 ` Matt Corallo
2019-03-09 18:29 ` Russell O'Connor
2019-03-10 3:25 ` Jacob Eliosoff
2019-03-11 17:49 ` Russell O'Connor
2019-03-12 21:08 ` Matt Corallo
2019-03-12 22:39 ` Jacob Eliosoff
2019-03-13 0:54 ` Gregory Maxwell
2019-03-13 1:34 ` Russell O'Connor
2019-03-08 19:12 ` Sjors Provoost
2019-03-08 20:14 ` Matt Corallo
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 ` Moral Agent
2019-03-12 7:34 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 ` Dustin Dettmer
2019-03-11 19:15 ` Russell O'Connor
2019-03-12 2:23 ` Matt Corallo
2019-03-13 1:38 ` Russell O'Connor
2019-03-09 18:29 ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-03-10 15:22 ` Russell O'Connor
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2019-03-07 19:57 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-13 1:34 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73b04e70-33aa-076c-a3a5-a658a01876c5@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox