CIP-0005 | update drep and cc identifier prefixes

[ashisherc]

Update drep hashes prefix to reflect the actual hash type, as dRep ID is not just a hash but a credential (unlike pool ID), we need a hex representation of the various keys, bech32 is supposed to be only for the human-readable representation.

eg.

• modify drep -> drep_vkh
• cc_cold > cc_cold_vkh
• etc

---

drep, cc_cold etc prefix to be used to represent the credential hex format, to be proposed in a dedicated CIP.

[gitmachtl]

whats a drep address? there is just an ID

drep1xxx
drep_script1xxx

there is also no flag or prebyte that would differ from a mainnet or testnet "address". like with a pool id, there is just one. same for mainnet and testnets.

a drep-id is like a pool-id. you can delegate to it. i don't see how such an id would count as an address?

[ashisherc]

whats a drep address? there is just an ID

drep1xxx drep_script1xxx

there is also no flag or prebyte that would differ from a mainnet or testnet "address". like with a pool id, there is just one. same for mainnet and testnets.

a drep-id is like a pool-id. you can delegate to it. i don't see how such an id would count as an address?

dRep-id is not same as pool id, pool ID is a single hash, whereas dRep is a credential with - type and key field, see here, https://github.com/IntersectMBO/cardano-ledger/blob/a44a5b5ac9f68c5d7a2ff38b040a5fcac8ccfc6a/eras/conway/impl/cddl-files/conway.cddl#L338

similarly, a stake address is defined with stake credential and an additional network flag is added to identify if a stake address is on mainnet or testnet.

Similarly a dRep address is combination of network flag + dRep Credential

[gitmachtl]

there is no network flag for a drep id. i made an issue about that i think a year ago if such a thing should be implemented, did not get the attention of many, result was: "no we don't need a network flag for dreps"

[gitmachtl]

that was the issue i opened back in time: #564

[ashisherc]

1001 - 1101 are reserved for future address formats, which unfortunately is not enough to define all the addresses above. I'd also like to point out that a unique hex representation of the above credentials is also required.

[ashisherc]

Since a network flag is probably not required for these addresses, should we use the network flag bytes instead for specifying the credential type and defining a new schema for these addresses, eg.

4-7 bits define the address type

0000 - cc_hot
0001 - cc_cold
0010 - drep

0-3 bits define the credential type

0000-0001 reserved (to avoid accidental fund transfers, as 0-1 is network tag in normal address)

0010 - keyhash28
0011 - scripthash28

eg. dRep address of keyhash credential type
2227ce10b87147e3e19a5dc622b6a535ab9ce01cb2d586a3a690a74c0e

[Ryun1]

Hey @ashisherc, thanks for opening this.

A few thoughts from me;

