Ratified Doc 101 - Removal of ANO from the Authority Set for Cause

Public: Only invited members may reply

  • Viewed Bedrock Solutions Bedrock Solutions Blockchain Innovation Foundation Blockchain Innovation Foundation Blockrock Mining Blockrock Mining Brian Deery BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers CryptoLogic CryptoLogic Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factom Inc Factom Inc Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This Go Immutable HashnStore HashnStore Julian Fletcher-Taylor LayerTech LayerTech Luciap Luciap Matters Matters Multicoin Capital Multicoin Capital Niels Klomp PrestigeIT PrestigeIT Quintilian RewardChain RewardChain Samuel Vanderwaal Stamp-IT Stamp-IT Syncroblock Syncroblock The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified?


All votes are in

  • Total voters
    31
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Hi Sam,

Do you mean Guides or ANOs? Can you point me to the section of the document you're referring to?
This is the section:
"During the meeting the Guides shall hold a vote, and for the removal motion to pass there shall be an affirmative vote by a majority of the Disinterested Guides. Disinterested Guides must not abstain from the vote. "

There is also another one section just above mentioning a majority of disinterested guides. Could be better to explicit what majority is considered.
 
Hence my preference for no quorum, thereby avoiding these dynamics all together. If I'm seeing this incorrectly, please let me know!
Hi Jay!

The issue with no quorum is: what happens if quite a large portion of ANOs get used to not actively participate? We are in a locked situation. That is why the quorum has been made for.

I understand your concern about lowering the threshold but it is not really a good point as it depends on us all together to prevent a minority of ANOs to take control. A quorum is just a minimum participation needed to consider the vote valid or democratic. Not a maximum value.

Implicitly you suppose that there is more chances for ANOs to participate to kick out another ANO than to participate to defend another ANO.
Not sure I agree with that and it also a good incentive to be scared by some ANOs taking control. Nothing replace vote participations.
 
Please correct me if wrong but I see the potential difference is this:
  • With a quorum rule, if an ANO abstains from voting it makes it harder for the removal process to be successful.
  • Without the quorum rule, then an ANO abstaining makes it easier for the removal process to succeed.
Having read through the document again, I've noticed we haven't discussed whether the ANO vote would be private or not?

The removal of an ANO could very well be contentious. Imagine a situation where an ANO goes through the removal process but survives and knows exactly who voted for their removal.

Some ANOs might want to avoid politics by abstaining the vote. Presumably, it's likely that those who do vote would be voting for the removal of the ANO, thus not having a quorum would make it much more likely to succeed.

In my opinion, we need the quorum to ensure that ANOs participate but I do see the danger in this also. If the community for some reason dies and we have a number of ANOs who decide not to participate anymore then we need some kind of mechanism for removing them.

It might actually make sense for us to have a different set of voting requirements for removing an ANO due to non-participation?
 
I would like to simplify the discussion down to four questions then:

1. % of Disinterested Guides that need to vote "Yes" for motion to proceed?
The document currently specifies a majority, which I believe is legally defined as 51%, correct? @Shuang Leng @Nikola is there any ambiguity with the term "majority"? I interpret it as "a number or percentage equaling more than half of a total"

2. Should there be a quorum required on the ANO vote?
I say no, agreeing with you and the others' points regarding this.

4. % of ANOs that need to vote "Yes" for the motion to be ratified?
Note: If #2 is "No", this is % of total ANOs. If #2 is "Yes", this is % of total voting ANOs.
The consensus seems to fall on 2/3, 66% which I also think is a good number.
 
Hi Sam,



This is the section:
"During the meeting the Guides shall hold a vote, and for the removal motion to pass there shall be an affirmative vote by a majority of the Disinterested Guides. Disinterested Guides must not abstain from the vote. "

There is also another one section just above mentioning a majority of disinterested guides. Could be better to explicit what majority is considered.
See my post above. I believe "majority" means 51% but have asked our resident attorneys if I'm understanding that correctly.
 
