feat(kaspa): verify hardware tx inputs via on-device refTx

[ByteZhang1024]

Bump @onekeyfe/hd-* to 1.1.32-alpha.4, which adds the streaming Kaspa sign protocol with previous-transaction (refTx) verification: the device recomputes each spent input's tx id from its previous transaction and checks the amount/script on-device.

• KeyringHardware: describe outputs by both script (legacy blind-sign) and address/addressN (streaming), so signing degrades gracefully — blind-sign without refTxs, stream with on-device verification when present; change outputs go by BIP-32 path so the device shows KASPA_PAYTOCHANGE.
• Vault.collectRefTxsByApi: fetch the spent inputs' previous transactions from the kaspa REST API via the network-aware RPC proxy, mapped to KaspaRefTransaction (buildPrevTx handles consensus-hex and REST JSON); capped at a 30s timeout.
• Any fetch failure/timeout/incomplete result falls back to blind signing and is logged via transaction.send.refTxFetchFailed for diagnosis.
• collectTxsByApi kept as groundwork for preferring the backend raw-transaction/list once it supports kaspa.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​onekeyfe/​hd-transport-usb@​1.1.31 ⏵ 1.1.32				+1
	@​onekeyfe/​hd-transport-electron@​1.1.31 ⏵ 1.1.32
	@​onekeyfe/​hd-shared@​1.1.31 ⏵ 1.1.32
	@​onekeyfe/​hd-ble-sdk@​1.1.31 ⏵ 1.1.32
	@​onekeyfe/​hd-common-connect-sdk@​1.1.31 ⏵ 1.1.32
	@​onekeyfe/​hd-transport@​1.1.31 ⏵ 1.1.32	+1		+1
	@​onekeyfe/​hd-web-sdk@​1.1.31 ⏵ 1.1.32	+1		+1
	@​onekeyfe/​hd-core@​1.1.31 ⏵ 1.1.32	+1		+1

View full report

[originalix]

当 refTx 获取失败时，调用方会执行这个方法，但这里没有 @LogToLocal()，因此它只是返回对象，不会进入日志管线。结果是 blind-sign 降级发生后没有任何可追踪记录，和调用方注释声明的诊断能力不一致。

请为该方法加上 @LogToLocal()，确保失败事件实际落到本地日志。

[ByteZhang1024]

fixed

[sidmorizon]

🟡 P2 buildPrevTx 读取的多个字段在代理响应中并不存在，静默降级为 0

问题

JSON 分支通过 IKaspaRestTx 读取前序交易的 version / lock_time / gas 以及每个 input 的 sequence，但该数据实际来自 sendProxyRequest<IKaspaGetTransactionResponse>（api.kaspa.org 的 /transactions/{id}），其响应体并不包含这些字段。于是 sequenceNumber: input.sequence ?? 0、version、lockTime、gas、script_public_key_version 恒为 0，与真实前序交易无关。

影响

设备会用 refTx 重算前序交易的 txId 来校验每个输入。对标准 OneKey 交易（version/lockTime/gas/sequence 恰好都为 0）能对上；但一旦被花费 UTXO 的前序交易带有非零 sequence/lockTime/version（来自其他钱包、矿池 coinbase 等），重算出的 txId 与 input 的 prevTxId 不一致，设备将中途拒签。此时 refTxs 已成功构建，代码不会再回退盲签，而是直接 throw convertDeviceError(response.payload)，导致该 UTXO 在硬件钱包上无法花费（可用性/资金问题），且与 catch 分支的 fallback 是不同代码路径。

建议

明确这些字段无法从该 REST 端点取得（从 IKaspaRestTx 移除误导性可选字段或加注释），并在设备因 refTx 校验失败（response.success === false 且 refTxs 非空）时回退到不带 refTxs 的盲签，避免硬失败。

Claude session ↗

---

Generated by Claude Code

[sidmorizon]

🟠 P1 v0 gate 恒不触发：/transactions/search 响应缺少共识字段，被静默置 0

问题

collectRefTxsByApi 把 client.getTransactions() 返回的 IKaspaGetTransactionResponse（来自 /transactions/search）直接 JSON.stringify 后喂给 buildPrevTx，而后者按 IKaspaRestTx 解析。但这两个类型并不一致：IKaspaGetTransactionResponse / IKaspaGetTransactionInput / IKaspaGetTransactionOutput（packages/core/src/chains/kaspa/sdkKaspa/types/clientRestApi.ts）根本没有 version、lock_time、gas、payload、逐 input 的 sequence、逐 output 的 script_public_key_version 这些字段（input 侧只有 sig_op_count）。

于是 buildPrevTx 里所有这些字段全部走 ?? 0 / ?? '' 默认值：

version: Number(j.version ?? 0),        // 恒为 0：响应无 version
sequenceNumber: input.sequence ?? 0,    // 恒为 0：input 无 sequence
lockTime: j.lock_time ?? 0,             // 恒为 0
scriptVersion: Number(output.script_public_key_version ?? 0), // 恒为 0

因为 version 永远解析为 0，本 commit 新增的 refTxs.some((tx) => tx.version !== 0) 判定永远为 false，v0 gate 形同虚设——一笔真实的 v1 prev tx 会被当作 v0 构造并下发到设备。

影响