• The DRep ID definition was inherited from CIP-1694 here.
• CIP-105 adds some extra context and thought around this, see rationale on Why not allow network tags?
  • to add more to this, at the time there just was not really an appetite to add network tags (See Martin's issue), instead we decided to follow CIP-1694's definition and omit them.
• The current way of implementing DRep IDs, has already seen much adoption across tooling.
  • any such changes like this would be quite disruptive not just for implementers, but for those community members who already understand the current DRep ID mechanisms
• I would suggest that this pull request amend adjacent CIPs (CIP-1694, CIP-105 and CIP-19), to supply the rationale you are providing via comments in a more discoverable way.

[ashisherc]

@Ryun1
The DRep ID definition was inherited from CIP-1694 [here](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md#registered-dreps).

The CIP1694 does not define the bech32 prefix, I think there is a misunderstanding here, I am not suggesting a change to how a drep ID spec should be, but infact suggesting a change that fits well with existing bech32 formats in this CIP.

eg. the bech32 prefix for drep keyhash is just drep but I am suggesting it should be drep_vkh. Following the CIP-1694 the actually hex representation should be as I am suggesting or similar to it.

CIP-105 as well does not require any changes, it does define a vkey prefix precisely as drep_vk, again stating that this CIP should use drep_vkh for a key hash.

I would propose relevant amendments to cip-19 once this CIP makes the changes and uses the relevant bech32 format. As suggested a drep address prefix will use drep as prefix for a drep address but has been already used here to define a vKeyhash and not an address.

[Ryun1]

@ashisherc

As you have pointed out, when defining this we more or less ignored the "credential" nature of these DRep and CC credentials, and thus avoided defining addresses for them.

Motivation for current setup

• We were modelling off of stake pool IDs, just as vote delegation (delegating to DReps) is modelled on top of delegation to stake pools.
  • This was just the easier and simplier.
  • At the time there was little to no community interest in pursing anything more than this.

Benefits of proposed changes

• Conformity with existing Stake and Payment credential definitions

Im not sure of anymore?

Drawbacks of proposed changes

• Adding DRep/CC addresses would, I believe, add confusion.
  • for me, the term address is something ada can be sent to
  • with these addresses ada cant be sent which I see as counter intuitive
• Existing implementers would have to upgrade or not - potentially leading to fragmentation and confusion

### Specific Responses

I am not suggesting a change to how a drep ID spec should be, but infact suggesting a change that fits well with existing bech32 formats in this CIP.

My bad, I had misinterpreted you as wanting to remove DRep IDs.

eg. the bech32 prefix for drep keyhash is just drep but I am suggesting it should be drep_vkh.

This is a fair take, the reason I chose drep over drep_vkh is that I was modelling the DRep IDs off of Pool IDs (pool).

I would propose relevant amendments to cip-19 once this CIP makes the changes and uses the relevant bech32 format. As suggested a drep address prefix will use drep as prefix for a drep address but has been already used here to define a vKeyhash and not an address.

My suggestion is that this proposal becomes it's own CIP, then while editing CIP-19 the edits can point to the full definition and explaination within the new CIP.

[Ryun1]

Also, not sure if intentional, but you seemed to have removed all significant file changes with the last force push.

[ashisherc]

@Ryun1 thanks for the background, the idea is not to have drep/cc as addresses in the sense of sending/receiving ADA but a unique hex representation for sharing across the community, specially in tooling. While it was a good idea to base of pool id, but due to nature of these keys being a credential and not just a vkh unlike a pool id, it is a bit misrepresented.

I agree for a dedicated CIP for this, but I would like to use drep prefix for such identifier, similarly for other credentials as well, and hence update this current CIP to represent a vkh as such, hence this PR.

Also, not sure if intentional, but you seemed to have removed all significant file changes with the last force push.

I updated the PR to only keep the changes relevant for this CIP which is updating the prefix to use _vkh for the key hash values.

While this amendment might create confusion initially, it is not a user facing terminology yet, but will soon become once the explorers etc start showing this data, I believe it will be good to modify it at this time then to be stuck with it forever.

[Ryun1]

@ashisherc

While it was a good idea to base of pool id, but due to nature of these keys being a credential and not just a vkh unlike a pool id, it is a bit misrepresented.

I completely agree, it is somewhat wonky 😆

I agree for a dedicated CIP for this, but I would like to use drep prefix for such identifier, similarly for other credentials as well, and hence update this current CIP to represent a vkh as such, hence this PR.

I look forward to seeing this proposal 💪

While this amendment might create confusion initially, it is not a user facing terminology yet, but will soon become once the explorers etc start showing this data, I believe it will be good to modify it at this time then to be stuck with it forever.

understood, good points
ill wait for the proposal to discuss further

[ashisherc]

@Ryun1 #857

[Ryun1]

Suggested change

	| `drep_script_vkh` | Delegate representative script hash | blake2b\_224 digest of a serialized delegate representative script |
	| `drep_script` | Delegate representative script hash | blake2b\_224 digest of a serialized delegate representative script |

script verification key hash (vkh)?

[ashisherc]

merged with #857