CIP-???? | Default SPO vote

[teodanciu]

Allow SPOs to configure an explicit default vote via pool parameters.

---

(rendered latest proposal version)

[Ryun1]

@Crypto2099's comment from CIP Editors meeting # 123

• Since we are making this change, does it make sense to offer a default "yes" vote?

[Cerkoryn]

Personally I would be opposed to having a default "yes" option to closely mimic our default "no" voting for all governance actions as it applies to dReps and the CC already. I think allowing SPOs to effectively choose default "yes" as an option could cause issues with inactive/myopic SPOs that causes some GAs to pass that otherwise shouldn't.

IF we were to allow default "yes", then I think it should come with some sort of expiration date that requires an SPO to re-affirm this default choice every so often. However I think that added complexity is not worth the benefit and would rather just leave default "yes" out altogether.

[gitmachtl]

I am on the same page as @Cerkoryn , whats the point of a default "yes" vote? Do an "always abstain" if you don't care. A default "yes" vote sounds like a "do whatever you guys want i support it" option.

[rphair]

Didn't see this discussion at the time I posted #1108 (review) but in any case we should consider this an active review item.

[lehins]

See my take on this suggestion: #1108 (comment)

TLDR: it is a bad idea and I am very much against it.

This was also the comment on Discord from Johnny Kelly on Discord about this idea:

So long as the Default Options available are only Auto-Abstain, or No-confidence Delegation.
An Auto Yes Vote Option could be very irresponsible...

[Crypto2099]

There is no fundamental difference from a "default" yes, no, or abstain vote or an explicit vote cast on chain except for the person who wants to agree with any action except for those they explicitly want to cast a "No" or "Abstain" vote on. What questions have been posed to SPOs in the year+ of governance for which they've been responsible that would have been endangered by a default "yes" option?

The CC has no "default" vote option so must always cast an explicit vote for those actions which their vote is required for. For an ecosystem that values personal liberty and freedom of choice and permissionless behavior it's rather strange that three strangers in a quiet back room get to decide which options I'm allowed to choose for myself and which ones are "too dangerous" for me to be trusted with.

You don't get to have it both ways, are we governed by the people, for the people, for the good of the blockchain, or by what whomever happens to be the Ledger team lead at the time thinks is a "good and responsible" decision?

[lehins]

@Crypto2099 That is the beauty of the CIP process. I can suggest whatever the hell I want in my CIP. You don't like it, write your own and stop pushing your opinion on CIP authors.
I am sure you know by now, that online it is usually the loudest person that wins. And you are one of the loudest people I know. So, stop blaming me on using some sort of powers that you think I have and look in the mirror before blaming someone.

[gitmachtl]

@lehins can we make this change - if adopted - without changing cli outputs? for the user it doesn't matter how the "default" vote is set, as long as the output via the cli query stays consistent. would not require to change anything on there side.

[rphair]

@teodanciu we weren't able to confirm this at the CIP meeting today because of some concern over the asymmetry of the configurable vote default (2 editors believed it should be possible to register a yes default).

Some comments at the meeting were made over the fact that an opt-out is much less likely to be delivered than an opt-in. We acknowledged that this could have consequences in some Cardano updates being much more likely to move ahead from intertia rather than real consensus... but I believe this is also mitigated by the fact that such default yes voting would itself be opt-in and therefore not the sole result of inattention or disinterest (cc @Crypto2099 @fallen-icarus).

p.s. discussion of the yes option & adding an "expiration date" to such a setting: see #1108 (comment)

[lehins]

without changing cli outputs? for the user it doesn't matter how the "default" vote is set, as long as the output via the cli query stays consistent. would not require to change anything on there side.

yes, we would just continue reporting the default vote, instead of how it was set.

[lehins]

(2 editors believed it should be possible to register a yes default).

@rphair I believe a default "yes" vote would have serious security implications and should not be allowed as a feature.

• Firstly, voting yes on everything is irresponsible. If researchers and developers thought it was a good idea then we would have also introduce an AlwaysYesDRep. We didn't, because it is a bad idea.
• Secondly, if we introduced a default Yes vote, in a sense it would give the power to SPOs to lower the voting thresholds. Eg. 10% of SPOs choose default always Yes, this would have exactly the same effect as lowering the SPO required threshold, because it would be applicable to all governance actions and would be visible to all parties, including the malicious actors.

