From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 15:49:06 +0200 [thread overview]
Message-ID: <CANEZrP04SUHShoqUkA3aSs3yEP3GSsZ_3ZOGFXyJfNve5KTPfA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]
Hi Pieter,
I believe Gavin plans to write a blog post about the hard fork process, but
I'd like to debate this with you now, if only to give him material to work
with :)
Your points look to me like the hard/soft fork debate in different clothes.
For example, we all agree that the rules of Bitcoin *can* be changed, and
have been before (e.g. P2SH), with software upgrades.
When such a fork happens, any user who does not upgrade their node isn't
fully verifying the block chain anymore. Their software might *think* it
is, but it's running NOPs that don't mean NOP to other nodes. So there is a
divergence in the consensus, it's merely been done in such a way that the
node won't stop and print "hard fork detected" to the logs. It'll happily
accept a block that violates the new rules, then wait to be corrected by
miners.
So with any fork, hard or soft, there is risk to those who don't upgrade.
They may accept a block, or even two blocks, that they believe are valid
according to their old rule set, but which other miners would reject. The
effect on double spending is much the same.
Now let's talk philosophy.
* Philosophy: Bitcoin is not a democracy.
>
This appears to be a key point of dispute. Bitcoin is a democracy, though
the analogy is not perfect. You can certainly believe whatever you like
about the true state of the ledger, but rubber hits the road the moment you
go and trade with other people.
If 90% of the people you trade with believe a coin exists, and you don't,
you're gonna discover you keep getting paid with that coin and its
descendents. You may hate it, you may feel your rights are being violated,
you may refuse to trade with those people but it will keep happening.
Money is about trade, and trade inherently involves the decisions of other
people. No man is an island.
With Bitcoin we have a great way to quickly find out what other people
believe about the ledger. If the vast majority of people are on ledger A
and you're on ledger B, then you've got a strong incentive to come into
line with the majority in order to keep trading.
> Changing the rules should be possible if there is wide consensus, but
> nobody should feel forced to change their code against their will.
>
Nobody, not even after a hard fork, is *forced* to change their code
against their will. It may be something that *other people require* as part
of trading with them though. Whether one considers this "forced" or not I
guess can be argued either way. Are you "forced" to buy oranges from the
single orange seller in town if the other goes bankrupt, or could you just
avoid oranges? Where does economic freedom begin and end?
> * Governance: being able to push for a controversial change to the system
> sets an incredibly dangerous precedent about who is in charge of the
> system's rules.
>
I think it's surely the opposite - *not* being able to push for
controversial changes sets an incredibly dangerous precedent. Namely,
whoever gets to decide that a change is controversial gets to veto anything
they like!
> I can promise you that I will say anything in mail to this list if someone
> points a gun at me
>
Indeed, me too! But it's worse than that: what if someone sockpuppets a
discussion to make it look like a change does or does not have consensus?
One reason I keep banging on about *process* and how Wladimir needs to be
The Decider is that the current attempt at "process" is so vague, not only
is it unexplainable, but it's wide open to manipulation.
Good thing we have a way to resolve this problem: the block chain. Now it
doesn't matter if someone points a gun at you or me. We can object to
whatever we like and that wouldn't bring Bitcoin to a halt, thus removing
the incentive to try and pressure individuals.
But if we don't have that ability to vote through choice of software and
rulesets, then us poor developers really are in charge and that's not a
place any of us should want to go. There must be a mechanism for people to
disagree with the consensus, even in major, controversial ways, and that
mechanism must have real force to it.
[-- Attachment #2: Type: text/html, Size: 5604 bytes --]
next prev parent reply other threads:[~2015-06-18 13:49 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn [this message]
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
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=CANEZrP04SUHShoqUkA3aSs3yEP3GSsZ_3ZOGFXyJfNve5KTPfA@mail.gmail.com \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=pieter.wuille@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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