pull down to refresh
21 sats \ 0 replies \ @theariard OP 20 Jun \ parent \ on: Hacking on a new libbitcoinkernel-based full-node bitcoin
will publish wen 1st ibd good. very ugly now.
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...
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.