rfc/obpp-05.mediawiki，来自 master · OpenBitcoinPrivacyProject/rfc

跳到内容

OpenBitcoinPrivacyProject/ rfc 公开

• 通知 你必须登录才能更改通知设置
• Fork\ 8
• Star\ 19

折叠文件树

文件

master

搜索此仓库

/

obpp-05.mediawiki

复制路径

Blame更多文件操作

Blame更多文件操作

最近提交

SamouraiDev

change status to 'Final' // 将状态更改为“最终”

May 4, 2021

dc3a49d · May 4, 2021

历史

历史

打开提交详情

查看此文件的提交历史。

325 行 (246 loc) · 21.8 KB

/

obpp-05.mediawiki

顶部

文件元数据和控件

• 预览

• 代码

• Blame

325 行 (246 loc) · 21.8 KB

Raw

复制原始文件

下载原始文件

目录

编辑和原始操作

  OBPP-05
  Title: Reusable Payment Codes for Hierarchical Deterministic Wallets, version 3 and 4  // 针对分层确定性钱包的可重用支付码，版本 3 和 4
  Author: Justus Ranvier <justus@openbitcoinprivacyproject.org>
  Status: Final  // 状态：最终
  Created: 2021-02-15

Abstract

Permalink: Abstract

This RFC extends reusable payment codes as defined by BIP-47 by defining version 3 and version 4 payment codes. // 本 RFC 通过定义版本 3 和版本 4 支付码来扩展 BIP-47 定义的可重用支付码。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. // 本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 必须按照 RFC 2119 中的描述进行解释。

Copyright

Permalink: Copyright

This RFC is in the public domain. // 本 RFC 属于公有领域。

Motivations

Permalink: Motivations

Version 3 payment codes address two shortcomings of previous payment code versions: // 版本 3 支付码解决了以前的支付码版本的两个缺点：

• Key reuse will occur if the same payment code is used to receive transactions on more than one blockchain. // 如果同一个支付码被用于在多个区块链上接收交易，则会发生密钥重用。
• Both version 1 and version 2 notification transactions both require the use of an OP_RETURN output, which limits the number of notifications which can be performed by a standard transaction to one. // 版本 1 和版本 2 的通知交易都需要使用 OP_RETURN 输出，这限制了标准交易可以执行的通知数量为一个。

Specification

Permalink: Specification

Version 3 and 4 payment codes behave identically to version 1 and version 2 payment codes as defined in BIP-47 except where noted below. // 版本 3 和版本 4 的支付码的行为与 BIP-47 中定义的版本 1 和版本 2 的支付码相同，除非下面另有说明。

Path levels

Permalink: Path levels

The recommended BIP-32 path levels for payment code derivation are identical to previous versions except for the coin type. // 除币种类型外，建议的用于支付码派生的 BIP-32 路径级别与以前的版本相同。

Coin type

Permalink: Coin type

Wallets which only support one coin type and use BIP-44 SHOULD set this value per BIP-44. // 仅支持一种币种类型并使用 BIP-44 的钱包应根据 BIP-44 设置此值。

Wallets which support multiple coin types and do not use version 3 or higher payment codes SHOULD create a different payment code for each coin type and set this value per BIP-44. // 支持多种币种类型但不使用版本 3 及更高版本支付码的钱包应为每种币种类型创建一个不同的支付码，并根据 BIP-44 设置此值。

Wallets which support version 3 or higher payment codes should use one payment code per logical user identity regardless of the number of coin types the wallet supports and SHOULD set this value to 0'. // 支持版本 3 或更高版本的支付码的钱包，无论钱包支持的币种类型数量如何，都应为每个逻辑用户身份使用一个支付码，并且应将此值设置为 0'。

Hardened derivation is used at this level. // 在此级别使用强化推导。

Versions

Permalink: Versions

Defined Versions

Permalink: Defined Versions

