CIP-0036 | Change reward address field for Fund 10 #373
Conversation
Why should an incorrect type still be valid? |
Good question. The idea is that its a lesser sin to not get a reward for voting than be denied your voting rights, due to a reward address change outside of your control, that you may have not found out about until after its too late. Registrations should entitle you to vote. IF the rewards address is something we can pay to, AND you earn a reward, then a reward gets paid to it. (forwarded answer from @stevenj) |
|
lgtm |
|
How are you going to explain this change to those of us who struggle with change? I just figured out how to vote, Fund9 was my first. What is "regular payment address"? I hold my Cardano on Daedalus. |
don't worry. daedalus will get an update in time. |
@GitCardano - This change is to be implemented by wallets and supporting tools. End users/voters should not have to do anything but keep their wallet/tool of choice updated. |
rphair
added
the
Update
There was a problem hiding this comment.
My reading of the dialogue so far is that all reservations have addressed so I would readily approve this, pending:
- @KtorZ - I assume will want to give it a good technical review (I'm not qualified to determine if there could be any hang-ups in doing it this way).
- @Ryun1 - Is there a way we can verify that IO > Catalyst team actually intends to do things this way? (see below)
(edit, added) Although this requires changes to wallets in production I would forego the usual "Path to Active" because with IO's official endorsement it seems that wallets starting with Daedalus would be forced to implement the change quickly & as a matter of course.
CIP-0036/README.md
Outdated
| @@ -230,6 +230,10 @@ Fund 8: | |||
| - added the `voting_purpose` field to limit the scope of the delegations. | |||
| - rename the `staking_pub_key` field to `stake_credential` and `registration_signature` to `registration_witness` to allow for future credentials additions. | |||
|
|
|||
| Fund 10: | |||
| - stipulated that `reward_address` must be a Shelley payment address, otherwise voting reward payments will not be recieved. | |||
| - **Note:** up to Fund 9 `reward_address` was a Shelley rewards address; from Fund 10 onwards, it will be a normal payment address. This will allow rewards to be paid directly from the designated Catalyst pot rather than requiring MIR transfers. | |||
There was a problem hiding this comment.
Could we add a link to some Catalyst documentation that verifies this change? If no link exists, could we add some background here about the Catalyst team's decision to do this?
There was a problem hiding this comment.
This will allow rewards to be paid directly from the designated Catalyst pot
What is, the "designated Catalyst pot" ? I thought this pot was precisely called the "treasury" 😶 ?
There was a problem hiding this comment.
@KtorZ from my reading of the CIP currently, Fund 10 will allow (or be based on) paying from accounts that are not the treasury. But @Ryun1 there is still a need to document this change. The Catalyst changes are usually documented on a Git Doc somewhere & I still believe we should have a link to this resolution in the CIP text.
There was a problem hiding this comment.
@rphair I think there is a misunderstanding here. Proj Catalyst did not make a decision to make this change. Proj Catalyst was forced to by circumstance and directive. IOG does not control the keys sufficient to perform MIR transfers, so its incapable of performing them. The only documentation proj catalyst has on registration and delegation is CIP-15 and CIP-36. The motivation therefore is "Project Catalyst would like to continue to have the option of paying voter rewards. Now that MIR transfers are unavailable for that purpose, the only option is to change the reward address to a normal payment address. This also has the added benefit that these formats can be utilized by other applications, which is what the CIP-36 specifically envisioned when it added a voting purpose to the record. In recognition that this change may cause a large number of previously registered voters to now have an 'invalid' registration, the prudent course would seem to be not denying a voter the right to vote, simply because they would be unable to receive a voter reward through no fault of their own.". Or words to that effect.
There was a problem hiding this comment.
There was a problem hiding this comment.
See, updated motivation section :)
There was a problem hiding this comment.
thanks for updates @Ryun1 but so far I'm only seeing the Motivation section of the CIP draft has had "address" changed to "payment address" & no other changes. @stevenj's comments are now reflected in the original post of this PR but I don't see them in the CIP document yet... have I missed something?
Co-authored-by: Ján Mazák <[email protected]>
CIP-0036/README.md
Outdated
| @@ -110,7 +110,7 @@ considered valid if the following conditions hold: | |||
| The advised way to construct a nonce is to use the current slot number. | |||
| This is a simple way to keep the nonce increasing without having to access | |||
| the previous transaction data. | |||
| - The reward address is a Shelley address discriminated for the same network | |||
| - The reward address is a Shelley payment address discriminated for the same network | |||
There was a problem hiding this comment.
That sentence reads funny now 🙃 ... "reward_address is a payment address". Naming things is hard I guess.
-> Might be good to consider renaming the field altogether.
There was a problem hiding this comment.
maybe we should change it here and in the cddl from rewards_address to voting_rewards_payout_address. or remove the wording "rewards" in total and just call it voting_payout_address or even just payout_address.
There was a problem hiding this comment.
I'm on the fence about renaming it, I would like further input.
Historically, before Catalyst's Fund 4, this field was a payment address and was named reward_address, see #89 - it does not appear to have been an issue back then. With that said, I do understand additional the potential for confusion as this is not the first time this field has changed.
There was a problem hiding this comment.
See most recent commit, I have renamed the field to just payment_address. In addition to making things clearer, I believe removing the notion of rewards from the field name makes the specification less Catalyst specific; as the notion of voting rewards are Catalyst specific.
There was a problem hiding this comment.
@Ryun1 hey, yes thx i have seen it and i think its ok. but tbh, i have not really seen a problem calling it rewards_address too. But its clear now IMO.
Co-authored-by: Ján Mazák <[email protected]>
Ryun1
changed the title
There was a problem hiding this comment.
Looks to me like last round of editing covers everything & I will leave it to @KtorZ & maybe also @SebastienGllmt to double-check.
…n#373) * Stressed payment address for reward payments * Adjusted wording and started with test vectors * Reset changes to test vectors * Added test vectors * Typos + added public gov key to test vectors * Missed comma * Update CIP-0036/README.md Co-authored-by: Ján Mazák <[email protected]> * Update CIP-0036/README.md Co-authored-by: Ján Mazák <[email protected]> * Removed cardano-cli specific notation from test vectors, just leaving CBOR hex * Renamed rewards_address field to payment_address * Addressed @KtorZ comments Co-authored-by: Matthias Benkort <[email protected]> Co-authored-by: Ján Mazák <[email protected]>
Proposed Change
Replace
reward_addresswithpayment_address. Wherepayment_addressshould be a Shelley payment address. This means that the payment of voting rewards in Catalyst can no longer be done via MIR transfer but rather require regular transactions.Motivation
Past Catalyst's Fund 9, MIR transfers will be unavailable to be used by Project Catalyst. The operators of Project Catalyst, IOG, do not control the keys necessary to perform MIR transfers. This aligns Catalyst with all other projects implementing this standard.
Historically the use of MIR transfers by Project Catalyst was allowed to save on the costs associated with the payment of thousands of voting rewards. But this application was beyond the intended design of the mechanism since Project Catalyst is not a core network function.
The removal of this constraint makes the application of this standard more practical for projects beyond Catalyst to adopt.
Note: In an effort to ease the transition and not remove voting rights unexpectedly from already registered voters, Catalyst's Fund 10 registrations/delegations with the incorrect type of
reward_addresswill still be valid, but will not be eligible to receive voting rewards.cc: @kevinhammond @stevenj @ehanoc