Hi Anonymous,<br /><br />Let's add more characterization by zooming out on a 15 years timeline on<br />the situation for an external observer less versed in usual bitcoin core development.<br /><br />Historically, the project has been cared of by veteran of open-source projects,<br />old cypherpunks and other contributors used to security system engineering. While<br />qualms on technical proposals have always been heated even in the early days (e.g<br />the infamous OP_EVAL or bloom-filters bip37), at the very least protagonists in<br />the conversation were taking technical arguments at their sound value and killing<br />weak ideas when a majority of contributors have came to the same conclusion.<br /><br />The resistant to the arguments, if they did not have the intellectual honesty to<br />fully appreciate arguments, were slowly moving out of contributing to bitcoin or<br />projects around to go work on fork-coins or something else. From my experience,<br />historically bitcoin had some of the most scientifically grounded and software<br />skilled contributors sweating hard and ready to risk their professional careeers<br />to make the bitcoin core codebase advance. There is a bit of subjectivity involved<br />here though I worked on code changes and review with some people since the early<br />days and if you take the "old guard" the level is here.<br /><br />With time, especially after the block size war which have been intense whatever<br />the camp you have followed, some more "senior" core contributors have take a more<br />or less step back, without necessarily taking the time to fully transmit the same<br />level of technical and ethical standard to newcomers making their dents on the project.<br />This trend has only been worsen with the Faketoshi lawsuits, where even more "senior"<br />contributors have take a step back.<br /><br />All those "senior" folks, of which Peter is a good specimen, where very okay when you<br />yelled at them that code was broken or a significant low-level proposal was weak and<br />it was better to fix them before to move forward. Without always necessarily caring<br />about following the utmost courtesy and politeness.<br /><br />At the very same time of the end of the block size war and when faketoshi lawsuits where<br />taking the most of their toll among the contributors, there has been more the growth<br />of a culture of "professionalizing" the bitcoin core space. That have translated in a<br />number of dimensions, e.g we have started to seen a myriad of "money-helicopter" open-source<br />grants (most of the times attributed to hard working folks, sometimes giving the impression<br />that attribution has been done on more external "social" factors). In parallel, there<br />has been an emphasis in the core developnment process to ship complex code in low-level<br />subsystems, whatever the thoroughness of the design and code review, as landing complex<br />code not only make good story to tell on podcasts and twitter but it has also become a<br />self-sustaining argument to grap more open-source grants for some less regarding contributors.<br /><br />(I don't know if a lot of folks are familiar with the school of public choice in economics<br />and the concept of rent-seeking capture, one can wonder if it's not a phenomena affecting<br />bitcoin open-source stage too. This is not saying that it's great to have folks on open-source<br />grants to handle releases, refactor the old parts of the codebase or write more tests,<br />I think just to be more far conservative when it comes to implementation of new mechanism and<br />minimizing the impact of incentives nurturing complacency).<br /><br />With that accumulation of uncoordinated cultural changes, and open-source grants becoming<br />the norm as a mode of compensation among the majority of bitcoin core contributors (rather<br />than exercising their skills on the market or being good with their btc stack), in my<br />impression there has been more and more a wind of spontanous self-censorship arising among<br />the current generation of contributors. After all, what one would take the risk of being<br />far too negative or adverserial in the review of one's co-contributors patchset, when that<br />very co-contributor might judge for your grant re-attribution at the end of the year ?<br /><br />Better to not take the risk, and if it's coupled with having a small btc stack even if there<br />is a major security failure X years from now, you wouldn't personally pay the cost as your<br />fiat-denominated grant will be still dump on you. All you have to do in case of security failure<br />is run away from any responsibility and engage in a heavy public relationship effort saying<br />everything is all right, bragging about the fact that you're a maintainer or that you've seen<br />worst in the past (were indeed you were not the ones doing the hard work at the time).<br /><br />It might be a very personal opinion, though I think there have been a serious downgrade in<br />bitcoin core culture about technical proposals, where it was estimated that the code was broken<br />to a more current culture of first not making wawe and to be always "constructive" (even if no<br />ones knows exactly what does it mean to be constructive when a technical proposal has been analyzed<br />to be broken and when it's reasonably wiser to abandon months of engineering effort rather to<br />jeopardize end users funds safety) [0].<br /><br />[0] https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md<br /><br />Quote: "One can just have a look on the newer moderation rules, where it is explicitly said "on the<br />understanding that it is easier to rephrase deleted comments to be constructive and respectful<br />than to replace long term contributors who are burnt out from a discussion culture that is<br />unnecessarily contentious and overbearing" [0].<br /><br />I think here some astute minds could observe that progress in the domain of scientific ideas if one<br />complete history on few centuries are driven a lot by controversy, overbearing experiments done again<br />and again and argumentation layout repeated multiple times in front of many audiences, as some brilliant<br />ideas might be counter-intuitive at first.<br /><br />With all said and joining on your suggestion to fork core or have in-place multiple security<br />mailing lists. On the former this does not abstract from gathering enough dedicated experts<br />behind the same codebase, though more importantly maintaining a culture of collaboration among<br />the different full-node implementation. If it's go back to the situation of Bitcoin XT fork<br />and Bitcoin Segwit2X, where experts are fighting each other to "dictate" the consensus rules<br />this is not worth it. New civil war in bitcoin is a situation where everyone will be at loss.<br /><br />On the latter suggestion, multiple security list is more or less already the current dynamics<br />as historically you had coordination among lightning implementations or with the mining ecosystem.<br />Whatever the reality of a single endpoint, at the end of the day it's more a "peer-to-peer" dynamic,<br />after a while you know you can personally trust and who is very skilled in area X or area Y or bitcoin. <br /><br />Degree and goodwill of collaboration is more important that the communication channel itself, as some<br />bitcoin core contributors reveals publicly recently what was more or less known in internal circles about<br />the project management of security issues [1]:<br /><br />[1] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w<br /><br />Quote: "The project has historically done a poor job at publicly disclosing security-critical bugs, whether externally<br />reported or found by contributors. This has led to a situation where a lot of users perceive Bitcoin Core as<br />never having bugs. This perception is dangerous and, unfortunately, not accurate."<br /><br />I hope certainly there will be some cultural electro shocks, of which Peter's present disclosure email<br />can consistute an opportunity for a lot of people to medidate on, that we improve the security of the bitcoin<br />ecosystem at large by adopting good security issues handling process. And that before we're seeing massively<br />contract protocols and second layers being p0wned by North Korea sponsored hacking groups -- if the evidences<br />gathered by the wider cybersecurity community is correct on this front.<br /><br />Reader beware - All those historical considerations on the evolution of bitcoin core culture only represents<br />my own opinion, this is necessarily the reflect of my subjective experience as a contributor and there is no need<br />to trust me.<br /><br />Best,<br />Antoine<br />ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891<br />

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com</a>.<br />