I'll put it this way. The goal of this CIP is improve usability of the governance system without compromising the security of the system as it is today, because it does not change the semantics of the Cardano governance. If SPOs feel they want to change the actual semantics, they should propose a whole new CIP with whatever new features they prefer. With that said, heads up to anyone that will suggest a CIP that tries to introduce a default "Yes" vote for any entity, I personally and I am sure many others will be very much against it.

My call to reviewers of this CIP, especially SPOs, you should ask only one question: are SPOs fine with supplying the default vote using indirection through the delegation to a predefined DRep or they prefer an actual setting for this concept in the pool params? If majority prefers the former, then feel free to close this CIP, I am happy to have less work for the Ledger team, since we have plenty of other things to worry about.

[rphair]

OK @lehins you've convinced me 😇 ... @Crypto2099 @Ryun1 I think therefore this should be put back on the agenda for the next CIP meeting since the main obstruction to its being confirmed as a CIP candidate has likely already been addressed. If there's unanimity from editors some time this week I'd be happy to switch its status to Confirmed and assign a CIP number.

[Crypto2099]

(2 editors believed it should be possible to register a yes default).

@rphair I believe a default "yes" vote would have serious security implications and should not be allowed as a feature.

• Firstly, voting yes on everything is irresponsible. If researchers and developers thought it was a good idea then we would have also introduce an AlwaysYesDRep. We didn't, because it is a bad idea.

Correct me if I'm wrong, but this is supposed to be a blockchain and community driven by consensus, not what the "Ledger Team Lead" feels, personally, is "irresponsible" behavior? We should take your "It is a bad idea" as canonical fact because... reasons? Why is voting "No" on everything somehow morally righteous while voting "Yes" on everything is morally ambiguous?

• Secondly, if we introduced a default Yes vote, in a sense it would give the power to SPOs to lower the voting thresholds. Eg. 10% of SPOs choose default always Yes, this would have exactly the same effect as lowering the SPO required threshold, because it would be applicable to all governance actions and would be visible to all parties, including the malicious actors.

If 10% of SPOs always cast a "Yes" vote anyway, does it fundamentally matter whether they did it via an "auto" vote or via casting transactions on chain?

I'll put it this way. The goal of this CIP is improve usability of the governance system without compromising the security of the system as it is today, because it does not change the semantics of the Cardano governance. If SPOs feel they want to change the actual semantics, they should propose a whole new CIP with whatever new features they prefer. With that said, heads up to anyone that will suggest a CIP that tries to introduce a default "Yes" vote for any entity, I personally and I am sure many others will be very much against it.

What semantics would be changed by introducing the ability to always vote "Yes" unless the operator felt a need to cast an explicit "No" vote? Isn't the CIP process and the fact that we are discussing and debating making changes to the ledger (right now) the perfect time to raise and have this discussion?

Can we talk a bit more about this point which basically says: Fuck you, I'm not going to do anything I don't feel like doing?

With that said, heads up to anyone that will suggest a CIP that tries to introduce a default "Yes" vote for any entity, I personally and I am sure many others will be very much against it.

My call to reviewers of this CIP, especially SPOs, you should ask only one question: are SPOs fine with supplying the default vote using indirection through the delegation to a predefined DRep or they prefer an actual setting for this concept in the pool params? If majority prefers the former, then feel free to close this CIP, I am happy to have less work for the Ledger team, since we have plenty of other things to worry about.

You also seem to be personally happy with not actually having a discussion and simply mandating and dictating to the community what your team will and won't do, why even bother with the CIP process at all?

[Crypto2099]

...since the main obstruction to its being confirmed as a CIP candidate has likely already been addressed.

Where, exactly, was the concern about adding a default "yes" option addressed aside from Alexey stating that he personally feels that it is irresponsible and a bad idea?

[rphair]

@Crypto2099 I said "likely" addressed because of the likelihood that lots of others across the ecosystem are of the same opinion as @lehins. Eventually this current matter will be put up to some consensus decision that will reflect this + some commonly accepted principles of the governance process in which the default-yes idea has already been voted down in a number of contexts.

