Extend oversight in moderation policy with rules to deal with persistent conflict of interest

[ariard]

This issue is a follow-up of #3 on conflict of interest rules.

While moderation rules now mention rules to deal with conflict of interest in oversight (#7), there has been no mention of rules on what do to if there are persistence conflict of interests among regular contributors to the bitcoin core project. There has been a proposition with 05cd245. E.g a moderator could abuse of its own permissions to arbitrary defavor another contributor, as the organization entities they belong to have competing business interest.

I think there is a historical example of interest, during the block size “war”, Jeff Garzik who was a maintainer at that time was on the payroll of a company called Bloq, while at the very same time some other contributors were on the payroll of Blockstream. Both companies were in the business of providing blockchain infrastructure, and have raised millions of dollars from external investors, so they were under fiduciary duties to deliver on.

[pinheadmz]

You will have to define "persistent conflict of interests" to get any traction with this. We will also need a way to moderate policy abusers who simply claim they have such a conflict with everyone in the community / organization / species / universe.

I'm afraid we will end up in an infinite loop of circumstantial claims.

example: Contributor claims moderator's employer's lawyer has sent them a letter. Moderator claims employer has not instructed them to moderate any contributor any differently than the written policy already instructs them to and in fact employer rarely ever instructs moderator to do anything specific at all, ever.

Besides a boundless waste of time by a limited set of full time bitcoin core contributors, the worst case here is that a maintainer restricts or removes a moderator and then we are back to where we were in April: contributors and maintainers are distracted by unproductive comments on GitHub that impedes development progress.

[ryanofsky]

I don't understand what problems 05cd245 is supposed to solve.

Are moderators deleting posts that should not be deleted or breaking with guidelines in another way other way due to conflicts of interest?

Are there potential discussion participants who are intimidated or discouraged from posting because of conflicts of interest?

Are there outside observers who are losing trust in the development process due to conflicted decision making, and adding a conflict section could be a step towards regaining their trust and esteem?

I feel like whatever problem 05cd245 is trying to solve there has got to be a better of way of solving it than having the project maintain a list of potential conflicts of interests and creating different rules for different moderators.

[ariard]

You will have to define "persistent conflict of interests" to get any traction with this. We will also need a way to moderate policy abusers who simply claim they have such a conflict with everyone in the community / organization / spec
ies / universe.

I'm afraid we will end up in an infinite loop of circumstantial claims.

I think the historical example I gave above about Bloq vs Blockstream asymmetric commercial interests illustrates well the notion of persistence.

Even by the time of the block size war, the bitcoin core project was already about technical ideas, implementing code and testing / reviewing. What were the asymmetric commercial interests of the two susbset of regular contributors belonging either to Bloq and Blockstream circa 2015 / 2016 should not have been a subject of concern for the remaining bitcoin core contributors, yet it might have influenced the exercise of maintenance rights by that time. I have some versions of what did happen from some Blockstream folks and beyond, though one could ask Jeff Garzik for more, the guy had a track record in contributing to operating system world before hacking on bitcoin.

About what to do about policy abusers who simply claim they have such a conflict with everyone in the community / organization / species / universe / other riemannian universes, I think it's easy for the moderators, they can ask themselves if there is substance backing each claim, like it's done by courts of justice in evaluating a legal claim. How to proceed exactly and formalize that in the rules ? It's a matter of discussions, I can come with suggestions.

About running in an infinite loop of circumstancial claims, ain't what about life ? As was saying the great Spanish philosopher Jose Ortega y Gasset, who has fled Spain during the Civil War in the 1930s, “Yo soy yo y mis circunstancias". I don't have understanding of Spanish, though from its translation in other langages, I think in English it means "I am I and my circumstance" and I'll let you mediate more on it...

example: Contributor claims moderator's employer's lawyer has sent them a letter. Moderator claims employer has not instructed them to moderate any contributor any differently than the written policy already instructs them to and in fact employer rarely ever instructs moderator to do anything specific at all, ever.

Besides a boundless waste of time by a limited set of full time bitcoin core contributors, the worst case here is that a maintainer restricts or removes a moderator and then we are back to where we were in April: contributors and ma> intainers are distracted by unproductive comments on GitHub that impedes development progress.

It's all on the "rarely", something happening "rarely" can nevertheless have a significant impact.

I think I have the list of Blockstream co-founders from 2014 who had effectively a conflict of interest management provision in their work contracts, which were allowing to exit with financial compensations if their employer instructed them to commit something which was "immoral" towards Bitcoin, people who had maintenance rights in the past.

I think if there is an interesting lesson of the block size war, it's more thinking about a subset of regular contributors, which were tied by common financial interests, that have progressively get the hands on github repository administration and other auxiliaries to more or less influence their technical viewpoint about small blocks. And then once having the hands on github and other communication channels, arrogated themselves to judge what were "distractive" or "unproductive" comments in the realization of the small block idea. It's not like after few years of more technical ruminations that bitcoin scalability picture is more complex than doing a coin toss between 1MB block or 1 TB block...

[ariard]

Are moderators deleting posts that should not be deleted or breaking with guidelines in another way other way due to conflicts of interest?

I believe it was one of the complaint of Peter Todd as expressed on the mailing list about its mempoolfullrbf PR in July of this year, that it has been closed in a less than fully neutral fashion, or at least a bit fast...

Are there potential discussion participants who are intimidated or discouraged from posting because of conflicts of interest?

I'm not in people shoes...though yeah during all the mempoolfullrbf discussions in 2022, there were some proponents of the status quo (i.e not introducing full-rbf and favoring 0-conf transactions), some who were vendoring wallets with real-world traffic that seems a bit lost if they could post their viewpoint, which was necessarily clashing with what was can be technically justified best for lightning.

Are there outside observers who are losing trust in the development process due to conflicted decision making, and adding a conflict section could be a step towards regaining their trust and esteem?

I think has been outside observers who have been losing trust in the development process of the bitcoin core project due to conflicted decision making since the early days of the OG bitcoin foundation, and the subsequent spurs of Blockstream.

I feel like whatever problem 05cd245 is trying to solve there has got to be a better of way of solving it than having the project maintain
a list of potential conflicts of interests and creating different rules for different moderators.

I think you're pointing out well the crux of the issue. I agree with you that we don't wish to create different moderation rules for different moderators, on the other hand I think we're assuming moderation is mostly done by human beings, with different walk of life. So they can have for sure potential conflicts of interests and let some bias being expressed, it’s human nature. If you're familiar with US law system, it's not for nothing that "voir dire", i.e juree selection can be a complex process...

[ariard]

lightning/bolts#1207 (comment)

As I think it’s interesting and it can only make anyone very skeptical on moderation being done in an impartially fashion by anyone belonging to chaincode labs payroll.

[ariard]

@pinheadmz This is great thing that you’re fast to do the moderation on this bitcoin core issue, and appreciated that: bitcoin/bitcoin#31989 (comment).

However, this is still surprising that this issue asking hard questions about conflict of interests of moderators do not get an answer after ~5 months. Great things that all conversation on Github happen in public, of which the HTML pages can be timestamped for any future records.

[kanzure]

Public moderation with non-public adversaries is a failed experiment, and should be rolled back.

[pinheadmz]

~5 months

That's nothing -- there's open issues in bitcoin/bitcoin that are ten years old or more. If no one opens a PR, nothing changes.

[pinheadmz]

Public moderation with non-public adversaries is a failed experiment, and should be rolled back.

I don't understand -- what's an example of a non-public adversary in the context of bitcoin pull request review comments?

[kanzure]

Public moderation with non-public adversaries is a failed experiment, and should be rolled back.

I don't understand -- what's an example of a non-public adversary in the context of bitcoin pull request review comments?

The current issue we are commenting on (issue 9) is about moderation policy. My comment was pertaining to the topic of moderation policy, not about your pull request review comments.

To answer your immediate question, a "non-public adversary" refers to how attackers are not under any obligation to disclose their campaign. I'm not suggesting anyone in that pull request is a known attacker. I'll specifically address the pull request later in this comment.

I will clarify my position. I believe that there should be no "moderation policy", certainly not a public one, and that I think enemies of the project will optimize adversarial behavior against any such public written "rules" or governance. Any policy that also includes a requirement for moderator actions to be published, or meta discussion in public "official" channel such as this meta repository, also creates a further target for adversarial optimization.

For example, adversaries can endlessly argue rules and monopolize scarce collaborator attention (which is a form of attack), or point to the moderation policy or its enforcers as to why consensus rules are or are not merged, or attempt consensus bypass attacks by attacking meta. Anyone is welcome to discuss consensus changes online, and at the same time it is important to remember that nobody here has any obligation to host, participate, endorse, distribute, or promote any discussions of anything.

These policies should be deleted and this meta repo should also be deleted. I observe that github repo collaborators are under no obligations except to themselves to engage or withdraw their voluntary efforts as they find appropriate. I believe bitcoin pull request review comments are able to be deleted or hidden, for example spam is a trivial example that gets deleted. But you can delete spam or even non-spam comments even without a "moderation policy". I don't see the point of one. It's not helpful. It's actively harmful. In fact, even with a moderation policy it's still possible to delete ANY github comment, even on-topic comments!

I would like to echo a reminder of an earlier comment from here:

I strongly recommend you abandon these efforts. They won't serve you. Kanzure is right—they will only serve as a roadmap for attackers whose actual bad intentions are well-funded and fuelled by a small army of people who have the willingness to maintain a literal active daily attack effort for literally more than a decade.

To be fair, you asked a very similar question then too:

Excuse my naivety but could someone give me an example of how an attacker would use a policy designed to preserve and focus on technical work as an attack?

Well for one, writing policy and meta/ is itself a failure to focus on technical work. Second, adversaries could deliberately toe the line of the moderation policy by engaging in disruptive behavior that technically adheres to the letter of the policy while violating its spirit. This can drain resources and attention. This is one example among many.

Also: I believe you should refuse to recognize "conflicts of interest" (subject of this issue 9) as policy-relevant because it is based on the flawed assumption that participants, who I remind you are voluntary freely associating individuals, are obligated to act in an interest other than their own. Obligated by who or what? In a decentralized voluntary open source software project, the default assumption should be that you don't know what someone's true interests are, or that they believe they are acting in their own best interests, not that their interests have been dictated by project policy or whatever. (In case you are wondering, accusations of conflict of interest have historically been used as a form of politics to influence human behavior-- even your behavior is likely vulnerable to pleas of conflicts of interest!)

But it doesn't matter, because this policy stuff should be deleted anyway.

[ariard]

that's nothing -- there's open issues in bitcoin/bitcoin that are ten years old or more. If no one opens a PR, nothing changes.

You’re confusing a social issue, i.e your potential conflict of interests in your janitorial role as a moderator, and technical code changes that are proposed through Github Pull Request. Beyond, the moderation rules are not 10 years old, and those kind of considerations should have been weighted before their establishment. Not answering a public issue or faking silence on it, when it’s not at your advantage, I think it’s called a dilatory tactic in Common Law litigation…

There is no obligation for you to answer this issue and for sure everyone has the right to silence.

I will clarify my position. I believe that there should be no "moderation policy", certainly not a public one, and that I think enemies of the project will optimize adversarial behavior against any such public written "rules" or governance. Any policy that also includes a requirement for moderator actions to be published, or meta discussion in public "official" channel such as this meta repository, also creates a further target for adversarial optimization.

I’ll support a deletion of the “moderation policy” of bitcoin core. I’ve initially supported it, as during the mempoolfullrbf debate, the conversation have been at time less than civil and courteous.

On the other hand, there have been also cases in the bitcoin community of allegations (proven or unproven) of sexual abuse whatever the sex, mentors blackmailing their mentorees, hard to adjudicate issue like when Gavin was revoked his permissions because he was judged “toxic”. Those kind of issues are not “black or white”, more “grey”.

who I remind you are voluntary freely associating individuals, are obligated to act in an interest other than their own. Obligated by who or what?

In the name of what a developer or security researcher is obligated to report security vulnerabilities ? In truth, nothing. At the exception of one’s sense of ethics and principles, something that is indeed raising the question of how do you promote ethics and principles in a decentralized voluntary open source software project.

[pinheadmz]

@ariard open a PR that adds the oversight rules you want to the moderation guidelines document. I can't do it for you because I don't understand your issue well enough, as there have been no actual incidents as far as I know. Meanwhile, Will and I have helped the maintainers clear spam comments and reduce the emotional temperature in controversial issues.

My concern with "conflict of interests" as I understand it from you, is that someone can just claim that every employer in the world has sent them legal notices and therefore no person who has a job is allowed to hide their inflammatory github comments.

[ariard]

I’ll see with Alex and Suhas directly. There is no more to be said.

[ariard]

For the records:

that every employer in the world has sent them legal notices

I’m not a Chaincode employe since June 2020 and my open-source contributions on both Bitcoin Core and Lightning have been started in Spring 2018, i.e a year before I become an employe in June 2019.

All those pre-Chaincode contributions were done during my free and unpaid time as a student during the last year of my software engineering school.

The legal notice was sent after my time as an employee, for matters so confuse (what does the f*ck improper communications means ?) that any decent US judge would rather remind said legal notice author (i.e the Jackson Lewis guy) in the way legal notice should be written to not be accused of intimidation.