1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2B2DC7A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:57:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56EC55E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:57:31 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id 0316112035A;
Thu, 7 Mar 2019 19:57:29 +0000 (UTC)
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
Date: Thu, 7 Mar 2019 19:57:29 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 07 Mar 2019 23:48:02 +0000
Subject: Re: [bitcoin-dev] Sighash Type Byte;
Re: BIP Proposal: The Great Consensus Cleanup
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 19:57:31 -0000
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.
|
