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

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

支付协议对于比特币各种重要功能的开发至关重要，因此了解它如何使用比特币非常重要。本文描述了基本功能，并展示了一些将其集成到钱包应用程序中的示例代码。

具体来说比特币电子钱包注册教程，第一版协议规定：

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

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

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

您可以阅读付款协议常见问题解答，其中详细说明了其设计背后的原理。

协议概述

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

在付款协议处理的付款中，该流程以两种方式之一启动：

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

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

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

签名和证书

签署支付请求的目的是替换用户钱包应用程序中的此类消息：

Pay 10mBTC to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

有了这个：

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

答案是它们包含在 X.509 数字证书中，该证书本身由证书颁发机构签名。尽管名称如此，CA 只是签署证书的任何实体比特币电子钱包注册教程，唯一赋予他们权力的是人们对软件的信任。身份验证和证书颁发市场竞争激烈，这意味着您可以免费获得非常易于验证的身份证书（如电子邮件地址或域名）的证书。更复杂的身份，例如个人或公司的法定名称，需要更多的努力来验证，因此必须付费。

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

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

bitcoinj 中的支付协议 API

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

不过，这里有一个演示我们如何使用新功能。

String url = QRCodeScanner.scanFromCamera(.....);
ListenableFuture future;
if (url.startsWith("http")) {
    // URL may serve either HTML or a payment request depending on how it's fetched. 
    // Try here to get a payment request.
    future = PaymentSession.createFromUrl(url);
} else if (url.startsWith("bitcoin:")) {
    future = PaymentSession.createFromBitcoinUri(new BitcoinURI(url));
}
PaymentSession session = future.get();    // may throw PaymentRequestException.
String memo = session.getMemo();
Coin amountWanted = session.getValue();
if (session.isExpired()) {
    showUserErrorMessage();
}
PaymentSession.PkiVerificationData identity = null;
try {
    identity = session.verifyPki();
} catch (Exception e) {
    log.error(e);
    // Don't show errors that occur during PKI verification to the user!
    // Just treat such payment requests as if they were unsigned. This way
    // new features and PKI roots can be introduced in future without
    // being disruptive.
}
if (identity != null) {
    showUserConfirmation(identity.domainName, identity.orgName);
} else { 
    showUserConfirmation();
}
// a bit later when the user has confirmed the payment
SendRequest req = session.getSendRequest();
wallet.completeTx(req);  // may throw InsufficientMoneyException
// No refund address specified, no user specified memo field.
ListenableFuture 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。第 3 方的名称（即 CA）也应该可见，尽管默认情况下将其隐藏在切换/滑块后面是可以接受的。

其次，如果提供了签名的 PKI 数据但无法验证，则应以与签名数据完全丢失完全相同的方式显示付款。打开一个签名错误的请求的体验永远不会比打开一个完全未签名的请求更糟糕。这使我们能够灵活地引入新的证书颁发机构或签名系统。

二维码

如果你的应用集成了对扫描二维码的支持，你应该知道 BIP 73.它说如果钱包应用扫描二维码并找到 HTTP URL 而不是比特币 URI，它应该执行HTTP[ S] GET 到带有特殊 HTTP 标头的 URL，该标头要求服务器提供付款请求。

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

操作系统集成

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

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

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

测试

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

~gavi...

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

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