观察钱包怎么搭建：监控余额但不暴露私钥

一台只看不花的机器

个人金库常放在不常联网的设备上，同时又希望有一台服务器能对账、报警。观察钱包（watch-only）解决的就是这个组合：联网机器只导入“能生成地址、能识别支出，但不足以花钱”的信息，私钥始终留在冷设备里。概念背景见 观察钱包是什么？为何不能转账？，托管侧对照见 托管钱包 vs 自托管：私钥到底在哪里，风险怎么判断。

边界在哪：xpub 能看到什么

HD 钱包的架构决定了观察钱包的边界：根私钥派生出账户扩展公钥 xpub，xpub 可以按路径无限派生子公钥和地址，也能验证哪些地址被花了，但按椭圆曲线单向性无法推出任何私钥，见 比特币私钥与公钥：从 256 位随机数到地址。所以交给联网机器的正确材料是描述符（descriptor）或 xpub，而不是钱包文件，更不是助记词。描述符把地址方案、派生路径、校验密钥打包成一个可核对的字符串，冷钱包端先导出并留档，再经离线路径（二维码、加密U盘）导入监控端；导入后用 deriveaddresses 抽几个路径地址与冷设备上的收款地址逐字核对，对不上立即中止。

监控端能做的三件事

第一，收付可见：节点扫描后，listunspent 在监控端同样列出全部持仓 UTXO（注意其筛选口径见 listunspent怎样筛安全UTXO？），余额变动报警即基于此。第二，地址预派生：收款前在联网机生成新地址也能与冷设备互验。第三，发起流程：PSBT 草稿可以在监控端构造、由冷端签、再回监控端广播，回路见 比特币离线签名流程是什么？不联网怎么完成一次转账，用 analyzepsbt 检查每个输入当前缺什么签名再流转（analyzepsbt如何判断下一步？）。监控端全程只接触未签名或已签名的交易数据，不接触任何私钥。

自查清单与残余风险

上线前逐项确认：监控端导入的描述符与冷端留档逐字一致；地址抽查至少三个索引路径；监控端钱包内不残留任何私钥字段；报警测试用真实小额走通；恢复演练按 比特币助记词备份怎么做才可靠？抄写、恢复演练与保管的完整清单 完成。要清楚的残余风险有三条：xpub 一旦泄露，对手至少得到你的地址生成能力与历史模式，隐私暴露大于资金风险；描述符导入错误会造出“看着有钱其实对不上账”的假监控，核对不能省；监控端被入侵虽不能直接转走资金，但会篡改你看到的余额，重要核对应至少在冷端复核一次。自托管的一切便利都以流程纪律为前提，本文不构成投资建议。

报警与对账的工程细节

监控端的余额报警建议基于“描述符派生地址集合”的变化事件，而不是简单轮询余额数字：地址集合内出现新支出、新入金或被标记地址被花费，三类事件分别对应转账进度、收款到账与潜在异常，事件类型分清后再决定通知渠道。对账逻辑上，把每笔入金与交易所提币记录做交易级匹配（交易哈希与确认数都入库存证），出金则保留 PSBT 流转记录即可审计谁在何时签了什么；节点侧扫描进度可参考 scanblocks怎样扫描描述符？ 的思路限定范围，避免每次重启都全链重扫。报警文案里不要展示完整地址，尾缀四位加事件类型已足够定位。整套体系的目标是把“冷”和“热”的职责切割干净：冷设备只签名，热设备只观察和汇报，两边都拿不到对方的完整能力。

补三个容易踩的边界。第一，描述符带校验和字符串，导入时逐字符核对不等于校验通过——校验和本身能拦住大部分手抄错误，但正确校验和下的错误路径仍会造出“另一套合法地址”，所以与冷端比对必须落到地址字符串层面，至少抽验接收过真实资金的旧地址。第二，派生边界要显式管理：监控端与签名端使用相同的起始索引与地址间隔上限，否则已收款地址可能被识别为“外部地址”而漏计，这类漏报在报警系统里比误报危险得多。第三，恢复演练时观察钱包与恢复流程的关系：xpub 泄露不损失资金，但助记词才是根，验证“监控端被毁后仅凭冷端可完整重建”应作为年度动作，具体抄写与恢复演练清单参见本栏目助记词备份专文。