path: root/4c/907e1dbff3b20e912e2d8256327e7036629a7f

Return-Path: <patrick.murck@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 01A0DAE7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 19:05:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
	[209.85.220.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5FABB12C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 19:05:22 +0000 (UTC)
Received: by pactm7 with SMTP id tm7so93344490pac.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 12:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:message-id:in-reply-to:references:subject:mime-version
	:content-type; bh=BnGzuW46oAzUn3nDJH0nJlE9y6VmlGvBsprO2e068aY=;
	b=ipee6XcdouJsnQLmHmgfarbK99n6HzMHSkS2OqLx6zbrpXMh3/cOAv9Ft/6orWPckl
	PIO87uTB99B/ovcs5R11ue5T8bayCogE8qqGsHpT6aIyjH8d0+vRFMDThAsdYC5qYzlj
	TJc6yOoIbAqoA0M33ycorJ2cyjkJRgDtuJGE4M6SOOUC1LA2ofvOgOJtWC8uNzXYuE16
	jkwe3F4aIcQ9UQD3X2MPEaHrBEwnE5xWr2zLHvW6VIp/WWSK5Z7+owDDgK4mbw8+V3NJ
	dK5UtbjYVoWS14/UfnqeMUxMXUlAgCNvt2OmtU89Sp/KUWVpUXFwtQdGaLSUCNTEO6nQ
	MAqA==
X-Received: by 10.70.52.1 with SMTP id p1mr23958119pdo.113.1435518322078;
	Sun, 28 Jun 2015 12:05:22 -0700 (PDT)
Received: from Patricks-MacBook-Pro-2.local
	([2601:602:8900:ff:792d:7217:c042:324c])
	by mx.google.com with ESMTPSA id oh4sm4151553pdb.42.2015.06.28.12.05.20
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sun, 28 Jun 2015 12:05:21 -0700 (PDT)
Date: Sun, 28 Jun 2015 12:05:04 -0700
From: Patrick Murck <patrick.murck@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org, Milly Bitcoin <milly@bitcoins.info>
Message-ID: <etPan.5590456f.61df0e2.23f7@Patricks-MacBook-Pro-2.local>
In-Reply-To: <55901F7D.4000001@bitcoins.info>
References: <COL402-EAS127289185B11D0D58E1F5E6CDAE0@phx.gbl>
	<558B7352.90708@bitcoins.info>
	<CABm2gDrCxLyxC=BkgiQOjRczy26kQOZb2+p9xDXOh4HuDG8nRw@mail.gmail.com>
	<558D46EC.6050300@bitcoins.info>
	<CABm2gDojz6PHdRKxRkMZh-gfYLdcekVfeQMz5r_4EYc-j5tn+w@mail.gmail.com>
	<558E9C06.9080901@bitcoins.info>
	<CABm2gDpTuEoaXZ_M166UEe+z6t-hq39yJaF3K+aL_Ra836jnSg@mail.gmail.com>
	<558FF307.9010606@bitcoins.info>
	<CABm2gDpHL3RUXUK_PAiPv49EcxgjBSjPBwf=4VLhW0Y28OE=FQ@mail.gmail.com>
	<55901F7D.4000001@bitcoins.info>
X-Mailer: Airmail (303)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5590456f_1bf2bd2_23f7"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2015 19:05:24 -0000

--5590456f_1bf2bd2_23f7
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Wladimir has no more or less =E2=80=9Cpower=E2=80=9D to push change to th=
e Bitcoin Core codebase than any other person with commit privileges to t=
he GitHub repo. If I=E2=80=99m not mistaken there are 7 people with commi=
t privileges and five of them are active. If Wladimir committed a change =
it could be reverted by any of the others. This is by design and ensures =
that changes will have reached some level of technical consensus before t=
hey are merged, among other things.

=46urthermore even assuming the Core Maintainer commits a change to Bitco=
in Core (that isn=E2=80=99t reverted and that gets packaged up into the n=
ext code release) that still doesn=E2=80=99t push a change to the bitcoin=
 network. There is no auto-update on Bitcoin Core so individuals and comp=
anies running Bitcoin Core software have to choose to upgrade. =46urther =
still, developers that maintain alternative implementations would have to=
 decide to merge those changes to the codebase they are indepently mainta=
ining (and their users would need to update, etc.).

I understand why it might *seem* to be the case that the Core Maintainer =
is empowered to make changes to =22teh Bitcoin=22 but the reality is that=
 the Core Maintainer role is really about cat herding and project managem=
ent of Bitcoin Core the open-source software project and not the bitcoin =
network. We=E2=80=99re lucky Wladimir has agreed to take on so much of th=
e scut work to keep the project moving forward.

The process might get ugly and inefficient but that=E2=80=99s the cost of=
 having no wizard behind the curtain.

-pm

--=C2=A0
Patrick Murck

On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly=40bitcoins.info) wro=
te:

