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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F34E3C04E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 15:57:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f178.google.com (mail-it1-f178.google.com
[209.85.166.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5100912E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 15:57:26 +0000 (UTC)
Received: by mail-it1-f178.google.com with SMTP id f186so6762011ita.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Mar 2019 07:57:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=wSLoXijqwqH8r63FEh2kAaSdd8rO/4szIsXz5UDLk18=;
b=nbPWpWr2hrJdMEOh5a1cMzIU2RM27QTuFI5ixnignkN4iXSKj3lqXe1QymFGG+RWxc
LN3SjnSC5salvfiGSWB/T9vVDuT1PAsbUCaEJu7OQPAcXjPPKWG6YUS+up7LZFpvc9fe
LNQpEXv+WsoyVelh199oefH2Ff6ODyD+368JI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=wSLoXijqwqH8r63FEh2kAaSdd8rO/4szIsXz5UDLk18=;
b=Fj21qxw3Pm9nqSHoEYj0BP5mAU8jaOeJA3fvyYWSIrrr+HmqqTJ3X7WNn5FuUZxVaQ
dD68I5o+yjOtWkoPUPPQ/YycgwroSd0YDrO1H/EbpZ3XVB0Q8GlvX+BHTDynhJMvcQAt
v5ApBApKOf7a5NNXd7UtQEl6JUNwnTJkBv+SchBeBxB4OXoIvC5VSwQm4o4eDkoRux7P
LkCDlcDVngurep27PmcpENnG3N4/57yU05jxqYIcUBM1exoep0DTP8lszxwgQjL/oxiV
3I8cS4N111BoW+oPZ3RfZvFp6/4znSKemQLLYwvZNSvcmpz8rmwV/DbPtzw1QvOnB5jt
ZbSw==
X-Gm-Message-State: APjAAAXmgXALsDx59WoKmzoJhYC9+EGzvf8bLLVD6D8AMYMbaul7Xvmc
qR4w9gOgTuTzXcwq3ZslfjbjjafAwPJka2gY2uIorExh
X-Google-Smtp-Source: APXvYqzpv+jWfJk6XNxsUQj6N8SUUPR5ZkEhouvwz6kQdJddwilo7wLccvv0RgU9Jxf3tKUI6xO4g/fakz6riFzb7SM=
X-Received: by 2002:a24:36c8:: with SMTP id
l191mr10285905itl.101.1552060645366;
Fri, 08 Mar 2019 07:57:25 -0800 (PST)
MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
<eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
In-Reply-To: <eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 8 Mar 2019 10:57:14 -0500
Message-ID: <CAMZUoKnrUENVwSLJd6HEprqrjmU_Em5LFL4o+UW1-nOBKADVUw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="0000000000006ff6e205839747c6"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Fri, 08 Mar 2019 18:58:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 08 Mar 2019 15:57:27 -0000
--0000000000006ff6e205839747c6
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> 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 "somewhat less candidates for soft-forking" is a fair
description. These bits essentially unsuitable for soft-forking within
legacy Script.
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.
I disagree. It is sufficient.
When was the last time Bitcoin soft-forked out working transactions that
sent funds from securely held UTXOs to securely held UTXOs (aside from
those secured by Scripts using the reserved OP_NOP1-OP_NOP10)? AFAIK it
has never occurred since the time of Satoshi, even for the most
hypothetical of transactions. It is my understanding is that Bitcoin Core
would never do such a thing unless the security of Bitcoin protocol itself
was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
Core would only soft-fork out the minimal amount necessary to safely
diffuse such a threat.
Since the above soft-fork isn't addressing addressing any such threat (that
I'm aware of), and could hypothetically destroy other people money, it
crosses a line I thought we were never supposed to cross.
>
> 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.
>
Perhaps you don't see them in used in the blockchain because the users
trying to use them are caught up by the fact they they are not being
relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
difficulty redeeming them.
You cannot first make transactions non-standard and then use the fact that
you don't see them being used to justify a soft-fork.
I know of users who have their funds tied up due to other changes in
Bitcoin Core's default relay policy. I believe they waiting for their
funds to become valuable enough to go through the trouble of having them
directly mined. Shall we now permanently destroy their funds too, before
they have a chance to get their transactions mined?
--0000000000006ff6e205839747c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 7, 2019 at 2:57 PM Mat=
t Corallo <<a href=3D"mailto:lf-lists@mattcorallo.com" target=3D"_blank"=
>lf-lists@mattcorallo.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">I can't say I'm particularly married to th=
is idea (hence the alternate <br>
proposal in the original email), but at the same time the lack of <br>
existing transactions using these bits (and the redundancy thereof - <br>
they don't *do* anything special) seems to be pretty strong indication =
<br>
that they are not in use. One could argue a similarity between these <br>
bits and OP_NOPs - no one is going to create transactions that require <br>
OP_NOP execution to be valid as they are precisely the kind of thing <br>
that may get soft-forked to have a new meaning. While the sighash bits <br>
are somewhat less candidates for soft-forking, </blockquote><div><br></div>=
<div>I don't think "somewhat less candidates for soft-forking"=
; is a fair=20
description.=C2=A0 These bits essentially unsuitable for soft-forking withi=
n legacy Script.<br></div><div> <br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">I don't think "someone <br>
may have shoved random bits into parts of their <br>
locked-for-more-than-a-year transactions" is sufficient reason to not =
<br>
soft-fork something out.</blockquote><div><br></div><div>I disagree. It is =
sufficient.</div><div><br></div><div>When was the last time Bitcoin soft-fo=
rked out working transactions that sent funds from securely held UTXOs to s=
ecurely held UTXOs (aside from those secured by Scripts using the reserved =
OP_NOP1-OP_NOP10)?=C2=A0 AFAIK it has never occurred since the time of Sato=
shi, even for the most hypothetical of transactions.=C2=A0 It is my underst=
anding is that Bitcoin Core would never do such a thing unless the security=
of Bitcoin protocol itself was under existential threat (see OP_CODESEPARA=
TOR) and even then Bitcoin Core would only soft-fork out the minimal amount=
necessary to safely diffuse such a threat.</div><div><br></div><div>Since =
the above soft-fork isn't addressing addressing any such threat (that I=
'm aware of), and could hypothetically destroy other people money, it c=
rosses a line I thought we were never supposed to cross.</div>=C2=A0<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"> Obviously, actually *seeing* it=
used in <br>
practice or trying to fork them out in a fast manner would be <br>
unacceptable, but neither is being proposed here.<br>
</blockquote><div><br></div><div>Perhaps you don't see them in used in =
the blockchain=20
because the users trying to use them are caught up by the fact they they
are not being relayed by default (violating SCRIPT_VERIFY_STRICTENC) and a=
re having difficulty redeeming them.</div><div>You cannot first make transa=
ctions non-standard and then use the fact that you don't see them being=
used to justify a soft-fork.</div><div><br></div><div>I know of users who =
have their funds tied up due to other changes in Bitcoin Core's default=
relay policy.=C2=A0 I believe they waiting for their funds to become valua=
ble enough to go through the trouble of having them directly mined.=C2=A0 S=
hall we now permanently destroy their funds too, before they have a chance =
to get their transactions mined?<br></div><div><br></div></div></div></div>=
</div>
--0000000000006ff6e205839747c6--
|