• Version 1 // 版本 1
  • Address type: P2PKH // 地址类型：P2PKH
  • Notification type: address // 通知类型：地址
• Version 2 // 版本 2
  • Address type: P2PKH // 地址类型：P2PKH
  • Notification type: bloom-multisig // 通知类型：bloom-multisig
• Version 3 and Version 4 // 版本 3 和版本 4
  • Address type: varied, see Payment Output Scripts // 地址类型：不同，请参阅支付输出脚本
  • Notification type: cfilter-multisig // 通知类型：cfilter-multisig

Compatibility Rules

Permalink: Compatibility Rules

1. In any case where a notification or payment is sent between payment codes of different versions, the conventions of the recipient's version SHALL be used. // 在任何情况下，如果通知或支付是在不同版本的支付码之间发送的，则应使用接收者版本的约定。
2. Implementations MUST NOT send notifications or payments to recipient payments codes with a version number for which the conventions are not known. // 实现不得将通知或付款发送给版本号未知的接收者支付码。
3. Implementations which receive notifications from sending payment code with a unknown version SHOULD assume the sender followed the first rule. // 接收来自未知版本的发送支付码的通知的实现应假定发送者遵循了第一条规则。

Version 3

Permalink: Version 3

Representation

Permalink: Representation

Binary Serialization

Permalink: Binary Serialization

• Byte 0: version. required value: 0x03 // 字节 0：版本。必需值：0x03
• Bytes 1 - 33: compressed public key // 字节 1 - 33：压缩公钥
  • Byte 0: sign. required value: 0x02 or 0x03 // 字节 0：符号。必需值：0x02 或 0x03
  • Bytes 1 - 31: x value, must be a member of the secp256k1 group // 字节 1 - 31：x 值，必须是 secp256k1 组的成员

The feature bits and chain code fields which were defined in earlier versions are no longer present in version 3 or higher. // 在早期版本中定义的特征位和链码字段不再出现在版本 3 或更高版本中。

If a version 3 code must be serialized in 80 byte form, for example in order to send a notification transaction to a recipient of a lower version, use the serialization method from version 1. The chain code is the derived value defined below and the feature byte and other fields are all zero filled. // 如果必须以 80 字节的形式序列化版本 3 代码，例如为了将通知事务发送给较低版本的接收者，请使用版本 1 中的序列化方法。链码是下面定义的派生值，并且特征字节和其他字段都填充为零。

Base58 Serialization

Permalink: Base58 Serialization

When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form. // 当向用户展示支付码时，应该以 Base58Check 编码的形式展示。

• The version byte is: 0x22 (produces a "P" as the first character of the serialized form) // 版本字节是：0x22（产生一个 "P" 作为序列化形式的第一个字符）
• The payload is the binary serialization of the payment code // 有效负载是支付码的二进制序列化

Protocol

Permalink: Protocol

Definitions

Permalink: Definitions

• Chain code: Whenever BIP-32 calculations or other procedures require a chain code that corresponds to the public key the required value SHALL be calculated as c = SHA256(SHA256(p)) where p is the compressed public key. // 链码：每当 BIP-32 计算或其他程序需要与公钥对应的链码时，所需的值应计算为 c = SHA256(SHA256(p))，其中 p 是压缩公钥。
• Payment code identifier: The script element used by senders to construct notification scripts and by recipient to locate their notifications SHALL consist of the first 32 bytes of c = HMAC-SHA512(c, v) where c is the chain code and v is the one byte version of the sender's payment code. // 支付码标识符：发送者用于构建通知脚本，接收者用于定位其通知的脚本元素应由 c = HMAC-SHA512(c, v) 的前 32 个字节组成，其中 c 是链码，v 是发送者支付码的单字节版本。
• Notification address: The 0th non-hardened key pair derived from the BIP32 extended private key created using the BIP47 account private bytes and the chain code as described above. // 通知地址：使用 BIP47 帐户私有字节和如上所述的链码创建的，从 BIP32 扩展私钥派生的第 0 个非强化密钥对。

