BIP75：支付协议扩展

该 BIP (Bitcoin Improvement Proposal) 提议对 BIP70 支付协议进行扩展，主要包括：允许支付请求的发起者（Sender）自愿签名原始请求，并提供证书，让收款人（Payee）知道交易的身份；以及加密返回的 PaymentRequest，以防止中间人查看 Payment Request 的详细信息，从而实现更安全和自动化的支付信息交换过程。

跳至内容

techguy613/ bips Public

forked from bitcoin/bips

折叠文件树

文件

master

搜索此仓库

/

bip-0075.mediawiki

复制路径

BlameMore file actions

BlameMore file actions

最近提交

luke-jrluke-jr

BIP 75: 添加 License header

Jan 1, 2017

7d94bb6 · Jan 1, 2017

历史

历史

打开提交详情

查看此文件的提交历史。

428 行 (343 loc) · 29.1 KB

/

bip-0075.mediawiki

顶部

文件元数据和控件

  • 预览

  • 代码

  • Blame

428 行 (343 loc) · 29.1 KB

Raw

复制原始文件

下载原始文件

大纲

编辑和原始操作

  BIP: 75
  Layer: Applications
  Title: Out of Band Address Exchange using Payment Protocol Encryption
  Author: Justin Newton <justin@netki.com>
          Matt David <mgd@mgddev.com>
          Aaron Voisine <voisine@gmail.com>
          James MacWhyte <macwhyte@gmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075
  Status: Draft
  Type: Standards Track
  Created: 2015-11-20
  License: CC-BY-4.0
## 目录<br>Permalink: 目录<br>- 摘要<br>- 版权<br>- 定义<br>- 动机<br>- 用例示例<br>- 修改 BIP70 pki_type<br>- 新消息 <br> - InvoiceRequest<br> - ProtocolMessageType 枚举<br> - ProtocolMessage<br> - 版本控制<br> - EncryptedProtocolMessage<br>- 带有 InvoiceRequests 的支付协议流程<br>- 消息交互详情 <br> - 新消息类型的 HTTP 内容类型<br> - 支付协议状态通信 <br> - 支付协议状态码<br> - 传输层通信错误<br>- 扩展的支付协议流程详情 <br> - InvoiceRequest 消息创建<br> - InvoiceRequest 验证<br> - 使用 EncryptedProtocolMessages 发送加密的支付协议消息<br> - 使用 EncryptedProtocolMessages 验证和解密支付协议消息<br> - ECDH 点生成和 AES-256 (GCM 模式) 设置 <br> - AES-256 GCM 身份验证标签使用<br> - AES-256 GCM 附加身份验证数据<br> - 用于 InvoiceRequest 加密的初始公钥检索<br>- 具有 HTTP 存储和转发服务器的支付/PaymentACK 消息<br>- 公钥 & 签名编码<br>- 实现<br>- BIP70 扩展<br>- 移动到移动示例 <br> - 完整支付协议<br> - 通过 EncryptedProtocolMessage 加密初始 InvoiceRequest<br>- 参考

摘要

Permalink: 摘要

此 BIP 是对 BIP 70 的扩展，它为现有的支付协议提供了两项增强功能。

  1. 它允许 PaymentRequest 的请求者（发送方）自愿签署原始请求并提供证书，以便收款人知道他们正在与谁交易。
  2. 它在返回 PaymentRequest 之前对其进行加密，然后将其交给 SSL/TLS 层，以防止中间人查看 Payment Request 详细信息。

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 中的描述进行解释。

版权

Permalink: 版权

本作品根据 Creative Commons Attribution 4.0 International License 授权。

定义

Permalink: 定义
发送方 希望转移他们控制的价值的实体
接收方 接收价值转移的实体

动机

Permalink: 动机

定义此 BIP70 支付协议扩展的动机是允许双方以许可和加密的方式交换支付信息，从而使钱包地址通信成为一个更自动化的过程。此扩展还扩展了支持的 PKI（公钥基础设施）数据的类型，并允许双方共享它（使用 BIP70，只有接收方可以提供 PKI 信息）。这允许自动创建人类可读的链下交易日志，现在包括关于发送方的信息，而不仅仅是接收方。