That's certainly enough to get this PR back on the review agenda to see if we can revisit this CIP's candidacy in the short term vs. punting it into the long term while leaving this Unconfirmed indefinitely. I might be happy to see the symmetry of a default-yes setting on general principles (as one of the "2 editors" counted above), but I wouldn't stand against the entire evolutionary process of CIP-1694 to do it.

In any case we've highlighted that issue now, and both editors & reviewers can keep highlighting it even after this CIP might be accepted as a candidate... right up until the point when this PR is either merged or closed.

[Crypto2099]

@Crypto2099 I said "likely" addressed because of the likelihood that lots of others across the ecosystem are of the same opinion as @lehins. Eventually this current matter will be put up to some consensus decision that will reflect this + some commonly accepted principles of the governance process in which the default-yes idea has already been voted down in a number of contexts.

That's certainly enough to get this PR back on the review agenda to see if we can revisit this CIP's candidacy in the short term vs. punting it into the long term while leaving this Unconfirmed indefinitely. I might be happy to see the symmetry of a default-yes setting on general principles (as one of the "2 editors" counted above), but I wouldn't stand against the entire evolutionary process of CIP-1694 to do it.

In any case we've highlighted that issue now, and both editors & reviewers can keep highlighting it even after this CIP might be accepted as a candidate... right up until the point when this PR is either merged or closed.

I disagree entirely. If we don't have a default Yes option then it is equally irresponsible to have a default No option because what if people simple select Default No and halt all on-chain governance progress indefinitely because they can't be bothered to participate? I believe that this argument was never properly raised and is constantly using a straw man as its bogeyman to scare people away from talking about a default yes option ("Oh noes, what if the bad guys get the monies from the treasuries cause you weren't paying attention!").

[lehins]

@Crypto2099 Introducing the default Yes vote is not what this CIP is about!
I am one of the authors of the CIP. And I am telling you and others as the author of this CIP, not as a Ledger team lead, that this feature is not going to be part of this CIP, because I am against it.
I am also letting everyone know my opinion, this time as a Ledger team lead, on the suggestion of introducing the default Yes vote, that it is a bad idea, but it has nothing to do with this CIP!
So, if you feel strongly about introducing such feature, please, by all means, submit a new CIP. I am not going to argue with you or anyone else about it on this CIP!
If you, as a reviewer, feel strongly of not approving this CIP, because it does not also introduce the feature you would like, feel free to reject this CIP and we can close this conversation. However, if you would like to create a CIP about adding a default Yes vote for SPOs, you should know, that you need this CIP, because it is a prerequisite.

Hopefully, I made myself clear on the topic of the "default Yes vote misfeature"

You also seem to be personally happy with not actually having a discussion and simply mandating and dictating to the community what your team will and won't do, why even bother with the CIP process at all?

Now, on the topic of you accusing me of dictatorship and using some sort of magic power you think that I have.

First of all, I am literally having a discussion with you and others on this and other CIPs that I participated in. The fact that I am not agreeing with you or you simply don't like what I have to say, does not mean I am not discussing it.
Second of all, my job as a lead is to make sure that Ledger and Cardano as a whole is safe. If I see a suggestion that can compromise it even a bit I will always say "No", because that is my number 1 priority. However, most of the time it is not even my decision which CIP should be implemented.
Most importantly, it is not in my power or in my desire to tell anyone what they should or should not do. So, do not for a second think that I can dictate anything to anyone in the Cardano community. All I can do is use my expertise to provide my profession recommendation. If you do not value my opinion, then so be it, I could not care less.
That being said, if I will be told by my management that my team shall implement a CIP, even if I disagree with it, I will do everything in my power to get it done, because that is where my responsibilities are. If you don't like that, please complain to my employer. It is definitely not my job to convince every person in the world who has an opinion on a matter whether their opinion is right or wrong. Especially not the ones that try to accuse me or blame me for whatever reason.

Where, exactly, was the concern about adding a default "yes" option addressed aside from Alexey stating that he personally feels that it is irresponsible and a bad idea?

https://x.com/intertreeJK/status/1953649313118375997

