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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
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 781C2C7B7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:44:26 +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 C94323F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:44:25 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id B309F12035A;
Thu, 7 Mar 2019 19:44:23 +0000 (UTC)
To: Luke Dashjr <luke@dashjr.org>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<201903071044.34985.luke@dashjr.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <73b04e70-33aa-076c-a3a5-a658a01876c5@mattcorallo.com>
Date: Thu, 7 Mar 2019 19:44:23 +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: <201903071044.34985.luke@dashjr.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] 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:44:26 -0000
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.
|