设备会用 refTx 字段重算 prev-tx id 并与 input.prevTxId 比对。对于任何 version != 0、或 v0 但 sequence/lock_time/scriptPublicKey.version 非 0 的 prev tx，下发的字段被置 0 → 设备重算出的 txid 不匹配 → 硬拒绝。而 sdk.kaspaSignTransaction（KeyringHardware.ts 约 284 行）在 try/catch 之外，这个拒绝不会被捕获、没有 blind-sign 兜底 → 用户直接签不了、无法转账。标准支付 tx（各字段恰为 0）能过，纯属巧合；本 commit 声称的"只信任 v0"保护实际不生效。

建议

不要用 version 作判据（该端点根本给不出可靠的共识字段）。改为自校验：在 buildPrevTx 后本地按共识规则重算 prev-tx id，只保留重算 id 等于 input.prevTxId 的 refTx，其余整批丢弃 → 走 blind-sign；或至少把 sdk.kaspaSignTransaction 也纳入兜底：设备因 prevtx 不匹配拒绝时，去掉 refTxs 重签一次。

// 伪代码：自校验，避免依赖 REST 端点是否返回 version/sequence
const verified = refTxs.filter((rt) => recomputeKaspaTxId(rt) === rt.txId);
if (verified.length !== refTxs.length) throw new OneKeyLocalError('refTx id mismatch');

Claude session ↗

---

Generated by Claude Code

[sidmorizon]

🟡 P2 Promise.race 超时后败方 sendProxyRequest 未处理 → unhandledRejection

问题

getTransactions 用 Promise.race([sendProxyRequest(...), timeoutPromise])。当 30s 超时先 reject 时，sendProxyRequest 这个 promise 仍在挂起。如果它随后（比如 31s 时网络失败）自行 reject，就是一个没有任何 .catch 接管的 rejection。

const [txs = []] = await Promise.race([
  this.backgroundApi.serviceAccountProfile.sendProxyRequest<...>({ ... }), // 败方无 catch
  new Promise<never>((_resolve, reject) => { timer = setTimeout(() => reject(...), 30s); }),
]);

这是上一轮已提出的问题，重构进 ClientKaspa 后依旧存在。

影响

在 RN/Hermes 与 Node 下会触发 unhandledRejection 警告，严重时被全局处理器上报为 Sentry 噪音或告警；虽不影响本次签名结果（已走 blind-sign 兜底），但污染错误监控、掩盖真实问题。

建议

给败方挂一个 no-op .catch，吞掉超时后迟到的 rejection：

const req = this.backgroundApi.serviceAccountProfile.sendProxyRequest<...>({ ... });
req.catch(() => {}); // 防止超时胜出后成为 unhandledRejection
const [txs = []] = await Promise.race([req, timeoutPromise]);

Claude session ↗

---

Generated by Claude Code

[originalix]

当 /transactions/search 响应没有 version 时，当前 proxy 类型也不保证该字段存在，这里的 ?? 0 会把未知版本直接构造成 v0。后面的 version !== 0 检查因此无法拦截不完整或非标准前序交易，错误字段会继续发送给设备，并可能导致 txid 重算不一致后硬拒绝签名。

请在构建 refTx 前要求 version 明确存在且严格等于 0；字段缺失或版本不支持时直接抛错，不要用默认值通过 v0 gate。

[originalix]

当 UTXO 来自 v1 或具有非默认 lock time/sequence 的交易时，/transactions/search 的响应并不提供这些共识字段；这里用 ?? 0 补出的 refTx 内容会与保留的 transaction_id 不一致。后面的 v0 gate 也无法识别这种情况，因为缺失的 version 已经被改写为 0。

设备收到该 refTx 后会重算出不同 txid 并拒绝签名，预期的 blind-sign 回退不会发生。请改用能返回 raw consensus transaction 或完整共识字段的数据源，并在发送设备前本地重算、校验 txid；校验不通过时不要附加该 refTx。

[originalix]

当签名的是 KRC20 commit 时，它不会进入上面的 reveal 分支，因此这里仍会请求全部 refTx；但 commit 的 P2SH 输出不满足 1.1.32 SDK 的 streaming 条件，SDK 最终必然使用 legacy blind-sign，这批 refTx 不会被使用。代理缓慢时，用户会在硬件确认前无意义地等待最长 30 秒。

请在发起请求前按 SDK 的 streamable-script 条件增加 guard，至少对带 commitScriptPubKey 的 KRC20 commit 直接跳过 refTx 获取。

[originalix]

当前序交易输出金额超过 Number.MAX_SAFE_INTEGER sompi 时，这里的 Number(output.amount) 会静默舍入。舍入后的金额会通过 KaspaTxAckPrevOutput 发给设备，使设备重建出的前序交易与 transaction_id 不一致并拒绝当前签名；由于 refTx 获取已经成功，这条路径也不会自动回退到 blind-sign。

请保持 uint64 的无损表示，例如改为 output.amount.toString()；@onekeyfe/hd-core 1.1.32 已支持用十进制字符串编码该字段。

[originalix]

当签名 KRC20 commit 时，它不会进入上面的 reveal 分支，因此这里仍会请求全部 refTx；但 commit 的 P2SH 输出不满足 SDK 1.1.32 的 streaming 条件，SDK 最终必然使用 legacy blind-sign，这批 refTx 不会被使用。代理缓慢时，用户会在硬件确认前无意义地等待最长 30 秒。

请在请求前增加能力 guard，至少在 encodedTx.commitScriptPubKey 存在时直接跳过 refTx 获取。