临时尘埃：零费包里的占位输出如何解掉闪电锚定的费用难题

先回忆”尘埃”为什么让人头疼

比特币节点有防尘埃规则：一笔输出的金额如果低于按当前费率计算的支出成本，默认政策下它连被中继的资格都没有——攻击者可以往全网灌海量一元不到的碎输出，谁接盘谁就被永久占内存和 UTXO 集合。这条线保护了所有人，但也卡住一类正当需求：有些协议需要交易里存在一个”暂时不算钱”的占位输出，任务完成后随即被同一包里的另一笔交易花掉。v29 起的”临时尘埃”（ephemeral dust）就是为此开的特例。

规则本体

v29.4 发布说明把条件写得很收敛：交易满足两个前提时允许恰好一个尘埃输出——这笔交易本身费用为零，且任何要花它未确认输出的后续交易必须同时花掉这个尘埃。翻译一下：尘埃只作为交易包里的”引线”存在，包内创建、包内消亡，节点验证的是整包拓扑而不是孤立单笔。典型画面是父交易带一个尘埃占位，子交易把它连同需要的输出一起花掉——两个动作在内存池眼里是同一个包。

它替闪电挡掉什么麻烦

锚定输出的老问题在于锚太小：要让它达到可花费阈值就得抬高费用或加大锚值，两种都在给紧急关闭的账本加税。临时尘埃与零费父交易的组合改变了算法——锚输出不必再是”有钱的输出”，而是”合法存在的占位”，包内子交易负责带足手续费。加上 v3 交易的拓扑约束，节点对这类包的评估既简单又有 incentive 保障。发布说明同时提示：v30 的包中继改进进一步覆盖父交易已带未确认祖辈的拓扑，1 父 1 子包在更宽结构下也能被接受传播。

钱包与用户侧的可见面

普通用户不会在界面里看到”临时尘埃”四个字，但它改变了钱包创建交易的构造规则：如果你用描述符钱包手工组包、或用 RPC 试算零费父交易，忘了处理尘埃输出会直接被内存池拒收。排查顺序值得记住：先看包内是否有未被花费的尘埃；再看交易费是否严格为零（这正是临时尘埃的前提，与普通交易的低费完全是两回事）；最后检查是否只有一个尘埃（规则只给一个名额）。

与”粉尘攻击”的边界

别把这个特例读成尘埃防线松了：非零费交易里的尘埃照样被拦，临时尘埃名额仅限单笔单输出、且强制包内花销。网络防的是”留下垃圾”，这种”即生即灭”的占位不产生长期 UTXO 负担，属于风险与功能权衡后的窄门。评估任何教程时可以用同一把尺：方案是否会让尘埃沉淀进链上余额——会，就是在吃公地。

一段可以直接跑的检查流程

如果你在用 RPC 手工组装带占位输出的交易包，顺序建议这样安排：先用 createrawtransaction 构造零费父交易并确认其费用字段确实为零——钱包自动补费功能在这一步是敌人，必须显式关闭；接着用 testmempoolaccept 把父子两笔按包顺序提交预检，返回的 reject-reason 字段会把”父交易带非零费""尘埃未被子交易花掉""尘埃数量超过一”这三类常见错误区分得很清楚；预检通过再走 submitpackage 整包提交。子交易费率要给足，它实际承担整包的验证经济学——父交易零费不是免费午餐，只是把账单全部搬到了子交易名下。

风险提示：交易包与尘埃规则细节繁多，手工构造请以官方文档与 RPC 返回的拒绝原因为准；本文不构成任何手续费策略建议或投资建议。