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 ) 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 ; 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> <526DD18A.7060201@jerviss.org> <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: From: Mike Hearn To: Peter Todd 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 , Andreas Schildbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > Peter Todd 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
Yes, exactly. That'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's pretty much the whole purpose of Bitcoin's d= esign. Undermining that security model is problematic.


On Tue, Oct 2= 9, 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 "bloc= k is
>from the
>> future"? We don't want to lose the nVersion field to peop= le 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.<= br>
Actually, that statement didn't go far enough: rejecting blocks w= ith 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
=3DOaON
-----END PGP SIGNATURE-----


--001a11c2275ecea7d204e9e0688a--