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; 
Date: Thu, 6 Nov 2014 18:19:50 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20141106231949.GB26859@savin.petertodd.org>
References: <20141106213215.GA12918@savin.petertodd.org>
	<A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
	<545BF0C2.3030201@bluematt.me>
	<CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
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: <CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The difficulty of writing consensus
 critical code: the SIGHASH_SINGLE bug
Precedence: list


--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--