Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	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 1Vb8TJ-0007NN-UZ
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 Oct 2013 12:32:33 +0000
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; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Vb8TJ-0002ji-0g
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 Oct 2013 12:32:33 +0000
Received: by mail-ob0-f175.google.com with SMTP id wm4so5057618obc.20
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.34.194 with SMTP id b2mr18769158obj.41.1383049947159;
	Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
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
X-Google-Sender-Auth: m1VxsYQkVWa_sB_VUcpBjD6im4s
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
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 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: petertodd.org]
	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: 1Vb8TJ-0002ji-0g
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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, 29 Oct 2013 12:32:34 -0000

--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--