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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XbXJH-0008BI-3a
for bitcoin-development@lists.sourceforge.net;
Tue, 07 Oct 2014 16:08:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.173 as permitted sender)
client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f173.google.com;
Received: from mail-ob0-f173.google.com ([209.85.214.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XbXJF-0005J7-Pl
for bitcoin-development@lists.sourceforge.net;
Tue, 07 Oct 2014 16:08:23 +0000
Received: by mail-ob0-f173.google.com with SMTP id wp4so5891119obc.18
for <bitcoin-development@lists.sourceforge.net>;
Tue, 07 Oct 2014 09:08:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.232.229 with SMTP id tr5mr4407705obc.83.1412698093321;
Tue, 07 Oct 2014 09:08:13 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.105 with HTTP; Tue, 7 Oct 2014 09:08:13 -0700 (PDT)
In-Reply-To: <CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
<CABbpET8_FMCcnh0dELnHsYmF+YP05Gz=nZ3SPkLZuqXYV3JUpQ@mail.gmail.com>
<1987325.zKPNeYyO8K@crushinator>
<201410031750.27323.luke@dashjr.org>
<CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
<CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com>
<20141004003850.GA23202@muck>
<CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com>
<CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
Date: Tue, 7 Oct 2014 18:08:13 +0200
X-Google-Sender-Auth: wry7TjGAT3x9QOrp9ZrDTBbTHfI
Message-ID: <CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c32f940702da0504d7689f
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XbXJF-0005J7-Pl
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Flavien Charlon <flavien.charlon@coinprism.com>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
a txout from being spent until an expiration time
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 16:08:23 -0000
--001a11c32f940702da0504d7689f
Content-Type: text/plain; charset=UTF-8
>
> That is easy to change; I'll submit a pull request.
>
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for future rule changes, it helps more.
It would be good if getblocktemplate was updated at the same time to serve
errors if the fork warning is active. I'd hope miners have some way to
automatically handle IBD/getting forked off the chain, but I guess some
(newer) pools might not, and refusing to serve work should be the safest
option that shuts them down.
I don't have any opinion on the hard- versus soft- fork debate. I think
> either can work.
>
P2SH was a soft fork and the sky did not fall, but miners did lose money
and waste electricity mining blocks on the wrong side of the chain:
https://bitcointalk.org/index.php?topic=75294.0
Presumably they didn't notice for longer because it looked like a run of
unusually bad orphaning luck. It seems safer to have a clean fork, with
alerts telling people during the lockin period before new rule enforcement
starts (and possibly automated termination if there's no upgrade by the
flag day?). Miners who ignore it would still risk losing money, but
merchants who wait for a block at least would not be at risk.
One open question is how can you actually trigger a hard fork? Coinbase
scriptSigs are not executed, so putting some ignored but failing opcode
sequence there wouldn't work. One possibility would be to have a special
invalid tx in the block that marks the start of new rule enforcement. New
nodes would know to ignore it. But this risks corrupting block explorers.
Alternatively the coinbase outpoint structure could have its hash set to 1
instead of 0.
--001a11c32f940702da0504d7689f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div>That is easy to change; I'll submit a pull request. </div=
></div></div></div></blockquote><div><br></div><div>That's certainly a =
useful improvement. It won't help the existing userbase though - assumi=
ng CHECKLOCKTIMEVERIFY is to go in to the next major release. If there'=
s going to be an intermediate release (6 months?) which lays the groundwork=
for future rule changes, it helps more.<br></div><div><br></div><div>It wo=
uld be good if getblocktemplate was updated at the same time to serve error=
s if the fork warning is active. I'd hope miners have some way to autom=
atically handle IBD/getting forked off the chain, but I guess some (newer) =
pools might not, and refusing to serve work should be the safest option tha=
t shuts them down.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"font-=
family:arial,sans-serif;font-size:12.7272720336914px">I don't have any =
opinion on the hard- versus soft- fork debate. I think either can work.</di=
v><div class=3D"" style=3D"font-family:arial,sans-serif;font-size:12.727272=
0336914px"></div></blockquote><div>=C2=A0</div><div>P2SH was a soft fork an=
d the sky did not fall, but miners did lose money and waste electricity min=
ing blocks on the wrong side of the chain:</div><div><br></div><div><a href=
=3D"https://bitcointalk.org/index.php?topic=3D75294.0">https://bitcointalk.=
org/index.php?topic=3D75294.0</a><br></div><div><br></div><div>Presumably t=
hey didn't notice for longer because it looked like a run of unusually =
bad orphaning luck. It seems safer to have a clean fork, with alerts tellin=
g people during the lockin period before new rule enforcement starts (and p=
ossibly automated termination if there's no upgrade by the flag day?). =
Miners who ignore it would still risk losing money, but merchants who wait =
for a block at least would not be at risk.</div><div><br></div><div>One ope=
n question is how can you actually trigger a hard fork? Coinbase scriptSigs=
are not executed, so putting some ignored but failing opcode sequence ther=
e wouldn't work. One possibility would be to have a special invalid tx =
in the block that marks the start of new rule enforcement. New nodes would =
know to ignore it. But this risks corrupting block explorers. Alternatively=
the coinbase outpoint structure could have its hash set to 1 instead of 0.=
</div></div></div></div>
--001a11c32f940702da0504d7689f--
|
