From: Peter Todd <pete@petertodd•org>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Date: Thu, 6 Nov 2014 18:19:50 -0500 [thread overview]
Message-ID: <20141106231949.GB26859@savin.petertodd.org> (raw)
In-Reply-To: <CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2014-11-06 23:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 21:32 Peter Todd
2014-11-06 21:58 ` Tamas Blummer
2014-11-06 22:05 ` Matt Corallo
2014-11-06 22:11 ` Jeff Garzik
2014-11-06 22:48 ` Justus Ranvier
2014-11-06 23:26 ` Peter Todd
2014-11-06 23:36 ` Justus Ranvier
2014-11-07 0:03 ` Peter Todd
2014-11-07 8:07 ` Tamas Blummer
2014-11-07 8:48 ` Peter Todd
2014-11-07 11:30 ` Clément Elbaz
2014-11-07 11:47 ` Peter Todd
2014-11-07 12:01 ` Wladimir
2014-11-07 16:52 ` Mike Hearn
2014-11-15 4:43 ` Jean-Pierre Rupp
2014-11-06 23:19 ` Peter Todd [this message]
2014-11-06 23:12 ` Peter Todd
2014-11-07 2:04 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141106231949.GB26859@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox