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 prevents a race condition where sometimes an Initialize message
could arrive before the homescreen was fully booted -- and Recovery
homescreen would cancel it as part of its bootup sequence.
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
also refactor show_pin_invalid and its usages so that it raises directly
note that we are now using PinCancelled instead of ActionCancelled where
appropriate
- core/bitcoin: move common files to the app's root
- core/bitcoin: use require_confirm instead of confirm
- core: move bitcoin unrelated functions from 'bitcoin' to a new 'misc' app
- core/bitcoin: use relative imports inside the app
- core: rename wallet app to bitcoin
- core/wallet: replace SigningErrors and the other exception classes with wire.Errors
- CLSAG signature scheme added
- type hints added
xmr: optimize protocol, send only required data
- real_out_additional_tx_keys contains only one element as nothing more is needed during signature
- only src_entr.outputs[index] is HMACed and always present. Other outputs are present only if needed which reduces comm and CPU overhead.
- getting rid of subaddresses dictionary (memory requirements), now subaddr indices are present per source entry so keys are computed when needed
xmr: prepare for permutation sending removal, specify index
- specify source entry ordering index prior sorting by key images as original HMAC keys are generated based on these.
- permutation checked just by valid HMACs, size of the set, key image sort order
- sending permutation is now deprecated, will be removed in the following protocol versions
- more strict state transition checks, guard strict check with respect to steps ordering
