CIP-0021 | Conway update #687
Conversation
There was a problem hiding this comment.
@Ryun1 @Crypto2099 I know I said I wouldn't tag you over the holidays, but also I thought it would be better in the long run to get ahead of a merge conflict with #666 by promptly reviewing & merging either this one or that one.
rphair
added
the
Category: Wallets
janmazak
force-pushed
the
cip-0021-conway
branch
from
3a86a90 to
2414be6
Compare
|
I've rebased it and made a couple of additional small changes, so please review it again to make sure I've not missed anything. |
There was a problem hiding this comment.
@janmazak still looks good to me & matches the changes I recall from before I edited the code base.
I would be OK with merging this now whenever (#687 (comment)) but would also want @KtorZ to look it over first... maybe also with @Ryun1 double checking that key (or cert?) names and/or official descriptions aren't also about to change when #737 is merged (which should also be soon).
|
Id vote to keep this PR open for a little longer, whilst the HWW implementations are being finished off. I dont think there is a rush to merge it? |
|
On the Conway parts, I think this addition is wholly complete. Past that, I do have two suggestions;
|
|
@janmazak I would also be ready to merge this, between the CIP meetings or at the next meeting, once you can follow or refute @Ryun1's suggestions in #687 (comment). |
| * `stake_vote_deleg_cert` | ||
| * `stake_reg_deleg_cert` | ||
| * `vote_reg_deleg_cert` | ||
| * `stake_vote_reg_deleg_cert` | ||
|
|
||
| If a transaction contains a pool registration certificate, then it must not contain: |
There was a problem hiding this comment.
why do we not add any protections like this around constitutional committee keys or DRep keys
There was a problem hiding this comment.
The main reason for pool registration certificate restrictions is that pool owners are signing them with stake keys, which also sign other elements of the transaction (e.g. withdrawals and other certificates), and that's a security risk: the transactions are not created by them and so they might contain, from their viewpoint, third-party elements --- they can't easily distinguish whether a key hash used in a withdrawal belongs to them or not, and a HW wallet does not see the whole tx at once, so cannot warn them that the same stake key hash is used in several places.
With DRep or constitutional committee keys, only votes are signed, nothing else AFAIK.
There was a problem hiding this comment.
With DRep or constitutional committee keys, only votes are signed, nothing else AFAIK.
@janmazak @Ryun1
I have not tested this, but when you do a DRep deregistration, you could also sneak in a vote too. Not sure what the protocol is doing with that. Or the other way round, you just wanna vote, but a deregistration certificates gets sneaked in. So theses two things should not happen within one transaction imo.
There was a problem hiding this comment.
DRep keys are used for votes, registration certs, update certs and resignation certs.
CC Hot keys are only used for voting.
CC Cold keys are used for authorising hot cert and resign cert.
There was a problem hiding this comment.
@Ryun1 do you think its worth to check if there is a vote together with a cert in the transaction?
There was a problem hiding this comment.
to follow the precedent of how stake key signing is handled, yes it makes sense for the check.
But practically speaking, I don't think this is a significant issue, so IMO it is probably fine.
It is quite easy for a DRep to re-register.
There was a problem hiding this comment.
@Ryun1 i was more thinking in a way that if online services provide the feature to easy register as a DRep, if they could sneak in a vote for there proposal f.e. and the user would not see that directly.
There was a problem hiding this comment.
yes this would be easy to do over a dApp.
but of course on the hardware wallet device it still shows the vote to the user, at signing time.
No description provided.