协议演进 / BIP/比特币改进提案 / BIP-175
BIP-175
把合同文档的哈希编进 BIP-32 派生路径，使收款地址可被证明是从合同条款与收款方公钥派生出来的。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-175 |
|---|---|
| 标题 | Pay to Contract Protocol |
| 作者 | Omar Shibli <[email protected]>, Nicholas Gregory <[email protected]> |
| 指定日期 | 2017-07-17 |
| 层级 | Applications（应用） |
| 类型 | Informational（信息类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/175 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki |
二、放在哪一族
分层确定性钱包的派生应用族。它不另造钱包体系，而是站在三份既有文档之上：
BIP-32：分层确定性钱包，提供扩展公钥与派生路径
BIP-43：Purpose 字段，本篇据此固定用途值为 175'
BIP-44：Coin type 字段，本篇的币种层与它一致
学理来源是 Ilja Gerhardt 与 Timo Hanke 提出的同态支付地址与多方 Pay-to-Contract 协议，本篇把该派生方案写成可实现的规范。
三、它要解决什么
一笔比特币交易在现实世界里往往对应一份合同：谁付给谁、为什么付。传统商业里靠发票与收据追踪付款；付款人签字确认发票，收款人交付货物。
问题是：光看链上地址，看不出这笔钱对应哪份合同。Gerhardt 与 Hanke 的思路是让地址本身可被证明地派生自“合同条款＋收款方公钥”——任何拿到合同与支付基公钥的人都能重算地址、核对这笔付款到底绑的是哪份合同。
原文强调两点性质：这种派生不膨胀 UTXO 集，且对网络其他参与者完全隐形——派生出的地址看起来与普通 P2(W)PKH 或 P2(W)SH 地址没有区别；要花这笔钱，需要同时知道合同内容与收款方私钥。
四、规则本身
4.1 角色与流程
需要两方：付款人（customer）与收款人（merchant）。
- 付款人向收款人提交购买请求，说明要买的商品或服务；
- 收款人据此构造发票（即合同），列明计费项与总金额；
- 收款人把合同连同“支付基”扩展公钥（payment base）交给付款人；
- 付款人按合同与支付基生成付款地址公钥，把资金发到该地址。
付款本身即构成付款人的收据：商家要动用这笔资金，就必须按同一合同与支付基重建私钥路径，等于默认接受了合同条款。
4.2 派生路径结构
m / purpose' / coin_type' / contract_hash
- Purpose：常量
175'（即0x800000AF），按 BIP-43 的建议固定， hardened 派生； - Coin type：与 BIP-44 同名字段相同，hardened 派生；
- Payment base：
m / purpose' / coin_type'对应的扩展公钥； - Contract hash：由合同文档算出的一段多层路径（见 4.3），拼在支付基之后得到付款地址。
4.3 由合同生成地址
给定合同文档 c1…cn、支付基扩展公钥与哈希函数 h：
- 对每份文档求哈希 h(c1)…h(cn)；
- 把这些哈希按字典序排序；
- 在前面拼上 payment_base 后拼接，再整体求一次哈希，得到 combined hash；
- 把 combined hash 按“哈希转部分派生路径”的规则映射：十六进制数每 4 个字符切一段、转成十进制整数、用
/连接，得到 contract_hash 路径； - 路径拼到支付基之后，算出扩展公钥，再由它算出地址（原文示例为 P2PKH）。
4.4 验证与赎回
验证只需用同一合同、同一支付基重算地址，与给定地址比对；一致才说明地址确实绑着这份合同。文档内容稍有不同，算出的地址就不同——原文给了一个把合同换成单文档 baz 后地址不匹配的反例。
赎回由收款人离线完成：按同样方法构造私钥，并监控链上该付款地址的到账。
原文示例使用 SHA256 作为哈希函数，并走通了从两份文档（内容分别为 bar 与 foo）到地址 1C7f322izqMqLzZzfzkPAjxBzprxDi47Yf 的全过程。
五、谁必须动
普通持币人（付款方）：需用支持本协议的钱包，拿到合同与支付基后由钱包生成绑定合同的地址再付款；普通钱包直接转账无法得到“地址即合同证明”的性质。
钱包开发者：改动不小。原文在兼容性一节直言：付款方与收款方的通信、合同哈希与路径生成都需要对钱包做显著修改；该派生虽符合 BIP-32 的形式，但不与 BIP-32 的既有用法向后兼容理解。
收款方（商家）：负责构造合同、提供支付基、离线重建私钥并监控到账。
全节点与矿工、共识层：无改动。链上只看到普通地址与普通交易，合同绑定关系只存在于双方的链下计算中。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。这意味着该提案已不再作为现行标准推进；读它是为了理解“用派生路径绑定链下合同”这一设计思路及其完整算法，而不是把它当作今天接入支付时应遵循的现行规范。原文没有给出它被广泛采用的结论，本页也不作此推断。
常见误读：
“付到这种地址，合同就写进区块链了。”
不对。链上只有普通地址与交易，合同文档本身不上链、不公开。绑定关系靠的是可重算性：谁同时拿到合同原文与支付基，谁就能验证地址与合同对应；没有合同的人，从链上什么也推不出来。
七、延伸
- 阅读版：https://bips.dev/175
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki
- 相关：BIP-32 分层确定性钱包、BIP-43 Purpose 字段、BIP-44 多账户层级
- 仓库总目录：https://github.com/bitcoin/bips