From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XaOun-0005Md-Sg for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 12:58:25 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.172 as permitted sender) client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f172.google.com; Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XaOum-00006l-UY for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 12:58:25 +0000 Received: by mail-ob0-f172.google.com with SMTP id wo20so2080282obc.17 for ; Sat, 04 Oct 2014 05:58:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.39.5 with SMTP id l5mr13730585oek.23.1412427499473; Sat, 04 Oct 2014 05:58:19 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.69.135 with HTTP; Sat, 4 Oct 2014 05:58:19 -0700 (PDT) In-Reply-To: <20141004003850.GA23202@muck> References: <20141001130826.GM28710@savin.petertodd.org> <1987325.zKPNeYyO8K@crushinator> <201410031750.27323.luke@dashjr.org> <20141004003850.GA23202@muck> Date: Sat, 4 Oct 2014 14:58:19 +0200 X-Google-Sender-Auth: l7W742sjYIKsMjbP9zSRzu05h7A Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=089e0139fcda6095680504986732 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 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation 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: 1XaOum-00006l-UY Cc: Bitcoin Dev , Flavien Charlon Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time 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: Sat, 04 Oct 2014 12:58:26 -0000 --089e0139fcda6095680504986732 Content-Type: text/plain; charset=UTF-8 > > Anyway the stuff Mike is saying about being able to detect upgrades is > incorrect - detecting an upgrade is *easier* with a soft-fork, just look > at the block header nVersion numbers and warn the user if they increase > beyond what you know is valid. Bitcoin Core implements this IIRC, and > bitcoinj should. > Nobody said hard forks shouldn't have an associated block version number increase - that's a straw man. They should! The difference is only whether older clients are presented with data they would refuse to accept thus ensuring they don't accept the new version blocks. Meanwhile, what I said *is* correct. New version numbers result in only a log print. Being hard forked off results in both log prints *and* the -alertnotify being run: it's noisier, and if the user followed the instructions printed to the console when there is no config file present, he/she should also get an email or some other kind of more meaningful alert. Finally, please stop trying to imply that all this is settled and I'm somehow an idiot for bringing it up. You've done that on the pull request and now here, it gives me a headache. Instead of making hand-waving references to "stuff on IRC ages ago", explain why it's better to keep these nodes in some fantasy world where they think they're fully validating but are actually not. --089e0139fcda6095680504986732 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Anyway the stuff Mike is saying about being able= to detect upgrades is
incorrect - detecting an upgrade is *easier* with a soft-fork, just look at the block header nVersion numbers and warn the user if they increase
beyond what you know is valid. Bitcoin Core implements this IIRC, and
bitcoinj should.

Nobody said hard forks= shouldn't have an associated block version number increase - that'= s a straw man. They should! The difference is only whether older clients ar= e presented with data they would refuse to accept thus ensuring they don= 9;t accept the new version blocks.

Meanwhile, what= I said is=C2=A0correct. New version numbers result in only a log pr= int. Being hard forked off results in both log prints and=C2=A0the -= alertnotify being run: it's noisier, and if the user followed the instr= uctions printed to the console when there is no config file present, he/she= should also get an email or some other kind of more meaningful alert.
=C2=A0
Finally, please stop trying to imply that all this i= s settled and I'm somehow an idiot for bringing it up. You've done = that on the pull request and now here, it gives me a headache. Instead of m= aking hand-waving references to "stuff on IRC ages ago", explain = why it's better to keep these nodes in some fantasy world where they th= ink they're fully validating but are actually not.
--089e0139fcda6095680504986732--