solvable等于钱包能花费吗？

“solvable: true”看起来像“可以花费”，但在Bitcoin Core里，它回答的是脚本知识问题，而不是密钥保管问题。把两个层次混在一起，最常见的后果是恢复钱包后余额可见，却到真正付款时才发现签名材料不完整。

查询前先锁定active wallet

getaddressinfo的部分钱包字段只在地址属于当前active wallet时返回，所以先要确认查询的wallet上下文。

同一个节点可以加载多个钱包，地址在钱包A中属于自己的描述符，在钱包B中可能只是普通外部地址。RPC调用路径、wallet名称和加载状态都要记录。只复制一段getaddressinfo输出却不保存钱包上下文，审计时无法重现结论。

地址格式本身也不能说明所有权。一个看起来有效的bech32地址，只证明字符串满足网络编码；它不证明当前钱包持有私钥，也不证明外部硬件设备仍可用。

solvable表示钱包知道如何花费该脚本，官方明确说它忽略可能缺少私钥的情况，因此不等于当下可签名。

solvable为false可能表示钱包缺少描述符、redeem script或其他脚本信息；solvable为true也可能是watch-only描述符足够完整，却没有任何私钥。正确问题不是“这个布尔值真不真”，而是缺失发生在哪一层。

ismine标记地址是否属于钱包；iswatchonly在31.0中已废弃并始终返回false，旧监控逻辑需要修改。

如果旧系统以iswatchonly=true识别观察钱包，31.0中始终false会让分类突然变化。迁移时不要恢复依赖已废弃字段，而应基于钱包类型、描述符是否包含私钥材料、外部签名配置和业务元数据重新建模。升级前用真实watch-only样本做回归测试。

ismine同样不应被翻译成“私钥在这里”。它表示地址属于当前钱包的管理范围；描述符钱包、禁用私钥的钱包和外部签名器钱包都可能有不同托管结构。

desc只在solvable时出现，描述符钱包还可返回parent_desc；可再用listdescriptors核对完整备份。

desc描述具体地址或脚本的可解形式，parent_desc帮助描述符钱包指回生成它的父描述符。备份审计应再运行listdescriptors，核对active、internal、range与next_index，并确认备份包含的是公开描述符还是带私钥的敏感材料。

公开描述符可用于恢复监控和地址派生，但不应被误当成花费备份；带私钥描述符则属于高敏感秘密，不能放入普通日志、工单或云端明文。多签场景还要确认所有协作者的公钥路径、阈值和恢复约定。

第一，ismine与solvable都真且钱包包含私钥，可进入离线试签；第二，ismine与solvable真但禁用私钥，应找到外部签名器；第三，地址被跟踪但solvable假，需要补齐描述符或脚本；第四，地址不属于当前钱包，应切换wallet上下文或停止把它计入本钱包余额。

不要为了让solvable变真而从陌生人处导入所谓恢复材料。任何助记词、私钥或硬件恢复操作都应在离线可信环境完成，并先确认地址派生结果。

可先创建未广播PSBT，检查输入、找零、费用与接收地址，再由实际签名设备尝试签名。多签需要验证达到阈值后的最终化流程。若必须链上测试，使用可承受损失的小额，并在广播前重复核对网络与地址。

最终报告应分别写“钱包识别”“脚本可解”“签名已验证”和“链上已确认”，不要用一个“可用”字段把四种状态压扁。

solvable适合判断钱包是否理解花费结构，真实可用性还要核对私钥位置、外部签名器、多签参与方和完整试签流程。资产迁移前必须完成端到端验证。

本文没有把媒体标题当证据终点，原始依据包括Bitcoin Core 31 getaddressinfo、Bitcoin Core 31 listdescriptors、Bitcoin Core 31 Release Notes。

当前不能越过的事实边界是：私钥可能在硬件签名器、外部签名程序或多个参与方中，单一RPC不能替代端到端试签名。

相关背景可继续查看listdescriptors审计、getbalances对账、钱包加载状态。处置钱包与地址问题时，应保全私钥和交易记录并使用正规支持渠道；本文不提供规避安全控制的方法。