When deriving an address with a foreign staking key Trezor would crash
due to forgotten `decode()` on hexlified staking key hash which was to
be displayed.
This wasn't discovered while testing because it weirdly would pass with
a `aaff00` string, but not with longer ones.
Update protobuf
- Previous transactions don't need to be sent anymore, because fee is
included in the transaction now. Thus transactions_count can be
removed from CardanoSignTx message and the CardanoTxAck and
CardanoTxRequest messages can be removed altogether.
- CardanoTxInputType.type is unused so remove it
Add NULL (None type) serialisation to CBOR
- Transaction metada must either have a valid structure or CBOR NULL
must be used (if metadata is empty) - it can't be simply left out.
Add protocol_magics file
- Just to have a nicer way of representing protocol magics
Update transaction signing
- Previous transactions no longer need to be requested
- Output building is simplified, since fee doesn't need to be calculated
- Remove transaction class since it is no longer needed (only functions
remained)
- Reorder functions so it reads top to bottom
Add protocol magic to byron address on testnet
- This has always been a part of the spec, but it hasn't been
implemented before, because it wasn't really needed.
Update trezorlib
Update tests
- Transaction messages are no longer required
- Expected values are different since tx format changed
- Common values in test cases have been extracted
Remove unused file
- Progress was used when receiving previous transactions
Add CRC check to output address validation
also make a cleaner distinction between keychain, seed, path
This enables using `unsafe_prompts`, because with the original code, if
there was no namespace match, we wouldn't know which curve to use.
For ease of implementation, we use a LRU cache for derived keys,
instead of the original design "one cache entry per namespace".
SLIP21 is now treated completely separately, via `slip21_namespaces` and
`derive_slip21` method.
If more slip21-like things come in the future, we can instead hang them
on the keychain: put a per-curve Keychain object accessible by
`keychain[curve_name].derive()`, and the majority usecase will just pass
around `keychain[curve_name]` instead of having to specify the curve in
every `derive()` call.
Or alternately we'll just specify the curve in every `derive()` call,
whichever seems more appropriate.
