门罗 view key 全解：只读钱包能看到什么、看不到什么（2026）

view key 是门罗钱包的「只读那一半」，也是加密会计里最常被过度分享的秘密。 每个标准门罗地址把两把公钥塞进 95 个字符：花费公钥 B 和查看公钥 A。A 对应的私钥就是 view key a，32 字节，通常写成 64 个十六进制字符。只有 a，你能解开打进这个钱包的每一笔转账并读出金额；只有 a，你一个 piconero 也动不了。正是这种不对称，让会计、审计和资金团队会来要 view key，也正是它要求「交出去要有规矩」而不是靠人情。

这套代数我们重写了一遍，不是照抄。 钱包是推导出来的，不是存下来的：花费私钥 b = Hs(seed)，查看私钥 a = Hs(b)，地址 = base58(varint(18) || B || A || keccak256(keccak256(varint(18) || B || A)) 的前 4 字节)。为了核实下面每一条说法，我们把这条流水线重建了一遍：Keccak-256 对上标准向量（空输入得 c5d24601...）；base58 编码器通过门罗官方 tests/unit_tests/base58.cpp 里全部 14 个分块向量，包括 8 字节 FF..FF 必须编码成 jpXCZedGfVQ 的用例和两个前导零用例。端到端的地址校验更硬：把门罗钱包序列化测试里硬编码的两对公钥，按测试网前缀 53 重新编码，得到 9svHk1wHPo3... 与 9y52S6PH8tz...——正好是门罗给那两个钱包文件命名的前六个字符。

view key 到底买到了什么。 用一个全新种子，我们推出了一个主网地址：49DEK2pVdZBTkmY4yYkxs5EXMG45X83RygMDVi34zxC6HHDKMgKN4wrBv2xBs5oyamEu4Vy5RzZ3XU9Sn8XRVSrNGRzc1Um，95 字符，前缀 18。它的 view key 是 8b2f295c...5a05。由此得到两项能力。第一，每笔交易都公布一个交易公钥 R；钱包对每笔交易算一次共享密钥 aR，然后对每个输出序号 i 算 Hi = Hs(aR || i)，构造 P' = Hi*G + B，与链上写着的输出公钥比对；命中即「这个输出是我的」，同一份共享密钥还能解开金额。第二，子地址可以只靠 view key 推出来：m = Hs('SubAddr' || a || major || minor)，D = B + mG，C = a*D。只用 a 和公开的 B，我们就生成了 (0,1)、(0,2)、(0,3) 三个子地址：84Y1S91V...、82b5J7zr...、88shGQ6Z...，各 95 字符、全部以 8 开头（前缀 42），全程没碰花费密钥。

而这正是风险所在。 view key 不是「只读所以无害」。它泄漏这个钱包生命周期内的每一笔入账——过去和未来、精确金额、时间戳；而且因为子地址出自同一套代数，它把你这辈子发过的每一个收款地址都拴回同一个钱包。它看不到出账，而这道缺口有现实后果：只读钱包算不出 key image，因为 key image 是 (Hs(aR || i) + b) * Hp(P)，缺了 b。于是它无法判断哪些输出已经被花掉，花费钱包一动钱，它报的余额就会偏高。把 view key 侧的余额当成「累计收到」，而不是「可用余额」。在我们的测试交易里，只读扫描把 1 号输出匹配到子地址 (0,3) 并读出了金额，而它能算的只有出款侧标量 Hs(aR || 1) = d2a1346b...；key image 只有在 b 重新出现后才算得出来。

在活链上长什么样。 区块 3,796,140（今天 13:18:40 UTC）30,980 字节里装了 18 笔交易。交易 38488d18... 占 2,220 字节，付了 0.0001776 XMR 手续费：每字节 80,000 piconero，是节点当前报价下限 20,000 piconero/B 的四倍。它有两个输入、每个 16 个环成员，两个输出的显示金额都是 0。这个 0 不是 bug，RingCT 把金额搬进加密字段，链上只留承诺。它的 extra 字段以 0x01 加 32 字节交易公钥开头，接着是 0x02 和 9 字节 nonce，里面装的是加密付款 ID。外部观察者对这笔交易能做的全部事情，就是数出两个输出然后猜；收款方 view key 能做的全部事情，是拿两个候选输出公钥去试，然后解开其中一个的金额。 (门罗费用机制)

怎么交出去，而不是把钱包交出去。 不要复制主钱包文件，单独生成一个只读钱包：monero-wallet-cli --generate-from-view-key audit.dat --restore-height N，粘贴 view key，并把 --subaddress-lookahead 设到足够覆盖你发过的地址——超出预生成的旧子地址根本认不出来。恢复高度比任何其他参数都重要：从创世块扫是纯浪费，而扫描成本是真的。最近 30 个区块里，块大小中位 67,089 字节、均值 102,540 字节（其中两个块只有 1 笔或 0 笔交易），照此推算光是跟到链尖每天约 74 MB、一年约 27 GB 链上数据。给审计一个「第一笔预期入金之前」的恢复高度，并把日期区间写进委托书。

把暴露面压到最小的四条规矩。 一，只交副本，绝不交原文件，委托结束就删掉副本——这把钥匙不会过期。二，能交导出表就别交密钥：一份入账 CSV 能回答绝大部分会计问题，且对未来收款零泄漏。三，确实需要实时跟踪时，给密钥附上截止日期和收款人清单，并假设持有人能看到这个钱包此后每一笔入金。四，绝不把 view key 和它对应的地址放在同一个渠道发，也绝不发一把没逐字符核对过的密钥。view key 和花费密钥都是 64 个十六进制字符，下错一条命令就够交错了。把公开的花费公钥、查看公钥打印在私钥旁边，核对这一对确实属于发票上那个地址。

即时兑换在这件事里的位置。 兑换不需要 view key，也永远不该要。VeilSwap 的下单接口正好收七个字段：fromAsset、toAsset、fromAmount、toAddress、toExtraId、refundAddress、refundExtraId。退款地址自 2026 年 10 月 25 日起必填，目录当前是 516 个资产、75 条网络，其中 60 个稳定币，XMR 不需要备注 ID。一份报价有效期 120 秒，入金窗口 30 分钟；兑出由池子签名，不经过你的钱包。如果某个服务要你粘贴 view key 来「核实」入金，把它当红旗：入金地址加交易哈希已经能证明到账，放款不需要别的。 (转错网络如何找回)

一句话版本。 view key 是会计读收入的正确工具，也是「想确保别的都没被读」时的错误工具。能交导出表就交导出表，必须交钱包就交限时的只读钱包；花费密钥——唯一能签名、也唯一能算 key image 的那把——留在审计碰不到的机器上。汇率会动，所以这里的数字都带时间戳：今天 14:03 UTC，100 USDT-TRC20 报 0.14880904 XMR（隐含 671.99 USDT/XMR，现货 592.60）、10,000 USDT 报 16.61076502 XMR、1 XMR 报 574.509235 USDT、0.05 BTC 报 6.4437305 XMR。页面上的实时报价才算数。 (XMR 换 USDT 退出路线)