此 BIP70 扩展的动机有三方面：

  1. 确保支付详情只能由交易参与者看到，而不能被任何第三方看到。
  2. 增强支付协议以允许存储和转发服务器，以便允许，例如，移动钱包签名和服务 Payment Request。
  3. 允许资金发送方选择与接收方共享其身份。然后，此信息可用于：
    • 使比特币日志（钱包交易历史）更易于阅读
    • 让用户能够决定是否在被请求时共享其比特币地址和其他支付详情
    • 允许企业以基于开放标准的方式保存其金融交易的可验证记录，以更好地满足会计实务或其他报告和法定要求的需求
    • 自动化支付地址的积极交换，从而可以避免静态地址和 BIP32 X-Pub，以保持隐私和便利

简而言之，我们希望使比特币更人性化，同时提高交易隐私。

用例示例

Permalink: 用例示例

1. 地址簿

比特币钱包开发者希望提供存储收款人“地址簿”的功能，以便用户可以向已知实体发送多次付款，而无需每次都请求地址。静态地址会损害隐私，并且地址重用被认为是安全风险。BIP32 X-Pub 允许生成唯一地址，但为每个希望接收资金的人员监视 X-Pub 链对于移动应用程序来说过于耗费资源，并且总是存在在所有者失去对相应私钥的访问权限后，在不知情的情况下将资金发送到 X-Pub 地址的风险。

使用此 BIP，比特币钱包可以维护一个“地址簿”，该地址簿只需要存储每个收款人的公钥。可以通过使用钱包名称、扫描二维码、通过短信或电子邮件发送 URI 或搜索公共存储库来将条目添加到地址簿中。当用户希望付款时，他们的钱包会在后台完成所有工作，以与收款人的钱包通信以接收唯一的支付地址。如果收款人的钱包丢失、更换或销毁，则无法进行通信，并且可以防止将资金发送到“死”地址。

2. 个人许可地址发布

比特币钱包开发者希望允许用户在决定是否与潜在发送方共享支付信息之前，查看潜在发送方的身份信息。目前，BIP70 与任何请求者共享接收方的支付地址和身份信息。

使用此 BIP，比特币钱包可以使用发送方的身份信息来确定是否共享他们自己的信息。这使接收方可以更好地控制谁接收他们的支付和身份信息。此外，这可以用于自动向列入白名单的发送方提供新的支付地址，或保护用户的隐私免受未经请求的支付请求。

3. 使用存储和转发服务器

比特币钱包开发者希望使用公共存储和转发服务进行异步地址交换。这对于移动和离线钱包来说是一个常见的用例。

使用此 BIP，返回的支付信息在使用 ECDH 计算的共享密钥加密后，再发送到存储和转发服务。在这种情况下，对存储和转发服务的一次成功攻击将无法读取或修改钱包地址或支付信息，只能删除加密的消息。

修改 BIP70 pki_type

Permalink: 修改 BIP70 pki_type

此 BIP 为 PaymentRequest 消息中的 pki_type 变量添加了额外的可能值。完整的列表现在如下：

pki_type 描述
x509+sha256 x.509 证书，如 BIP70 中所述
pgp+sha256 OpenPGP 证书
ecdsa+sha256 secp256k1 ECDSA 公钥

注意：虽然 BIP70 支持 SHA1，但它已被弃用，BIP75 仅支持 SHA256。哈希算法仍然在上面列出的值中指定，以实现向前和向后兼容性。

新消息

Permalink: 新消息

更新后的 paymentrequest.proto 包含现有的 PaymentRequest Protocol Buffer 消息以及此 BIP 中新定义的消息。

注意：为了方便加密通信，双方的公钥必须彼此已知。虽然在每条消息中都包含两个公钥可能会变得冗余，但它提供了最大的灵活性，因为每条消息都是完全独立的。

InvoiceRequest

Permalink: InvoiceRequest

InvoiceRequest 消息允许发送方将信息发送给接收方，以便接收方可以创建并返回 PaymentRequest。

message InvoiceRequest &#123;
        required bytes  sender_public_key &#61; 1&#59;
        optional uint64 amount &#61; 2 &#91;default &#61; 0&#93;&#59;
        optional string pki_type &#61; 3 &#91;default &#61; &quot;none&quot;&#93;&#59;
        optional bytes  pki_data &#61; 4&#59;
        optional string memo &#61; 5&#59;
        optional string notification_url &#61; 6&#59;
        optional bytes  signature &#61; 7&#59;