I’m not aware of a standard legal definition. If guides are only allowed to vote yes or no, then I don’t see any ambiguity. The only issue I can foresee is how to count potential lack of votes from unresponsive guides. It wouldn’t hurt to write that sentence in children’s terms along the lines of: “for a removal motion to pass, there shall be more approving ‘yes’ votes than disapproving ‘no’ votes from the Disinterested Guides.”
 
Added a bunch of comments to the google doc. Sorry for being late to the party.

Some big ones:
  1. The process is solely in control of the guides.
  2. The document isn't necessary once full standing parties are implemented
  3. The process is private to ANOs and Guides and the community is only notified if the ANO is removed.
  4. A "Standing Party" can start the process, but in this document "Standing Party" isn't defined. If I use the Doc 001 definition, then the references to ANOs, private threads, and guides in this document are a bit hard to understand. I think this document could use its own definition (i.e. Guides and ANOs are currently the only standing parties)
  5. In fact, a number of terms are defined inline instead of in a definitions section.
  6. In Doc 001, Guides are removed using a straight forward up down vote, either taking some time to deliberate, or quickly due to gross misbehavior. Not quite sure the simple path isn't the better path for ANOs as well.
  7. We lack any instruction on what core developers maintaining the network are to do should an ANO attack the network with their authority. This could be intentional or non-intentional, but core developers need the right to remove a misbehaving node from the network on a temporary basis if that is what is necessary to get the network running or keep it running.
Edited for Clarity, and to add numbers for easier reference.
 
Last edited:
Added a bunch of comments to the google doc. Sorry for being late to the party.

Some big ones:
  • The process is solely in control of the guides.
I don't think it's fair to say it's "solely in control of the guides" though it's probably fair to say that Guides have an outsized role in the process. One way to fix that would be to get rid of the first phase of the process where Guides either reject or confirm a removal motion and let it go straight to ANOs.

  • The document isn't necessary once full standing parties are implemented
I think we need something in the meantime, but I agree.


  • The process is private to ANOs and Guides and the community is only notified if the ANO is removed.
What are the pros and cons of this in your opinion?

  • A "Standing Party" can start the process, but in this document "Standing Party isn't defined"
Standing Parties are defined in the Governance document but we currently only have a few of them implemented so that's probably a fair point.

  • In fact, a number of terms are defined inline instead of in a definitions section.
We can change this unless legal says there's a good reason not to.

  • Guides are removed using a straight forward up down vote, either taking some time to deliberate, or quickly due to gross misbehavior. Not quite sure the simple path isn't the better path.

The governance document says this for Guide removal:

Guides can be removed by a vote of no confidence initiated by at least 10% of the standing party weight, and voted upon over 30 days. A 51% vote to remove a guide is required.

A motion of no confidence initiated by 50% of the standing party weight, and passing with 60% of the standing party weight will take effect immediately.
This may or may not be suitable for Guide removal, but I definitely think it is too low of a bar for ANO removal. In terms of the simplicity of the process, you may be on to something, but I'm concerned that we have to have a well-defined thorough process for ANO removal as it's a bigger deal than removing a Guide, IMO. I'm open to different approaches and ideas here though.

  • We lack any instruction on what core developers maintaining the network are to do should an ANO attack the network with their authority. This could be intentional or non-intentional, but core developers need the right to remove a misbehaving node from the network on a temporary basis if that is what is necessary to get the network running or keep it running.
This should probably be within the domain of the Core Committee?
 
I don't think it's fair to say it's "solely in control of the guides" though it's probably fair to say that Guides have an outsized role in the process. One way to fix that would be to get rid of the first phase of the process where Guides either reject or confirm a removal motion and let it go straight to ANOs.
Yeah but a private process gated by the guides (what is written here) puts the guides in exclusive control.

What are the pros and cons of this [a completely private process] in your opinion?
Removal of an ANO in a completely private process is a real problem if the goal is to build an involved community. This is what staking provides, a path for community involvement that isn't a full time job (which guides and ANOs practically are right now). And right now grants are going mostly to ANOs, which also fails to spread out the influence of the protocol.

The con is of course the public drama of a public execution. But I'd hope that the politics of the process could create informal ways of private negotiation to avoid drama when it can be avoided. And I'd say we take it on the chin when the drama can't be avoided. Because this keeps decisions in the community to the extent possible.

