From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VbCGH-00043D-5y for bitcoin-development@lists.sourceforge.net; Tue, 29 Oct 2013 16:35:21 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.55 as permitted sender) client-ip=62.13.149.55; envelope-from=pete@petertodd.org; helo=outmail149055.authsmtp.co.uk; Received: from outmail149055.authsmtp.co.uk ([62.13.149.55]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VbCGE-0005t0-UE for bitcoin-development@lists.sourceforge.net; Tue, 29 Oct 2013 16:35:21 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id r9TGZCnF010851; Tue, 29 Oct 2013 16:35:12 GMT Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r9TGZ6DD056510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Oct 2013 16:35:10 GMT Date: Tue, 29 Oct 2013 12:35:05 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20131029163505.GA28320@petertodd.org> References: <526B45DB.2030200@jerviss.org> <526DD18A.7060201@jerviss.org> <20131029101452.GA15808@savin> <7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 14472d7a-40b8-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAsUF1YAAgsB AmUbWlJeU1h7WGM7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxVl cXQYJm1ycgNDeX4+ Z0JkVnAVXUB+ckQp RR9JEW1UbXphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOTh0 XBcMAXAhGlcGXG06 KRBuKlcGEAMfNV8x KjMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 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] X-Headers-End: 1VbCGE-0005t0-UE Cc: Bitcoin Development , Andreas Schildbach Subject: Re: [Bitcoin-development] On soft-forks and hard-forks 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 16:35:21 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd wrote: > > 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. > > 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. That's a nice sentiment, but there's a lot more nuance to it than "soft-forks are bad" We're talking about rejection here: you don't want to end up on an isolated chain fork wondering if maybe miners have been unlucky. You want to know that a longer chain exists so as to have solid evidence that you're local configuration isn't what miners are mining. Thus not only should you "accept" blocks with versions you don't know about, you should relay those blocks as well so that other out-of-date nodes have the highest possible chance of finding out about them. Creating a block is expensive, so with some minor safeguards - a high minimum difficulty, and maximum size - relaying blocks you consider invalid is perfectly safe and doesn't enable DoS attacks. Relaying block headers has similar logic, and even less DoS attack worry. (don't apply bloom filters to invalid blocks though!) I had this discussion with Warren the other day actually: Litecoin is considering banning old node versions and rejecting their attempts to connect. I pointed out how you wanted to be damn sure there was no-one mining with them, least you wind up creating a slowly growing fork mined by nodes unaware of the main chain. Soft-forks and SPV nodes is another topic. SPV nodes don't do any meaningful validation - they usually don't even have the transaction inputs spent by a transaction to determine if a scriptSig is valid. Their security is already dependent on miners, so allowing those miners to upgrade does no harm. In addition there are even cases where what would be a hard-fork for a full node, is a soft-fork for a SPV node. On the other hand if your "SPV" node is more sophisticated, then by all means use a nVersion change to trigger an alert to the user. If you're implementation relays blockchain data, continue doing so to ensure other nodes find out about the new version as soon as possible. (all SPV nodes should relay block headers if possible) Note how the nVersion field is useful for voting: the "chain height in coinbase" soft-fork was accomplished this way, changing nVersion from 1 to 2 with full enforcement of the rule triggered by a 95% supermajority. Bitcoin is a decentralized system, so any changes need to be done by voting to show that a clear consensus of hashing power will enforce and validate the new rules. (time and height deadlines can be disasters if the upgrade is ever ignored or delayed) Interestingly this suggests that what we actually want is two nVersions per upgrade: the first to signal that nodes wish to upgrade, and are showing their intent to use the new rules. The second to signal that the upgrade has actually happened and the old rules are now ignored. Client software can use this two stage approach to know when rules may have changed, and the user probably should consider upgrading. As applied to the chain height upgrade we would have gone from version 2 during the voting, to version 3 for any block produced while the rules were in effect. Put another way, the last in nVersion is simply to signify that the new blockchain rules are now active, as opposed to being proposed. --=20 'peter'[:-1]@petertodd.org 000000000000000180dabf823b09a30b4f2032b5cab7ba1d0351cab350bee91f --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSb+O5AAoJEBmcgzuo5/CFSFMIALH6Ouh20Dj0e4hpKvY/MF7I 3ZKfRslfVmyw6ak03D1FD1yPPknbfqwavzA8zpIGlfxmXvT6OP803MsoLA+78Tks pP1Stpj3r/bKCGYSmfXrX2QwClgjkwJ0QgATLThDg3ZDWCk4oxzYUhiUYWE85hxE qQeL7Sfn+GYtCcTARQQzRxGCZLnrmu7lZcSNR5dO556oJjE33TUH08qMrCJpcNF0 tT7gxfTkGc86ZMUzGguddfIKBzh5HoQaSNJv/knQMAcwxFFxoZs+UAJeu0RDHNA6 MZapymKcLfRvREJDWloojBGOCbmwLKd2Q8oyn4nYT7u6Tw7Dwh4I6zyxIn/wwp4= =DZRm -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--