门罗子地址与付款 ID：2026 年真正还能用的部分

门罗链上约 93% 的交易都带着付款 ID，而其中几乎没有一个是真货。 2026 年 10 月 24 日的 3,791,102 到 3,791,141 这 40 个区块里共有 1,463 笔普通交易：其中 1,357 笔（92.8%）的 extra 字段里带 nonce，而 1,355 笔的 nonce 恰好是 9 字节——一个 0x01 标记加 8 字节加密付款 ID。带 2017 年那种 32 字节长 ID 的交易，一笔都没有。官方 Moneropedia 说得很直白：长付款 ID 自 0.15 版起已被移除，不可能再用。所以链上那些「像付款 ID 的东西」，绝大多数是钱包故意塞进去的填充。

地址和付款 ID 是两个不同的东西，把它们混为一谈制造了大部分工单。 一个门罗地址长 95 字符：1 字节网络前缀、32 字节花费公钥、32 字节视图公钥、4 字节校验和，用 base58 按 8 字节分块编码——8 个块各 11 字符，剩下的 5 字节尾块编成 7 字符，95 这个数字正是这么来的。前缀决定首字符：cryptonote_config.h 里标准地址用 18、以 4 开头，子地址用 42、以 8 开头，集成地址用 19。集成地址就是同样的内容再塞进 8 字节付款 ID：77 字节、106 字符，仍然以 4 开头。付款 ID 从不「住在」地址里（集成地址那种打包形式除外），它是交易 extra 字段里的附加元数据。

子地址只是在你已有的地址上做一次密钥加法，不是第二个钱包。 子地址（账户、索引）的花费公钥等于主花费公钥加上「主视图私钥 + 账户号 + 子地址号」的哈希，视图密钥是共用的。账户 0、索引 0 的那个地址就是主地址本身，所以钱包把它列在第一位。索引是 32 位整数，因此一个账户能给 4,294,967,295 个收款用途打标签，不需要第二份种子、第二份备份、第二套会弄丢的密钥。给每个客户、每个订单、每张账单一个独立门罗地址，靠的就是这一点：链上看到的是一堆互不相关的收款方，你的钱包里只是一本带标签的账。

这种填充是故意的，源码里写着。 在 cryptonote_tx_utils.cpp 里，构造交易的代码开头就是 `bool add_dummy_payment_id = true;`，如果没有提供长 ID 或短 ID，它就加密一个空的 hash8 塞进去——源码注释原话是「这将成为随时间推移的绝大多数交易」。两种情况会关掉它：交易本身已带付款 ID；或者收款目的地超过「一个收款 + 找零」的常规形态。链上样本几乎完美吻合这条规则：1,357 笔带 nonce 的交易全部恰好两个输出，而 106 笔没有 nonce 的交易里有 96 笔是三个以上输出——49 笔三个、16 笔四个，还有一笔十六个。剩下 10 个例外是两输出交易，只是那个钱包没做填充。

隐私上的效果是双向的，而这才是有用的部分。 对付款方来说，填充是好事：一笔真的带了付款 ID 的交易，和一笔没带的交易，在链上无法区分，这个字段不再泄露「谁在给交易所打钱」。对收款方来说，它拿掉了一个你可能依赖过的信号——你没法看着链上数据判断付款 ID 是发送方填的、还是钱包自动生成的。这正说明入账必须锚在地址上，最好是锚在专用的子地址上，而不是锚在付款 ID 上。如果你的账务系统仍然靠付款 ID 把入金关联到客户，那你是在用一个 93% 都是噪声的字段做匹配。

子地址不额外收费，8 字节付款 ID 也不额外收费，手续费根本不看你用哪种。 2026 年 10 月 24 日 14:00 UTC 之前的 10 个区块共 326 笔交易，费率只有三档：每字节 20,000、80,000、320,000 piconero，分别有 179、74、39 笔。手续费中位数 44,570,000 piconero，即 0.00004457 XMR——按 CoinGecko 上 XMR 597.78 美元算约 0.027 美元。1 进 2 出的交易实测 1,534 字节，2 进 2 出是 2,220 字节。子地址的输出就是普通输出：同样的 tagged key、同样三十几字节，没有附加费。8 字节付款 ID 会在 tx_extra 里加 9 字节，但钱包本来就要填充这个字段，所以打开它在体积上等于零变化。真正影响费用的是钱包选的优先级档，而同一笔交易在最高档和最低档之间能差 16 倍。 (门罗费用机制)

放到兑换订单上，这条规则就只剩一句：只贴 95 个字符，别的都不要。 我们的下单表单只要一个 XMR 地址——币种目录里 xmr 的 hasExtraId 是 false，所以没有备注字段要填，也没有付款 ID 要编。下单接口只校验地址是不超过 256 字符的字符串，也就是说 106 字符的集成地址也能通过校验、链上也能收；但它不是订单要的东西，而这种差别恰恰会把一笔入金推进人工审核。2026 年 10 月 24 日 14:05 UTC，报价接口给出 100 USDT-TRC20 兑 0.16382091 XMR、500 兑 0.82593、1,000 兑 1.652442、5,000 兑 8.264534，而 1 XMR 兑 592.31 USDT。如果交易所的提币表单在你要打给我们时问「付款 ID」，留空：我们从没要过 ID，它帮不上匹配，而 32 字节的长 ID 现在根本发不出去。 (XMR 换 USDT 退出路线)

收款方至今还在踩的五个坑。 一，把付款 ID 当必填：一笔没带 ID 的入金到了，就拒绝入账——钱已经在地址里，缺的那个字段不是缺的那笔钱。二，把 106 字符的集成地址贴进文档写明 95 字符的表单，有些服务方会直接判为无效。三，所有用途共用一个子地址，等于把子地址本来要解决的「共享地址」问题重新造了一遍。四，往集成地址做批量付款：加密付款 ID 这条路径要求恰好一个目的地，cryptonote_tx_utils.cpp 里的构造逻辑遇到多输出目的地会直接报错。五，以为换个子地址就能藏住金额和时间——藏不住；它只是把你的客户彼此隔开，仅此而已。

把子地址用对，只需要三个习惯。 建立时就打标签，别等以后：一个有 200 行没有标签的钱包，就是一本对不上的账。退款地址用同一份种子、但换一个子地址，这样失败的订单永远不会退回到客户看得见的地址上。只读对账用视图密钥、不要用种子——视图密钥能让会计看到入账金额却没有花费能力，这是「能回答问题」的最小暴露面。时间上，我们抽样的 40 个区块平均出块间隔 105.9 秒，目标是 120 秒，所以 10 个确认大约二十分钟；这个等待跟收款地址是主地址还是账户 3 的第 87 号子地址毫无关系。 (转错网络如何找回)

值得记住的那条规则。 付款 ID 是钉在共享地址上的标签；子地址本身就是地址的标签。2026 年的做法是：凡是你自己控制收款的一侧，全用后者；凡是别人家的表单在问付款 ID，留空。上面所有数字都来自 2026 年 10 月 24 日 14:00 UTC 前后的链上数据与站内接口——1,463 笔交易、326 个费率样本、1 XMR 报 592.31 USDT 对现货 597.78——价格会动，唯一作准的是兑换页面上的实时报价。 (XMR 换 USDT 退出路线)