[ARC-81] Partkey integrity hash

[tasosbit]

No description provided.

[tasosbit]

Given that participation keys are not portable between networks for the majority of users, should we include the network in the integrity hash? (e.g. genesis hash)

This would prevent network mismatch accidents, where e.g. a keyreg meant for testnet ended up on mainnet.

[urtho]

The ARC-78 URL strives to be as minimal as possible and does not include GH or network-id .
Adding network id to ARC-81 might make it incompatible with ARC-78.

[tasosbit]

Adding network id to ARC-81 might make it incompatible with ARC-78.

Not sure how it makes them incompatible. If ARC78 QR doesn't encode network/GH, that is all the more reason to include it in the integrity hash. The information (GH) would be independently known everywhere where you would want to generate an integrity hash - node, wallets, explorers.

The ARC-78 URL strives to be as minimal as possible and does not include GH or network-id .

Arguably ARC78 should have included network as well - in the TUI we currently have to warn users to make sure they are on the correct network when going through the QR. If we include the network in the encoded URL, the wallet can detect a mismatch and warn or refuse appropriately. *

But even if we don't, not sure what would be stopping the wallet from including its current network GH in the integrity hash calculation

* ARC-78 is status final

[tasosbit]

Second thread: Should this cover keyreg offline txns as well as @urtho suggested offline?

If so, what do you think about same payload structure, including the keys & rounds as all-zero?

[urtho]

Good questions, the standard way is to hash empty values - that is zero filled arrays instead of skipping them.
As in providing the same length binary input no matter the contents and tx type online/offline.