From: Justus Ranvier <justusranvier@riseup•net>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Date: Thu, 06 Nov 2014 16:48:54 -0600 [thread overview]
Message-ID: <545BFAD6.1000504@riseup.net> (raw)
In-Reply-To: <CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1678 bytes --]
On 11/06/2014 04:11 PM, Jeff Garzik wrote:
> 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.
Yes, there are risks, but those risks could be managed with appropriate
effort. Major players could publicly commit to a set of ground rules vis
a vis what categories of changes are and are not acceptable.
Maybe at some point there could even be something that resembles project
management for the Bitcoin protocol.
Why not schedule protocol upgrades every two years for the foreseeable
future?
Spend one year achieving broad consensus regarding what changes to make
in the next upgrade, then spend one year in feature freeze (all future
proposals postponed for the next cycle) then execute the upgrade.
The top priority should be fixing bugs that make specifying and
re-implementing the protocol nearly impossible. Those kinds of changes
should have little difficulty achieving near-unanimous consensus.
There shouldn't be any problems separating obviously-needed changes from
the ones that let third parties blacklist coins, or a majority of miners
vote to confiscate block rewards from minority, tamper with the issuance
schedule, etc.
--
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
[-- Attachment #1.2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14265 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2014-11-06 22:49 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 [this message]
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
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=545BFAD6.1000504@riseup.net \
--to=justusranvier@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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