比特币交易手续费：计算方式、影响因子与BSV实践指南

先讲结论

交易手续费不是写在某个字段里的固定数字，而是由交易输入总额减去输出总额得出的差额。矿工根据交易数据量（而非转账金额）决定是否打包，因此交易大小才是影响费用的关键。在BSV生态中，低费率不等于零费用，应用开发者需要主动管理手续费，避免因忘记找零或估算不当导致资金损失。

手续费的基本计算

比特币交易没有名为“手续费”的输出字段。手续费的计算公式非常直接：

举例来说，假设一笔交易：

• 输入总额：1000 satoshis
• 输出1：300 satoshis 给收款人
• 输出2：650 satoshis 找零

那么手续费 = 1000 - (300 + 650) = 50 satoshis。

如果开发者忘记添加找零输出：

• 输入总额：1000 satoshis
• 输出1：300 satoshis 给收款人

手续费将变为 1000 - 300 = 700 satoshis。这笔交易仍然可能有效，但用户多付了650 satoshis。

为何费用与交易大小相关

矿工处理的是交易数据，而非转账金额。交易占用的字节越多，其传播、验证和存储的资源消耗就越大，因此矿工倾向于按交易大小收取费用。

影响交易大小的常见因素包括：

• 输入（inputs）的数量
• 输出（outputs）的数量
• 解锁脚本（unlocking script）的长度
• 锁定脚本（locking script）的长度
• 是否包含较多 OP_RETURN 数据
• 是否包含复杂脚本

因此，一笔转账100 satoshis但输入多、数据复杂的交易，其体积可能远超一笔转账100000 satoshis的简单交易，手续费也可能更高。

用SDK计算手续费

常用的BSV SDK（如TypeScript SDK）提供了自动计算手续费的机制。典型流程是先添加输入和输出，再调用 await tx.fee()。如果设置了 change: true 的找零输出，SDK会在计算费用后自动调整找零金额，使输入输出保持平衡。

示例代码片段：

注意，SDK并非凭空“创造”手续费，它只是根据交易结构和费率模型计算出合理费用，并将剩余金额放入找零输出。

手动处理费用的两个层次

层次一：理解差额

至少能够看懂：

• 输入总额是多少
• 输出总额是多少
• 二者差额即手续费

这是最基础的手续费意识。

层次二：估算交易大小

在生产系统中，需要根据交易字节大小和当前费率计算目标手续费。SDK的费率模型可以辅助完成此事，但开发者仍需理解：为什么输入越多费用越高、数据越多费用越高、脚本越复杂费用越高。掌握这些原理，才能在估算费用时做出合理判断。

BSV的低费路线不等于零费

BSV的技术路线强调大区块和低费率，适合高频、微支付及数据交易。但低费用不意味着零费用。矿工和交易处理服务仍有自己的网络策略，交易必须满足其基本费用要求才能被接受。

因此，生产级应用应当：

• 使用合理的费率
• 检查交易是否被网络接受
• 对广播失败实施重试和错误处理
• 监控异常高费用的交易
• 避免因忘记找零导致资金损失

手续费与粉尘输出的边界

如果输出金额太小，可能在实际网络策略中受到限制（即“粉尘”）。BSV的政策和具体服务实现会影响交易是否容易被接受。入门阶段不需背下所有参数，但要建立认知：

协议允许的结构，不一定等于所有服务都会接受的结构。

这也是为什么真实项目必须测试当前使用的广播服务、钱包和矿工策略。

手续费在BSV技术栈中的位置

手续费是BSV经济模型的核心部分，它激励矿工处理交易，也让应用为链上资源付费。对应用来说，手续费设计直接影响产品形态：

• 微支付产品 必须关心单笔费用
• 数据应用 要衡量每字节成本
• 高频系统 需考虑批量交易、UTXO预分配和广播稳定性
• Overlay或钱包系统 要处理交易失败后的状态恢复

手续费不是底层实现细节，而是应用架构设计的一部分。

新手常见误解

• 手续费不是显式输出：它是输入与输出的差额，容易遗漏
• 低费不等于零费：交易仍需满足网络接受条件
• 转账金额大不代表手续费高：交易大小才是关键影响因素
• 忘记找零会导致手续费异常偏高
• SDK自动算费不代表可以不做检查：生产环境应记录费用、交易大小和广播状态

参考资源

• Transaction Inputs and Outputs
• Large Transactions guide
• Direct Transaction Creation
• Transaction reference
• Fees concept