📅 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
>
Milly Bitcoin [ARCHIVE] /
npub1rv…hc5wt
2023-06-07 15:38:40
in reply to nevent1q…5vsx
Author Public Key
npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wtPublished at
2023-06-07 15:38:40Event JSON
{
"id": "92c5bc83bfcd7a5b05715b0b0322c6d22bdd6267ba0181e038ae92a261ed7302",
"pubkey": "1b29d94ee81e1ee0479f1db4bc4ac887407bd470a0d7060e76f8ab27fdd57e50",
"created_at": 1686152320,
"kind": 1,
"tags": [
[
"e",
"23c1bb2f25b9e7356b48aa2a86751c4f26fb3977b440917a1cb3512c200b0b2f",
"",
"root"
],
[
"e",
"612e5b02f466d67ce8197acf6277f0ea6e502f9b917acf140ae7526e3d1303e6",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2015-06-18\n📝 Original message:What is immediately clear to anyone who looks at Bitcoin software \ndevelopment is that there is no clear process or method to make \nchanges/updates to the software. When I have questioned this in the \npast the response is usually some cultish answer about how some kind of \ntechnical consensus is reached yet nobody can point to an actual \nprocess. If companies are expected to dedicate resources to adopt \nBitcoin there needs to be some type of process spelled out that can give \nthese entities at least minimal assurance that there is some type of \nprocess in place. I think the whole process is based on how certain \npersonalities handle issues but as those personalities change the system \nchanges in unknown ways which equates to risk.\n\nThe other thing that is immediately clear is that there is no systems \nengineering process in place to make changes. A \"risk study\" was done \nby the Bitcoin Foundation but that is only the first baby step in the \nprocess. It works by defining a set of risks, likelihood, mitigations, \netc. and a risk matrix and maintaining those as living documents. \nWhen changes are proposed alternative scenarios are created and they are \nmeasured against the baseline of what there is now. Standard test plans \nare created to measure the changes against defined metrics. It is a lot \nof work to define those risks to the level of detail needed for work \nlike this. However, the amount of time/energy saved in the end is \ntremendous. Right now the process is haphazard at best with people \nposting random tweets, Reddit posts, blog posts, etc. All this drama \nmakes Bitcoin look somewhat amateurish and rather risky.\n\nhttp://www.dtic.mil/ndia/2004cmmi/CMMIT1Mon/Track1IntrotoSystemsEngineering/KISE09RiskManagementv2.pdf\n\nhttps://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf\n\nSome people also seems to conflates the notion of decentralization of \nthe state of the ledger by mining/nodes with that of decentralization of \nopen source software by forking the software. These are very different \nproblems and I don't think it is possible (or even desirable) to achieve \nthe same level of decentralization for both things. In any case \n\"decentralization\" for the state of the blockchain is only an \napproximation anyway since there are things like 51% attacks and \ncheckpoints.\n\nRuss\n\n\n\n\nOn 6/18/2015 7:14 AM, Wladimir J. van der Laan wrote:\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e\n\u003e On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:\n\u003e\n\u003e\u003e Core is in the weird position where there's no decision making ability at\n\u003e\u003e all, because anyone who shows up and shouts enough can generate\n\u003e\u003e 'controversy', then Wladimir sees there is disagreement and won't touch the\n\u003e\u003e issue in question. So it just runs and runs and *anyone* with commit access\n\u003e\u003e can then block any change.\n\u003e Bitcoin Core is completely different from your average open source project in one aspect: where it concerns consensus.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e (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)\n\u003e\n\u003e Wladimir\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e Version: GnuPG v1\n\u003e\n\u003e iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID\n\u003e +NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ\n\u003e tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4\n\u003e 7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9\n\u003e ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta\n\u003e mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=\n\u003e =W26K\n\u003e -----END PGP SIGNATURE-----\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "112b4f3f999f3e2c2fce55362e150908145a080f7579e62d03c481ecb07172ed0e916b70b838b73627cb0f4946e719415374f88eb91130f0e1e89ad522a3c3e6"
}