&#125;
字段名 描述
sender_public_key 发送方的 SEC 编码的 EC 公钥
amount amount 是 satoshis 的整数 (默认值: 0)
pki_type none / x509+sha256 / pgp+sha256 / ecdsa+sha256 (默认值: "none")
pki_data 取决于 pki_type
memo 针对接收方的人类可读的发票请求描述
notification_url 安全的（通常是受 TLS 保护的 HTTP）位置，准备就绪后应在此处发送 EncryptedProtocolMessage
signature 依赖于 PKI 的签名

ProtocolMessageType 枚举

Permalink: ProtocolMessageType 枚举

此枚举用于新定义的 ProtocolMessage 和 EncryptedProtocolMessage 消息中，以定义序列化的消息类型。ProtocolMessageType 枚举以可扩展的方式定义，以允许向支付协议添加新的消息类型。

enum ProtocolMessageType &#123;
    UNKNOWN_MESSAGE_TYPE &#61; 0&#59;
    INVOICE_REQUEST &#61; 1&#59;
    PAYMENT_REQUEST &#61; 2&#59;
    PAYMENT &#61; 3&#59;
    PAYMENT_ACK &#61; 4&#59;
&#125;

ProtocolMessage

Permalink: ProtocolMessage

ProtocolMessage 消息是任何支付协议消息的封装包装器。它允许支付协议消息的双向、非加密通信。该消息还包括一个状态代码和一个状态消息，用于错误通信，以便该协议不依赖于传输层错误处理。

message ProtocolMessage &#123;
    required uint64 version &#61; 1
    required uint64 status_code &#61; 2&#59;
    required ProtocolMessageType message_type &#61; 3&#59;
    required bytes serialized_message &#61; 4&#59;
    optional string status_message &#61; 5&#59;
    required bytes identifier &#61; 6&#59;
&#125;
字段名 描述
version 协议版本号（当前为 1）
status_code 支付协议状态代码
message_type serialized_message 的消息类型
serialized_message 序列化的支付协议消息
status_message 人类可读的支付协议状态消息
identifier 用于在服务器上标识整个交换的唯一键。默认值应为 SHA256(序列化的初始 InvoiceRequest + 当前 Epoch 时间（以字符串形式表示）)

版本控制

Permalink: 版本控制

此 BIP 引入了此协议的第 1 版。使用这些基本要求发送的所有消息必须使用值 1 作为版本号。任何修改此协议（加密方案等）的未来 BIP 都必须将版本号递增 1。

启动通信时，第一条消息的版本字段应设置为发送方理解的最高版本号。所有客户端必须能够理解小于他们支持的最高编号的所有版本号。如果客户端收到版本号高于他们理解的消息，他们必须将消息发送回发送方，状态代码为 101（“版本太高”），并且版本字段设置为收件人理解的最高版本号。然后，发送方必须使用收件人返回的相同版本号重新发送原始消息或中止。

EncryptedProtocolMessage

Permalink: EncryptedProtocolMessage

EncryptedProtocolMessage 消息是任何支付协议消息的封装包装器。它允许支付协议消息的双向、经过身份验证和加密的通信，以便对其内容保密。该消息还包括一个状态代码和一个状态消息，用于错误通信，以便该协议不依赖于传输层错误处理。

message EncryptedProtocolMessage &#123;
    required uint64 version &#61; 1 &#91;default &#61; 1&#93;&#59;
    required uint64 status_code &#61; 2 &#91;default &#61; 1&#93;&#59;
    required ProtocolMessageType message_type &#61; 3&#59;
    required bytes encrypted_message &#61; 4&#59;
    required bytes receiver_public_key &#61; 5&#59;
    required bytes sender_public_key &#61; 6&#59;
    required uint64 nonce &#61; 7&#59;
    required bytes identifier &#61; 8&#59;
    optional string status_message &#61; 9&#59;
    optional bytes signature &#61; 10&#59;
&#125;
字段名 描述
version 协议版本号
status_code 支付协议状态代码
message_type 解密的 encrypted_message 的消息类型
encrypted_message AES-256-GCM 加密的（如 BIP75 中所定义）支付协议消息
receiver_public_key 接收方的 SEC 编码的 EC 公钥
sender_public_key 发送方的 SEC 编码的 EC 公钥
nonce 自 Epoch 以来经过的微秒数
identifier 用于在服务器上标识整个交换的唯一键。默认值应为 SHA256(序列化的初始 InvoiceRequest + 当前 Epoch 时间（以字符串形式表示）)
status_message 人类可读的支付协议状态消息
signature DER 编码的对完整的 EncryptedProtocolMessage 的签名，该签名带有属于发送方/接收方的 EC 密钥