Notification Output

Permalink: Notification Output

Note: this procedure is used if Bob uses a version 3 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 3, see the appropriate section of BIP-47. // 注意：如果 Bob 使用版本 3 支付码（无论 Alice 的支付码版本如何），则使用此过程。如果 Bob 的支付码不是版本 3，请参阅 BIP-47 的相应部分。

Note: this procedure may be used to send notifications from senders using older version payment codes to send notifications to version 3 or version 4 recipients with slight modifications noted below. // 注意：此过程可用于从使用旧版本支付码的发送者发送通知到版本 3 或版本 4 接收者，但需进行以下细微修改。

Version 3 notifications are self-contained to a single transaction output, therefore MAY be included as part of any transaction, whether related to the recipient of the notification or not. // 版本 3 通知包含在单个交易输出中，因此可以作为任何交易的一部分包含在内，无论是否与通知的接收者相关。

1. Alice selects the private and associated public key designated for change output creation: a, A = aG // Alice 选择用于更改输出创建的私钥和关联公钥：a, A = aG
2. Alice derives a unique shared secret using ECDH: // Alice 使用 ECDH 派生唯一的共享密钥：
3. Alice selects the public key associated with Bob's notification address: B, where B = bG // Alice 选择与 Bob 的通知地址关联的公钥：B, where B = bG
4. Alice calculates a secret point: S = aB // Alice 计算一个秘密点：S = aB
5. Alice calculates a 64 byte blinding factor: s = HMAC-SHA512(Sx, A) where Sx is the x value of the secret point // Alice 计算一个 64 字节的致盲因子：s = HMAC-SHA512(Sx, A)，其中 Sx 是秘密点的 x 值
6. Alice serializes her payment code in binary form. // Alice 以二进制形式序列化她的支付码。
7. Alice generates renders her payment code P unreadable to anyone except Bob: P' // Alice 生成的支付码 P 除了 Bob 之外的任何人都无法读取：P'
8. Replace the x value with x': x' = x XOR (first 32 bytes of s) // 将 x 值替换为 x'：x' = x XOR (s 的前 32 个字节)
9. Alice composes a notification output and adds it to an outgoing transaction // Alice 组成一个通知输出并将其添加到传出事务
10. The notification output consists of a 1 of 3 bare multisig script. // 通知输出由 1 of 3 的裸多重签名脚本组成。
11. The first key is A and MUST be in compressed form // 第一个密钥是 A，并且必须是压缩形式
12. The second key is the Bob's payment code identifier formatted as a compressed public key F // 第二个密钥是 Bob 的支付码标识符，格式化为压缩公钥 F
    1. Byte 0: either 0x02 or 0x03 // 字节 0：0x02 或 0x03
    2. Byte 1-32: the value of Bob's payment code identifier which corresponds to the version of Alice's payment code // 字节 1-32：Bob 的支付码标识符的值，该值对应于 Alice 的支付码版本
13. The last key is Alice's blinded payment code G // 最后一个密钥是 Alice 的致盲支付码 G
    1. Byte 1-33: P' // 字节 1-33：P'
14. Script opcodes: OP_1 A F G OP_3 OP_CHECKMULTISIG // 脚本操作码：OP_1 A F G OP_3 OP_CHECKMULTISIG

The relative ordering of the keys in the notification output script MUST be maintained as A F G. // 通知输出脚本中密钥的相对顺序必须保持为 A F G。

