比特币付款尚未确认，收款人除了耐心等待，还有没有可能加速确认过程？
如果收款人能花费这笔未确认付款产生的输出，且钱包与节点支持相应处理，就可能透过CPFP 建立另一笔交易，提高相关交易组合的费率，吸引矿工一起收录。
CPFP 不会替换原付款。它建立的是依赖原付款的新交易，因此理解「父子关系」与「组合费率」，比只看子交易付了多少费用更重要。
CPFP 是Child Pays For Parent 的缩写，常译为「子交易为父交易付费」。
它是一种交易费用调整方式：花费低费率未确认交易的某个输出，建立较高费率的子交易，让父子交易一起被收录更有吸引力。
其中「为父交易付费」是经济效果的描述，不是把额外费用填回父交易，也不是让父交易原本的手续费数字改变。
本文以Bitcoin（比特币）的一般交易为主，不将特定钱包功能视为全网通用介面。
Bitcoin 交易输入会引用先前的UTXO 未花费交易输出。若交易B 花费交易A 产生的输出，A 就是B 的父交易，B 是A 的子交易。
在符合条件的情况下，子交易可以先被建立与传播，不必等父交易取得一个确认后才开始处理。
但在有效链上，必须先有父交易产生输出，才有子交易花费它。父子交易可以出现在同一个区块，父交易在区块中的顺序须早于子交易。
在Mempool 交易池中，交易不一定是各自独立的候选项目。矿工若想收取子交易的费用，就必须处理它依赖的未确认交易。
如果相关组合的费率具竞争力，矿工可能选择一起收录。这是CPFP 的核心原理。
不过，并非全网有一个共同排序名单，也不是只要子交易费率高，矿工就必须将它放进下一个区块。传播、接受政策、依赖关系及后续费率竞争都会影响结果。
先以「一笔未确认父交易＋一笔子交易，且没有其他未确认依赖」的简化情境说明：
组合费率＝（父交易费＋子交易费）÷（父交易虚拟大小＋子交易虚拟大小）。
费用以sat 计算，虚拟大小以vB 计算，得到的单位就是sat/vB。这是依两笔交易费用与大小加总推导的算例，不是任何节点都必定接受的门槛公式。
假设父交易大小为200 vB，已支付400 sat；预估子交易大小为150 vB，希望两笔合计达到10 sat/vB：
子交易的费率约为20.67 sat/vB，组合费率才达到10 sat/vB，因为它也承担了提高整体竞争力的成本。
反过来，若只让子交易本身支付10 sat/vB，也就是1,500 sat，组合费率只有（400＋1,500）÷350≈5.43 sat/vB。
以上均是假设数字，不代表当前建议费率。实际签署后的大小、费用取整及政策要求仍须核对。
若父交易本身又依赖其他未确认交易，实际需要一起考虑的范围可能更大。若有其他子交易或更复杂的相连结构，矿工与节点也可能依交易群组评估。
因此，简单父子平均公式适合入门算例，不能直接代替所有版本的实际区块选择演算法。
判断重点是「谁能花费父交易中的适合输出」。
一般情况下，付款人不能任意花费收款人的输出，收款人也不能任意花费付款人的找零。
如果付款直接存入交易所，由平台控制对应地址，使用者不能只凭帐面余额，在自己的钱包建立该输出的CPFP。
以下是通用检查顺序，实际按钮及支持条件依钱包不同。
取得原付款TxID，核对网路、地址与确认状态。父交易如果已经确认，便不再需要靠它的子交易带动确认。
确认自己控制的是找零还是收款输出，并查看钱包是否提供CPFP、子交易加速或相应的币控制功能。
若钱包限制使用未确认输出，或输出有不符当前条件的锁定要求，就不能假设按一般转帐即可完成。
除了子交易自身费率，也查看父交易大小与费用，以及是否有其他未确认依赖。可优先使用钱包提供的组合估算，再确认额外成本。
所选输出的金额需足以安排子交易费用与有效输出；若需要加入其他输入，子交易大小及费用也要重新估算。
常见方式是将资产移至自己控制的地址。检查新地址、金额与费用，不要为了加速而把资产转给陌生服务。
签署应在自己的可信钱包或硬体钱包流程完成，公开查询与加速咨询不需要交出助记词。
CPFP 会新增子交易TxID，父交易TxID 不因建立子交易而改变。确认时要查看两笔状态，不能只看到子交易已广播就认定父交易已完成。
RBF 费用替换会建立与原交易存在输入冲突的替代交易；CPFP 则建立依赖原交易的后续交易。
两者不是固定哪个比较便宜。应比较钱包支持情况、交易结构与实际成本。已有子交易时，也可能影响钱包可提供的替换选项。
若父子两笔交易都确认，两笔各自的费用都会计入，不像RBF 的原交易与替代交易互相冲突。
前述范例中，父交易费是400 sat，子交易费是3,100 sat，整体费用为3,500 sat。若另有服务费，则还需额外核对。
如果父交易已自行确认，而子交易也已有效广播，子交易并不会因此自动取消。它仍可能作为一般后续转帐继续确认并支付费用，操作前应考虑这个结果。
Bitcoin Core 31.0 引入cluster mempool，以相连交易群组处理相关限制，并移除旧有CPFP carveout 例外。
移除carveout 不等于取消CPFP。它改变的是部分特定交易结构如何取得政策例外；一般读者仍可理解父子交易的加速原理，但不宜照抄旧版固定限制及「一定能多塞一笔子交易」的说法。
另外，将交易提交给一个节点，与保证全网传播、保证矿工收录是不同事情。套件提交与转发能力依软体版本及交易结构而异，不能以提交成功视为加速完成。
正常CPFP 是花费父交易建立的输出，不是竞争花费父交易原本的输入，因此不应直接称为双重支付。
不过，父交易尚未确认时，不能把收款视为完全不可改变。若原付款失效，依赖它的子交易也可能无法成立。
父子都被收进有效区块后，仍须依需求查看确认深度。
常称为子交易为父交易付费，或父子交易加速。
不是。能花费父交易中合适输出的一方，都可能在符合条件下操作，包括收款人。
可以在符合条件时先建立及传播，但有效链必须先包含父交易，才可包含花费其输出的子交易。
可以，区块内须先排列父交易，再排列子交易。
不是。要一起考虑需要收录的未确认依赖、费用及接受政策。
不能把CPFP 当成撤回父交易的方法；它本身依赖父交易成立。
通常不能直接操作由交易所控制的输出，应先询问平台提供的处理方式。
不因建立子交易而改变；需要同时记录父交易与子交易各自的TxID。
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
