In Shelley Cardano started using the purpose 1852'. Unfortunately,
we completely missed that the public key path validation fuction checks
for purpose 44' explicitly, which means that the user is shown a warning
when deriving public key with the purpose 1852'. Which is always when
"logging in" to a wallet. This commit should fix that.
I've also updated type hinting in get_public_key.
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.
This avoids problems with large timeouts causing the scheduler queue to
think the time counter has overflown, and ordering the autolock task before
immediate tasks.
The maximum reasonable time difference is 0x20000000, which in
microseconds is ~8 minutes, but in milliseconds a more reasonable ~6
days.
this makes sense, really: close_others() requests UI exclusivity, and
that is something that generally happens at the same places we emit a
ButtonRequest
The original wait_layout was unreliable, because there are no guarantees
re order of arrival of the respective events. Still, TT's event handling
is basically deterministic, so as long as the host sent its messages
close enough to each other, the order worked out.
This is no longer the case with the introduction of loop.spawn: TT's
behavior is still deterministic, but now ButtonAck is processed *before*
the corresponding wait_layout, so the waiting side waits forever.
In the new process, the host must first register to receive layout
events, and then receives all of them (so the number of calls to
wait_layout must match the number of layout changes).
DebugLinkWatchLayout message must be version-gated, because of an
unfortunate collection of bugs in previous versions wrt unknown message
handling; and this interests us because upgrade-tests are using
wait_layout feature.
this prevents a certain class of UI test failure. It also localizes the
use of debuglink signals into the layout classes instead of call sites,
which is a design we were already using for confirm_signals
this involves some changes to the workflow defaults:
* workflow.start_default() takes no arguments
* workflow.set_default() (originally replace_default) configures the
default that will be started by next call to start_default().
The intended usecase is to set_default() first and then start it
separately.
* apps.base.set_homescreen() factors out the logic originally in
main.py, that decides which homescreen should be launched. This uses
set_default() call. start_default() is then used explicitly in main.py