带有 InvoiceRequests 的支付协议流程

Permalink: 带有 InvoiceRequests 的支付协议流程

下面定义了在支付协议中使用 InvoiceRequests 的完整流程概述。

所有支付协议消息必须封装在 ProtocolMessage 或 EncryptedProtocolMessage 中。一旦流程开始使用 EncryptedProtocolMessage 消息，所有后续通信必须使用 EncryptedProtocolMessages。

所有支付协议消息应使用 EncryptedProtocolMessage 封装消息进行通信，但如果接收方的公钥未知，则可以考虑使用 ProtocolMessage 通信 InvoiceRequest。

使用 EncryptedProtocolMessages 发送加密的支付协议消息 中列举了创建加密的支付协议消息的过程，并且可以在 使用 EncryptedProtocolMessages 验证和解密支付协议消息 下找到解密加密消息的过程。

从头到尾的标准交换如下所示：

  1. 发送方创建 InvoiceRequest
  2. 发送方将 InvoiceRequest 封装在 (加密的) ProtocolMessage 中
  3. 发送方将 (加密的) ProtocolMessage 发送给接收方
  4. 接收方从发送方检索 (加密的) ProtocolMessage 中的 InvoiceRequest
  5. 接收方创建 PaymentRequest
  6. 接收方将 PaymentRequest 封装在 EncryptedProtocolMessage 中
  7. 接收方将 EncryptedProtocolMessage 传输给发送方
  8. 发送方验证从 EncryptedProtocolMessage 检索到的 PaymentRequest
  9. PaymentRequest 根据 BIP70 进行处理，包括封装在 EncryptedProtocolMessage 消息中的可选 Payment 和 PaymentACK 消息。

注意： 有关检索接收方公钥的可能选项，请参见 用于 InvoiceRequest 加密的初始公钥检索。

消息交互详情

Permalink: 消息交互详情

新消息类型的 HTTP 内容类型

Permalink: HTTP 内容类型用于新消息类型

通过 HTTP 进行通信时，必须使用适当的 Content-Type 标头通过受 TLS 保护的 HTTP 传输以下列出的消息，如下表定义的消息：

消息类型 内容类型
ProtocolMessage application/bitcoin-paymentprotocol-message
EncryptedProtocolMessage application/bitcoin-encrypted-paymentprotocol-message

支付协议状态通信

Permalink: 支付协议状态通信

每个 ProtocolMessage 或 EncryptedProtocolMessage 必须包含一个状态代码，该代码传达有关最后接收的消息的信息（如果有）（对于发送的第一条消息，即使没有先前的消息，也使用状态 1“OK”）。如果发生错误导致支付协议流程停止或需要重试消息，则生成错误的一方应返回 ProtocolMessage 或 EncryptedProtocolMessage。消息的内容必须包含相同的 serialized_message 或 encrypted_message 和标识符（如果存在），并且必须适当地设置 status_code。

应使用状态代码的人类可读的解释来设置 status_message 值。

支付协议状态代码

Permalink: 支付协议状态代码

状态代码 描述
1 OK
2 取消
100 常规/未知错误
101 版本太高
102 身份验证失败
103 需要加密的消息
200 金额过高
201 金额过低
202 金额无效
203 支付不符合 PaymentRequest 的要求
300 需要证书
301 证书已过期
302 证书对于交易无效
303 证书已吊销
304 证书未良好扎根

+==取消消息==+ 如果交易的参与者想要通知另一方先前的消息应被取消，他们可以发送相同的消息，状态代码为 2（“取消”），并在适用的情况下，更新 nonce。收件人如何使用“取消”消息由开发者决定。例如，钱包开发者可能希望为用户提供取消他们已发送给其他用户的支付请求的功能，并使该更改反映在收件人的 UI 中。使用非加密 ProtocolMessage 的开发者可能希望忽略“取消”消息，因为可能难以验证该消息是否来自同一用户。

传输层通信错误

Permalink: 传输层通信错误

