Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VbR59-0005lL-7j for bitcoin-development@lists.sourceforge.net; Wed, 30 Oct 2013 08:24:51 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VbR58-0006bP-Ef for bitcoin-development@lists.sourceforge.net; Wed, 30 Oct 2013 08:24:51 +0000 Received: by mail-oa0-f43.google.com with SMTP id m1so1115218oag.30 for ; Wed, 30 Oct 2013 01:24:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.68.135 with SMTP id w7mr3301002oet.9.1383121484869; Wed, 30 Oct 2013 01:24:44 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Wed, 30 Oct 2013 01:24:44 -0700 (PDT) In-Reply-To: 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: Wed, 30 Oct 2013 09:24:44 +0100 X-Google-Sender-Auth: qIsJdxPoaeHkHExe1Ql2rumhgX8 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a1134c4c2c979bd04e9f110d1 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 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: 1VbR58-0006bP-Ef 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: Wed, 30 Oct 2013 08:24:51 -0000 --001a1134c4c2c979bd04e9f110d1 Content-Type: text/plain; charset=UTF-8 > But if you are getting soft-forked recent versions of the reference > implementation WILL alert you; see this code in main.cpp: > Perhaps I'm confused about how we're using the term soft fork. My understanding is that this is where a new upgrade is designed to look valid to old nodes, and if you don't upgrade you rely on the miner majority to get you "back on track". For instance, P2SH was done this way - old nodes that didn't upgrade during that transition believed all spends of P2SH outputs were valid, even those spending someone elses coins. In this case, the code you cite won't do anything because your client will never reject a block during a soft-forking upgrade, even if it does something that's supposed to be invalid or nonsensical. If a new block version changes the serialization format or script language or SIGHASH rules such that old clients reject the block, then they will end up on a hard fork and the alerting code will trigger, which is correct and as it should be. --001a1134c4c2c979bd04e9f110d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
=
But if you are getting soft-forked recent versions of the reference im= plementation WILL alert you; see this code in main.cpp:

Perhaps I'm confused about how we&= #39;re using the term soft fork. My understanding is that this is where a n= ew upgrade is designed to look valid to old nodes, and if you don't upg= rade you rely on the miner majority to get you "back on track". F= or instance, P2SH was done this way - old nodes that didn't upgrade dur= ing that transition believed all spends of P2SH outputs were valid, even th= ose spending someone elses coins.

In this case, the code you cite won't do anything b= ecause your client will never reject a block during a soft-forking upgrade,= even if it does something that's supposed to be invalid or nonsensical= .

If a new block version changes the serialization format= or script language or SIGHASH rules such that old clients reject the block= , then they will end up on a hard fork and the alerting code will trigger, = which is correct and as it should be.
--001a1134c4c2c979bd04e9f110d1--