pull down to refresh
0 sats \ 0 replies \ @theariard OP 8h \ parent \ on: FOSS politics or Not FOSS politics, that is the question bitcoin
abusive usage of bitcoin core github permissions by chaincode labs to silence folks dissenting with them on bitcoin consensus changes.
@BITC0IN hear my versions of the fact as told so.
With cryptographic proofs to verify. Do not trust.
I’m not my former manager’s keeper and was not privy to his call log or the content of any phone calls he may have had.
So there is no denial that the call happens. That’s a point.
I may have been paid by Chaincode in the past, but I can confirm that I independently came to the decision to limit my attention to you.
Go to read any deontological playbook, past money paid to someone are often retained as factor indicating a bias on a subject.
If you have made your opinion on myself based on information that you have been exposed to during your paid time at Chaincode, that’s enough.
No independence of yours there given your present organization have been set by a people who have been privy to what did happen. But I’m not going to say more, I’m a man of honor.
Here for community transparency the Github message announcing the ban from bitcoin core.
Of course, I think this is ban is a complete violation of the github tos, and I’ll ignore it and keep contributing to bitcoin core software, as I see fit.
However, in case of future problems due to this abusive ban, I’ll keep Alex, Suhas and Jack Jack legally responsible in front of a competent jurisdiction. Bitcoin is not their private property and saying who is allowed or not to contribute, they have not right.
I'm a man of my words and I've never fear of a real fight.
Doing so, I’ll just act to clarify the lines with the judicial ruling of 2023 rendered in the UK, "They contend that they have nothing like the power or control”. (quote from Lord Bliss).
May I say, there is an overlap among the people who funded the legal defense of the defendants and the 2 organizations who are currently paying the salary of moderators.
There is a logical problem somewhere.
Of course, going to court, it’s not very the spirit in open-source, however it did happen in the past among the Linux kernel among maintainers themselves.
Looking forward that the Chaincode Labs informally understand the legal issues with their currently completely arbitrary practice of the moderation rules.
In all kindness here.
And I’ll reply your behavior and Chaincode’s behavior is toxic.
And we’re in a decentralized community and who is a legitimate “impartial party” to say who is really “toxic” if those words means really anything, I have no idea.
You have been banned from contributing to at least four projects and one forum for harassing or insulting people, or other disruptive behavior.
Pfff, your words are so cheap and I’ve seen few times Alex and Suhas doing a 180 U-turn. E.g when they remove their trust about a former of their long-time employee for some actions end of 2021. Someone they helped in the past set up a 501c.
You know better than most how little Alex and Suhas instruct Chaincode employees.
I’m not sure I understand, if you can clarify.
E.g when Adam Jonas threatened me by call in date of the 20th October 2022 with the following words “X has power” and that I should shut up. What he instructed by Alex and Suhas, or what is just a mistake of Adam.
Or do you deny publicly that call with Jonas in 2022 never happened ?
Mistake happens. I understand that with a lot of humanity.
I’ll end my post by saying I respect the real Murch, the one who has spent days and nights sharing his know-how on stackoverflow. However, I have doubt here that your opinion is not financially biased.
Do not trust, verify.
I'm not sure either party in this case is guiltless.
I do wish to insinuate there is something like "guiltiness" on the part of Chaincode folks.
Pure incompentency yes. Guiltness no.
One has to zoom out that we're in a community of developers spread all over the world, where there is no really strong cultural norms, and there has been a lot
of traumas from all sides due to the block size war.
I'll not enter into the details of this post, I'll just add the more info from the viewpoint of an insider, and who knows quite well the ins and outs.
Somehow, from my perspective this is a failure of the development culture as it has been nurtured over the last ~8 years, when the majority of bitcoin core developers have started to be on "no-string-attached" style of funding grants.
This is something I can talk about, because I've not only been a beneficiary of that style of funding in the past (and I quite deliberately of my own), I’ve seen the massive influx of grants becoming the industry norm circa 2020, and I’ve been few times called to give my opinion in matters of grant attribution (funny enough on someone who is at Chaincode now).
But the problem there is quite flagrant, once you've seen how few grant attributions
are effectively made, sure most of the time there is technical code works but the "social" factor plays a lot. If you're friendly with the grant committee or sharing their ideological bias, or their view on "inclusivity" most of the time at equal technical work, you will be the one doing the grant. And everyone in a grant committee will try to draw the cover towards their own interest, e.g favor open-source work needed for their commercial endeavors on another title. And they might not be transparent on their conflict of interests towards their committee co-chairs.
I'm not saying that if you're the girlfriend or boyfriend of someone influent in a grant
committee (we have straights, gays and bi among the devs saying this with some distant), you'll be sure to have a "grant" in priority over other folks, who might have a stronger track records than yours...but you see...
Developers are human beings, and I have my own bias like any one else. It's a constant work to be careful about situations where you could be in conflict of interest, or act ethically very early on some topics, even if it's become an issue even years and
years after. Do no trust, verify.
The present situation has been worsened by the csw cases, which is a sad fact
for sure and something we all agree on, where few bitcoin FOSS veterans have
seen their legal fees covered mainly by 2 organizations in this industry. If it has not generated a direct economical subordination, it certainly has generated a sentiment of "debt" among some bitcoin FOSS veterans, and as such those people might be more incline to give leeway to Chaincode for things like the moderation
guidelines.
I fully understand their positions their and I've myself shared valuable info to harden any defensive litigation info when the BDFL was announced in Q1 2022 in a "this is a problem for all of us" mindset. Though, yes when you’re an open-source devs and you become used to turn yourself towards Big Boys to solve all your problems, including legal fees for your actions, that's it’s only generating dependency and subordination.
Again, I fully understand them, serious legal trouble can be a real burden, and here I'm not talking about the bullshit Alex's attorney's letter, I’ve seen worst in my experience.
However, that's latent subordination one can only wonder if it's not playing
when during a IRC meeting there is only ~13 folks ACKing the moderation guidelines.
Burnout in the open-source world is of course a serious topic and somehow why I’ve not been formally opposed to civility or courtesy rules on the bitcoin core github repository. In my opinion, when you have to tread with the utmost civility anyone who is a maintainer it’s a hard job. But it doesn’t mean you cannot talk truth to them, and they have any legitimacy in leveraging github permissions to silence your view.
It’s only making things more inflated.
Let's be frank, no one give will grant you independence in your role as dev or as a maintainer, certainly not for anything related to consensus change or your "developer self-sovereignity" in this space. This is something you have to push for, with your grit, your talent and your work ethics. Independence has to be built and fight for, it's never just "granted".
did you mean "just doing politics" ?
It’s not clear what they’re trying to achieve with the present measure.
To be frank, I’m agreeing with your framing of the issue you did in your above comment.
"However, everyone should play fair. However, if no one is playing fair, how can you play fair? That would appear to be the dilemma, in the eyes of those core devs (including those at chaincode) who control the politically important github account(s?)."
I don’t know how to more describe the issue. For what they intend exactly you’re free to ask to https://github.com/morcos and https://github.com/sdaftuar.
It’s a real problem if 2 people in the bitcoin world, can decide who is allowed or not to contribute to bitcoin consensus change. And it will start to be a problem for them.
Here the HTML of the Delving Bitcoin forum that was the trigger for me to be ban (also) from Delving Bitcoin under the following motivation "No constructive purpose to their actions other than creating dissent within the community”
So there is people playing the role of Satoshi in the community, and who can decide or not who is legitimate in the community.
This has been published last ~Friday 18th April (depends your timezone).
<meta itemprop='datePublished' content='2025-04-19T01:13:47Z'>
<meta itemprop='articleSection' content='Meta'>
<meta itemprop='keywords' content=''>
<div itemprop='publisher' itemscope itemtype="http://schema.org/Organization">
<meta itemprop='name' content='Delving Bitcoin'>
</div>
<div id='post_1' class='topic-body crawler-post'>
<div class='crawler-post-meta'>
<span class="creator" itemprop="author" itemscope itemtype="http://schema.org/Person">
<a itemprop="url" rel='nofollow' href='https://delvingbitcoin.org/u/ariard'><span itemprop='name'>ariard</span></a>
</span>
<link itemprop="mainEntityOfPage" href="https://delvingbitcoin.org/t/some-problems-with-current-bitcoin-core-moderation-md/1616">
<span class="crawler-post-infos">
<time datetime='2025-04-19T01:13:47Z' class='post-time'>
April 19, 2025, 1:13am
</time>
<meta itemprop='dateModified' content='2025-04-19T01:13:47Z'>
<span itemprop='position'>1</span>
</span>
</div>
<div class='post' itemprop='text'>
<p>Following some <a href="https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2702330203">moderation incident</a> on the proposal to add CTV support on bitcoin core, I’ve <a href="https://github.com/bitcoin-core/meta
/pull/15">opened a PR</a> to remove the moderation guidelines (the <code>MODERATION.md</code> floating in the
<code>bitcoin-core-meta</code> repo). I don’t think bitcoin core should have mod guidelines, not concerning consensus rules.</p>
<p>Philosophically, in consideration of bitcoin history with the block size war, there should be no formal governance, or even the gist of some “<em>Impatience led various participants to advocate</em>
<em>models that would privilege high-profile actors and grant them control over the direction of</em>
<em>the protocol</em>”. See the <a href="https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd">The Tao of Bitcoin Development</a> essay from 2017. Yes you will find the “project management" in the <code>.md</code>, s
o it’s unclear what’s the goal.</p>
<p>Legally, there is something called the <a href="https://en.wikipedia.org/wiki/Berne_Convention">Berne Convention of 1886</a>, it’s an IP treatise with 170+ countries are contracting parties. Almost all the historical or active development or organization stakeholders contributing to bitcoin dev are located in those countries. In its <a href="https://www.law.cornell.edu/treaties/berne/7bis.html">article 7bis</a>, it’s protecting what’s called joint authorship. Yes, joint authorship can be applied to open source projects. See <a href="https://ctlj.colorado.edu/wp-content/uploads/2018/09/3-Chestek-6.20.18-FINAL.pdf">A Theory of Jointauthorship for Free and Open Software Projects</a> from some 2017 FSF workshop.</p>
<p>The <code>.md</code> has been acked by <a href="https://github.com/bitcoin-core/meta/pull/13#issuecomment-2748178454">~13 contributors</a> only, with somehow no respect for the hard
contributed work of the ~1200 contributors that can be fetched from bitcoind git log, and as such there eventual right to consent or not to the <code>MODERATION.md</code>.</p>
<p>Legally more, there is a UK judicial ruling of 2023, to which few formers or current maintainer(s) have been defendants (<a href="https://www.judiciary.uk/wp-content/uploads/2023/02/Tulip-v-Van-Der-Laan-judgment-030223.pdf">Tulip Trading Limited v Van Der Laan and ors [2023] EWCA Civ 83</a>). Within, they made the following defense “<em>They contend that they have nothing like the power or control</em>” on the bitcoin network and go to argue “<em>they are part of a very large, and shifting, group of contributors without an organisation or structure</em>” (quote from the judicial ruling). The ruling explicitly considers Github, "<em>with the relevant electronic password for the particular code database on GitHub</em>”.</p>
<p>Now currently, there is a <code>.md</code>, with some specific contributors (“<em>the moderators</em>” and “<em>the maintainers</em>”) that can enforce <a href="https://github.com/bitcoin-core/meta/pull/14#issuecomment-2753889160">behavioral guidelines</a> on other contributors, decide what is “<em>on-topic</em>” / “<em>off-topic</em>”, decide what is related to “<em>project management</em>” and what is related to “<em>technical issues</em>”…I don’t know if it’s “<em>power</em>” or “<em>control</em>", though it doesn’t sound exactly like "<a href="https://bitcoincore.org/en/about/">janitorial roles</a>”…</p>
<p>Somehow, there is a logical problem somewhere.</p>
<p>I care about civility and courtesy in an internet community of contributors spread over the whole world, and treating with fairness and respect any contributor whatever the social background, however I don’t think at all the current <code>MODERATION.md</code> flies very well.</p>
<p>Opening this as a “meta”, as I don’t see why it’s not a meta subject as long as it’s discussed with politeness and kindness. And it’s of interest to everyone in bitcoin.</p>
</div>
<div itemprop="interactionStatistic" itemscope itemtype="http://schema.org/InteractionCounter">
<meta itemprop="interactionType" content="http://schema.org/LikeAction"/>
<meta itemprop="userInteractionCount" content="0" />
<span class='post-likes'></span>
</div>
</div>
</div>
:
I’m fine with the status quo on CTV.
The real question as phrased very well by standcrypto is the following dilemma.
"However, everyone should play fair. However, if no one is playing fair, how can you play fair? That would appear to be the dilemma, in the eyes of those core devs (including those at chaincode) who control the politically important github account(s?).”
It’s a matter of who is free to contribute on bitcoin consensus change. Or if you have to do your lips-kiss to folks like Alex or Suhas to be allowed to contribute.
They broke their own moderation policy as (a) first they apply ban and (b) they go to ask the maintainers to a posteriori agree to the ban.
I’ve not seen so far a PGP-signed message to ACK the ban of all the maintainers as appearing in
contrib/verify-commits/trusted-keys and this message being published, before the ban occurs.And it’s not like all the maintainers currently in
trusted-keys have been designated maintainers, after my first commits on bitcoin core. I’ve been there since a while now.It’s the pure reign of Chaincode’s arbitrary...
Chaincode Labs and Alex Morcos started with the legal intimidation in 2023, see the link about what I posted at the time.
So yes, when someone is forwarding you attorney’s letter to tell you obey to their will, you’re not going to send them flowers and chocolate in reply. You take the measures to defend yourself.
Be certain, going in front of legal courts among open-source developers it would be very saddening and it’s clearly not the open-source ethos. Sadly, it’s something that did happen in the past inside the Linux kernel, for stories about open-source licenses (beware it’s in German).
Talking about this subject in public is way to build more awareness among the community, and as such resolve or improve on the problems in a more informal way.
There is another rational about why going to the court early is an option.
When you work on security vulnerabilities search and corresponding coordinated disclosure, you have to work with folks spread on many countries, all under embargo and it’s a high bar to do things correctly. In the bitcoin space, I’ve been doing it for more than half a decade now, so I’ve a bit more of perspective on the subject.
Though, if something goes wrong in case of coordinated security disclosure, you’re reputation could be engaged, and that means for someone like me might have to spend a posteriori lot of time with things like the FBI, the CISA (the cyber agency, not the other service), the SEC or any other appropriate interlocutor to explain what effectively happened. And who played poor politics with a Github repository...
So yes in full frankness, if I have to the courts is a real option. I’m saving potential trouble to myself in the future.
However, ideally competent and veteran contributors are free to review and contribute a priori to complex technical changes on bitcoin core and as such limit the numbers of nights you have to do the acrobat in matters of embargoed coordinated security disclosure for bugs fixing. And I’m saying this with a lot of courtesy and politeness.
I’ll go to publish a timeline with the chronological elements in my possession.
That way any in the community would be able to have clarity on what did happen over the last weeks.
Note the issue pointed out by Murch is “their” versions of the fact, and one should note they have administrative permissions on the Github, so they can hide or delete comments to nurture some kind of “official” narrative in the eyes of external observers.
But it’s only their narrative of what did happen...
I would also align with this opinion. Not just for CTV, but for any soft fork which for some fluffy (sorry I can't give the criteria) definition of consensus, is agreed as the path forward. The idea being that CTV just hasn't met this (fluffy) criteria to be forking the main repo, not even for regtest.
There is the theory and there is the practice. I’m +1 on the idea to have another repository like
bitcoin-inquisition to test many iterations of a things like CTV.In practice, there is always value with a branch opened on the mainnet branch, as you can review the code with all the mainnet standard policy rules playing out (and for Script interpreter there is the many flags interacting one with each other, just go to see
src/policy/policy.h sigh) and default mainnet configuration for memory caches.Where is the clean limit and when something is mature to be opened on the main repository, I have no idea. But there is the theory and there is the practice...
To state my bias up front, if they are trying to slow down CTV, I align with chaincode. I am YAGNI on CTV.
To be frank, I'm not in popping girls mode on CTV. I've been known skeptical on CTV for years and I'm fine with the status quo. On the other hand, there is a point to mark from the CTV supporters, that hash-chain based immutability adds value for folks who wish to improve self-custody in the space.
A lot of Taproot features have been also advocated to improve self-custody, and speaking in experience from someone who ACKed the code consensus change in the repository, Taproot was far more ambitious than CTV.
To said my mind, I don't think we'll go to zero to hero on "vaults" in the bitcoin space, with a silver bullet style consensus change that does everything. More a situation like Lightning, where progress are made painfully stage by stage. A 1st version of the network is deployed with real-economic usage, it's gives more streets credibility to argue a consensus change, change enable a 2nd version of the network, etc...
Mind that few years ago I attempted to move the needle forward with the contracting primitives WG on IRC open to all for a while.
I
n the sense of hoping that folks we'll build use-cases to cross the base-layer to second-layers communication silos, that explain so much frustration about any cov talks over the last years. Note CLTV was explicitly pointing out "Payment Channels" in its motivation, and it got activated before Lightning got in prod.
However, everyone should play fair. However, if no one is playing fair, how can you play fair? That would appear to be the dilemma, in the eyes of those core devs (including those at chaincode) who control the politically important github account(s?).
You've exposed the full dilemma. Nothing to add.
We should be very careful for any consensus changes, though that's the thing on which forum if the CTV proponents and myself we wish to review the code. Where we should do it ? It's better to do it with the code under the eyes, and we constant rebases being done. Sometimes a small line of code in bitcoin can change the whole technical effect.
but I think "people in the room" would like it to be true now. I think there may also be people who for whatever agenda (maybe a bad one) want you blocked, and yeah that sucks if they are hiding. IDK if chaincode is "in control" of the github in question, my feeling is "probably to some extent but it's complicated." Whoever is running that account, one thing I think "people in the room" feel is, it's turning into a shitshow and it's putting undue stress on those who just want to do cool collected code review.
I do not think there is any fed agency hidden agenda playing out here.
It’s pure Chaincode politics.
Sorry you got your account blocked for the review. As someone who myself has been blocked a few times in various stupid internet troll wars (not that this is one of those, it's not, CTV is important) I encourage you to, in addition to registering the action in the appropriate channels, also use it to your advantage as a cooldown. If it's anger, anger must be channeled appropriately. If it's frustration, realize that those across the table from you are probably also frustrated.
No worries, I'll cooldown as usual by going to investigate more weird bugs. Unless someone goes to put a gun on your head, you're always free to do so. I've never been bored over the last years among bitcoin or lightning.
Zooming out, yes when you're facing that kind of situations, it's still always wise to go for a walk in nature or go to read something to cultivate your mind. When you're a professional in this space, it’s really important to keep a life beyond the boundaries of bitcoin.
Thanks for the words, and that there is people actually caring about the development process.
This is all a deliberate attempt of Chaincode Labs to privatize the common bitcoin development process, that started by forwarding intimidation letter by one of their attorneys in 2023. The “steamrolled” moderation guideline is just one more saddening episode in this direction.
May I ask you how you can express yourself objectively in this situation, as you’ve been taking money from Alex Morcos for years as a salary. It’s a real question, even if it’s not making you “comfortable”.
The community can only see that you have real or perceived bias in this episode.
Basically, the active contributors to Bitcoin Core are split in 2 groups, the 1st group who is taking money from Chaincode, e.g directly or indirectly as donations to their orgs and the 2nd group who is more independent or not directly in position economic subordination, and who care less about what Chaincode says.
One just has to look on the only ~13 folks who “ACKed” the moderation guidelines. It’s pretty clear what the affiliations of the folks are conveying.
For report of the security disclosures, I stopped sharing any sensitive information with Chaincode or their affiliates. When there is no trust, there is no trust. There are still far more contributors or developers in the community remaining with whom to collaborate on security disclosures.
There is a little bit of “bad faith” from Murch in saying on one of the
bitcoin-core-meta issue that I’m toxic, when even few months ago we where sharing our know-how for the greater good of the whole community on a podcast. One has a very selective memory…And who is supreme judge to say who is toxic or not in bitcoin a decentralized development process with all over the world. I have no idea.
This is true that the ban has an impact on the review and contributing to consensus changes, including things like CTV.
This does not say that I don’t respect Murch’s work as a BIP editor or on stackoverflow. But here I think he has a very fully characterized bias.
No - I've even been kicked-out from Delving Bitcoin for a while this week (received April 21).
Some people have arrogated themselves the exclusive right to talk in the name of the community, and to say who is legitimate or not in the community
Somehow AJ is a veteran of the open-source world, he works in the Debian world and I respect him for his technical contributions in this space, though there is no certainty he has legal independence protection in his work contract with MIT DCI. As such minimizing the risks that his maintenance of Delving Bitcoin being instrumentalized in that kind of situation.
And I looked again on sibling eviction as I was saying in my original post. It’s a bad idea for multi-party contracting protocol, that the full-node mempool is evicting a sibling child of a parent transaction. From the perspective of an adversary, it's just make easier to do funny mempool games for that kind of protocols.
As with Alice's transaction, Bob's transactions can also be rebroadcast by anyone after they expire from mempools.
Yes for sure, Bob's transactions can be rebroadcast by anyone. Yet any node doing is still facing some "efficient selection" of package to rebroacast issue in a world of limited bandwidth / cache space, easy inadvertently to increase DoS surface.
Mempool expiration is an entirely optional, node-local, feature, and I'm sure plenty of miners have disabled it for obvious economic reasons.
I hope so, I think the presence or absence of expiration in a miner mempool one can probe it from the outside. I don't remember that
mempoolexpiry can be turn off completely without custom patchset.Also, transaction expiration should be based on the oldest transaction in a group of dependent transactions. IIUC, Core does not do this already. But if it did, that attack wouldn't work as using the about-to-expire transaction would reset the expiration timer.
No, I think it should be the most recent transaction in a group of dependent transaction.
Though yes, that variant of the attack wouldn't work anymore as the "group" the expiration timer at each replacement-in of Bob's transaction(s) would be reset. The other variants of the attacks would be still plausible, however the one based on expiration time is by far the dumbest one.
You mention expiration exactly one in the above write-up, and you fail to make a case for it being important. Mempool expiration is just a local, per-node, thing they kicks out transactions after a few weeks (two IIRC). How exactly is that relevant to an HTLC, which typically expires in a day or so max? Secondly, I don't see any way that rebroadcasting could be abused. The attacker triggering the cycling attack has to broadcast fee paying transactions, just like any other replacement. It's no different than using up bandwidth in any other way.
I know the write-up itself is not super explicit on expiration. There is a section "Another Attack Vector: Transaction Expiration Time" in the paper.
When you write a disclosure report on an unfixed vuln, the goal is not to come with a complete handbock for script kiddies on how to exploit it. The goal is to point out what is broken.
Let's re-explain a replacement cycling attack on a Lightning channel, with Alice and Bob.
Alice broadcasts her commitment tx with an outbound HTLC and a 2nd stage timeout tx.
Bob replaces out Alice's timeout with a preimage tx. Then replaces the preimage tx with another tx (let's call it the "sweep") on top of an UTXO unrelated to the chan.
If the "sweep" is on top of a soon-to-be-expired parent tx (2 weeks by default), all the contributed fees to kickout Alice's timeout tx is gone out of the mempool.
Bob does not pay anymore for each replacement of Alice’s timeout tx.
Rebroacasting can be abused in the miner-setting, as whatever the altruistic rebroadcast timing, the junk branch can still be there and a better replacement included in the adversary's block template.
Meanwhile, every time the attacker needs to perform the attack to remove the target from mempools yet again, they're spending money.
Have a look on the second trick playing on mempool expiration time (
CtxMemPool::Expire()) that allows an attacker to dwarf the money spent to almost none. This is more severe than one thing at first sight.I’m still very doubtful on altruistic re-broadcasting to solve that kind of issues, namely due to the open nature of the altruistic bandwidth being also abused by an adversarial LN counterparty or miner. Though yes I forgot to mention altruistic re-broadcasting in the report as one line of solution that deserves more analysis in being able to fix or not RCA-like issues.