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
|
Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2CA89CC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Mar 2019 22:39:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com
[209.85.166.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6EDF829
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Mar 2019 22:39:41 +0000 (UTC)
Received: by mail-io1-f45.google.com with SMTP id x3so3587613ior.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Mar 2019 15:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=I/TIwsJ1t0mR9LCUdLNkAsOco86Yaof7cS4aqa/bbYI=;
b=K+Yqsd8IfIrsC8hqyfyuk9z5A0R8rYeIWN6HO4LY2VfYN3VnO4scAfL8bv+ejgOczO
w11gKvxOKYmfQReGkZ+iWSUZSZVNPWzmFbOUdGfpgla0+SlVVPuMyQ0VJIzQlDR8dgD+
xd/kmDcPJd3ZI5g2+JRMXlvOttdr0LU3qS74cFEKj1k5BqJed/XdXCsDWMlDScenUwng
qBu79yDEfxGpthbVXOxj+EbjvIpcj+tjN0nJulPR1Z878M/2bx/92hXpgilLh9ndI8lE
+L92i5u/zmQA2nn/SdrooSwMSz619X5y4vfv933BeyVRanJd6rLsjiEE7xiKW09EMACf
7kPw==
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=I/TIwsJ1t0mR9LCUdLNkAsOco86Yaof7cS4aqa/bbYI=;
b=FJsO5S+gso1SxulffT9lk28xlsfmis3e3rVdcUEC8MdWZ0l4YKGs8ZQs5We2RvjWpp
r24+EYmfToQTmsVd0lYaKS6K/s7mNvpyCs2WS9M+2Uk4XTHlNgXwnwYZuTZhLivvRO41
oEz55jC/Z5jT9qVbbZ87aPnGRgBSezQHA4GXLIfW2MbaqXAwijLPlaUg2G1XzWcly7ye
Jxqlz7CEpBN759D7kHlR/VHGyc0q/kv1Dv9ByQEKtc972+ZIec/SZfeC4pJ0ckTX4+hR
fbD7NygRLv27xdOkvTelGZSAXn9e+mQeBozgZg8WnFaIHfkkRXyEmOYNaV9ZYra35n9I
M1YQ==
X-Gm-Message-State: APjAAAWywQHBEBIpVXD4pEGmkwhf0MPHLtSGFlDq/mhZfkq5Y7mpg5DU
wSm/r+n2zuUKhhc8Mnhi9RmsYKR09pjisAv7r7ewBQ==
X-Google-Smtp-Source: APXvYqzxGoxtzckjky7RmHrtFLKQHeJUBQmSCVC70eAHT6sZFK0SwFQLe8qLYd2EBIPwcbVmYmky5e/1S7Ds8GAHd9Q=
X-Received: by 2002:a6b:e418:: with SMTP id u24mr13251312iog.128.1552430380823;
Tue, 12 Mar 2019 15:39:40 -0700 (PDT)
MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
<CAMZUoKk3CgatSexAHRuxn3ibCYwgHpTkc0gF0yDi6hLAVcCiNA@mail.gmail.com>
<db3405ef-7e06-9538-0700-df37abaa602d@mattcorallo.com>
<CAMZUoKnK2YhucaJ-1HxH3MXeBtQZebV+h_rcS5Oq=yCMDC5u7A@mail.gmail.com>
<88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com>
In-Reply-To: <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 12 Mar 2019 18:39:28 -0400
Message-ID: <CAAUaCyixU14z-ym6s62b_BDn2c4TL9jEk-Fa7VwPeNWPm9SPbg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006339fe0583ed5d14"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Wed, 13 Mar 2019 00:41:46 +0000
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR 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: Tue, 12 Mar 2019 22:39:42 -0000
--0000000000006339fe0583ed5d14
Content-Type: text/plain; charset="UTF-8"
Also, if future disabling isn't the point of making a tx type like
OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
support of these oddball features, what do we gain by making them hard to
use/mine?
I see questions like "Is it possible someone's existing tx relies on this?"
as overly black-and-white. We all agree it's possible: the question is how
likely, vs the harms of continued support - including not just security
risks but friction on other useful changes, safety/correctness analyses,
etc.
It is so easy to say stuff like this when one's own money isn't what is at
risk.
Stepping back for a second here: I dispute this framing. My money *is* at
risk, because the value of my bitcoins depends on adoption and feature
growth. And I've long viewed an absolutist, actual-known-user-indifferent
approach to backwards compatibility as the #1 impediment to Bitcoin's
adoption and growth.
Again, the point being not to throw caution to the wind, but that a case
like this where extensive research unearthed zero users, is taking caution
too far.
On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io>
> wrote:
> > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--0000000000006339fe0583ed5d14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Also, if future disabling isn't the point of making a=
tx type like OP_CODESEPARATOR non-standard - what is?=C2=A0 If we're c=
ommitted to indefinite support of these oddball features, what do we gain b=
y making them hard to use/mine?<div dir=3D"auto"><br></div><div dir=3D"auto=
">I see questions like "Is it possible someone's existing tx relie=
s on this?" as overly black-and-white.=C2=A0 We all agree it's pos=
sible: the question is how likely, vs the harms of continued support - incl=
uding not just security risks but friction on other useful changes, safety/=
correctness analyses, etc.</div><div dir=3D"auto"><div style=3D"font-family=
:sans-serif" class=3D"elided-text" dir=3D"auto"><div dir=3D"ltr"><br><div c=
lass=3D"elided-text" dir=3D"auto"><blockquote style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"elided=
-text"><div>It is so easy to say stuff like this when one's own money i=
sn't what is at risk.</div></div></div></div></div></div></blockquote><=
/div></div></div></div><div dir=3D"auto"><br></div>Stepping back for a seco=
nd here:=C2=A0 I dispute this framing.=C2=A0 My money <i>is</i> at risk, be=
cause the value of my bitcoins depends on adoption and feature growth.=C2=
=A0 And I've long viewed an absolutist, actual-known-user-indifferent a=
pproach to backwards compatibility as the #1 impediment to Bitcoin's ad=
option and growth.<div dir=3D"auto"><br></div><div dir=3D"auto">Again, the =
point being not to throw caution to the wind, but that a case like this whe=
re extensive research unearthed zero users, is taking caution too far.<br><=
div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Mar 12, 2019, 5:48 PM Matt Corallo vi=
a bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Note that even your carve-outs for OP_NOP is not sufficie=
nt here - if you were using nSequence to tag different pre-signed transacti=
ons into categories (roughly as you suggest people may want to do with extr=
a sighash bits) then their transactions could very easily have become un-re=
alistically-spendable. The whole point of soft forks is that we invalidate =
otherwise-unused bits of the protocol. This does not seem inconsistent with=
the proposal here.<br>
<br>
> On Mar 9, 2019, at 13:29, Russell O'Connor <<a href=3D"mailto:r=
oconnor@blockstream.io" target=3D"_blank" rel=3D"noreferrer">roconnor@block=
stream.io</a>> wrote:<br>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that=
invalidated transactions that send secured inputs to secured outputs (excl=
uding uses of OP_NOP1-OP_NOP10).<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev<br></a><br>
</blockquote></div></div></div></div>
--0000000000006339fe0583ed5d14--
|
