Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
	<9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
	<526B45DB.2030200@jerviss.org>
	<CABsx9T2OMA_u=S9yUh2j78QDuCDUorYctktuixjwAjqc6neW=Q@mail.gmail.com>
	<526DD18A.7060201@jerviss.org> <l4lajm$3ga$1@ger.gmane.org>
	<CAAS2fgSuL4f9Sdg2CyK-EuCKK04gD98zHDoKFyTg_Fp_cNiz=A@mail.gmail.com>
	<CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
	<CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com>
	<20131029101452.GA15808@savin>
	<7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com>
Date: Tue, 29 Oct 2013 13:32:27 +0100
Message-ID: <CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2275ecea7d204e9e0688a
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
Precedence: list

--001a11c2275ecea7d204e9e0688a
Content-Type: text/plain; charset=UTF-8

Yes, exactly. That's the point. As you well know I think the whole
soft-fork mechanism is wrong and should not be used. If the rules change,
your node is *supposed* to end up on a chain fork and trigger an alert to
you, that's pretty much the whole purpose of Bitcoin's design. Undermining
that security model is problematic.


On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete@petertodd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> Peter Todd <pete@petertodd.org> wrote:
> >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
> >> For block 0x11 again shall there be a separate code for "block is
> >from the
> >> future"? We don't want to lose the nVersion field to people just
> >using it
> >> for nonsense, so does it make sense to reject blocks that claim to be
> >v2 or
> >> v3?
> >
> >That would prevent us from using nVersion as a soft-forking mechanism.
>
> Actually, that statement didn't go far enough: rejecting blocks with
> nVersions that you don't expect is a hard fork.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.0.9
>
> iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+
> 5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL
> BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U
> uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO
> 99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE
> UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4
> 44xU
> =OaON
> -----END PGP SIGNATURE-----
>
>

--001a11c2275ecea7d204e9e0688a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, exactly. That&#39;s the point. As you well know I thi=
nk the whole soft-fork mechanism is wrong and should not be used. If the ru=
les change, your node is *supposed* to end up on a chain fork and trigger a=
n alert to you, that&#39;s pretty much the whole purpose of Bitcoin&#39;s d=
esign. Undermining that security model is problematic.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 2=
9, 2013 at 12:38 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pet=
e@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class=3D"im"><br>
<br>
<br>
Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>=
&gt; wrote:<br>
&gt;On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:<br>
&gt;&gt; For block 0x11 again shall there be a separate code for &quot;bloc=
k is<br>
&gt;from the<br>
&gt;&gt; future&quot;? We don&#39;t want to lose the nVersion field to peop=
le just<br>
&gt;using it<br>
&gt;&gt; for nonsense, so does it make sense to reject blocks that claim to=
 be<br>
&gt;v2 or<br>
&gt;&gt; v3?<br>
&gt;<br>
&gt;That would prevent us from using nVersion as a soft-forking mechanism.<=
br>
<br>
</div>Actually, that statement didn&#39;t go far enough: rejecting blocks w=
ith nVersions that you don&#39;t expect is a hard fork.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: APG v1.0.9<br>
<br>
iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+<br>
5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL<br>
BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U<br>
uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO<br>
99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE<br>
UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4<br>
44xU<br>
=3DOaON<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div>

--001a11c2275ecea7d204e9e0688a--