1. Bob watches for any transactions which contain notification output which reference his payment code identifiers. // Bob 监视任何包含引用其支付码标识符的通知输出的交易。
2. Bob MUST watch for incoming notifications for his payment code version and SHOULD watch for notifications for all earlier versions // Bob 必须监视其支付码版本的传入通知，并且应该监视所有早期版本的通知
3. The recommended method for detecting incoming notification transactions is to use BIP-157 client-side filtering with OBPP-4 Enhanced Selectivity (ES) filters. // 检测传入通知事务的推荐方法是使用带有 OBPP-4 增强选择性 (ES) 过滤器的 BIP-157 客户端过滤。
   1. ES filters are capable of sub-element matching of uncompressed public keys // ES 过滤器能够对未压缩的公钥进行子元素匹配
   2. Bob detects notification transactions by adding his payment code identifiers to the set of elements to be matched. // Bob 通过将他的支付码标识符添加到要匹配的元素集中来检测通知事务。
4. When a transaction matching the payment code identifier is located, Bob's client examines it to determine if it contains a valid notification // 当找到与支付码标识符匹配的交易时，Bob 的客户端会检查它以确定它是否包含有效的通知
5. A is the first key and must be 33 bytes // A 是第一个密钥，必须是 33 字节
6. F is the second key may be 33 bytes or 65 bytes, but in either case bytes 1-32 must match one of Bob's payment code identifiers // F 是第二个密钥，可以是 33 字节或 65 字节，但在任何一种情况下，字节 1-32 必须与 Bob 的支付码标识符之一匹配
7. G is the last key and may be 33 bytes or 65 bytes // G 是最后一个密钥，可以是 33 字节或 65 字节
8. Bob determines the version of Alice's payment code based on which of Bob's payment code identifiers was used to form the notification transaction. // Bob 根据用于形成通知交易的 Bob 的哪个支付码标识符来确定 Alice 的支付码版本。
9. If all keys in the script are compressed (33 bytes), then the incoming payment code to be unblinded is 34 bytes long. If F and G are 65 bytes then the incoming payment code to be unblinded is 80 bytes long. // 如果脚本中的所有密钥都被压缩（33 字节），则要解盲的传入支付码的长度为 34 字节。如果 F 和 G 是 65 字节，则要解盲的传入支付码的长度为 80 字节。
10. Bob unblinds Alice's payment code // Bob 解盲 Alice 的支付码
11. Bob selects the private key associated with his notification address: b // Bob 选择与其通知地址关联的私钥：b
12. Bob calculates a secret point: S = bA // Bob 计算一个秘密点：S = bA
13. Bob calculates a 64 byte blinding factor: s = HMAC-SHA512(Sx, A) where Sx is the x value of the secret point // Bob 计算一个 64 字节的致盲因子：s = HMAC-SHA512(Sx, A)，其中 Sx 是秘密点的 x 值
14. Bob unblinds P' to recover P // Bob 解盲 P' 以恢复 P
    1. Replace the x value of P' with x': x' = x XOR (first 32 bytes of s) where x is the x of Alice's payment code // 将 P' 的 x 值替换为 x'：x' = x XOR (s 的前 32 个字节)，其中 x 是 Alice 的支付码的 x 值
15. If the updated x value is a member of the secp256k1 group, the payment code is valid. // 如果更新后的 x 值是 secp256k1 组的成员，则支付码有效。
16. If the updated x value is not a member of the secp256k1 group, the payment code is ignored. // 如果更新后的 x 值不是 secp256k1 组的成员，则忽略该支付码。

Alice's wallet should spend the notification change output at the next appropriate opportunity. // Alice 的钱包应该在下一个适当的时机花费通知变更输出。

Wallets SHOULD prefer to create of notification outputs in any situation where a change output is required, if the wallet knows of the existence of any payment codes but has not yet sent a notification. The practice of preemptive notification makes assumptions about the relationship between a notification output and the transaction in which it is contained invalid, therefore wallets which practice preemptive notification MAY include the notification output with the first payment to a new transaction recipient. // 如果钱包知道任何支付码的存在但尚未发送通知，则在任何需要更改输出的情况下，钱包应首选创建通知输出。抢先通知的做法使通知输出与包含它的交易之间的关系无效，因此实行抢先通知的钱包可以将通知输出与首次付款一起发送给新的交易接收者。