必须通过通信层现有的错误消息传递工具将通信错误传达给发起通信的一方。对于受 TLS 保护的 HTTP，这应通过标准 HTTP 状态代码消息传递来完成- 创建一个 InvoiceRequest 消息

  • sender_public_key 必须设置为一个 EC 密钥对的公钥
  • amount 是可选的。如果 InvoiceRequest 没有指定金额，接收者可以在返回的 PaymentRequest 中指定金额。如果 InvoiceRequest 指定了金额，但无法生成该金额的 PaymentRequest，则 InvoiceRequest 应该在 ProtocolMessage 或 EncryptedProtocolMessage 中返回相同的 InvoiceRequest，并适当设置 status_code 和 status_message 字段。
  • memo 是可选的。这可以设置为 InvoiceRequest 的人类可读描述
  • 将 notification_url 设置为接收者将提交已完成的 PaymentRequest（封装在 EncryptedProtocolMessage 中）的 URL
  • 如果不包含证书，将 pki_type 设置为 "none"
  • 如果包含证书：
    • 将 pki_type 设置为 "x509+sha256"
    • 按照 BIP-0070（Certificates）中的设置方式设置 pki_data
    • 使用 X509 证书的私钥对 InvoiceRequest 进行签名，signature = ""
    • 将 signature 值设置为计算出的签名

InvoiceRequest 验证

Permalink: InvoiceRequest Validation

  • 验证 sender_public_key 是一个有效的 EC 公钥
  • 验证 notification_url（如果设置了），包含被认为是 URL 的有效字符（避免与 XSS 相关的字符等）。
  • 如果 pki_type 为 None，则 InvoiceRequest 有效
  • 如果 pki_type 为 x509+sha256，并且 signature 对于序列化的 InvoiceRequest 有效（其中 signature 设置为 ""），则 InvoiceRequest 有效

使用 EncryptedProtocolMessages 发送加密的支付协议消息

Permalink: Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages

  • 使用 AES-256-GCM 加密序列化的支付协议消息，设置方式如 ECDH Point Generation and AES-256 (GCM Mode) Setup 中所述
  • 创建 EncryptedProtocolMessage 消息
  • 将 encrypted_message 设置为支付协议消息的加密值
  • version 应该设置为客户端理解的最高版本号（目前为 1）
  • sender_public_key 必须设置为发送者 EC 密钥对的公钥
  • receiver_public_key 必须设置为接收者 EC 密钥对的公钥
  • nonce 必须设置为在 AES-256-GCM 加密操作中使用的 nonce
  • 将 identifier 设置为在原始 InvoiceRequest 的 ProtocolMessage 或 EncryptedProtocolMessage 包装消息中接收到的 identifier 值
  • 将 signature 设置为 ""
  • 使用通信方的 EC 公钥对序列化的 EncryptedProtocolMessage 消息进行签名
  • 将 signature 设置为上述签名操作的结果

签名说明： EncryptedProtocolMessage 消息使用传输消息的一方的公钥进行签名。这允许存储转发服务器或其他传输系统防止垃圾邮件或其他滥用行为。对于那些注重隐私并且不希望服务器跟踪两个公钥之间的交互的人，发送者可以为每次交互生成一个新的公钥，以保持其身份匿名。

使用 EncryptedProtocolMessages 验证和解密支付协议消息

Permalink: Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages

ECDH 点生成和 AES-256（GCM 模式）设置

Permalink: ECDH Point Generation and AES-256 (GCM Mode) Setup

注意：使用 AES-256-GCM 是因为它提供了经过身份验证的加密功能，因此无需单独的消息哈希进行身份验证。

  • 使用本地实体的私钥和远程实体的公钥作为输入，使用 ECDH 生成 secret point
  • 初始化 HMAC_DRBG
    • 使用 SHA512(以大端字节表示的 secret point 的 X 值) 作为熵
    • 使用给定消息的 nonce 字段作为 Nonce，转换为字节字符串（大端）
  • 在 GCM 模式下初始化 AES-256
    • 使用 256 位的安全强度初始化 HMAC_DRBG
    • 使用 HMAC_DRBG.GENERATE(32) 作为加密密钥（256 位）
    • 使用 HMAC_DRBG.GENERATE(12) 作为初始化向量 (IV)（96 位）
AES-256 GCM 身份验证标签的使用

Permalink: AES-256 GCM Authentication Tag Use

从 AES-GCM 加密操作产生的 16 字节身份验证标签必须前缀到返回的密文中。解密操作将使用密文的前 16 个字节作为 GCM 身份验证标签，并将密文的其余部分作为解密操作中的密文。

AES-256 GCM 附加身份验证数据

Permalink: AES-256 GCM Additional Authenticated Data

当 status_code 或 status_message 存在时，在加密和解密操作中使用的 AES-256 GCM 身份验证数据必须是：STRING(status_code) || status_message。否则，没有额外的身份验证数据。这提供了身份验证，即使 status_code 和 status_message 未加密。

