CIP-0181? | Remove dRep Requirement for Reward Withdrawals

[Cerkoryn]

Very simple CIP here. Maybe some controversy around it, but I think it's a discussion worth having especially now that governance is bootstrapped and we are seeing some of the negative effects of the choice to have this requirement.

(rendered)

[rphair]

@lehins @WhatisRT if you can think of any reason(s) why removing this from the logic & code will not be as simple as what's described here, please post before our next meeting where this will be up for Triage: https://hackmd.io/@cip-editors/130

[lehins]

I am personally in favor of the CIP and it would be very easy to implement for a new era (eg. could be included in Dijkstra)
Since all we need to do is remove a predicate check. If anything, it would be a simplification for Ledger implementation.
That being said, it is definitely not my call whether this check should or should not be removed. To put it in other words, there is no technical reason why it can't be removed, but I can't speak for any potential social and governance issues that could span from its removal.

[lehins]

I don't believe that listing here IntersectMBO/cardano-ledger#4092 as a valid concern is justified, since this check was not planned to be implemented for scripts. Note that the ticket was closed as a non-issue.

The fact that we've discussed it, does not make it a concern. There are plenty of things developers evaluate before implementing a feature, this was just one of those cases.

I'd recommend removing this section as it is not relevant to this CIP and will only confuse readers, wrongfully thinking that this was ever a concern

[WhatisRT]

I've said it multiple times elsewhere that I don't believe that this restriction leads to any increase in participation & just leads to friction at the wallet level. The issue is that this was made part of the requirements of CIP-1694, and so now this is mostly a question of politics.

So while technically this CIP is a straightforward simplification, I suspect it might be quite difficult to get the buy-in from everyone. I'd be happy to be proven wrong on this.

[fallen-icarus]

Can't it be argued that this predicate is a huge reason why some of the wallet dReps are so large (e.g. Yoroi)? If yes, I actually think the community would get behind this CIP. Yoroi actually adds UX friction to choose a different dRep than themselves. Like choosing a stake pool has a user friendly interface with great information, but choosing a dRep aside from Yoroi is: enter dRep hash. If you don't have it, go find it yourself.

TBH I think this CIP is being too polite about the wallet flow problem.

[Cerkoryn]

@fallen-icarus exactly. And actually if you go to choose a stake pool Yoroi will ALSO bundle a delegation to their dRep in the same Tx.

And I agree that it is probably too polite. I had to dial back some of the language to what I felt would be appropriate for a CIP 😅

In any case the intent is to remove the requirement that contributed to this problem in the first place.

[rphair]

@Cerkoryn - agreed all around at the CIP meeting today (as mentioned in your OP) that this is an (atomically) "simple" proposition: already accepted as doable by Ledger representatives & as a "take it or leave it" proposition for whether or not to make such a change & at what era interval.

@gitmachtl pointed out at the meeting whether it would apply to previous protocol versions & it was confirmed that chains produced from older eras than the one implementing this CIP would naturally still require the dRep to be assigned before making withdrawals.

Please update the containing directory to CIP-0181 as well as the "rendered" link in your OP 🎉