交易备注放云端会被看到吗？SLIP-0015 元数据加密格式拆解

“这笔钱是房租”记在哪：一个尴尬问题

地址和交易哈希都是长串，人脑记不住”这笔进账是半年前卖 SECONDARY 那单”这类语境，于是钱包都有标签功能。问题是标签存在哪：只存本地，换设备即丢；明文传云，等于把财务日记公开给网盘服务商。SLIP-0015（2015 年 1 月 12 日创建，状态 Final）针对的正是这个两难：格式设计成”安全地保存在不可信的云服务（规范点名 Dropbox 这类）“，硬件钱包是首选但不强制。

三层密钥：设备、账户、文件

派生链从设备出发。先向硬件设备发一次 CipherKeyValue（该原语定义在 SLIP-0011）：路径 m/10015’/0——10015 就是提案号补零；key 参数是提示串 Enable labeling?；value 是一串写死的 32 字节十六进制常量 fedcba98…89abcdef；encrypt 为真，ask_on_encrypt 与 ask_on_decrypt 皆真，即加解密都要在设备上按键确认。设备返回的 32 字节即全设备共享的主密钥。每个账户再派生各自的账户密钥——这里有个刻意妥协：为了让不支持硬件钱包的第三方应用也能读同一个文件，账户密钥被设计成一个可以离线导入的字符串。从账户密钥一分为二：一部分算文件名、一部分做加密密钥。文件名对元数据本身做 HMAC 式派生后哈希得到，加密内容写成 JSON，账户的 xpub 列表同样加密存储——规范明确说这是为了可否认性（deniability）：云服务商连”这文件关联哪些钱包”都看不到。

设计目标的三角取舍

规范把三个目标并列写死：数据要能在不可信云端安全存放；配合安全硬件用时零负担；不支持硬件钱包的第三方应用也要能用。第三条牺牲最大——因为要允许用户在没带设备、甚至根本不持有设备时改标签，变更在不可信主机上加密，规范原话承认”不幸的后果”：攻击者拿下那台电脑就能读写全部元数据。因此这套格式的安全声明要精确复述：它对云服务商隐藏内容与账户关联，对传输窃听有效，对被入侵的终端不设防。把它理解成”端到端零知识”是过度解读，它更接近”对托管方加密”。

与普通记账工具、区块浏览器标签的分工

与BIP329钱包标签如何安全迁移？讨论的钱包标签迁移相比，这里多了一层”托管方不可见”的要求；同类需求整体有三种解法，信任模型完全不同。本地不联网（电子表格、本地 KeePass 加自建同步）：数据不出户，代价是换设备手工迁移。云端账户体系（区块浏览器的地址标签服务、记账 SaaS）：便利最高，但你把”哪个地址属于我”整张图交给了服务商，对方拿到的是明文关联图谱。SLIP-0015 介于两者：托管方只见密文与随机化文件名，但同步冲突合并、多端一致性要格式自己扛，生态也因此始终小众，主要实现停留在 Trezor 工具链。选择标准可以按泄密的代价排序：若标签内容本身比地址关联更敏感（备注里写明用途、对手方），云端零知识类方案的必要性最高；若只是给自己看的颜色备注，本地文件加密加定期导出核对已经足够。

使用与核验清单

上手前核四件事。第一，备份助记词后能否在纯离线电脑上重放派生：SLIP-0015 的密钥全部可复现，文件名和密文应逐字节一致——不一致说明恢复流程或版本实现有出入，先小额账户验证。第二，账户密钥那根”可离线导入的字符串”在你的备份计划里处于什么位置：拿到它的应用不需要你的设备就能读写该账户标签，这是格式为了兼容性明码标价的部分，它应与助记词同等对待。第三，设备上 ask_on 双真的确认弹窗要读内容再按，习惯盲按等于把规范承诺的一半兑现抹掉。第四，标签写什么也有安全边界：备注里避免写实名、身份证件、交易所账户名——密文强度再高，泄露任何一条明文备注都可能让攻击者反向猜测其余密文的归属。最后，这个 2015 年的格式没有活跃演进，遇到”支持 SLIP-0015 导入导出”的新工具先查实现仓库是否公开可审，再决定把哪几个账户的标签交进去试跑。