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'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.</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"><<a href=3D"mailto:pet= e@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></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 <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>= > wrote:<br> >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:<br> >> For block 0x11 again shall there be a separate code for "bloc= k is<br> >from the<br> >> future"? We don't want to lose the nVersion field to peop= le just<br> >using it<br> >> for nonsense, so does it make sense to reject blocks that claim to= be<br> >v2 or<br> >> v3?<br> ><br> >That would prevent us from using nVersion as a soft-forking mechanism.<= br> <br> </div>Actually, that statement didn't go far enough: rejecting blocks w= ith nVersions that you don'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--