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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1XaOun-0005Md-Sg
for bitcoin-development@lists.sourceforge.net;
Sat, 04 Oct 2014 12:58:25 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.172 as permitted sender)
client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f172.google.com;
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XaOum-00006l-UY
for bitcoin-development@lists.sourceforge.net;
Sat, 04 Oct 2014 12:58:25 +0000
Received: by mail-ob0-f172.google.com with SMTP id wo20so2080282obc.17
for <bitcoin-development@lists.sourceforge.net>;
Sat, 04 Oct 2014 05:58:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.39.5 with SMTP id l5mr13730585oek.23.1412427499473; Sat,
04 Oct 2014 05:58:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.69.135 with HTTP; Sat, 4 Oct 2014 05:58:19 -0700 (PDT)
In-Reply-To: <20141004003850.GA23202@muck>
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>
Date: Sat, 4 Oct 2014 14:58:19 +0200
X-Google-Sender-Auth: l7W742sjYIKsMjbP9zSRzu05h7A
Message-ID: <CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0139fcda6095680504986732
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
0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation
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: 1XaOum-00006l-UY
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: Sat, 04 Oct 2014 12:58:26 -0000
--089e0139fcda6095680504986732
Content-Type: text/plain; charset=UTF-8
>
> Anyway the stuff Mike is saying about being able to detect upgrades is
> incorrect - detecting an upgrade is *easier* with a soft-fork, just look
> at the block header nVersion numbers and warn the user if they increase
> beyond what you know is valid. Bitcoin Core implements this IIRC, and
> bitcoinj should.
>
Nobody said hard forks shouldn't have an associated block version number
increase - that's a straw man. They should! The difference is only whether
older clients are presented with data they would refuse to accept thus
ensuring they don't accept the new version blocks.
Meanwhile, what I said *is* correct. New version numbers result in only a
log print. Being hard forked off results in both log prints *and* the
-alertnotify being run: it's noisier, and if the user followed the
instructions printed to the console when there is no config file present,
he/she should also get an email or some other kind of more meaningful alert.
Finally, please stop trying to imply that all this is settled and I'm
somehow an idiot for bringing it up. You've done that on the pull request
and now here, it gives me a headache. Instead of making hand-waving
references to "stuff on IRC ages ago", explain why it's better to keep
these nodes in some fantasy world where they think they're fully validating
but are actually not.
--089e0139fcda6095680504986732
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Anyway the stuff Mike is saying about being able=
to detect upgrades is<br>
incorrect - detecting an upgrade is *easier* with a soft-fork, just look<br=
>
at the block header nVersion numbers and warn the user if they increase<br>
beyond what you know is valid. Bitcoin Core implements this IIRC, and<br>
bitcoinj should.<br></blockquote><div><br></div><div>Nobody said hard forks=
shouldn't have an associated block version number increase - that'=
s a straw man. They should! The difference is only whether older clients ar=
e presented with data they would refuse to accept thus ensuring they don=
9;t accept the new version blocks.</div><div><br></div><div>Meanwhile, what=
I said <b>is</b>=C2=A0correct. New version numbers result in only a log pr=
int. Being hard forked off results in both log prints <i>and</i>=C2=A0the -=
alertnotify being run: it's noisier, and if the user followed the instr=
uctions printed to the console when there is no config file present, he/she=
should also get an email or some other kind of more meaningful alert.</div=
><div>=C2=A0</div><div>Finally, please stop trying to imply that all this i=
s settled and I'm somehow an idiot for bringing it up. You've done =
that on the pull request and now here, it gives me a headache. Instead of m=
aking hand-waving references to "stuff on IRC ages ago", explain =
why it's better to keep these nodes in some fantasy world where they th=
ink they're fully validating but are actually not.</div></div></div></d=
iv>
--089e0139fcda6095680504986732--
|