The core maintainer has always been in control of the consensus rules. =20
Satoshi came up with the rules and put them in there. Since then any =20
changes to any part of the code go through the core maintainer. It =20
looks to me as if people are saying it somehow changed along the way =20
because they don't want to hurt people's feeling, upset up, get them to =20
quit, etc. Sure there are checks and balances and people don't have to =20
use the main code base but if they change the consensus rules they are =20
incompatible.

The notion that because people can download different rules and run them =
=20
is interesting from a theoretical perspective but that is constrained by =
=20
the network effect. I can say the US government is not the =22decider=22 =
of =20
laws because I can vote them out, recall them, challenge things in =20
court, or secede and start my own country. You can also say the =20
judge/jury in a criminal court case is not a =22decider=22 because the =20
president can always issue a pardon. But those points are generally not =20
useful in a practical sense.

The issue about the developers is the tremendous influence they have to =20
veto any changes. I don't have veto power yet I have more bitcoins than =20
garzik says he has. The whole Bitcoin software development system is =20
subject to attack from just a couple of people who have this veto =20
power. With all the crying and moaning about centralization on this =20
list I would think that would be a concern.

Russ



On 6/28/2015 11:35 AM, Jorge Tim=C3=B3n wrote:
> On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly=40bitcoins.info> =
wrote:
>> I never said something was approved by garzik added something after it=
 was
>> opposed. What I said was a proposal was made and 4 people commented on=
 the
>> Github. He then tweeted there was near universal approval before most
>> people even heard about the subject. It was not controversial but i wa=
s
>> pointing out the arrogance of some of the developers. He considers the=

>> entire universe of Bitcoin stakeholders to be a very small group of
>> insiders, not the entire universe of Bitcoin users. Another thing I ha=
ve
>> seen on Github for bitcoin.org is how some the maintainers change the =
rules
>> on the fly. Sometimes they say a proposal had no objections so it is
>> approved. Other times they say a proposal has no support so it is reje=
cted.
> Ok, I misunderstood.
> Well, the fact is that the number of capable reviewers is quite small.
> If more companies hired and trained more developers to become bitcoin
> core developers that situation could change, but that's where we are
> now.
>
>> You are also trying to say that the core developers actually have litt=
le
>> influence and are not =22deciders=22 because anyone can fork the code.=
 That has
>> already been discussed at length and such an argument is faulty becaus=
e
>> there is a constraint that your software is incompatible with everyone=
 else.
> Only if you change the consensus rules (which are, in fact, a
> relatively small part of the code).
> Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
> with the replace by fee policy, libbitcoin also changes many
> non-consensus things, there's code written in other languages...
> There's multiple counter-examples to your claim of that argument being =
faulty.
> Seriously, forking the project is just one click. You should try it
> out like at least 9627 other people have done.
> >=46rom there, you can pay your own developers (if you don't know how t=
o
> code yourself) and maybe they're also fine being insulted by you as
> part of the job.
> What you still can't do is unilaterally change the consensus rules of
> a running p2p consensus system, because you cannot force the current
> users to run any software they don't want to run.
>
>> The issue is that there is no way right now to change the consensus ru=
les
>> except to go through the core maintainer unless you get everybody on t=
he
>> network to switch to your fork. People who keep repeating that the sof=
tware
>> development is =22decentralized because you fork the code=22 without e=
xplaining
>> the constraints are just cultists.
> Please, stop the cultist crap. Maybe insulting people like that is how
> you got people to call you a troll.
> But, yes, you are right: there's no known mechanism for safely
> deploying controversial changes to the consensus rules
>
>> The discussion has nothing to do with who has the position now and I n=
ever
>> said he has =22control over the consensus rules.=22 The maintainer has=
 a very
