Skip to content

7.15 (2/5): New chains — Hive, Zcash Orchard, Ripple memos, THORChain any-denom#445

Open
BitHighlander wants to merge 11 commits into
release/7.15.0-pr1-evm-clearsign-corefrom
release/7.15.0-pr2-new-chains
Open

7.15 (2/5): New chains — Hive, Zcash Orchard, Ripple memos, THORChain any-denom#445
BitHighlander wants to merge 11 commits into
release/7.15.0-pr1-evm-clearsign-corefrom
release/7.15.0-pr2-new-chains

Conversation

@BitHighlander

Copy link
Copy Markdown
Collaborator

2/5 of the 7.15 stack. Stacks on 1/5 (release/7.15.0-pr1-evm-clearsign-core).

New chain families, independent of the EVM clear-signing in 1/5.

  • Hive (SLIP-0048)HiveGetPublicKey(s), HiveSignTx, HiveAccountCreate / Update. Hive's nanopb generation is split into its own protoc command so it doesn't collide with the shared dispatch.
  • Zcash Orchard — shielded support: PCZT signing, FVK export, unified addresses. Needs the trezor-firmware bump to 0ea97b09 (Pallas / Sinsemilla / RedPallas / ZIP-316).
  • Ripple — memo / Memos field support so XRP can route through THORChain.
  • THORChain any-denomThorchainMsgSend accepts any denom (TCY, RUJIRA, …); denom charset/format is validated before display, with separate amount / asset screens. Four SignTx vectors built on a zero-key fixture are disabled — the fixture was invalid, not the feature.

Same base pins as 1/5, plus trezor-firmware → 0ea97b09. Builds green (kkemu + firmware-unit).

Hive and Zcash land in one commit here: their message dispatch and nanopb build wiring (fsm.c, messagemap.def, CMakeLists.txt) are interleaved, so a clean per-chain split isn't possible without hunk surgery.

Accept any denom (TCY, RUJIRA, ...); validate the denom charset/format before
display and show amount and asset on separate screens. Disables four SignTx
test vectors built on an invalid zero-key fixture.
- Hive: HiveGetPublicKey(s), HiveSignTx, HiveAccountCreate/Update.
- Zcash Orchard: PCZT signing, FVK export, unified addresses; requires
  trezor-firmware 0ea97b09 (Pallas / Sinsemilla / RedPallas / ZIP-316).

Combined because their message-dispatch and nanopb build wiring
(fsm.c, messagemap.def, CMakeLists) are interleaved.
Account create/update trusted address_n[3] after only a length check,
letting a host derive replacement keys and sign from an arbitrary path.
Require m/48'/13'/role'/account'/0' with all components hardened, a
known role, and key index 0' before any derivation or signing.
# Conflicts:
#	lib/firmware/storage.c
…abels, session hygiene

- B8: Hive signs with a Graphene canonical callback (hive_is_canonic) so
  hived no longer rejects ~half of signatures
- B9: Hive amount display uses the same precision the serializer signs
  (msg->decimals) instead of hardcoded 3 dp; rejects precision > 18
- M11: Hive pubkey export label derived from the path role (address_n[2]),
  not the host-supplied msg->role
- M7: Zcash signatures buffer sized ZCASH_MAX_ACTIONS, not literal 16
- M8: ZcashSignPCZT clears prior-session state before init so buffered
  transparent sigs can't leak across sessions
…mat-truncation)

The B9 display fix used a 10-byte suffix buffer, but asset_symbol is a
10-char proto field, so " %s" can need 11 bytes. Size it from the field.
Zcash Orchard adds the Pallas curve arithmetic to the default image here;
stacked with the per-chain clear-sign code it overflows STM32 rom by the
time pr4 lands. Bump trezor-firmware to the AES_SMALL_TABLES opt-in and
define it, reclaiming 15,360 bytes (modest AES cost). Mitigation lives in
the PR that adds the flash cost; the later variant split restores
FOUR_TABLES for the Zcash-free default image.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant