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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XmWLO-0004Dg-Vq for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 23:19:59 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.101 as permitted sender) client-ip=62.13.149.101; envelope-from=pete@petertodd.org; helo=outmail149101.authsmtp.com; Received: from outmail149101.authsmtp.com ([62.13.149.101]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XmWLN-0006ng-S5 for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 23:19:58 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA6NJom1070477; Thu, 6 Nov 2014 23:19:50 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA6NJj6H061883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 23:19:48 GMT Date: Thu, 6 Nov 2014 18:19:50 -0500 From: Peter Todd To: Jeff Garzik Message-ID: <20141106231949.GB26859@savin.petertodd.org> References: <20141106213215.GA12918@savin.petertodd.org> <545BF0C2.3030201@bluematt.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 671e6d3e-660b-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUFloCAgsB AmIbWVdeUVR7XWs7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm0H eGREVGFycQROcH0+ ZEJhV3YVWkN7IEAp QRtJE2sGN3phaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DxwDEzsuFlABWzR7 KBJuNUQdAEcXPQ05 Nl06VFQDLgRwQgZE Hl1MCyZdb1IGSyd5 RR9aUAYlMRJ9aBx8 NSYJBDBsL3RYRyUw X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/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 X-Headers-End: 1XmWLN-0006ng-S5 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug 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: Thu, 06 Nov 2014 23:19:59 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote: > IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. >=20 > RE soft fork vs. hard fork: It's about this time at Mike Hearn will > chime in, on the side of hard forks. Hard forks are in a sense much > cleaner, and permit solving problems not otherwise solvable with a > hard fork. However, hard forks clearly have risks, notably the Big > Risk akin to a US Constitutional Convention: once you open the door, > anything can happen, any rule no matter how "sacred" can be changed. I think people in this community often miss the serious political and legal ramifications of hard-forks. Being in the social position of being able to succesfully pull off hard-forks, particularly for new features, is clear evidence that you have de-facto control over the system. Regulators around the world appear to be going in directions that would make that control subject to regulation and licensing, e.g. the European Banking Association proposals, and initial Bitlicense proposals. Equally, look how hard-forks - known as flag days elsewhere - are generally considered to be dangerous and worth avoiding in other contexts due to simple engineering reasons. It's just easier to upgrade systems in backward compatible ways, especially when they incorporate features specifically to make that possible. (as does bitcoin!) > Soft forks are not without their own risks, e.g. reducing some things > to SPV levels of security. This is a misconception; you can't prevent soft-forks from happening, so you always have an SPV level of security by that standard. People put *way* too much trust in small numbers of confirmations... --=20 'peter'[:-1]@petertodd.org 00000000000000000094d543907eaf0f94f4ff5f4c760b3552d84ff811cd9053 --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUXAISXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwOGYyMjkwOTI0YTY4ODI5MjhkNDU2NmY0ODdmMzNjYzU3 MjAzYTY1MzU3OTUyMDEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfumhAf/XQUzXi8Bp9QnTroek3kaNbSM DwzN2Q/JqJ2jw+RnwLAfAcbkrVUwtEHDa0u/v4w1dbnrOAWAwR96ut6MdbtSt+6j 97pk9C+c1Rhx6U7sP1Yf0EgyU0HTmnij0aSdZ7LklyGARXZHT0pH4hIgkfoYUE0m ykj07KrPlh+RlVU1NSbmOX0y/Uzwj5E+EQuvL3UueaaQvg1GgWJKwMJBS3Ae6PB8 8veTinn1cExGe8UAn/bD9wKpzeGCL+Js/J3N8uEy6G23jBNb16lxaQpL4EjEL3+u bK0l8oMA3ZdrjufgHcxccs+jbdbQSILfZtxqv57j+Doo7E71cVaDi02rLdTtRA== =TDDV -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig--