比特币如何使用 BIP70 支付协议 API

支付协议是指 BIP70、71、72 和 73 中指定的协议的术语。支付协议旨在通过用编码更复杂参数的小文件替换无处不在的比特币地址，为比特币添加额外的功能。 它指定了直接在资金发送方和接收方之间流动的支付请求、支付和支付方式的格式。

支付协议是比特币各种重要功能开发的核心，因此了解它如何使用比特币很重要。 本文介绍了基本功能，并展示了一些将其集成到钱包应用程序中的示例代码。

具体来说，协议的版本 1 提供：

1. 接收方/商家使用任意脚本请求多个输出的方式，而不仅仅是单个支付密钥哈希类型输出。 支付可以通过多个独立的交易来满足，允许未来实施基于规避合并的隐私技术。

2. 免短信备注栏，商家可填写钱包存储的购买明细，用户支付时附上留言。

3. 到期，过期的付款请求可能被视为无效。 这允许接收者在服务器端绑定他们的资源使用并丢弃从未支付过的请求。

4. 发行时间，支付请求知道什么时候发行——有利于记录保存。

5. 一个二进制 cookie 式字段，在提交支付交易时将简单地回显到服务器，允许商家实施无状态后端。

6、用户指定的退款地址。

7. 使用 X.509 数字证书对上述所有内容进行签名的可选功能，从而将支付请求绑定到某种经过验证的身份。

支付请求本身可以进行数字签名这一事实实现了一些非常重要和有用的功能。 中间人无法重写输出来劫持支付。 这对于像 Trezor 这样的硬件钱包来说尤其重要，它假定主机受到威胁，否则用户无法知道他们授权的付款与商家请求的付款相同。

此外，经过数字签名的支付请求和在区块链上完成的交易共同创建了一个非常类似于收据的支付证明。 收据对于争议调解和证明购买很有用，商家无需保留他们曾经拥有的每位客户的详尽数据库——即使商家删除了关于您的数据，只需出示收据就足以证明您进行了购买。

Protocol Buffers 是一种易于扩展的二进制数据序列化格式。 因此，我们可以很容易地想象到未来可能会添加的许多其他功能。

您可以阅读支付协议的常见问题解答，详细了解其设计背后的基本原理。

协议概述

在正常的比特币支付中，该过程从用户点击比特币 URI 或将文本地址复制并粘贴到他们的钱包应用程序并手动指定金额开始。

在支付协议处理的支付中，流程以两种方式之一开始：

用户单击带有新“r”参数的比特币 URI，该参数包含解析为支付请求文件的 (http) URL。

用户直接打开支付请求文件。

然后，用户钱包将支付请求数据解析为protocol buffer，正常开始请求确认的过程。 单击比特币 URI 时，URI 其余部分中的指令将被忽略（它们仅用于向后兼容），并且在给定 URL 中找到的数据优先。

支付请求包括包含（可选）签名和证书数据的外部“皮肤”消息，以及包含请求支付详细信息的内部“核心”消息的嵌入式序列化。 外部 PaymentRequest 消息独立于所使用的数字签名基础结构的类型，但目前仅定义了 X.509 绑定。 这与 SSL 中使用的系统相同。 内部 PaymentDetails 消息以二进制形式存储，而不是像普通的 protobuf 消息那样嵌入，以确保签名字节始终匹配。

一旦钱包创建了一组令人满意的比特币交易，付款消息就会被格式化并上传到 PaymentDetails 指定的目标 URL，一旦付款被令人满意地接受，钱包就会收到一条 PaymentACK 消息。

签名和证书

签名支付请求的目的是取代用户钱包应用程序中的此类消息：

Pay 10mBTC to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

有了这个：

支付 10mBTC 至

支付 20mBTC 给？

付给 Michael Hearn 30 亿比特币？

向加利福尼亚州旧金山的 Genius Widgets 公司支付 100 BTC

...当然，第一种形式是最无用的，因为在这种情况下，身份只是一个随机数，没有意义或稳定性。 这就引出了其他例子中的字符串从何而来的问题。

答案是它们包含在 X.509 数字证书中，该证书本身由证书颁发机构签名。 尽管名称如此，但 CA 只是签署证书的任何实体比特币二维码，唯一赋予它们权威的是人们对软件的信任。 身份验证和证书颁发具有竞争性市场，这意味着您可以免费获得电子邮件地址或域名等非常容易验证的身份的证书。 更复杂的身份，例如个人或企业的法定名称，需要更多的努力来验证，因此必须付费。

从技术上讲，证书只是关于公钥的声明，因此您必须首先生成私钥，然后生成证书签名请求 (CSR)，然后选择 CA 并上传 CSR，以及您想要的身份和任何验证所需的信息。 然后，CA 发回一个可以嵌入到支付请求中的签名证书，以及到达一组根证书所需的任何中间证书。 然后使用私钥对 PaymentDetails 消息进行签名，现在其他用户软件可以验证所有这些并在 UI 中显示经过验证的 ID。 它还充当密码证明比特币二维码，证明您在指定时间实际提出了给定付款请求。

事实上，上述手动创建密钥、创建 CSR、上传密码等过程通常会自动撤销最终用户电子邮件地址证书：相反，任何支持 HTML5 的现代 Web 浏览器都可以用来自动化整个过程。 在访问像 Comodo 这样颁发免费证书的 CA 后，用户输入请求的电子邮件地址并单击一个按钮。 然后他们的浏览器生成一个新的私钥并记录下来。 当用户单击传递到其电子邮件地址的验证链接时，签名过程完成，证书安装在本地密钥库中，可以在其中使用或导出到其他设备。 整个过程与注册网站没有太大区别。

bitcoinj 中的支付协议 API

从 0.12 开始，bitcoinj 中的支付协议支持是有限的。 它支持钱包应用程序中基本支持所需的一切，用于签署和使用支付请求。 但是，它不支持将它们存储在钱包中以备将来参考。 Bitcoinj 也没有利用这个机会向接收者提交多个独立的交易以避免合并。

尽管如此，这里还是展示了我们如何使用新功能的演示。

ack = session.sendPayment(ImmutableList.of(req.tx), null, null); Futures.addCallback(ack, new FutureCallback() { @Override public onSuccess(PaymentSession.Ack ack) { wallet.commitTx(req.tx) ; displayMessage(ack.getMemo()); } });

用户界面注意事项

以特定方式提交付款协议确认很重要。

首先，如果签名的 PKI 数据可用，您应该以某种视觉上有意义的方式向用户表明，让他们知道所提供的字符串是经过第三方验证的 ID。 第三方（即 CA）的名称也应该是可见的，尽管默认情况下将其隐藏在切换/滑块后面是可以接受的。

其次，如果提供了签名的 PKI 数据但无法验证，则应以完全相同的方式呈现付款，就好像签名数据完全丢失一样。 打开一个错误签名的请求的体验永远不会比打开一个根本没有签名的请求差。 这使我们能够灵活地引入新的证书颁发机构或签名系统。

二维码

如果您的应用程序集成了对扫描 QR 码的支持，您应该知道 BIP 73。它说如果钱包应用程序扫描 QR 码并找到 HTTP URL 而不是比特币 URI，它应该执行 HTTP[S]GET 以带有特殊 HTTP 的 URL 向服务器请求支付请求的标头的 URL。

这种机制的目的是让商家和支付处理商可以提供适用于任何类型的 QR 扫描仪的 QR 码，如果用户没有带有集成扫描仪的钱包，一个漂亮的 HTML 页面可以显示和说明可点击的比特币链接。

操作系统整合

如果您正在编写钱包应用程序，则应注册以处理比特币 URI，还应注册以处理类型为 application/bitcoin-paymentrequest 且扩展名为 .bitcoinpaymentrequest 的文件。

通过这样做，您可以确保您的应用程序可以处理附加到电子邮件、通过 IM 应用程序等发送的付款请求。

理想情况下，您还允许用户创建付款请求。 PaymentRequest消息的pki_type可以是“none”，所以创建这样一个文件是有效的。 为了方便的用户体验，我们建议：

在桌面上，允许用户拖放付款请求文件（以图标表示）。 例如，用户可以将其拖到电子邮件撰写窗口以将付款请求附加到电子邮件，而不是手动复制/粘贴地址和金额。 Gmail 支持将文件拖放到编辑器上，其他 HTML5 应用程序也可以接受拖放数据。

在移动设备上，允许用户“共享”付款请求文件，这将允许用户通过聊天应用程序发送、附加到电子邮件、通过 DropBox/Google Drive 共享等。

测试

Gavin 在这里运行一个简单的支付请求生成器应用程序：

您可以使用它来测试您的钱包实施。

分享一个java比特币初学者开发教程，涵盖了比特币的核心概念，如区块链存储、去中心化共识机制、密钥和脚本、交易和UTXO等。在代码中集成比特币支持功能，如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习教程。