Jormungandr: Cannot encode genesis.yaml with legacy_funds entry

[piotr-iohk]

Describe the bug
genesis.yaml with legacy_funds cannot be encoded to block.bin.

Example file -> genesis.yaml.txt

Mandatory Information

1. jcli 0.6.1 (HEAD-a0de8d4, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)] ;
2. jormungandr 0.6.1 (HEAD-a0de8d4, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]

To Reproduce

$ jcli genesis encode --input genesis.yaml --output block0.bin
genesis file corrupted
  |-> initial[992].legacy_fund[0]: encoding error at line 3068 column 14

Expected behavior
block0.bin is produced.

Additional context
This is a blocker for testing byron wallet migration in wallet-backend :sweat_smile:

I have checked few previous versions - they fail the same too.

I was able to generate block from the attached genesis.yaml.txt using jcli 0.3.9999. (had to remove certs before cause it was complaining, but other than that it encoded it fine)

[CodeSandwich]

@piotr-iohk Where's this legacy address on line 112 taken from? It's almost valid except it encodes array of 66 bytes as a raw address instead of 28 bytes. That's the root cause of the failure. I've made a search and I don't think that anything in current Jormungandr operates on 66-byte values. Are you aware of any version from any time that accepted it?

[piotr-iohk]

@CodeSandwich, I was positive that it worked for me in jcli 0.3.9999 (as I mentioned in the Additional context). But when I check now it doesn't work too, indeed. Maybe I made a mistake or it was some different version. Sorry, I'll try to dig it.

In any case the address is a currently valid Byron address, which I think needs to be supported as a legacy fund in order for us to perform migration from Byron to Shelley. @KtorZ can you confirm?

[KtorZ]

The address is a MainNet address, generated as usual although it contains a derivation path payload.
I've also double checked what cardano-cli thought of it before raising this issue and it looked fine there:

$ cardano-cli debug address DdzFFzCqrht5TM5GznWhJ3GTpKawtJuA295F8igwXQXyt2ih1TL1XKnZqRBQBoLpyYVKfNKgCXPBUYruUneC83KjGK6QNAoBSqRJovbG
Cardano Extended Address
  - address hash:       c43ee228266740f39b2161b74d65d585c0e2f76eda8f5e43267c476c
  - address type:       Public Key
  - payload:            be7536c5694d72c4a1f890237b37187f33f4f250c3194d9c1a99210a
  - stake distribution: bootstrap era

@CodeSandwich said: it encodes array of 66 bytes as a raw address instead of 28 bytes.

If you're referring to the address root (which is the only thing that is 28 bytes in the address..) then it is also 28 bytes here.

Actually, the raw address in bytes is:

82D818584283581CC43EE228266740F39B2161B74D65D585C0E2F76EDA8F5E43267C476CA101581E581CBE7536C5694D72C4A1F890237B37187F33F4F250C3194D9C1A99210A001A5FD5DCF7

which decodes to:

82                                      # array(2)
   D8 18                                # tag(24) [Cbor Tag]
      58 42                             # bytes(66) [Address Payload]
         83581CC43EE228266740F39B2161B74D65D585C0E2F76EDA8F5E43267C476CA101
         581E581CBE7536C5694D72C4A1F890237B37187F33F4F250C3194D9C1A99210A00 
   1A 5FD5DCF7                          # unsigned(1607851255) [CRC]

Now, the address payload of 66 bytes here decodes to:

83                                      # array(3) 
   58 1C                                # bytes(28)  [Address Root]
      C43EE228266740F39B2161B74D65D585C0E2F76EDA8F5E43267C476C 
   A1                                   # map(1) [Address Attributes Map]
      01                                # unsigned(1) [Derivation Path Attribute]
      58 1E                             # bytes(30) [Encrypted Derivation Path]
         581CBE7536C5694D72C4A1F890237B37187F33F4F250C3194D9C1A99210A
   00                                   # unsigned(0) [Address Type]

this corresponds to the address root (28 bytes) and a map containing the address attributes which for mainnet contains only the derivation path (if any, Yoroi addresses has none). Now, if you tell me that the legacy_fund have yet-another-special-format, that's also a possibility, albeit unfortunate :(

[rinor]

@CodeSandwich, if it helps one version of jcli that can encode/decode is v0.2.1. You would have to revert to old config format though. (removed certificates since probably format changed)

block0_consensus: genesis
....

initial_funds:
    - address: ta1swk7svu8avn5jysl83vja72lp0sqfczanqee6q08a4j7q27a77kpg4p254a
      value: 100000000000

initial_certs: []

legacy_funds:
  - address: DdzFFzCqrht5TM5GznWhJ3GTpKawtJuA295F8igwXQXyt2ih1TL1XKnZqRBQBoLpyYVKfNKgCXPBUYruUneC83KjGK6QNAoBSqRJovbG
    value: 100000000000

./jcli-v0.2.1 genesis encode --input genesis_legacy.yaml | ./jcli-v0.2.1 genesis decode

blockchain_configuration:
  block0_date: 1556202057
  discrimination: test
  block0_consensus: genesis
  slots_per_epoch: 500
  slot_duration: 10
  epoch_stability_depth: 10
  consensus_leader_ids:
    - ed25519_pk1v42lxnjdulhnkq0g38d6q73envaragxrdus3sngpgwd0jmzygt4s3gkwxw
  consensus_genesis_praos_active_slot_coeff: "1.000"
  max_number_of_transactions_per_block: 255
  bft_slots_ratio: "0.000"
  linear_fees:
    coefficient: 0
    constant: 42
    certificate: 0
  kes_update_speed: 43200
initial_funds:
  - address: ta1swk7svu8avn5jysl83vja72lp0sqfczanqee6q08a4j7q27a77kpg4p254a
    value: 100000000000
initial_certs: []
legacy_funds:
  - address: DdzFFzCqrht5TM5GznWhJ3GTpKawtJuA295F8igwXQXyt2ih1TL1XKnZqRBQBoLpyYVKfNKgCXPBUYruUneC83KjGK6QNAoBSqRJovbG
    value: 100000000000

[NicolasDP]

reopen, @CodeSandwich fix in input-output-hk/chain-libs#120 is not yet in the node.