path: root/1a/abd491db653fad9de3613406cde3807b2e95db

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Z5aBt-0005MM-OW
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 13:49:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f177.google.com; 
Received: from mail-wi0-f177.google.com ([209.85.212.177])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z5aBs-0007zs-8P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 13:49:13 +0000
Received: by wicnd19 with SMTP id nd19so23462302wic.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 18 Jun 2015 06:49:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.205.168 with SMTP id lh8mr27201478wic.95.1434635346240; 
	Thu, 18 Jun 2015 06:49:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 06:49:06 -0700 (PDT)
In-Reply-To: <CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
References: <55828737.6000007@riseup.net>
	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
	<20150618111407.GA6690@amethyst.visucore.com>
	<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
Date: Thu, 18 Jun 2015 15:49:06 +0200
X-Google-Sender-Auth: WbmxRDmsWCdQFDvYyh0BPuFjBL4
Message-ID: <CANEZrP04SUHShoqUkA3aSs3yEP3GSsZ_3ZOGFXyJfNve5KTPfA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c38ace31ec6a0518cb1226
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5aBs-0007zs-8P
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
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 13:49:13 -0000

--001a11c38ace31ec6a0518cb1226
Content-Type: text/plain; charset=UTF-8

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.

--001a11c38ace31ec6a0518cb1226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Pieter,<div><br></div><div>I believe Gavin plans to wri=
te a blog post about the hard fork process, but I&#39;d like to debate this=
 with you now, if only to give him material to work with :)</div><div><br><=
/div><div>Your points look to me like the hard/soft fork debate in differen=
t clothes.</div><div><br></div><div>For example, we all agree that the rule=
s of Bitcoin <i>can</i>=C2=A0be changed, and have been before (e.g. P2SH), =
with software upgrades.</div><div><br></div><div>When such a fork happens, =
any user who does not upgrade their node isn&#39;t fully verifying the bloc=
k chain anymore. Their software might <i>think</i>=C2=A0it is, but it&#39;s=
 running NOPs that don&#39;t mean NOP to other nodes. So there is a diverge=
nce in the consensus, it&#39;s merely been done in such a way that the node=
 won&#39;t stop and print &quot;hard fork detected&quot; to the logs. It&#3=
9;ll happily accept a block that violates the new rules, then wait to be co=
rrected by miners.</div><div><br></div><div>So with any fork, hard or soft,=
 there is risk to those who don&#39;t upgrade. They may accept a block, or =
even two blocks, that they believe are valid according to their old rule se=
t, but which other miners would reject. The effect on double spending is mu=
ch the same.</div><div><br></div><div>Now let&#39;s talk philosophy.</div><=
div><br></div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><div>* Philosophy: Bitcoin is not a democracy.</di=
v></div></div></div></blockquote><div><br></div><div>This appears to be a k=
ey point of dispute. Bitcoin is a democracy, though the analogy is not perf=
ect. You can certainly believe whatever you like about the true state of th=
e ledger, but rubber hits the road the moment you go and trade with other p=
eople.</div><div><br></div><div>If 90% of the people you trade with believe=
 a coin exists, and you don&#39;t, you&#39;re gonna discover you keep getti=
ng paid with that coin and its descendents. You may hate it, you may feel y=
our rights are being violated, you may refuse to trade with those people bu=
t it will keep happening.</div><div><br></div><div>Money is about trade, an=
d trade inherently involves the decisions of other people. No man is an isl=
and.</div><div><br></div><div>With Bitcoin we have a great way to quickly f=
ind out what other people believe about the ledger. If the vast majority of=
 people are on ledger A and you&#39;re on ledger B, then you&#39;ve got a s=
trong incentive to come into line with the majority in order to keep tradin=
g.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Changing the rules=
 should be possible if there is wide consensus, but nobody should feel forc=
ed to change their code against their will.<br></div></div></div></div></bl=
ockquote><div><br></div><div>Nobody, not even after a hard fork, is <i>forc=
ed</i>=C2=A0to change their code against their will. It may be something th=
at <i>other people require</i>=C2=A0as part of trading with them though. Wh=
ether one considers this &quot;forced&quot; or not I guess can be argued ei=
ther way. Are you &quot;forced&quot; 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?</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>* Governance: being able to push for a controversial=
 change to the system sets an incredibly dangerous precedent about who is i=
n charge of the system&#39;s rules. </div></div></div></div></blockquote><d=
iv><br></div><div>I think it&#39;s surely the opposite - <i>not</i>=C2=A0be=
ing able to push for controversial changes sets an incredibly dangerous pre=
cedent. Namely, whoever gets to decide that a change is controversial gets =
to veto anything they like!</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div>I can promise you that I will say anything in mail to this list if s=
omeone points a gun at me<br></div></div></div></div></blockquote><div><br>=
</div><div>Indeed, me too! But it&#39;s worse than that: what if someone so=
ckpuppets a discussion to make it look like a change does or does not have =
consensus?</div><div><br></div><div>One reason I keep banging on about <i>p=
rocess</i>=C2=A0and how Wladimir needs to be The Decider is that the curren=
t attempt at &quot;process&quot; is so vague, not only is it unexplainable,=
 but it&#39;s wide open to manipulation.</div><div><br></div><div>Good thin=
g we have a way to resolve this problem: =C2=A0the block chain. Now it does=
n&#39;t matter if someone points a gun at you or me. We can object to whate=
ver we like and that wouldn&#39;t bring Bitcoin to a halt, thus removing th=
e incentive to try and pressure individuals.</div><div><br></div><div>But i=
f we don&#39;t have that ability to vote through choice of software and rul=
esets, then us poor developers really are in charge and that&#39;s not a pl=
ace any of us should want to go. There must be a mechanism for people to di=
sagree with the consensus, even in major, controversial ways, and that mech=
anism must have real force to it.</div></div></div></div></div>

--001a11c38ace31ec6a0518cb1226--