钱包也换了数据库：比特币核心从 Berkeley DB 到 SQLite 的迁移线

钱包文件换引擎的三步棋

比特币核心钱包模块近几年最大的一次结构变化，普通用户可能完全无感：钱包不再按”密钥”记账，改为按”脚本”记账，底层数据库也从 Berkeley DB 换到 SQLite。这条路的版本节点清晰：v0.21.0 引入描述符钱包，发布说明明确标注”仍是实验性质”，并写明”描述符钱包用 SQLite 作为钱包文件后端，取代旧式钱包使用的 Berkeley DB”；v23.0 的说明宣布描述符钱包成为默认创建类型，除非在图形界面里取消勾选；v30.0 则划下终线——“BDB 旧式钱包不能再被创建或加载”，只能迁移到描述符格式，用 migratewallet 完成转换。与此同时，importprivkey、importaddress、importmulti、dumpwallet、dumpprivkey、newkeypool 等一批只服务旧格式的 RPC 被整体移除。

换引擎的动机不在数据库性能，而在旧模型的行为怪癖。旧钱包以密钥为中心，“哪些地址算我的”存在大量隐式规则，watch-only 导入、地址簿与密钥池互相牵扯，同一个动作在不同状态下语义漂移。描述符钱包改为用输出描述符显式声明”可花的脚本长什么样”，官方说明的原话是：因为转向基于脚本而非基于密钥的定义，旧钱包里许多令人困惑的行为在描述符钱包里根本不可能发生。

迁移当天的正确姿势

migratewallet 会把旧文件转换成描述符格式，过程中原版备份会留在原处，转换后建议再手动备份一次新文件。迁移前值得知道的行为差异：描述符钱包对”什么属于我”的判断更严格，批量导入单个私钥这类旧习惯没有对应命令——正确的路是把该密钥写进一个合适的描述符再导入；旧钱包地址簿里的标签不会自动消失，但管理入口改到了描述符标签机制。

对运维的实际影响集中在两点：其一，升级后老钱包必须完成迁移才能继续使用，长期跑旧文件的归档节点应在升级窗口内专门处理；其二，依赖 import 系列 RPC 的旧集成脚本必须改写为描述符工作流，否则直接报方法不存在。

一次迁移现场的清单

把迁移日拆成具体动作会更直观。升级前：给旧钱包文件做一份带时间戳的离线备份——迁移过程虽然自带备份逻辑，但任何涉及钱包文件的重写都值得双保险；确认节点已完成区块同步，因为迁移后首次加载可能触发一次重新扫描。迁移中：migratewallet 的输出会告诉你旧文件被改名保留、新描述符文件生成在旁；如果旧钱包设了口令，过程会先要求解锁。迁移后：用描述符列表核对地址覆盖是否与旧钱包一致，跑一笔测试收付款验证签名路径，再考虑删除旧格式文件——多数实现会保留原文件作为回退，删除决定宜缓不宜急。

还有一类容易被忽略的对象：只监视钱包（watch-only）。旧时代靠 importaddress 一点点往里贴地址的做法，在描述符世界里换成了整段描述符的导入——派生路径、扫描区间都要写成机器可读的声明。这对归档与审计场景其实是进步：过去要靠翻地址簿猜”这个钱包当年导入了什么”，现在一份描述符把意图完整写死，另一台节点导入同一描述符就能复现同样的账。迁移不只是一次文件转换，它把”钱包是什么”的定义从一袋密钥挪到了一份合同。

对备份策略的影响也值得单独一句：描述符钱包把”账户的定义”集中成声明文本，意味着一次文件备份的信息密度变高——拿到新文件等价于拿到整套派生规则。旧时代只备份密钥池的做法不再覆盖全部意图，标签、范围、策略都在文件里，敏感场景应把它按秘密级别对待。

风险提示：钱包文件迁移涉及私钥与资金安全，请先完整备份并在测试环境演练；本文不构成投资建议。