Earlier Version Senders

Permalink: Earlier Version Senders

Modify the above procedure as follows if the payment code to be conveyed is 80 bytes instead of 34 bytes: // 如果要传递的支付码是 80 字节而不是 34 字节，请按如下方式修改上述过程：

1. Alice generates renders her payment code P unreadable to anyone except Bob: P' // Alice 生成的支付码 P 除了 Bob 之外的任何人都无法读取：P'
2. Replace the x value with x': x' = x XOR (first 32 bytes of s) // 将 x 值替换为 x'：x' = x XOR (s 的前 32 个字节)
3. Replace the chain code with c': c' = c XOR (last 32 bytes of s) // 将链码替换为 c'：c' = c XOR (s 的后 32 个字节)
4. F is formatted as an uncompressed public key // F 格式化为未压缩的公钥
   1. Byte 0: 0x04 // 字节 0：0x04
   2. Byte 1-32: the value of Bob's payment code identifier which corresponds to the version of Alice's payment code // 字节 1-32：Bob 的支付码标识符的值，该值对应于 Alice 的支付码版本
   3. Byte 33-64: bytes 0 through 31 of P' // 字节 33-64：P' 的字节 0 到 31
5. G is formatted as an uncompressed public key // G 格式化为未压缩的公钥
   1. Byte 0: 0x04 // 字节 0：0x04
   2. Byte 1-48: bytes 32 through 79 of P' // 字节 1-48：P' 的字节 32 到 79
   3. Byte 49-64: arbitrary, MAY be set to any value // 字节 49-64：任意，可以设置为任何值

Bob recognizes when an incoming notification was sent by an earlier version user with an 80 byte payment code by noting the size of F and G are both 65 bytes. // 当 Bob 注意到 F 和 G 的大小都是 65 字节时，他可以识别出传入的通知是由具有 80 字节支付码的早期版本用户发送的。

1. Bob recomposes P' by concatenating bytes 33-64 of F and bytes 1-48 of G // Bob 通过连接 F 的字节 33-64 和 G 的字节 1-48 来重组 P'
2. Bob unblinds P' to recover P // Bob 解盲 P' 以恢复 P
3. Replace the x value of P' with x': x' = x XOR (first 32 bytes of s) // 将 P' 的 x 值替换为 x'：x' = x XOR (s 的前 32 个字节)
4. Replace the chain code of P' with c': c' = c XOR (last 32 bytes of s) // 将 P' 的链码替换为 c'：c' = c XOR (s 的后 32 个字节)

Sending

Permalink: Sending

1. Prior to this procedure, Alice MUST ensure that Bob is capable of accepting payments on the blockchain to be used via a suitable method. Such methods are outside the scope of this specification. // 在此过程之前，Alice 必须确保 Bob 能够通过合适的方法在要使用的区块链上接受付款。这些方法不在此规范的范围之内。
2. Each time Alice wants to initiate a transaction to Bob, Alice derives a unique public key for the transaction using ECDH as follows: // 每次 Alice 想要发起与 Bob 的交易时，Alice 都会使用 ECDH 为该交易派生一个唯一的公钥，如下所示：
3. Alice selects the 0th private key derived from her payment code: a // Alice 选择从她的支付码派生的第 0 个私钥：a
4. Alice selects the next unused public key derived from Bob's payment code, starting from zero: B, where B = bG // Alice 选择从 Bob 的支付码派生的下一个未使用的公钥，从零开始：B, where B = bG
   1. The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob // “下一个未使用的”公钥基于特定于 Alice-Bob 上下文的索引，而不是 Alice 或 Bob 的全局索引