We can change this [lack of a definitions section] unless legal says there's a good reason not to.
This is pretty standard in nearly all legal documents, so I'd expect no legal issue breaking out key definitions.


The governance document says this for Guide removal:
Guides can be removed by a vote of no confidence initiated by at least 10% of the standing party weight, and voted upon over 30 days. A 51% vote to remove a guide is required.

A motion of no confidence initiated by 50% of the standing party weight, and passing with 60% of the standing party weight will take effect immediately.
This may or may not be suitable for Guide removal, but I definitely think it is too low of a bar for ANO removal. In terms of the simplicity of the process, you may be on to something, but I'm concerned that we have to have a well-defined thorough process for ANO removal as it's a bigger deal than removing a Guide, IMO. I'm open to different approaches and ideas here though.
The magic of the Guide removal process is that it is simple. You could easily structure all this other stuff around the simple approach but leave it informal. And there are avenues of getting around road blocks, like guides protecting favored ANOs. Nothing in the current system allows for a work around of such a situation in the current proposal.

This [how to respond to immediate issues from an ANO for the network] should probably be within the domain of the Core Committee?
Well if so, then this document should point to the process. And keep in mind, even the Core Committee is not set up currently to do anything immediately. The only parties devoted to being accessible are the ANOs and immediate and timely dialog with ANOs is already part of the network crisis process. I'd actually claim this is something to be in the governance document, how to respond where action must really be taken immediately. Lacking anything (today's situation) we will boot ANOs and get the network running, then ask forgiveness and address the impacted ANO after the fact. And hope everyone can understand why actions were taken.
 
Well if so, then this document should point to the process. And keep in mind, even the Core Committee is not set up currently to do anything immediately. The only parties devoted to being accessible are the ANOs and immediate and timely dialog with ANOs is already part of the network crisis process. I'd actually claim this is something to be in the governance document, how to respond where action must really be taken immediately. Lacking anything (today's situation) we will boot ANOs and get the network running, then ask forgiveness and address the impacted ANO after the fact. And hope everyone can understand why actions were taken.
If/when that process is created, this document can be amended to point to it. I would certainly support such an amendment.
 

Chappie

Factomize Bot
Ben Jeater has seconded the motion to end the discussion early.

A motion is now active at the top of this thread to vote if you want to end the discussion early and move on the next phase. A majority voting yes will pass the motion and the discussion will be closed immediately. This vote will remain open until the normal discussion period ends or another motion is passed.
 
@Alex @CryptoVikings @Julian Fletcher-Taylor @Jay Cheroske @Ben Jeater @Alistair McLeay @Miguel Proulx @Niels Klomp @Valentin Ganev @Tor Paulsen @Mike Buckingham @Colin Campbell @Matthias Fortin

Sorry, everyone, we're not quite done with this discussion. Here are the salient points I've tried to pull out of the comments Brian and Paul added to the Doc:

  • Should the Guides be the gatekeepers to the process?
    • Guides currently act as a filter for new removal initiation requests
    • This potentially gives them a lot of power for blocking removal requests they don't approve
  • Is 2.1.3 fine as is for limiting spam or should it be modified?
    • It could be changed to limit removal motions from entities instead of against entities
    • It could be changed to require a support level for initiation similar to how the Governance document 001 describes guide removal
    • Others?
  • Should the process stay private as described in the document or should it be more public?
  • The Emergency Suspension takes a lot of procedure and may not be sufficient in cases where we need to act immediately to suspend a malicious ANO causing damage to the network
Paul, please chime in if I don't have these right or add other points I missed. We're running out of time for this discussion and it needs to happen here rather than in comments on the document itself.
 
Should the Guides be the gatekeepers to the process?

[*]Guides currently act as a filter for new removal initiation requests
[*]This potentially gives them a lot of power for blocking removal requests they don't approve
My initial inclination is no. Our goal is to automate out Guides at some point anyway. I'd prefer to not have it but if Guides are in the process, it won't result in Factomize voting no.
[*]Is 2.1.3 fine as is for limiting spam or should it be modified?

