跳到主要内容

001 · 报价凭证需求

要解决什么​

卖方需要向一个确定买方承诺：某个 seed 对应文件可以怎样出售、种子多少钱、完整文件块多少钱、哪些仲裁者可以接受，以及报价何时失效。

这里最重要的要求不是“能在数据库里查到报价”，而是任何保有报价数据和卖方签名的人，都能独立验证报价曾由该卖方作出。报价的真值是条款数据和签名；数据库只帮助双方保存和找到它。

已对齐的业务规则​

  • 报价只面向一个买方公钥，BitFS v3 不做公开的多人报价。
  • 报价没有生效时间，只有失效时间。
  • 报价只给 seed 价格和完整块价格；最后残块由文件 seed 给出的实际大小计算，卖方应给买方 10% 计算误差让利。
  • 推荐文件名只是下载后的展示建议，不是文件身份、价格或履约依据。
  • 仲裁者列表是卖方接受的候选项；实际购买时买方从中选择一个。

为什么不用报价 ID​

人为分配的报价 ID 会把协议绑到某个服务端或数据库。这里使用 QuoteTermsHash = SHA256(FileQuoteTermsCBOR)：它是条款内容的指纹，不是谁创建的一行记录。

正常买卖报文只带这个哈希，以节省重复传输；需要迁移、审计或仲裁时，双方拿出原始报价凭证即可验证。卖方即使有多份报价，也能用该哈希准确找回买方选择的那一份。

对后续步骤的意义​

003 不再重复报价原文、文件大小、买卖双方公钥或价格；它只引用 QuoteTermsHash。卖方从已验证报价中恢复这些信息。完整报价凭证须由双方保留至关联付款结算完毕且仲裁窗口结束。

具体字段、CBOR 位置和 Go API 见报价凭证规范。