pull down to refresh
121 sats \ 0 replies \ @theariard OP 2h \ on: Waiting Jack Dorsey answer with calm and patience bitcoin
Fundamentally, if I’m asked about the conflict here I’ll describe in the following way.
You have 2 types of open-source developers in bitcoin open-source.
The first group, sincerely believe in bitcoin mission of censorship-resistant money, but if they have a hard choice to make, i.e between independence and a comfortable salary at the end of the month, they will always take the second alternative. Let’s not make angry the corporate hand that feed you, after all. And being your own boss or in charge, that’s very scary with all the responsibilities, you know…Typically Matt Corallo.
I would say that’s 80% of the contributors.
The second group, sincerely believe in bitcoin mission of censorship-resistant money too, but they don’t see themselves contributing on bitcoin, without sacrificing their personal independence. It’s free and open-source code but it’s also yourself staying free in the process. The folks who prefer to stay self-sovereign on the software run, on their finance and their responsibilities.
I would say that’s 20% of the contributors.
The problem is when the first group, more numerous in people, are starting to instrumentalize code of conduct and moderation rules, at the demand of their corporate backers, to push out the first group out of the bitcoin development forums.
At the end of the day, independent people, they might have their interests more aligned with the end-users, but that makes things slower as you know "we’re busy we have quarterly newsletter to write to our shareholders” so shut up !
(…I’ve enough friends who have been at Goldman Sachs to make an IPO if need…it’s not magic it’s just a lot lot of downsides…)
In my view, you should be free to work on bitcoin open-source, without having to bind the knee or ask permission to a random CEO with a flat listed company stock price or a bullshit messiah who never has contribute one line of code to bitcoin.
We reject: kings, presidents and voting. That’s the bitcoin way.
It’s a hill I have no problem to fight on as long as I’ll have to.
185 sats \ 1 reply \ @theariard OP 2h \ parent \ on: Waiting Jack Dorsey answer with calm and patience bitcoin
I refuse to bind to LDK and Lightning completely arbitrary codes of conduct.
I started to work on rust-lightning and bitcoin core in 2018.
So before Square Crypto was a thing in 2019.
If Jake and his employes don’t change their behaviors, they will pay the price.
Met Jake Dorsey and Ray Youssef in the past, know which impressed me the most.
Like I said, I’m arming myself with calm and patience on this issue.
I’m putting apart Steve Lee, worked professionally with him a long time, he’s different.
I’m just sad for him that he failed Bitcoin Works, his previous initiative before Spiral.
Now, he found himself stuck in a nexus of perverse incentives...
I already got an answer from Microsoft actually on this subject….
Satya won’t play his reputation for Jack.
Let me improve the build process for now and do some rebase. It works, but roughly.
I’ll try to share a monthly release of code advances.
checked off-record emails
the day is correct "a full disclosure this Thursday 12 June late afternoon US East Coast time”, but screwed up in the report.
pushed an addedum on the web version, thanks for the catch.
so i won’t champion further this proposal, after an instance of meditation:
https://github.com/bitcoin-core/meta/issues/17#issuecomment-2849415676
i think it’s a reasonable way to move to for bitcoin core, but i do not wish to allocate my time lobbying for that among the community of contributors on bitcoin core.
i prefer to focus on dev’ing my own full-node implem.
cypherpunks write code.
well ECC public keys are cheap to generate.
but (a) yes coinjoin multiple-times the utxo you might have to use or other coins clustering obfuscations techniques and (b) if you’re a devs who can’t afford the ~300 sats (or 0.20 GBP) for a single on-chain UTXO you’re free (b.1) go to work until you can afford a 0.20 GBP utxo or (b.2) go to ask nicely to someone to lend you 0.20 GBP to buy an on-chain utxo.
otherwise, go to read the oreilly “accountability” chapter pointed out above, and you will realize that mitigating well spams is an incredibly hard task.
we do not have magical “trusted” third parties who can magically say what is “spam” or not “spam” in bitcoin, as the only source of truth we have is the blockchain itself.
i’m saying all of this without ironical tone, and it’s not like it’s publicly known i've worked for years now on distributed systems.
you have 4MB weight unit block and 10 min in average block time.
enough foundations to build internet-large anti-spams.
can ask the scarce utxo to be older than X blocks.
no need for everyone to have the same anti-spam policy, it’s a client-side config.
How would you stop unwanted posts from spamming up discussion?
ask every post to be counter-signed with a pubkey committed in a scarce utxo.
if too much spam posts originating from the pubkey, your client down scores the utxo.
now minimal fee cost on the spammer to get a new fresh utxo.
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...