Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote:
> IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.
> 
> 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...

-- 
'peter'[:-1]@petertodd.org
00000000000000000094d543907eaf0f94f4ff5f4c760b3552d84ff811cd9053

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]