>> large influence way beyond anyone else. As for your claim that I want
>> someone hurt because I am explaining the process, that is ridiculous. =
If
>> the Core maintainers did not have significant influence to change the
>> consensus rules then everybody would not be spending all this time lob=
bying
>> them to have them changed.
> Well, if you don't think he has control over the consensus rules we're
> advancing.
> I think that was implied from some of your previous claims. He is no
> =22decider=22 on consensus changes.
> Insisting on it can indeed get him hurt, so I'm happy that you're
> taking that back (or clarifying that really wasn't your position).
> Influence is very relative and not only core devs have =22influence=22.=

> Maybe Andreas Antonopolous has more =22influence=22 than I have because=
 he
> is a more public figure=3F
> Well, that's fine I think. I don't see the point in discussing who has
> how much influence.
>
>> The outside influences and stake of the developer is a relevant topic.=
 The
>> same types of things are discussed on this list all the time in the co=
ntext
>> of miners, users, merchants, and exchanges. Again, the developers try =
to
>> place themselves on some kind of pedestal where they are the protector=
s and
>> pure and everyone else (miners, users, merchants) are abusers, spammer=
s,
>> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made =
an
>> issue of how many bitcoins he holds and he made that issue in the same=
 place
>> where he announces many of the technical issues. It is very relevant t=
hat
>> he has a minimal stake in Bitcoin holdings yet he goes around making m=
ajor
>> decisions about Bitcoin and trying to dictate who is allowed to partic=
ipate
>> in discussions. If a core developer has minimal stake in Bitcoin yet h=
as
>> major veto power over code change that is a problem.
> Please, don't generalize. I don't think I put myself in any kind of ped=
estal.
> That is insulting to me and many others (you may not even know and
> you're insulting them).
> And I think my Bitcoin holdings are completely irrelevant when judging
> my contributions to the software: either they're good or not, and who
> I am or how many Bitcoins I have at any given time shouldn't matter.
> Again, nobody forces you to use our software, as said there's
> alternatives (including forking the project right now).
>
>> You are correct that you cannot give power to any person over the Inte=
rnet
>> which is why some kind of process needs to be developed that does not
>> involve trying to convince one person to make the changes or a system =
that
>> depends on unwritten, ever-changing rules maintained by a handful of p=
eople.
> Well, for now the process we have is seeking consensus, and although
> our definition of =22uncontroversial=22 is very vague, I think it is qu=
ite
> obvious when a proposed change is not =22uncontroversial=22 (like in th=
e
> block size debate).
> It seems to me that any other =22formal process=22 would imply
> centralization in the decision making of the consensus rules (and from
> there you only have to corrupt that centralized organization to
> destroy Bitcoin).
>


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
bitcoin-dev mailing list
bitcoin-dev=40lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--5590456f_1bf2bd2_23f7
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</=
style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust=
omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r=
gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Wladimir has no more o=
r less =E2=80=9Cpower=E2=80=9D to push change to the Bitcoin Core codebas=
e than any other person with commit privileges to the GitHub repo. If I=E2=
=80=99m not mistaken there are 7 people with commit privileges and five o=
f them are active. If Wladimir committed a change it could be reverted by=
 any of the others. This is by design and ensures that changes will have =
reached some level of technical consensus before they are merged, among o=
ther things.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-fami=
ly:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; l=
ine-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=
=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma=
rgin: 0px; line-height: auto;=22>=46urthermore even assuming the Core Mai=
ntainer commits a change to Bitcoin Core (that isn=E2=80=99t reverted and=
 that gets packaged up into the next code release) that still doesn=E2=80=
=99t push a change to the bitcoin network. There is no auto-update on Bit=
coin Core so individuals and companies running Bitcoin Core software have=
 to choose to upgrade. =46urther still, developers that maintain alternat=
ive implementations would have to decide to merge those changes to the co=
debase they are indepently maintaining (and their users would need to upd=
ate, etc.).</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-famil=
y:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; li=
ne-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=
=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma=
rgin: 0px; line-height: auto;=22>I understand why it might *seem* to be t=
he case that the Core Maintainer is empowered to make changes to =22teh B=
itcoin=22 but the reality is that the Core Maintainer role is really abou=
t cat herding and project management of Bitcoin Core the open-source soft=
ware project and not the bitcoin network. We=E2=80=99re lucky Wladimir ha=
s agreed to take on so much of the scut work to keep the project moving f=
orward.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:He=
lvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-h=
eight: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22f=
ont-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin=
: 0px; line-height: auto;=22>The process might get ugly and inefficient b=
ut that=E2=80=99s the cost of having no wizard behind the curtain.</div><=
div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;=
font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22=
><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helv=
etica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-hei=
ght: auto;=22>-pm</div> <br> <div id=3D=22bloop=5Fsign=5F1435509432272669=
184=22 class=3D=22bloop=5Fsign=22><span style=3D=22font-family:helvetica,=
arial;font-size:13px=22></span>--&nbsp;<br>Patrick Murck<br></div> <br><p=
 class=3D=22airmail=5Fon=22 style=3D=22color:=23000;=22>On June 28, 2015 =
at 9:23:47 AM, Milly Bitcoin (<a href=3D=22mailto:milly=40bitcoins.info=22=
>milly=40bitcoins.info</a>) wrote:</p> <blockquote type=3D=22cite=22 clas=
s=3D=22clean=5Fbq=22><span><div><div></div><div>The core maintainer has a=
lways been in control of the consensus rules.  <br>Satoshi came up with t=
he rules and put them in there.  Since then any <br>changes to any part o=
f the code go through the core maintainer.  It <br>looks to me as if peop=
le are saying it somehow changed along the way <br>because they don't wan=
t to hurt people's feeling, upset up, get them to <br>quit, etc. Sure the=
re are checks and balances and people don't have to <br>use the main code=
 base but if they change the consensus rules they are <br>incompatible.<b=
r><br>The notion that because people can download different rules and run=
 them <br>is interesting from a theoretical perspective but that is const=
rained by <br>the network effect.  I can say the US government is not the=
 =22decider=22 of <br>laws because I can vote them out, recall them, chal=
lenge things in <br>court, or secede and start my own country.  You can a=
lso say the <br>judge/jury in a criminal court case is not a =22decider=22=
 because the <br>president can always issue a pardon.  But those points a=
re generally not <br>useful in a practical sense.<br><br>The issue about =
the developers is the tremendous influence they have to <br>veto any chan=
ges.  I don't have veto power yet I have more bitcoins than <br>garzik sa=
ys he has.  The whole Bitcoin software development system is <br>subject =
to attack from just a couple of people who have this veto <br>power.  Wit=
h all the crying and moaning about centralization on this <br>list I woul=
d think that would be a concern.<br><br>Russ<br><br><br><br>On 6/28/2015 =
11:35 AM, Jorge Tim=C3=B3n wrote:<br>&gt; On Sun, Jun 28, 2015 at 3:13 PM=
, Milly Bitcoin &lt;milly=40bitcoins.info&gt; wrote:<br>&gt;&gt; I never =
said something was approved by garzik added something after it was<br>&gt=
;&gt; opposed.  What I said was a proposal was made and 4 people commente=
d on the<br>&gt;&gt; Github.  He then tweeted there was near universal ap=
proval before most<br>&gt;&gt; people even heard about the subject.  It w=
as not controversial but i was<br>&gt;&gt; pointing out the arrogance of =
some of the developers.  He considers the<br>&gt;&gt; entire universe of =
Bitcoin stakeholders to be a very small group of<br>&gt;&gt; insiders, no=
t the entire universe of Bitcoin users.  Another thing I have<br>&gt;&gt;=
 seen on Github for bitcoin.org is how some the maintainers change the ru=
les<br>&gt;&gt; on the fly.  Sometimes they say a proposal had no objecti=
ons so it is<br>&gt;&gt; approved.  Other times they say a proposal has n=
o support so it is rejected.<br>&gt; Ok, I misunderstood.<br>&gt; Well, t=
he fact is that the number of capable reviewers is quite small.<br>&gt; I=
f more companies hired and trained more developers to become bitcoin<br>&=
gt; core developers that situation could change, but that's where we are<=
br>&gt; now.<br>&gt;<br>&gt;&gt; You are also trying to say that the core=
 developers actually have little<br>&gt;&gt; influence and are not =22dec=
iders=22 because anyone can fork the code.  That has<br>&gt;&gt; already =
been discussed at length and such an argument is faulty because<br>&gt;&g=
t; there is a constraint that your software is incompatible with everyone=
 else.<br>&gt; Only if you change the consensus rules (which are, in fact=
, a<br>&gt; relatively small part of the code).<br>&gt; Mike mantains Bit=
coin XT and that's fine, Peter Todd maintains patches<br>&gt; with the re=
place by fee policy, libbitcoin also changes many<br>&gt; non-consensus t=
hings, there's code written in other languages...<br>&gt; There's multipl=
e counter-examples to your claim of that argument being faulty.<br>&gt; S=
eriously, forking the project is just one click. You should try it<br>&gt=
; out like at least 9627 other people have done.<br>&gt; &gt;=46rom there=
, you can pay your own developers (if you don't know how to<br>&gt; code =
yourself) and maybe they're also fine being insulted by you as<br>&gt; pa=
rt of the job.<br>&gt; What you still can't do is unilaterally change the=
 consensus rules of<br>&gt; a running p2p consensus system, because you c=
annot force the current<br>&gt; users to run any software they don't want=
 to run.<br>&gt;<br>&gt;&gt; The issue is that there is no way right now =
to change the consensus rules<br>&gt;&gt; except to go through the core m=
aintainer unless you get everybody on the<br>&gt;&gt; network to switch t=
o your fork.  People who keep repeating that the software<br>&gt;&gt; dev=
elopment is =22decentralized because you fork the code=22 without explain=
ing<br>&gt;&gt; the constraints are just cultists.<br>&gt; Please, stop t=
he cultist crap. Maybe insulting people like that is how<br>&gt; you got =
people to call you a troll.<br>&gt; But, yes, you are right: there's no k=
nown mechanism for safely<br>&gt; deploying controversial changes to the =
consensus rules<br>&gt;<br>&gt;&gt; The discussion has nothing to do with=
 who has the position now and I never<br>&gt;&gt; said he has =22control =
over the consensus rules.=22  The maintainer has a very<br>&gt;&gt; large=
 influence way beyond anyone else.  As for your claim that I want<br>&gt;=
&gt; someone hurt because I am explaining the process, that is ridiculous=
.  If<br>&gt;&gt; the Core maintainers did not have significant influence=
 to change the<br>&gt;&gt; consensus rules then everybody would not be sp=
ending all this time lobbying<br>&gt;&gt; them to have them changed.<br>&=
gt; Well, if you don't think he has control over the consensus rules we'r=
e<br>&gt; advancing.<br>&gt; I think that was implied from some of your p=
revious claims. He is no<br>&gt; =22decider=22 on consensus changes.<br>&=
gt; Insisting on it can indeed get him hurt, so I'm happy that you're<br>=
&gt; taking that back (or clarifying that really wasn't your position).<b=
r>&gt; Influence is very relative and not only core devs have =22influenc=
e=22.<br>&gt; Maybe Andreas Antonopolous has more =22influence=22 than I =
have because he<br>&gt; is a more public figure=3F<br>&gt; Well, that's f=
ine I think. I don't see the point in discussing who has<br>&gt; how much=
 influence.<br>&gt;<br>&gt;&gt; The outside influences and stake of the d=
eveloper is a relevant topic.  The<br>&gt;&gt; same types of things are d=
iscussed on this list all the time in the context<br>&gt;&gt; of miners, =
users, merchants, and exchanges.  Again, the developers try to<br>&gt;&gt=
; place themselves on some kind of pedestal where they are the protectors=
 and<br>&gt;&gt; pure and everyone else (miners, users, merchants) are ab=
users, spammers,<br>&gt;&gt; attackers, scammers, cheaters, etc.  It is G=
arzik who voluntarily made an<br>&gt;&gt; issue of how many bitcoins he h=
olds and he made that issue in the same place<br>&gt;&gt; where he announ=
ces many of the technical issues.  It is very relevant that<br>&gt;&gt; h=
e has a minimal stake in Bitcoin holdings yet he goes around making major=
<br>&gt;&gt; decisions about Bitcoin and trying to dictate who is allowed=
 to participate<br>&gt;&gt; in discussions.  If a core developer has mini=
mal stake in Bitcoin yet has<br>&gt;&gt; major veto power over code chang=
e that is a problem.<br>&gt; Please, don't generalize. I don't think I pu=
t myself in any kind of pedestal.<br>&gt; That is insulting to me and man=
y others (you may not even know and<br>&gt; you're insulting them).<br>&g=
t; And I think my Bitcoin holdings are completely irrelevant when judging=
<br>&gt; my contributions to the software: either they're good or not, an=
d who<br>&gt; I am or how many Bitcoins I have at any given time shouldn'=
t matter.<br>&gt; Again, nobody forces you to use our software, as said t=
here's<br>&gt; alternatives (including forking the project right now).<br=
>&gt;<br>&gt;&gt; You are correct that you cannot give power to any perso=
n over the Internet<br>&gt;&gt; which is why some kind of process needs t=
o be developed that does not<br>&gt;&gt; involve trying to convince one p=
erson to make the changes or a system that<br>&gt;&gt; depends on unwritt=
en, ever-changing rules maintained by a handful of people.<br>&gt; Well, =
for now the process we have is seeking consensus, and although<br>&gt; ou=
r definition of =22uncontroversial=22 is very vague, I think it is quite<=
br>&gt; obvious when a proposed change is not =22uncontroversial=22 (like=
 in the<br>&gt; block size debate).<br>&gt; It seems to me that any other=
 =22formal process=22 would imply<br>&gt; centralization in the decision =
making of the consensus rules (and from<br>&gt; there you only have to co=
rrupt that centralized organization to<br>&gt; destroy Bitcoin).<br>&gt;<=
br><br><br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F<br>bitcoin-dev mailing list<br>bitcoin-dev=40lists.linuxfoundation.or=
g<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br></=
div></div></span></blockquote></body></html>
--5590456f_1bf2bd2_23f7--