rich1.0npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wthttps://nostr.ae/npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wtnjumphttps://nostr.ae📅 Original date posted:2015-06-18 📝 Original message: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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >