Chaincode Labs is doing politics with Bitcoin consensus changes (CTV) \ stacker news ~bitcoin

pull down to refresh

Chaincode Labs is doing politics with Bitcoin consensus changes (CTV)

272 sats \ 10k boost \ 26 comments \ @theariard 22 Apr bitcoin

First and foremost, I do not like to use the word “politics” as it has a lot of cultural and historical connotation, and I’m always careful when I’m using such wording.

However, I do not have a better description to describe a situation when you have someone on your payroll doing the role of the poor schoolmaster to say who is allowed or not to contribute on bitcoin consensus change.

For the context, few weeks ago, I started to engage in the review process of CheckTemplateVerify.

I disagreed to have a moderator from Chaincode Labs telling me what I should think or not in matters of bitcoin consensus changes.

The post was purely technical and pointing out to be careful about use-cases if you start to chain covenant primitives to avoid some MEV-like risks (whatever the word MEV means, it has never been defined scientifically).

And now, I’ve learnt today that my github account is ban to comment or review on the bitcoin core repository, including being able to pursue my review of CTV.

Title: My github account is blocked to review CTV

It’s unclear if Chaincode is just not doing politics to block advances on CTV, as they might be disagreeing with that consensus proposal and they wish to prevent progress by all means.

Just saying that Alex Morcos and Suhas Daftuar are playing with your money, gals and guys.

Why do we have moderation guidelines covering consensus changes at first, it’s unclear to me. Why not any action done under any existent guidelines is not published or stamped in the bitcoin blockchain, it’s even more unclear to me.

Note, I’ve not been the only bitcoin FOSS veteran to question why those moderation guidelines have been steamrolled on contributors or maintainers. AFAICT, those “guidelines” have been uniquely authored by someone at Chaincode…Which make everything more weird...

Somehow, we have people who claim to work daily on bitcoin, though they do not believe in the transparency and authenticity effects of the bitcoin blockchain for electronic communications.

This is not clear...

view all related items

344 sats \ 3 replies \ @Murch 12h

It is misleading to imply that this ban is chiefly related to review of OP_CTV.

There has been a history of ariard posting off-topic and otherwise disruptive comments in several Bitcoin projects’ repositories over the past years that have previously led to bans by several organizations. Most recently, ariard has been making off-topic on BIPs pull requests. Requests to stick to the proposals at hand and to limit himself to constructive contributions prompted further meandering comments about unrelated topics containing insults and legal threats by ariard. ariard’s on-going disruptive and unwanted contributions have prompted requests for moderation action by several contributors recently. The situation was starting to incur a toll on other contributors time. To curb the disruption he was banned from the repositories of the bitcoin organization (notably including the Bitcoin Core code base and the BIPs repository).

Obviously, constructive contributions would be welcome, and he is welcome to make security disclosures through the appropriate channels any time. A more detailed explanation by the moderator that took action can be found in the bitcoin-core/meta repository.

0 sats \ 2 replies \ @theariard OP 7h

@Murch

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.

42 sats \ 1 reply \ @Murch 5h

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…

Don’t put words in my mouth. I said your behavior is toxic. I stand by that. For the past years the majority of your emails and GitHub comments I have seen were at least one of unnecessarily verbose, incomprehensible, off-topic, or unhelpful, and frequently contained a gratuitous helping of conspiracy theories and laughable legal babble. You have been banned from contributing to at least four projects and one forum for harassing or insulting people, or other disruptive behavior.

I have mostly stopped reading your emails and comments unless you are responding to me directly as their signal to noise ratio has been approaching zero. If I have to read one, I ask ChatGPT for a summary. You know better than most how little Alex and Suhas instruct Chaincode employees. If you want to find the party responsible for the perception other contributors have of you, check a friggin’ mirror.

0 sats \ 0 replies \ @theariard OP 5h

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.

142 sats \ 3 replies \ @standardcrypto 13h

"First and foremost, I do not like to use the word “politics” as it has a lot of cultural and historical connotation, and I’m always careful when I’m using such wording."

It's politics, rude and naked. I would compare a bitcoin softfork as something like an amendment to the US constitution, possibly even more difficult. Yes, there's going to be a lot of politics. And there's going to be a lot of amendments proposed that are not great for the US. And everyone is going to be accusing each other of black hatting.

To state my bias up front, if they are trying to slow down CTV, I align with chaincode. I am YAGNI on CTV.

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 was at a bitdevs nyc meetup recently at the chaincode office, and I did feel a distinctly anti-CTV vibe. I'm not an expert, but I have followed the covenant wars enough to feel like more than just an interested bystander.

To keep this from getting too long, and also to respect chathan house rules, I will try to channel the vibe briefly.

The vibe WRT to the merits of CTV was something like "YAGNI, or at least you aren't going to need it yet." More germane to this kerfluffle, the vibe WRT to reviewing CTV on github was something like, "the bitcoin repo is not a place to politically debate the merits of CTV or any softfork. The ideal is that the github repo should be a place for technical review (bugs/errors on patches) only, having established political consensus in other channels." Delving bitcoin was mentioned, as in the rebuke you linked to.

"Github not an appropriate place to debate politics of softforks" may not be true historically, maybe not not even now. Maybe it's more of a work in progress and "we are trying to shift the communications so that..."

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.

IE, I think the moderation policies are largely being driven by exhaustion and burnout, and not primarily driven by politics or anti ctv sentiment, although by and large chaincode DOES lean anti CTV but without being too obvious about it (to avoid getting sucked in to the war). Maybe you're collateral damage. Maybe it's targeted, someone doesn't like you. IDK.

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.

This would probably be a different post if I wanted CTV. I would be more heated myself. I would be more worried about the future of bitcoin.

But even then, you just have to stay cool. Don't feed the trolls. Don't be a troll. Try to empathize and find common ground, even when things seem unfair.

Also you're not wrong. This is bitcoin and only the paranoid survive.

Thanks for surfacing this, and thanks for caring about CTV.

0 sats \ 0 replies \ @theariard OP 6h

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.

0 sats \ 1 reply \ @standardcrypto 13h

To add color to this, I think many in the room thought that the pull request you were commenting on

https://github.com/bitcoin/bitcoin/pull/31989 ( BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only) #31989 )

should itself have not been permitted. For the same reasons as your comments on it.

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.

0 sats \ 0 replies \ @theariard OP 6h

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...

1205 sats \ 1 reply \ @BITC0IN 23 Apr

it appears you're banned for 30 days for getting that bip "off track" https://github.com/bitcoin-core/meta/issues/16#issuecomment-2822278376

and you've responded by threatening litigation https://github.com/bitcoin-core/meta/issues/16#issuecomment-2822446541

0 sats \ 0 replies \ @theariard OP 6h

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.

5 sats \ 2 replies \ @BITC0IN 23 Apr

I'd appreciate way more step by step screenshots of what has happened please. this is interesting stuff...

101 sats \ 0 replies \ @Murch 12h

Please see #955120 or the explanation by the moderator that took action: https://github.com/bitcoin-core/meta/issues/17

0 sats \ 0 replies \ @theariard OP 6h

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...

0 sats \ 3 replies \ @BITC0IN 23 Apr

From a user on Bitcoindiscord.com

It appears they "Broke their own moderation policy. Not obvious spam, banned, and no meta issue."

"Second to last bulletpoint here: https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md#moderation-transparency. If ariard is banned, given there is no issue in https://github.com/bitcoin-core/meta/issues, the moderator who banned him has broken the moderation transparency policy.

There are a string of hidden comments in https://github.com/bitcoin-core/meta/issues/16 relating to it."

21 sats \ 1 reply \ @Murch 12h

See https://github.com/bitcoin-core/meta/issues/17

0 sats \ 0 replies \ @BITC0IN 12h

ACK

0 sats \ 0 replies \ @theariard OP 6h

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...

0 sats \ 1 reply \ @BITC0IN 10h

I'm not sure either party in this case is guiltless.

Another comment on the situation from a Bitcoin Discord community member:

"The moderation rules are fucking ridiculous. They explicitly don't allow " not general criticism, or criticism of individuals or groups. Even the smartest people can have ideas that don't work out, and people with good intentions can make decisions that backfire. It does not add a lot of value generally to speculate about peoples motives or capabilities when discussing the merits of their ideas, and doing so will be considered off-topic in technical discussions." You can't be critical of an idea that is self serving for a company, you can't be critical of an idea because someones only interest is in using it to scam you apparently can't be critical of chaincode labs at all Fucking. Useless.

Delving Bitcoin has already banned me for commenting that a specific proposal to bundle a LNHANCE type set of BIPs together was an inappropriate bundling for a litany of explicit reasons. That apparently isn't technical enough. They will only accept positive constructive feedback about the proposal, not feedback that the proposal is inehrently inappropriate. The trouble is, those with control over the github community and delving bitcoin are the same small group of tight knit devs in a club. They don't want to hear dissenting oppinions from anyone, they aren't interested in having their biases illustrated for them. They frequently take this out on any dissenter, regardless of merit. A common example being Luke. For example as relates to taking over his own repo and translations from him. They use broad moderation policies like those cited above as an excuse to silence any criticism at all. It's just about getting a handful of people in their little club to assent that Luke is a troll, or I am a troll, or whoever is telling them that we need a flag day fork is a troll - and they can dismiss them. Including and regardless of active development activity as we see in both the Luke and Ariard examples. Ideas aren't discussed on merit, as the moderation policy pretends to enshrine - what happens is if you hurt someones feelings or you propose an idea the club doesn't like, you're removed. We see it time and again. the LOT true debate being another prime example. Or the blocksize wars debate over UASF All of that discussion was entirely silenced by Core. all code and technical discussion, silenced. once the IRC meeting was had and the idea shot down by the little club in spite of active and reasoned opposition, that's that. in every. single. instance. Core devs even use it, as noted, to impact consensus decisions!

It's totally inappropriate. A power grab by a development community that by design has none. These policies should be revoked. The core dev team need look no further than its own practices for why engagement is faltering. I don't feel welcome to engage there"

0 sats \ 0 replies \ @theariard OP 5h

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".

0 sats \ 1 reply \ @OT 17h

Not a good look is it. I guess they must really want CTV

61 sats \ 0 replies \ @theariard OP 6h

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.

0 sats \ 0 replies \ @theariard OP 3h

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.

0 sats \ 1 reply \ @standardcrypto 13h

re "It’s unclear if Chaincode is just not doing politics to block advances on CTV, as they might be disagreeing with that consensus proposal and they wish to prevent progress by all means."

did you mean "just doing politics" ?

If so, I would agree, and I would also align with their politics, and I would also say they are trying to have a light touch commensurate to their power in the space but with an issue becoming so heated it's hard to find the appropriate level of "light" so to say.

0 sats \ 0 replies \ @theariard OP 5h

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.

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.

0 sats \ 1 reply \ @BITC0IN 13h

"Honestly though this whole situation just reminds me of and reinforces how cooked the core org is. Removing all discussion from the repos and pushing Delving Bitcoin, a forum with even worse moderation, or an email list which is anything but reliable these days isn't exactly a great look." ~ a Bitcoin Discord user

0 sats \ 0 replies \ @theariard OP 5h

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>
: