public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
Date: Thu, 7 Mar 2019 10:44:34 +0000	[thread overview]
Message-ID: <201903071044.34985.luke@dashjr.org> (raw)
In-Reply-To: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>

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


  reply	other threads:[~2019-03-07 10:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 ` Luke Dashjr [this message]
2019-03-07 19:44   ` Matt Corallo
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=201903071044.34985.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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