cardano-cli should return a bech32 value for stake-address-info -> voteDelegation

[gitmachtl]

$ cardano-cli version
cardano-cli 8.17.0.0 - linux-x86_64 - ghc-8.10
git rev a4a8119b59b1fbb9a69c79e1e6900e91292161e7

Current Output for the stake-address-info query:

[
  {
    "address": "stake_test1urqntq4wexjylnrdnp97qq79qkxxvrsa9lcnwr7ckjd6w0cr04y4p",
    "delegationDeposit": 2000000,
    "rewardAccountBalance": 25425810004,
    "stakeDelegation": "pool1rdaxrw3722f0x3nx4uam9u9c6dh9qqd2g83r2uyllf53qmmj5uu",
    "voteDelegation": "keyHash-2c0e9f599655bd3f7f313a3a61fe05fb9caac4cc3d1aa77740fc9579"
  }
]

The entry for the voteDelegation should also be in bech32 format IMO, so the output is consistent with the address and the stakeDelegation entry.

./bech32 drep <<< 2c0e9f599655bd3f7f313a3a61fe05fb9caac4cc3d1aa77740fc9579
drep19s8f7kvk2k7n7le38gaxrls9lww243xv85d2wa6qlj2hjwur6sj

Expected Output for the stake-address-info query:

[
  {
    "address": "stake_test1urqntq4wexjylnrdnp97qq79qkxxvrsa9lcnwr7ckjd6w0cr04y4p",
    "delegationDeposit": 2000000,
    "rewardAccountBalance": 25425810004,
    "stakeDelegation": "pool1rdaxrw3722f0x3nx4uam9u9c6dh9qqd2g83r2uyllf53qmmj5uu",
    "voteDelegation": "drep19s8f7kvk2k7n7le38gaxrls9lww243xv85d2wa6qlj2hjwur6sj"
  }
]

[gitmachtl]

ok, realized that it can also return a string like:

"voteDelegation": "alwaysNoConfidence"

so maybe its ok to return a delegation to an actual DRep like it is done right now ?

or let it return the bech DRep-ID and the reserved text alwaysAbstain and alwaysNoConfidence ?

[smelc]

Maybe for @carlhammann?

[gitmachtl]

I also saw, that the returns for the voting state all contains values like keyHash-xxx so i don't know. Should those entries be changed to the corresponding bech formats like drep1xxx for DReps, pool1xxx for Pools and cc_hot1xxx ?

[carlhammann]

@gitmachtl You're right, the "alwaysNoConfidence" and "alwaysAbstain" options are special cases, and the current format makes collisions impossible. Another distinction we have to make: even if the voteDelegation is a credential, it may still be a "keyHash-..." or a "scriptHash-...". I haven't got enough overview of user's requirements in general, but how would you like that to show in the output? Maybe @CarlosLopezDeLara knows the right way™ to do this?

[CarlosLopezDeLara]

@carlhammann good that you brung it up, we have not implemented scripts as DReps, I just created a ticket for that v-> #559 .

It does make sense to have the output as bech32, See CIP0005. Perhpas it would make sense to first check for the special cases "always abstain" and "always no confidence" and if the stake key is not delegating to any of these, then we bech32 the keyhash/scripthash ?

[carlhammann]

@CarlosLopezDeLara I wonder what the correct prefixes are. Is CIP0005 incomplete, maybe? It proposes the prefix drep for "DRep credential"s. But, since such a credential can be either a script or a key hash, it seems wrong to me to use it for both cases. We could use the prefix script in the case where the credential is a script hash...?

[gitmachtl]

@CarlosLopezDeLara I wonder what the correct prefixes are. Is CIP0005 incomplete, maybe? It proposes the prefix drep for "DRep credential"s. But, since such a credential can be either a script or a key hash, it seems wrong to me to use it for both cases. We could use the prefix script in the case where the credential is a script hash...?

@Ryun1

its interesting that you bring this discussion up, because i opened up a discussion before if a drep key should just be a hash or like we have it with addresses also include a byte that tells the tools what it actually is. with the current implementation we can only differ this via the bech representation and tools that do it correctly. cardano-foundation/CIPs#564

[Ryun1]

with the current implementation we can only differ this via the bech representation and tools that do it correctly

If people are happy with this, we can just do it.
See; cardano-foundation/CIPs#737

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[gitmachtl]

@Ryun1 any news on that front?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[smelc]

@gitmachtl> is this still relevant?

[gitmachtl]

it depends. i think this has shifted into the CIP-129 discussion?
cardano-foundation/CIPs#857

for a consident output, it would of course be nice to have a bech output in there. but that needs
to be done with drep1xxx and drep_script1xxx values to be complete. not only drep1xxx.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.