[*]It could be changed to limit removal motions from entities instead of against entities
[*]It could be changed to require a support level for initiation similar to how the Governance document 001 describes guide removal
[*]Others?
I believe it is fine as is.
[*]Should the process stay private as described in the document or should it be more public?
I agree with Paul it should be public.
[*]The Emergency Suspension takes a lot of procedure and may not be sufficient in cases where we need to act immediately to suspend a malicious ANO causing damage to the network
My suggestion would be to amend this to have a process drawn up by the Core and Code Committee. Say something like, "An ANO can be suspended immediately by the Core and Code Committee via process document XXX. And then we take that process through ratification so we all approve.
 
2.1.3 creates a situation where an ANO could win the removal vote (not be removed) and then basically do whatever they want (efficiency to 0%, non-adherence to ANO Guidelines, etc.).

In general, I'm not too worried about spam. If ANO wants to spam this process, they will look foolish and it will hurt their social standing.

Maybe a compromise is that the same party that initiated the removal vote cannot do so for three months?
 
2.1.3 creates a situation where an ANO could win the removal vote (not be removed) and then basically do whatever they want (efficiency to 0%, non-adherence to ANO Guidelines, etc.).

In general, I'm not too worried about spam. If ANO wants to spam this process, they will look foolish and it will hurt their social standing.

Maybe a compromise is that the same party that initiated the removal vote cannot do so for three months?
Matt if an ANO does that they would obviously be wrong next round. Where the spam issue comes in is when we have expanded standing parties and someone have 50 staked addresses and keeps creating motions to remove
 
A compromise might be the same type of standing party cannot make a motion within 3 months. So if an ano made a motion a staked or user or grant recipient still can. This will reduce spam but not handcuff is for 3 months
 
Look at it this way:
A person gets arrested for burglary, goes to court, and then is deemed not-guilty. What society needs to guard against is that person being arrested for the exact same offense (double jeopardy). The way section 2.1.3 is written means that this person could actually go out and commit any crime he wanted and not be charged for three months. That's something we need to avoid.
 
But we also need to stop the cop who has a grudge.
A compromise might be the same type of standing party cannot make a motion within 3 months. So if an ano made a motion a staked or user or grant recipient still can.
We don't have "staked" or "grant recipients" standing parties yet and wont anytime soon.

1. We can put a decent speed bump in place by not letting the same ANO bring the charge twice
2. If a different ANO brings the claim, then the guides reviewing the claim can easily dismiss it with only a few minutes of time if they deem it spam
 
Why not future-proof the document to a degree and solve the problem you describe at the same time?
If we had more than two standing parties, I'd agree with your solution. I look forward to the day when we can implement it. But, we only have two standing parties right now. Therefore, I don't see the need to unnecessarily handcuff ourselves with overly stringent guidelines.

*The risk/damage of spam is minimal and easily addressed.
*The damage that could done by an ANO that is very difficult to remove because of some three month rule is vastly greater.

I vote for mitigating the greater risk/threat.
 

Chappie

Factomize Bot
PaulSnow has made a motion to extend the discussion. If someone seconds this motion by selecting the button below, a vote on the motion will start.

A majority voting yay will pass the motion and the discussion will be extended for 72 hours. This motion will remain open until the normal discussion period ends or a motion to end the discussion is passed by a majority.
 

Chappie

Factomize Bot
Matt Osborne has seconded the motion to extend the discussion.

A motion is now active at the top of this thread to vote if you want to extend the discussion. A majority voting yes will pass the motion and the discussion will be extended for 72 hours. This vote will remain open until the normal discussion period ends or another motion is passed.
 
My suggestion would be to amend this to have a process drawn up by the Core and Code Committee. Say something like, "An ANO can be suspended immediately by the Core and Code Committee via process document XXX. And then we take that process through ratification so we all approve.
I don't think the Core and Code Committee (which has no mechanism to have a meeting in a timely fashion) should be involved in the immediate process. After the fact, well, hard to say about that too. I am on the committee, but if it has ever met, I don't know about it.
 
Status
Not open for further replies.
Top