Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitcoins.info
	designates 70.90.2.18 as permitted sender) client-ip=70.90.2.18;
	envelope-from=milly@bitcoins.info; helo=mail.help.org; 
Message-ID: <5582BBC6.9070105@bitcoins.info>
Date: Thu, 18 Jun 2015 08:38:30 -0400
From: Milly Bitcoin <milly@bitcoins.info>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Wladimir J. van der Laan" <laanwj@gmail.com>, 
	Mike Hearn <mike@plan99.net>
References: <55828737.6000007@riseup.net>	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
	<20150618111407.GA6690@amethyst.visucore.com>
In-Reply-To: <20150618111407.GA6690@amethyst.visucore.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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
Precedence: list

What is immediately clear to anyone who looks at Bitcoin software 
development is that there is no clear process or method to make 
changes/updates to the software.  When I have questioned this in the 
past the response is usually some cultish answer about how some kind of 
technical consensus is reached yet nobody can point to an actual 
process.  If companies are expected to dedicate resources to adopt 
Bitcoin there needs to be some type of process spelled out that can give 
these entities at least minimal assurance that there is some type of 
process in place.  I think the whole process is based on how certain 
personalities handle issues but as those personalities change the system 
changes in unknown ways which equates to risk.

The other thing that is immediately clear is that there is no systems 
engineering process in place to make changes.  A "risk study" was done 
by the Bitcoin Foundation but that is only the first baby step in the 
process.  It works by defining a set of risks, likelihood, mitigations, 
etc.  and a risk matrix and maintaining those as living documents.   
When changes are proposed alternative scenarios are created and they are 
measured against the baseline of what there is now.  Standard test plans 
are created to measure the changes against defined metrics.  It is a lot 
of work to define those risks to the level of detail needed for work 
like this.  However, the amount of time/energy saved in the end is 
tremendous.   Right now the process is haphazard at best with people 
posting random tweets, Reddit posts, blog posts, etc.  All this drama 
makes Bitcoin look somewhat amateurish and rather risky.

http://www.dtic.mil/ndia/2004cmmi/CMMIT1Mon/Track1IntrotoSystemsEngineering/KISE09RiskManagementv2.pdf

https://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf

Some people also seems to conflates the notion of decentralization of 
the state of the ledger by mining/nodes with that of decentralization of 
open source software by forking the software. These are very different 
problems and I don't think it is possible (or even desirable) to achieve 
the same level of decentralization for both things.  In any case 
"decentralization" for the state of the blockchain is only an 
approximation anyway since there are things like 51% attacks and 
checkpoints.

Russ


On 6/18/2015 7:14 AM, Wladimir J. van der Laan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
>
>> Core is in the weird position where there's no decision making ability at
>> all, because anyone who shows up and shouts enough can generate
>> 'controversy', then Wladimir sees there is disagreement and won't touch the
>> issue in question. So it just runs and runs and *anyone* with commit access
>> can then block any change.
> Bitcoin Core is completely different from your average open source project in one aspect: where it concerns consensus.
>
> Like in any open source project there is lots of decision making ability for code changes. I'd say look at the changelog for e.g. 0.11 https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, or follow pull requests for a while, to see how many decisions about changes are made from day to day. No, I'm not sitting on my hands, and so is none of the other contributors that you'd like to get rid of.
>
> Consensus changes are *much* more difficult, on the other hand. Even relatively straightforward softforks come with a long discussion process (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone needs to upgrade their software!), and simply not possible if almost the entire technical community disagrees with you.
>
> Bitcoin is supposed to be a robust, global, decentralized network beyond anyone's control. It makes *no sense* to try to run it as a dictatorship. This would create a handy central position where power can be applied, pushing through changes to the behavior of the system, either by force or other ways of motivation. I refuse to take part in that.
>
> Hence, anything that is controversial needs to be considered really carefully. If I suddenly start making changes to the consensus code without full agreement, by all means take away my commit privileges.
>
> (a major reason for the ongoing libconsensus work is to separate "Bitcoin Core, the node software" and "The Bitcoin Consensus" along clear lines, to avoid this kind of nasty confusion)
>
> Wladimir
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
> +NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
> tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
> 7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
> ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
> mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=
> =W26K
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>