ZooBC wiki
Integrations

Hardware wallets

A hardware wallet is a small device that keeps a private key and signs on its own screen, so the key never touches a computer. ZooBC has written a signing specification for the makers of such devices. It sets out what a device must check, show and compute before it signs a ZooBC transaction.

The idea: the device decides what it signs

A computer can be compromised; the device is the part the user trusts. So the specification keeps the device in charge. The computer only proposes a transaction. The device reads it field by field, shows the user what it means, and signs only what the user approved, computing the digest itself.

Keys

The device derives its keys from the recovery phrase along m/44'/883'/account', using SLIP-0010 for Ed25519, where 883 is ZooBC's coin type (keys and account types). The signature is therefore Ed25519, as for any native ZooBC account, not the secp256k1 signature a Bitcoin device makes. The key never leaves the device.

What the device must do

  1. Receive the unsigned transaction bytes and the chain's genesis hash from the computer.
  2. Parse every field itself, and refuse any transaction whose length fields do not add up exactly.
  3. Check the sender: refuse unless the sender is the device's own derived account.
  4. Show the network, the transaction type, the amount, the recipient in full, the fee, any survival payment (paying to keep data (longevity)), the message and any escrow (escrow).
  5. Wait for the user's approval.
  6. Compute the chain-bound digest itself, SHA3-256("ZBC-TX" ‖ genesis hash ‖ bytes), and sign it with Ed25519 (chain-bound signatures).
  7. Return only the signature to the computer.
The computer sends unsigned bytes and the genesis hash; the device parses every field, checks the sender, shows network, full recipient, amount and fee, waits for approval, computes the digest itself and returns an Ed25519 signature; a ready-made 32-byte digest is refused
The computer sends unsigned bytes and the genesis hash; the device parses every field, checks the sender, shows network, full recipient, amount and fee, waits for approval, computes the digest itself and returns an Ed25519 signature; a ready-made 32-byte digest is refused

Why these rules

  • Never sign a ready-made digest. A 32-byte digest sent by the computer could be the hash of a transaction the user never saw. The device must build the digest from bytes it has parsed and shown. For the same reason, a command for signing raw messages refuses inputs of exactly 32 bytes, so that a transaction digest cannot be slipped in as a message.
  • Show the recipient in full, never shortened. A look-alike address can be made to match the start and end of a shortened one.
  • Show the network. The genesis hash decides which chain a signature is valid on, so the user sees which network the transaction is for (devnet, testnet and mainnet).

Where to start

The specification recommends that devices first support three transaction types: SendZBC (a payment), TransferToken (a token transfer, see issuing a token) and ApprovalEscrow (approving an escrowed payment).

See also