public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
Date: Thu, 7 Mar 2019 19:57:29 +0000	[thread overview]
Message-ID: <eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com> (raw)
In-Reply-To: <CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>

I can't say I'm particularly married to this idea (hence the alternate 
proposal in the original email), but at the same time the lack of 
existing transactions using these bits (and the redundancy thereof - 
they don't *do* anything special) seems to be pretty strong indication 
that they are not in use. One could argue a similarity between these 
bits and OP_NOPs - no one is going to create transactions that require 
OP_NOP execution to be valid as they are precisely the kind of thing 
that may get soft-forked to have a new meaning. While the sighash bits 
are somewhat less candidates for soft-forking, I don't think "someone 
may have shoved random bits into parts of their 
locked-for-more-than-a-year transactions" is sufficient reason to not 
soft-fork something out. Obviously, actually *seeing* it used in 
practice or trying to fork them out in a fast manner would be 
unacceptable, but neither is being proposed here.

Matt

On 3/7/19 3:16 PM, Russell O'Connor wrote:
> 
>     * 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.
> 
> 
> The sighash type byte is a "great" place to store a few bits of 
> ancillary data when making signatures.  Okay it isn't great, but it is 
> good enough that some misguided users may have been using it and have 
> unbroadcast transactions in cold storage (think sweeps) for UTXOs whose 
> private keys may have been lost.  I don't think that one's hunch that 
> there isn't much risk in disabling these sighashes is good enough to put 
> people funds at risk, especially given the alternative proposal of 
> caching the just-before-the-last-byte sighash midstate that is available.


  reply	other threads:[~2019-03-07 19:57 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
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 [this message]
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=eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.io \
    /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