莱特币 MWEB 隐私实测：藏住了什么，漏了什么

MWEB 通常被介绍成「打开隐私的莱特币」。这句话一半对，而错的那一半，恰好是你准备动币时最要紧的一半。我们取了区块 3,202,394 到 3,202,494——连续 101 个块，4 小时 31 分 31 秒，截止 2026-10-27 约 10:05 UTC——把里面每一段 MWEB 数据都读了一遍。结论分裂得很干净：扩展块内部什么都看不见，没有金额、没有地址、没有输入与输出的对应；但在边界上几乎什么都能看见——MWEB 里躺着多少币，每个块都精确公布到 litoshi，而每一次 peg-in 与 peg-out 都带着准确金额和收款地址落在透明链上。这不是 bug，这是 Mimblewimble 扩展块的结构决定的。但它决定了 MWEB 到底适合干什么。 (LTC 换 XMR 路线)

MWEB 到底是什么。 MWEB（LIP-0002、LIP-0003）不是一条新链，也不是主账本的新地址格式。它是挂在每个区块旁边的一段平行数据，里面是一条 Mimblewimble 式的链：机密输出加 kernel。主网在高度 2,265,984 激活，出块时间 2022-05-20 05:04:16 UTC。前一个块 2,265,983 有 125 笔交易、没有一个 MWEB 输出；紧接的这个块里出现两个特殊输出：一笔 1.24998370 LTC 的 peg-in（承诺到 kernel 7b367c60），以及把扩展块头（2d19998a）提交到主链的 HogEx 交易。你平时用的 LTC 地址没有任何变化。扩展块随块同行，每个块由一笔交易提交，共识把它的权重上限压在 200,000，而主块是 4,000,000。 (LTC 换 XMR 路线)

池子是个公开数字。 HogEx 交易就是那块表。区块 3,202,492 里它是 txid 6066d5a0，125 字节，一个输入两个输出：第一个输出把 45,155,067,009,209 litoshi——也就是 451,550.67009209 LTC——付给一个 ltc1g 开头的地址，这个数字正好等于该高度的 MWEB 供给量；第二个输出是一笔 2.97 LTC 的 peg-out，收款地址 ltc1q7v2qhf0。到采样窗口末尾，池子里是 451,920.71324566 LTC，约占流通量 7,777 万 LTC 的 0.581%，按 55.80 美元算是 2,522 万美元。这个数字不需要任何工具，每个块都能读到，永远都能读到。MWEB 是一个带公开刻度的混币池。 (LTC 换 XMR 路线)

真正被隐藏的部分。 扩展块内部，输出用 Pedersen 承诺代替金额，kernel 只证明账目平衡而不透露数字。kernel 还会聚合：101 个块一共 58 个 kernel，35 个块至少有一个，66 个块一个都没有，单块最多 4 个。cut-through 也能从计数看出来——41 个 MWEB 输入被消耗，产生 83 个输出——这正是设计目的：中间输出消失，剩下的只是一组不说明谁付给谁的承诺。体积同理：空的扩展段是 175 字节，我们窗口里的中位数正好就是这个数；最大 7,901 字节，出现在区块 3,202,422，里面有 4 个 kernel 和 600.12 LTC 的 peg-in。 (LTC 换 XMR 路线)

边界上漏出来的东西。 peg-in 和 peg-out 都是普通的透明输出。一笔 peg-in 是 203 字节的交易，一个输入一个输出，脚本是 OP_9 加 32 字节 kernel ID——一眼就能认出来；区块 3,202,493 里那两笔 peg-in 分别付了 326 与 1,630 litoshi 手续费，对应 0.103 与 378.236 LTC。peg-out 则是 HogEx 里的普通 P2WPKH 输出。在我们那 101 个块里：30 笔 peg-in 分布在 23 个块，合计 1,532.98198122 LTC；24 笔 peg-out 分布在 18 个块，合计 764.75040055 LTC；peg-out 中位数 8.35 LTC，最大 355.68 LTC。池子净增 789.41 LTC，整段窗口的 MWEB 手续费合计 178,902 litoshi——每个 kernel 中位数 2,901 litoshi，还不到一分钱。 (LTC 换 XMR 路线)

peg-out 是按地址建索引的。 这是大多数人没注意的一点。公开浏览器有个接口，可以按收款地址筛选 MWEB 的 peg-out，返回 kernel ID、以 litoshi 计的金额和地址类型。拿 ltc1q7v2qhf0 去问，它直接答：kernel 0124ff8d，金额 297,000,000，类型 witness_v0_keyhash。也就是说「某个地址的钱是从 MWEB 里出来的」这件事不只是写在链上，而是可以直接查询。再叠上时间：四个半小时里全网只有 24 笔 peg-out，大约每小时 5 笔。你 peg in 10 LTC、一小时内 peg out 9.97 LTC，你并没有融进 45 万 LTC 的池子，你只是排进了 5 个人的队，而且两头金额对得上。MWEB 的匿名集是同时发生的 peg 流量，不是池子余额。 (LTC 换 XMR 路线)

围绕一次兑换具体怎么用。 Litecoin Core 可以生成 MWEB 地址（getnewaddress 的 address_type 用 mweb）；地址 121 个字符，以 ltcmweb1 开头，用的是 bech32 而不是 bech32m，编码 66 字节——一个扫描公钥加一个花费公钥。步骤：生成地址，往它转 LTC（这一步就是 peg-in），等 MWEB 侧确认，然后 peg out 到兑换站的 LTC 充值地址。2026-10-27 10:15 UTC，本站报 100 LTC 兑 9.22231144 XMR——每 XMR 10.8433 LTC，而现货是 10.6351，全包成本 1.96%；10 LTC 兑 0.91940493 XMR，成本 2.27%。LTC 这一对的下限是 0.24991437 LTC（13.95 美元），上限 1,350.4905204 LTC（75,357 美元）。三个坑：交易所不会往 ltcmweb1 地址发币，peg-in 必须由能构造 OP_9 输出的钱包发起；peg-out 的金额和去向是公开的；peg-out 输出六个块内不能花（PEGOUT_MATURITY = 6），按我们测到的平均 162.9 秒一块，约 16.3 分钟。 (LTC 换 XMR 路线)

MWEB 还在打补丁。 v0.21.5.6（2026-08-02）的主网参数里多了一个冻结的 MWEB 输出清单——目前只有一条 32 字节的输出 ID，2f3a08d9 到 94f7，节点会拒绝花费它——外加针对源码所称「已知 MWEB 输入元数据漏洞」的单块豁免，以及从高度 3,154,440（2026-08-04 23:04:57 UTC）起生效的规则：声称带 pegout 特性的 kernel 必须真的包含一笔 pegout。v0.21.5.8（2026-09-12）给额外数据加了同样的规范化规则，从高度 3,172,640（2026-09-05 16:51:01 UTC）生效。提交标题很直白：reject empty MWEB pegout features、reject empty MWEB kernel extradata。这说明这套格式还在共识层面被钉死。结论：MWEB 适合用来切断「你手上的透明币」与「你打给站点的充值」之间的关联，前提是你接受充值本身是公开的、而且每小时 5 笔 peg-out 的人群很薄。它不是换成 XMR 的替代品——恰恰相反，换成 XMR 时，peg 这一步正是你藏不住的部分。 (LTC 换 XMR 路线)