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