From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 88FAA826 for ; Fri, 2 Dec 2016 04:18:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2D3751B5 for ; Fri, 2 Dec 2016 04:18:55 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 4940538AB8E3; Fri, 2 Dec 2016 04:18:24 +0000 (UTC) X-Hashcash: 1:25:161202:bitcoin-dev@lists.linuxfoundation.org::6yM9Un/SIlsHY9Ox:cnkF9 X-Hashcash: 1:25:161202:jtimon@jtimon.cc::XAxKj7z9IgSOunW/:aJ99T X-Hashcash: 1:25:161202:jl2012@xbt.hk::lRlEBfivrWHE9yz1:c0le From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Jorge =?iso-8859-1?q?Tim=F3n?= Date: Fri, 2 Dec 2016 04:18:21 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.31-gentoo; KDE/4.14.24; x86_64; ; ) References: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201612020418.23011.luke@dashjr.org> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] New BIP: Hardfork warning system X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:18:55 -0000 On Friday, December 02, 2016 1:42:46 AM Jorge Tim=F3n via bitcoin-dev wrote: > We can already warn users of a hardfork when a block is invalid (at > least) because of the highest bit in nVersion (as you say, because it > is forbidden since bip34 was deployed). The difference is that right now, full nodes will happily follow a shorter= =20 best-valid chain. This BIP would require them to hold back at the best-comm= on=20 block between the best-valid chain and the invalid chain, forcing the user = to=20 make a decision whether to reject the invalid chain permanently, or upgrade= to=20 a version which can understand that chain as valid. > It seems the softfork serves only to warn about soft-hardforks, assuming = it > chooses to use this mechanism (which a malicious soft hardfork may not do= ). Note: a malicious "SHF" is not a SHF at all, but an "evil fork". > In fact, you could reuse another of the prohibited bits to signal a soft- > hardfork while distinguishing it from a regular hardfork. And this will a= lso > serve for old nodes that have not upgraded to the softfork. But, wait, > if you signal a soft-hardfork with an invalid bit, it's not a > soft-hardfork anymore, is it? It's simply a hardfork. Nodes implementing this BIP will see it as a simple hardfork, but will=20 intentionally provide equivalent behaviour as older nodes which see it as a= =20 soft-hardfork. In other words, all [compatible] hardforks will now behave l= ike=20 a soft-hardfork without any special DMMS design. If Bitcoin's eventual hardfork is far enough down the road (such that no no= des=20 remain from before this BIP are adopted), the SHF design could be safely do= ne=20 away with entirely. And either way, it makes it easier to resist an un- consented-to hardfork. Luke