用于 InvoiceRequest 加密的初始公钥检索

Permalink: Initial Public Key Retrieval for InvoiceRequest Encryption

可以通过多种方式检索用于通过 EncryptedProtocolMessage 封装加密 InvoiceRequest 的初始公钥，包括但不限于以下方式：

  1. 钱包名称公钥资产类型解析 - DNSSEC 验证的名称解析通过 TXT 记录返回 Base64 编码的 DER 格式的 EC 公钥 RFC 5480
  2. 密钥服务器查找 - 基于密钥服务器标识符（即，电子邮件地址）的密钥服务器查找（类似于 PGP 的 pgp.mit.edu）返回 Base64 编码的 DER 格式的 EC 公钥 RFC 5480
  3. 二维码 - 使用二维码编码 SEC 格式的 EC 公钥 RFC 5480
  4. 地址服务公钥暴露

具有 HTTP 存储转发服务器的支付/PaymentACK 消息

Permalink: Payment / PaymentACK Messages with a HTTP Store & Forward Server

如果存储转发服务器希望保护自己免受垃圾邮件或滥用的侵害，他们可以制定他们认为合适的任何规则，例如以下规则：

  • 一旦收到 InvoiceRequest 或 PaymentRequest，所有后续使用相同 identifier 的消息必须使用相同的发送者和接收者公钥。
  • 对于每个唯一的 identifier，只能提交每种类型的 InvoiceRequest、PaymentRequest 和 PaymentACK 消息各一条。Payment 消息可以多次提交/覆盖。在收到 PaymentACK 后提交的所有消息将被拒绝。
  • 仅保存特定消息，直到它们已被预期收件人可验证地收到或经过一定时间为止，以先到者为准。

客户端应该记住，接收者可以在不返回 ACK 的情况下广播交易。如果需要更新 Payment 消息，它应该至少包含原始交易中引用的一个输入，以防止接收者广播两个交易并获得两次付款。

公钥和签名编码

Permalink: Public Key & Signature Encoding

  • 此 BIP 中定义的任何消息中包含的所有 x.509 证书都必须是 DER [ITU.X690.1994] 编码的。
  • 此 BIP 中定义的任何消息中的所有 EC 公钥（sender_public_key、receiver_public_key）都必须是使用 http://www.secg.org/sec1-v2.pdf 编码的 http://www.secg.org/sec2-v2.pdf ECDSA 公钥 ECPoints。编码可以是压缩的。
  • 此 BIP 中定义的任何消息中包含的所有 ECC 签名必须使用 SHA-256 哈希算法，并且必须是 DER [ITU.X690.1994] 编码的。
  • 所有 OpenPGP 证书必须遵循 RFC4880 的 5.5 和 12.1 节。

实现

Permalink: Implementation

可以在此处找到支持此提案的存储转发服务器的参考实现：

Addressimo

可以在此处找到 Addressimo 的 InvoiceRequest 功能测试中的参考客户端实现：

BIP75 Client Reference Implementation

BIP70 扩展

Permalink: BIP70 Extension

下图借用自 BIP70 并在其基础上进行了扩展，以便直观地描述此 BIP 如何成为 BIP70 的扩展。

移动到移动示例

Permalink: Mobile to Mobile Examples

完整支付协议

Permalink: Full Payment Protocol

下图显示了一个示例流程，其中一个移动客户端正在使用 InvoiceRequest、存储转发服务器、PaymentRequest、Payment 和 PaymentACK 向第二个移动客户端发送价值。在这种情况下，PaymentRequest、Payment 和 PaymentACK 消息使用 EncryptedProtocolMessage 进行加密并且接收者将交易提交到比特币网络。

通过 EncryptedProtocolMessage 加密初始 InvoiceRequest

Permalink: Encrypting Initial InvoiceRequest via EncryptedProtocolMessage

下图显示了一个示例流程，其中一个移动客户端正在使用 EncryptedProtocolMessage 通过加密传输 InvoiceRequest、存储转发服务器和 PaymentRequest 向第二个移动客户端发送价值。在这种情况下，所有支付协议消息都使用 EncryptedProtocolMessage 进行加密并且发送者将交易提交到比特币网络。

参考

Permalink: References

  • 原文链接： github.com/techguy613/bi...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
techguy613
techguy613
江湖只有他的大名，没有他的介绍。

techguy613

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！