5. Alice selects the 4 byte registered coin type for the transaction based on SLIP-0044, formatted as a 4 byte big endian integer. The unhardened value is used: t // Alice 根据 SLIP-0044 为交易选择 4 字节的注册币种类型，格式化为 4 字节的大端整数。使用未强化的值：t
6. Alice calculates a secret point: S = aB // Alice 计算一个秘密点：S = aB
7. Alice calculates a scalar shared secret using the x value of S: s = SHA256(HMAC-SHA512(Sx, t)) // Alice 使用 S 的 x 值计算一个标量共享密钥：s = SHA256(HMAC-SHA512(Sx, t))
   1. If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again. // 如果 s 的值不在 secp256k1 组中，Alice 必须增加用于派生 Bob 的公钥的索引并重试。
8. Alice uses the scalar shared secret to calculate the ephemeral public key used to generate the payment output script for this transaction: B' = B + sG // Alice 使用标量共享密钥来计算用于为此交易生成支付输出脚本的临时公钥：B' = B + sG
9. Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice. // 自从收到 Alice 的通知交易以来，Bob 一直在监视 B' 上的传入付款。
10. Bob calculates n shared secrets with Alice, using the 0th public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. // Bob 与 Alice 计算 n 个共享密钥，使用从 Alice 的支付码派生的第 0 个公钥，以及从 Bob 的支付码派生的私钥 0 - n，其中 n 是他期望的预读窗口。
11. Bob calculates the ephemeral deposit addresses using the same procedure as Alice: B' = B + sG // Bob 使用与 Alice 相同的过程计算临时存款地址：B' = B + sG
12. Bob calculate the private key for each ephemeral address as: b' = b + s // Bob 将每个临时地址的私钥计算为：b' = b + s

Payment Output Scripts

Permalink: Payment Output Scripts

The pubkeys derived by the above procedure MAY be used to generate any of the following output script types. Receiving wallets SHOULD monitor for all applicable types: // 通过上述程序派生的公钥可用于生成以下任何一种输出脚本类型。接收钱包应该监视所有适用的类型：