[Crypto2099]

@Crypto2099 Introducing the default Yes vote is not what this CIP is about! I am one of the authors of the CIP. And I am telling you and others as the author of this CIP, not as a Ledger team lead, that this feature is not going to be part of this CIP, because I am against it. I am also letting everyone know my opinion, this time as a Ledger team lead, on the suggestion of introducing the default Yes vote, that it is a bad idea, but it has nothing to do with this CIP! So, if you feel strongly about introducing such feature, please, by all means, submit a new CIP. I am not going to argue with you or anyone else about it on this CIP! If you, as a reviewer, feel strongly of not approving this CIP, because it does not also introduce the feature you would like, feel free to reject this CIP and we can close this conversation. However, if you would like to create a CIP about adding a default Yes vote for SPOs, you should know, that you need this CIP, because it is a prerequisite.

Hopefully, I made myself clear on the topic of the "default Yes vote misfeature"

You also seem to be personally happy with not actually having a discussion and simply mandating and dictating to the community what your team will and won't do, why even bother with the CIP process at all?

Now, on the topic of you accusing me of dictatorship and using some sort of magic power you think that I have.

First of all, I am literally having a discussion with you and others on this and other CIPs that I participated in. The fact that I am not agreeing with you or you simply don't like what I have to say, does not mean I am not discussing it. Second of all, my job as a lead is to make sure that Ledger and Cardano as a whole is safe. If I see a suggestion that can compromise it even a bit I will always say "No", because that is my number #1 priority. However, most of the time it is not even my decision which CIP should be implemented. Most importantly, it is not in my power or in my desire to tell anyone what they should or should not do. So, do not for a second think that I can dictate anything to anyone in the Cardano community. All I can do is use my expertise to provide my profession recommendation. If you do not value my opinion, then so be it, I could not care less. That being said, if I will be told by my management that my team shall implement a CIP, even if I disagree with it, I will do everything in my power to get it done, because that is where my responsibilities are. If you don't like that, please complain to my employer. It is definitely not my job to convince every person in the world who has an opinion on a matter whether their opinion is right or wrong. Especially not the ones that try to accuse me or blame me for whatever reason.

Where, exactly, was the concern about adding a default "yes" option addressed aside from Alexey stating that he personally feels that it is irresponsible and a bad idea?

https://x.com/intertreeJK/status/1953649313118375997

I'm going to let this go on the premise that you fairly raised that it is outside of the scope of this particular CIP which is merely addressing the mechanism by which an SPO may signal their prefered, default option. However, please do not back up future arguments with a Twitter poll that achieved 42 total votes representing roughly 10% of the people who even saw the poll in the first place which represents less than 20% of the total SPO population assuming all of the Twitter viewers were also SPOs.

[lehins]

However, please do not back up future arguments with a Twitter poll that achieved 42 total votes representing roughly 10% of the people who even saw the poll in the first place which represents less than 20% of the total SPO population assuming all of the Twitter viewers were also SPOs.

I am not backing anything up. You asked a question: "was there anyone beside Alexey" and I posted Johnny's tweet who said: it seems like it would be irresponsible. It also happens to have a poll that shows how some random people on the internet feel.

You wanna continue arguing about nothing and continue wasting my time?

[intertreeJK]

Hey, since a random Poll I once Posted on ex-twitter (like your ex-girlfriend) has be cited in this thread.

I would just like to formally acknowledge that it is/was not in ANY way a representative sample of Cardano Community Sentiment.

Carry on folks, and have a nice day!

[gitmachtl]

I am neutral to the method on how to set the default vote behavior for a stakepool. But, as this affects Stakepool Operators, i opened up a sentiment poll in our closed SPO-Channel group and asked a simple question if SPOs are fine on how the default vote behavior is currently set via the pool-rewards-account dRep delegation. Or if they would prefer to set it as a pool parameter via a pool re-registration.

Current result after 53 votes is:

• 81% i am fine how it is right now for 1+ year
• 19% i don't like the poolRewards method and would rather do a pool re-registration to set my default vote

I don't know if this is something that can influence decisions, but i wanted to give this feedback. Poll will stay open for a while.

Best regards, Martin