Breaking OpCertCounter Issue in Babbage-Era

[gitmachtl]

@refi93 @davidmisiak

Cardano HW CLI Tool version 1.10.0
Commit hash: cd28f24

Using cardano-hw-cli to generate pool cold keys on the HW-Wallet device using the
cardano-hw-cli node key-gen --path 1853H/1815H/0H/0H --cold-verification-key-file pool.node.vkey --hw-signing-file pool.node.hwsfile --operational-certificate-issue-counter-file pool.node.counter
command, results in an OpCert counterfile that is starting with an index 1 and not index 0.

{
    "type": "NodeOperationalCertificateIssueCounter",
    "description": "Next certificate issue number: 1",
    "cborHex": "820158205474de0dd906dae02e33cad45bb24a21f1ade6af57457b6ea171985412cd35d0"
}

The description part doesn't matter, but the 01 at the start of the cborHex "81015820..."

With the hardfork to the Babbage era in a few weeks it is not allowed to increase the OpCertCounter by more than one, this was not an issue in the past because the new OpCertCounter just had to be higher than an older one. So starting with an index 1 was ok here. But in the Babbage era we have to start with index 0 !

Issuing a new OpCert via cardano-hw-cli using a pool.node.counter file that was externally set to 0 is working fine. So the issue is really in the "node key-gen" calling command itself. Most likely an initialization error or no differentiation between generating a new node.opcert file or modifying an existing one.

For a new file it should look like:

{
  "type": "NodeOperationalCertificateIssueCounter",
  "description": "Next certificate issue number: 0",
  "cborHex": "820058205474de0dd906dae02e33cad45bb24a21f1ade6af57457b6ea171985412cd35d0"
}

[davidmisiak]

Thank your for reporting this issue. The fix seems to be trivial (setting the correct initial counter value here), we will add it to the next hw-cli release.

[davidmisiak]

The fix was merged, closing.