跳到主要内容

005 · 累计支付需求

要解决什么​

买方验证 004 的内容后，才签出本次累计付款状态并交给卖方。费用池不为每个块独立扣一笔临时金额，而采用覆盖式的累计支付状态：同一池始终花费同一个基础输出，最新状态完整承接此前已付金额。

卖方把该远期交易提交给 BSV 非最终交易池。它在到期前只被节点验证、保存和覆盖，不进入区块；到期后最新状态才进入可打包状态。买卖双方若协商结束池子，则把同一状态改为立即最终化并提交。

最重要的规则：支付序号​

PaymentSequence 就是花费交易输入的 nSequence，描述费用池版本，不是文件块编号、请求编号，也不表达种子与块的顺序。

设当前最新状态为 N，卖方累计应得金额为 S。一次正常付款产生任意一个 N 以上、但小于 0xffffffff 的序号；卖方累计应得金额变为 S + 本次应付金额。

状态 7：卖方累计可得 1,000 sat
本次支付：80 sat
状态 8 或状态 20：卖方累计可得 1,080 sat

跳号不改变金额规则，也不允许生成两份相同或较小序号的不同状态。0xffffffff 专门表示主动关闭，不能用于正常内容付款。

买方签出付款交易后，卖方不需要再发一个“我确认该金额”的应用层反签报文。交易签名和非最终交易池接受结果本身就是可验证事实。

文件块、费用池与串行请求​

种子先用于发现文件块哈希列表；此后文件块可以按任意哈希、任意顺序购买。一个文件的不同块可使用不同费用池；同一费用池也可支付任意文件块，只要它属于相同买方、卖方和选定仲裁者组成的有效费用池。

但同一池在某个当前序号上只能有一笔待付款的内容请求。否则买方可以用同一余额同时请求多个块，卖方先交付后，买方却只签出其中一笔付款，造成免费内容交付。

因此 BitFS v3 的卖方行为是：

  1. 接收 003 时，核对费用池当前最新状态与 BasePaymentSequence 一致，且池中不存在进行中的请求。
  2. 原子地保存该进行中请求，再交付 004。
  3. 收到 005 后，验证交易金额、买方签名、输入和更高序号；仅在非最终交易池确认接受后，释放该池的门闩。
  4. 门闩存在、序号过时或重复时，拒绝新的 003。买方要并行购买，应新开费用池。

该门闩是卖方的交付风险控制数据，须通过外部存储钩子保存；它不是费用池或付款的真值，不能被用于篡改已签交易。

到期与风险边界​

这是一条单向风险边界：卖方不提交任何付款交易，买方在到期后走初始全额退款；卖方提交最新累计付款交易，到期后交易按其中的累计金额与买方找零结算。买方不因卖方不作为向仲裁者起诉，也不需要卖方反签一个链下“金额确认”。

卖方无法正常提交一份买方已签出的付款交易时，才可按 007 请求仲裁者补足签名。仲裁者验证的是完整开池证明与精确付款交易，而不是数据库记录、单独金额字段或支付序号文字。

为什么这是可行的​

普通 Bitcoin 的整数序号本身不是“较大即胜”的链上规则；本设计依赖 BSV 节点的非最终交易池：同一输入的远期交易以更高 nSequence 覆盖旧状态，并在到期后再进入可打包状态。因而 005 的实现必须使用支持该能力的节点提交接口，而不能把普通广播节点当作费用池状态机。

具体 CBOR 字段、交易校验和钩子边界见累计支付规范。