During the last weeks, while I was reviewing few PRs on Bitcoin Core (e.g v3 policy or sibling eviction), I did notice that code design and proposals were abnormally vulnerable to some class of attacks to target Bitcoin use-cases. After questioning the reviewers and proposing them to test the code branch in real-world conditions on signet or mainnet, they ignored my critics and one of the maintainer move ahead merging the PRs.
Latter on, on the Bitcoin R&D forum dubbed “Delving Bitcoin”, AJ Towns did reveal the existence of private discussions rooms where some selected Bitcoin Core contributors were engaging and designing new Bitcoin Core proposals. Thus bypassing the usual transparency standards underpinning FOSS and making Bitcoin Core development a “close-door” process. Some of the vulnerable code enhancements I did pointed out the issues in public on the Core repository, sounds to have been through this “close-doors” process.
As Pieter Hintjens (the Zero MQ creator and a FOSS veteran), put it in one of his book on the necessity of transparency in FOSS.
"Transparency is very important to get rapid criticism of ideas and work in progress. If a few people in a team go off and work on something together for some time -- a few days seems harmless, a few weeks is not -- then what they make can be presented to the group as a fait accompli. When one person does that, the group can just shrug it off. When two or more people do that, it becomes much harder to back off from bad ideas. Secrecy and incompetence seem bound together. Groups that work in secret do not achieve wisdom.
TIP: When one person does something in a dark corner, that's an experiment. When two or more people do something in a dark corner, that's a conspiracy.”
When I did the same remark to AJ Towns on the aforementioned thread, rather to engage constructively in the discussion on what communication standards we all wish to maintain a high-degree of intellectual honesty on the “Delving Bitcoin” forum in a decentralized ecosystem, he did threat me back to cancel my account by abusing its admin rights on the platform and then deleted my post (cf. the screenshot).
Dear Bitcoin community, there is something very fishy happening in the Bitcoin Core development process right now, and I seriously wonder if a subset of contributors are not engaged in deliberately inserting backdoors to defraud or hypothetically get technical leverage on user funds in the future, for any kind of political move.
Personally, I’ll stop engaging or contributing on Delving Bitcoin, we have many more communications platforms available to engage in Bitcoin development (e.g nostr, google groups, personal blogs, stacker.news, etc).
datacarriersize
config option from:datacarrier
to also catch inscriptions. Then Gloria Zhao and Ava Chow (Bitcoin Core maintainers with commit access) used that new meaning ofdatacarriersize
as an argument to reject the fix (for non autists: inscriptions store they data in the input section of transactions, while "scriptPubKey" means output, so they narrowed the applicability ofdatacarriersize
in its description text).datacarrier
anddatacarriersize
config options to Bitcoin Core back in 2014. They redefined the meaning of his contribution in his face to be able to reject his new work more comfortably.datacarriersize
:mempoolfullrbf
is a worthy technical change, especially to avoid discrepancies among network mempool states.datacarriersize
is.