• Version 3 // 版本 3
  • Pay to pubkey (P2PK), preferred // 支付给公钥 (P2PK)，首选
  • Pay to witness pubkey hash (P2WPKH), chains with segwit support only // 支付给见证公钥哈希 (P2WPKH)，仅限支持 segwit 的链
  • Pay- Alice
  • Bip 39 单词: response seminar brave tip suit recall often sound stick owner lottery motion
  • 序列化支付码 (Base58): PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA
  • 支付脚本的公钥
  • 0: 0275fd0d1519ac24f4944a843c6475cda578d6286ee846ece105d5b0c69a1b9b3e
  • 1: 035e6e2c1701229a7a4cddcfa83f42f06cafeba42a63dfb3287c35ffb8d1c6f872
  • 2: 039f32033263f0fac7636fc3f2ffc68d4701dcb81641ed6c0f8d76b4fc7f2b5a3a
  • 3: 02aa38313e99a2e7d8f22a7efa6b1c4b1f2769e4b91622bd4e6d919ffd2a41f388
  • 4: 02ed75fc071317eae5d046389d54614dfb787856739f812e8de0f12f30d4d6bcee
  • 5: 03d6cfc06f11b706a0f34de2486246c4495ce90ee02553d3239b5a235d19153ba3
  • 6: 034b87613a9a6230ad831839e5da55d29970154d6b91bd3e42aeeb70b234b1b9ff
  • 7: 02f014490536f79c0c8c1b2cee39428a1446a74ec1af19ce515da6e3fb29db0cfa
  • 8: 03f96d069cffd4a0bb9430f6cda1376cee63825ec1619b5cc22077122c36b200c9
  • 9: 03406c84ad2c5549af30e0c8886922eb51db925e35b7ed058d52f2458f1ce5d8ca
  • 用于通知脚本的私钥: (m/44'/0'/0'/1/0) 872313fe1beb41a9e1ae19c0def97591e5c204387b64b85f4077078b232906d0
  • 盲化的支付码: 01000292d97c287932848852890ded442311623e32ebfeba12e2020b41c2fbe12f38127e36136254548e0a4dfc14232b6de263a69a1955629b75137d2beeccb639b2d300000000000000000000000000
  • 用于通知 Bob 的 A 的值: 0383b5e54776628baacee0cbb66b4db31aa95176dba1f62cabf0415103d0fdbda6
  • 用于通知 Bob 的 F 的值: 044e299b083f610d5ab6e7e241089f185cf222deb9a790eacf01a72930c90d226101000292d97c287932848852890ded442311623e32ebfeba12e2020b41c2fbe1
  • 用于通知 Bob 的 G 的值: 042f38127e36136254548e0a4dfc14232b6de263a69a1955629b75137d2beeccb639b2d300000000000000000000000000XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  • 最后 16 个字节可以是任意值
• Bob
  • Bip 39 单词: reward upper indicate eight swift arch injury crystal super wrestle already dentist
  • 序列化支付码 (Base58): PD1jFsimY3DQUe7qGtx3z8BohTaT6r4kwJMCYXwp7uY8z6BSaFrpM
  • 支付码标识符
  • 版本 1: 4e299b083f610d5ab6e7e241089f185cf222deb9a790eacf01a72930c90d2261
  • 版本 2: a6806034129abafba1511019991cca9bd8bededb1580bdc4fe0eb905dec8da2d
  • 版本 3: ce75616fcd80345bca54dabd279b155f960c57260378455b872269221de231b6
  • 支付脚本的公钥
  • 0: 03bebccead98ce8d1ba065b814ce565ea8a79979a572c901188d5c274af1c82d9b
  • 1: 02f0e0a7998e55c559fa57292a101cf5ab6e6cbe86bfdcf222e26d63c7773bbcf0
  • 2: 038a2b1c008a9e048b2bb93d4eac24357012d5bd0fe84e772af646bad482f0528b
  • 3: 0343cd902a36f5a4dda6bb11489f7bb4ebe381586e07fafc9e5039abb14c314972
  • 4: 02b90e340e73eb2bc1addaf51e2229ec1d2aae78569879d022d208964fa741b6e1
  • 5: 03f1ff5daadfb93ca15dfe4fe96ee77fa6465bcf0b98ab6b599e8b7a8e962ed38d
  • 6: 02d7f5628abf1b64f7f4f1eea11a510740d1110a8f937821870eb5f47155b09c70
  • 7: 02bd05db146de0273e704ecf162bef5de21032fc9b646237038d9f00004436172c
  • 8: 020f0b8c3bf9a97566fae19b30b93b6a19b26905bcf6742260699a1cba39ff639d
  • 9: 03ac995a811b20e68541ab1840671c84cc2765ed9625a53daf57c9f07ecfabfb42
  • 用于盲化的私钥: (m/44'/0'/0'/1/0) 0fb05a28df58b2add0d01eb491962b79092239e4d9396442eed83144b6541f4c
  • 对应的公钥: 0389087b9573ccc7efc5252a8a7c93d349d9b3dd882724c818e5369cbff0647d35
  • 用于盲化的 Outpoint: 86f411ab1c8e70ae8a0795ab7a6757aea6e4d5ae1826fc7b8f00c597d500609c01000000
  • 盲化的支付码: 030002b07dccadbf4289635ecf85eb12e1a0d7a7c93bcb905d5a5b2e75e9248fe4c92c113ccdbd406889022aa8a3d40d329553586d73914877626479f26b08ef7d3de000000000000000000000000000

参考实现

永久链接: 参考实现

Open-Transactions

参考

永久链接: 参考

• OBPP-04: 增强选择性的紧凑区块过滤器
• BIP-0047: 分层确定性钱包的可复用支付码
• BIP-0147: 版本 0 Witness 程序 的交易签名验证
• BIP-0157: 客户端区块过滤
• SLIP-0044: BIP-0044 的注册币种类型

• 原文链接： github.com/OpenBitcoinPr...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～