Skip to content

fix(bitbox): sign the registration with a chainId-extended EIP-712 domain#877

Draft
Blume1977 wants to merge 1 commit into
RealUnitCH:stagingfrom
Blume1977:fix/bitbox-registration-chainid-domain
Draft

fix(bitbox): sign the registration with a chainId-extended EIP-712 domain#877
Blume1977 wants to merge 1 commit into
RealUnitCH:stagingfrom
Blume1977:fix/bitbox-registration-chainid-domain

Conversation

@Blume1977

Copy link
Copy Markdown
Contributor

Problem

BitBox users cannot complete the RealUnit registration: on submit, the BitBox02 (Nova) rejects the signing request and shows "typed data has no chain ID" on the device (first affected customer: userData 412822, 23.07.). The firmware requires a chainId member in the EIP712Domain; our registration payload signs the chainId-less domain { name: 'RealUnitUser', version: '1' }. Software wallets sign it regardless, which is why this never surfaced.

Change

  • Eip712Signer.signRegistration includes chainId (value: apiConfig.asset.chainId, already plumbed through) in the EIP712Domain for BitboxCredentials only.
  • Software wallets keep the legacy domain — pinned by the existing golden-signature test, so this path provably does not change.

Pair PR / merge order

  1. fix(realunit): accept registration signatures over a chainId-extended EIP-712 domain DFXswiss/api#4354 first: verification accepts both domain variants (backward compatible).
  2. Then this PR. Shipping this app change against an older API would break BitBox registrations differently (signature rejected at submit).

Open coordination point before release

Aktionariat re-verifies the registration signature. If their check is pinned to the legacy domain, chainId-signed (BitBox) registrations will fail on their side as "Invalid signature" at forward time. Needs confirmation from Aktionariat (via Dani) that their verification accepts the chainId-extended domain. Restricting the new domain to hardware wallets keeps the blast radius at "BitBox stays blocked at a later stage" in the worst case — strictly no regression for software wallets.

Tests

  • new: BitBox path signs with domain.chainId + chainId member in EIP712Domain types
  • existing golden signature (software wallet) unchanged → legacy path frozen
  • wallet package + registration service suites: 82/82 green; analyze delta vs staging: 0

…main

The BitBox02 firmware refuses to sign typed data whose EIP712Domain has no
chainId and aborts with 'typed data has no chain ID' on the device, so BitBox
users could not complete the registration at all. Hardware wallets now sign
with the chainId-extended domain; software wallets keep the legacy domain
(pinned by the golden signature test) until Aktionariat confirms its
re-verification accepts the extended variant. Pair PR: DFXswiss/api#4354
(accepts both domain variants, must deploy first).

@TaprootFreak TaprootFreak left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wir brauchen mehr daten um sicher zu sein ob das der echte fix ist

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.

2 participants