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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
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
Precedence: list

--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&#39;t have an associated block version number increase - that&#39;=
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&#39;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&#39;m somehow an idiot for bringing it up. You&#39;ve done =
that on the pull request and now here, it gives me a headache. Instead of m=
aking hand-waving references to &quot;stuff on IRC ages ago&quot;, explain =
why it&#39;s better to keep these nodes in some fantasy world where they th=
ink they&#39;re fully validating but are actually not.</div></div></div></d=
iv>

--089e0139fcda6095680504986732--