Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_BAF567DA-0AAA-4C33-82EE-720314ECC0C9";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <558C03F1.70603@sky-ip.org>
Date: Thu, 25 Jun 2015 06:41:01 -0700
Message-Id: <53DED62D-6645-464A-998F-C31464FD0C1A@gmail.com>
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
	<558B4632.8080504@bitcoins.info> <558C03F1.70603@sky-ip.org>
To: s7r@sky-ip.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Precedence: list


--Apple-Mail=_BAF567DA-0AAA-4C33-82EE-720314ECC0C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Wladimir is doing an amazing job under difficult circumstances. Give the =
guy a break, please.

- Eric Lombrozo

> On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip.org> wrote:
>=20
> I guess you mean Wladimir here. You are wrong, Wladimir does decide =
and
> if you look at the commit history on github.com for bitcoin core you
> will see, that he does actually decide and does it really good.
>=20
> He just does not want to decide (and he really should not) on =
CONSENSUS
> changes or protocol changes. This is totally different.
>=20
> Stop the analogy with "other open source projects". This is an open
> source project (the code part) but unlike any other open source =
projects
> which can just be forked, without affecting the other users, in =
bitcoin
> we need all the users to trust a single blockchain, so it'll have =
value.
> If some users fork the blockchain and change consensus rules, they are
> not just harming themselves, they are affecting ALL the users, since
> such a thing would have strong impact over the BTC/FIAT rate, =
affecting
> everyone in the ecosystem. There is economics involved here and human
> element, things which are hard to fix via code, even if the code is
> developed in open source style.
>=20
> It's one thing to decide to merge some patches, improve the code, etc.
> and another thing to decide for consensus rules when you literary play
> with 4 billion united states dollars of other people's money. This
> shouldn't be Wladimir's responsibility, it's just unfair for people to
> throw this on his shoulders.
>=20
> I do not under any circumstances suggest that the consensus should
> remain as it is now forever. We need to improve it, but this should =
not
> be on the maintainer. I've seen smart suggestions on this mail list
> where consensus changes can be made during a long period of time,
> through soft forks, where all users/miners/exchangers/merchants get =
the
> chance to choose / take action.
>=20
> On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
>> I have seen this question asked many times.  Most developers become
>> defensive and they usually give a very vague 1-sentence answer when =
this
>> question is asked.  It seems to be it is based on personalities =
rather
>> than any kind of definable process.  To have that discussion the
>> personalities must be separated out and answers like "such-and-such
>> wouldn't do that" don't really do much to advance the discussion.  =
Also,
>> the incentive for new developers to come in is that they will be paid =
by
>> companies who want to influence the code and this should be =
considered
>> (some developers take this statement as an insult when it is just a
>> statement of the incentive process).
>>=20
>> The other problem you are having is the lead developer does not want =
to
>> be a "decider" when, in fact, he is a very significant decider.  =
While
>> the users have the ultimate choice in a practical sense the chief
>> developer is the "decider."  Now people don't want to get him upset =
so
>> nobody wants to push the issue or fully define the process.  Now you =
are
>> left with a broken, unwritten/unspoken process.  While this type of
>> thing may work with a small group of developers businesses/investors
>> looking in from the outside will see this as a risk.
>>=20
>> Until you get passed all the personality-based arguments you are =
going
>> to have a tough time defining a real process.
>>=20
>> Russ
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>> I would like to start a civil discussion on an undefined, or at =
least
>>> unwritten, portion of the BIP process.  Who should get to vote on
>>> approval to commit a BIP implementation into Bitcoin Core?  Is a
>>> simple majority of these voters sufficient for approval?  If not, =
then
>>> what is?
>>>=20
>>> Raystonn
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>>=20
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_BAF567DA-0AAA-4C33-82EE-720314ECC0C9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVjATtAAoJEJNAI64YFENUfIsP/37ezA7UyMMjuekY6lRaB25k
a79vogIeJXstDjUejV4+6m0pyLR5VPHeF7WPI4nU2ocvZ4fTtG3ygrti3s7E2Mty
AoC22WfXvDQQINIsoxdMgjNFWVIz575dFEXfVeJGggQ0Yw9C15fuw5giY3UvxBNW
PgvjmbzHz0fUwjqmDPTsMuTiE7Q4VZJsjFO+UgF1Y5fWCkUvEn6BZisazKN1tsyU
ZmSSlbzYqacDXj1wOFcDsHuzhMQ8OxIVKIR/g06ihMi4rsxOHxro4Gtl5rVkrTrj
DrT9y8eAxOxuc4b6pUPWxUyYVFLSF78jEDR/RvehRbAlRwwpSlxV3etis+78SsyF
qbzYuCkQdvR8pz60KXHS8QnRtHMWvbJlOLsB7y8vGAquRkwawx/5ukiOMjwpcdsw
VEBsjoxQtkunO+spf0g2LTImCw1Iql1/UrFCXRNH1GxTLxTkZ/Zb3j9LdIvXlAzR
m6AcjX9SRaFUeg67zrgzOEQI3BnJmZhKfx+XuRRp8RP6A+zku88JlkWXXTm+5rYu
vqHTEZ6M3Baf/c63A4GlG7n4ZvgO/FTjQzlA896OUFo3eg4D5bRhIrIp8Qr5yWds
g3ffq3GwHaPhNE/xESW76ezgi9rK9c4vB2VB2LxWV+a+jV26dff81n0onUhJdO+k
RlxixxLlvgAPSHV1ya0G
=E4BJ
-----END PGP SIGNATURE-----

--Apple-Mail=_BAF567DA-0AAA-4C33-82EE-720314ECC0C9--