From: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Thu, 25 Jun 2015 21:05:40 +0100 [thread overview]
Message-ID: <CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]
On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <mark@friedenbach•org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented.
>
There is no process for handling hard forks, which aren't bug fixes.
Soft forks have a defined process of something like
- BIP proposal + discussion
- Proposed code
- Dev acceptance
- Release
- Miner vote/acceptance
The devs have a weak veto. If they refuse to move forward with changes,
miners could perform a soft fork on their own. They don't want to do that,
as it would be controversial and the devs know the software better.
The miner veto is stronger (for soft forks) but not absolute. The devs
could checkpoint/blacklist a chain if miners implemented a fork that wasn't
acceptable (assuming the community backed them).
When ASICs arrived, it was pointed out by some that the devs could hit back
if ASICs weren't made publicly available. If they slightly tweaked the
hashing algorithm, then current generation of ASICs would be useless. The
potential threat may have acted as a disincentive for ASIC manufacturers to
use the ASICs themselves.
Moving forward with agreement between all involved is the recommended and
desirable approach.
Consensus between all parties is the goal but isn't absolutely required.
This escape valve is partly what makes consensus work. If you dig your
heels in, then the other side can bypass you, but they have an incentive to
try to convince you to compromise first. The outcome is better if a middle
ground can be found.
Hard forks are different. The "checks and balances" of weak vetoes are not
present. This means that things can devolve from consensus to mutual
veto. Consensus ceases to be a goal and becomes a requirement.
This is partly a reflection of the nature of hard forks. Everyone needs to
upgrade. On the other hand, if most of the various groups upgrade, then
users of the legacy software would have to upgrade or get left behind. If
5% of the users decided not to upgrade, should they be allowed to demand
that nobody else does?
There is clearly some kind of threshold that is reasonable.
The fundamental problem is that there isn't agreement on what the block
size is. Is it equal in status to the 21 million BTC limit?
If Satoshi had said that 1MB was part of the definition of Bitcoin, then I
think people would accept it to the same extent as they accept the 21
million coin limit. It might cause people to leave the coin though.
It was intended to be temporary, but people have realized that it might be
a good idea to keep it. In effect both sides could argue that they should
be considered the status quo.
I wonder if a coin toss would be acceptable :). "Come to an agreement or
we decide by coin toss"
[-- Attachment #2: Type: text/html, Size: 3632 bytes --]
next prev parent reply other threads:[~2015-06-25 20:05 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 23:41 Raystonn
2015-06-24 23:49 ` Jeff Garzik
2015-06-25 0:11 ` Bryan Bishop
2015-06-25 0:21 ` Milly Bitcoin
2015-06-25 0:07 ` Milly Bitcoin
2015-06-25 1:50 ` Mark Friedenbach
2015-06-25 2:30 ` Alex Morcos
2015-06-25 2:34 ` Milly Bitcoin
2015-06-25 5:07 ` Jeff Garzik
2015-06-25 5:41 ` Milly Bitcoin
2015-06-25 6:06 ` Pindar Wong
2015-06-25 6:15 ` Mark Friedenbach
2015-06-25 6:16 ` Warren Togami Jr.
2015-06-25 6:27 ` Pindar Wong
2015-06-25 7:51 ` cipher anthem
2015-06-25 10:09 ` nxtchg
2015-06-25 12:42 ` Milly Bitcoin
2015-06-25 20:05 ` Tier Nolan [this message]
2015-06-26 0:42 ` Milly Bitcoin
2015-07-01 22:34 ` odinn
2015-06-25 3:42 ` Gareth Williams
2015-06-25 4:10 ` Milly Bitcoin
2015-06-25 13:36 ` s7r
2015-06-25 13:41 ` Eric Lombrozo
2015-06-25 13:51 ` s7r
2015-06-25 14:08 ` Milly Bitcoin
2015-06-25 17:03 ` Jeff Garzik
2015-06-25 17:29 ` Milly Bitcoin
2015-06-25 0:18 Raystonn
2015-06-25 3:00 Raystonn
2015-06-25 3:19 ` Milly Bitcoin
2015-06-26 11:13 ` Jorge Timón
2015-06-26 12:34 ` Milly Bitcoin
2015-06-27 11:28 ` Jorge Timón
2015-06-27 12:50 ` Milly Bitcoin
2015-06-28 12:30 ` Jorge Timón
2015-06-28 13:13 ` Milly Bitcoin
2015-06-28 15:35 ` Jorge Timón
2015-06-28 16:23 ` Milly Bitcoin
2015-06-28 19:05 ` Patrick Murck
2015-06-28 20:10 ` Milly Bitcoin
2015-06-28 20:16 ` Mark Friedenbach
2015-06-28 20:26 ` Ricardo Filipe
2015-06-28 21:00 ` Adam Back
2015-06-29 0:13 ` Milly Bitcoin
2015-06-29 0:23 ` Andrew Lapp
2015-06-29 1:11 ` Milly Bitcoin
2015-06-28 23:52 ` Milly Bitcoin
2015-06-28 20:21 ` NxtChg
2015-06-25 19:03 ` Tom Harding
2015-06-25 3:53 Raystonn
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='CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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