赞
踩
提议将使用“76”作为有争议的 BIP 号码。尚未分配实际号码。
该提案通过使用 bip32 键路径的附加约定扩展了 BIP 44 的结构。
通过标准化实现的兼容性允许用户选择比特币钱包软件,并能够将所有功能和收到的硬币一起使用,而无需扫描并向所有贸易伙伴传达新地址。此外,用户还可以根据需要将助记词移植到新的硬件平台。
此外,BIP32和相关标准允许用户仅使用易于记忆的小助记词来控制大量关键材料。简单的钱包密钥只是一种应用程序。
如果标准化,硬件钱包可以扩展以提供这些附加功能。例如,硬件钱包还可以充当具有 PEM 证书质询/响应的身份管理库,或者通过创建 gpg 签名数据包充当安全通信库。
Bip44,专门针对比特币,目前定义了路径:
该提案使用了非常相似的结构,以 76h 作为 patyh 根,0h 表示比特币,后面是账户索引,然后是具体用途扩展。
使用外部或更改密钥通过 QR 码打印 BIP38 样式的现金会使整个帐户面临风险,因为单个私钥可用于计算所有可能的外部和更改私钥。使用随机生成的私钥需要单独的备份方法,否则存在因纸币被破坏或丢失而导致资金损失的风险。使用 bip39 助记符清除或找回丢失的纸币的能力提高了实用性。在高清钱包内使用硬化路径可以限制现金印刷和交易造成的风险。现金路径约定允许钱包软件跟踪属于钱包的未使用现金。
许多钱包支持跟踪支付目的地的地址簿。通常这些是单个地址,这鼓励了地址重用的不良做法。作为替代方案,xpub 可以为多次付款提供有意义的地址簿,因为每次付款都可以包含一个新的、以前从未使用过的目标地址。为了防止无意中的地址重用,理想情况下,支付簿应该代表一个单一 HD 钱包到另一个单一 HD 钱包的关系,在某些情况下出于单一目的。不应与多个不同的其他用户共享同一地址簿。
为了创建“支付簿”以提供给其他用户,并帮助防止支付簿的重复使用,钱包可以具有用于此类生成的约定路径。钱包还能够自动检测定义的付款簿上收到的付款。
野外存在多种隐形币系统,它们通常需要发布比特币公钥。具有生成此类隐形币根约定的钱包将允许自动包含收到的隐形币。
虽然比特币钱包可以通过助记词恢复,但 GPG 私钥不提供此类功能。大多数比特币钱包都提供消息签名,但很少有提供与 gpg 相当的消息加密。从 gnuPG 版本 2.1 开始,可以使用比特币曲线 secp256k1 创建 GPG 私钥。
GPG 密钥编码通常需要熵,并且时间值大概是从当前时间开始设置的。如果从钱包重新生成 GPG,这将使签名无效,可能会更改密钥 ID,并以其他方式导致正常 GPG 使用出现问题。该提案将描述完全确定性的 GPG 密钥创建约定,使得 GPG 密钥可以仅从助记符多次完全恢复,同时输出逐位相同的输出,这将允许任何外部密钥 ID 和签名保持有效。
一般来说,每个提案都通过在外部/更改位置使用强化的派生密钥(而不是 0 或 1)来扩展给定帐户的 bip44 路径。
钱包为帐户acct创建的每张现金票据都会有一个序号ord,从 0 开始
钱包将使用以下路径创建它们:76H/0H/ acct H/2H/ ord H
钱包应该跟踪以定义的现金密钥序号到达的任何硬币。
钱包为帐户acct创建的每个付款簿都会有一个序号ord,从 0 开始。钱包应允许用户指定付款簿的配方和用途。钱包还应该跟踪支付簿地址收到的任何付款。
钱包将使用以下路径创建它们:76H/0H/ acct H/3H/ ord H
钱包为账户acct创建的每个 Stealthcoin 根都会有一个序数ord,从 0 开始。钱包还应该使用 Stealth 方案的常用机制跟踪收到到 Stealth Root 的任何付款
钱包将使用以下路径创建它们:76H/0H/ acct H/4H/ ord H
GPG 密钥根据 RFC 4880 和 6637 以数据包的形式构建。当前时间将被忽略,所有时间值将设置为 0x495C0780 又名 1230768000,代表 UTC 2009 年 1 月 1 日。为了替换 ECDSA 签名中的熵,将使用 RFC6979 确定性签名。对于密钥的公共部分,除了来自 HD 钱包本身的熵外,不使用任何外部熵。当导出受 s2k 保护的私钥时,可以使用外部熵,因为密钥的 s2k 部分不需要保持不变 - 因为它不会影响密钥 ID,密钥的签名也不依赖于受 s2k 保护的秘密部分。签名必须使用尽可能小的 S 值,该值应始终小于曲线阶数的一半。
仅导出公钥时,按顺序输出的前七个数据包将是:
导出密钥时,按顺序输出的前七个数据包将是:
所有密钥和子密钥数据包将使用由以下 BIP32 路径确定的密钥值。 (链码信息未编码到GPGP数据包中)
对于给定的 HD 钱包帐户acct,将存在一个唯一的验证密钥,该密钥不会被分类为创建签名,也不会被分类为加密目的地。
帐户acct的验证密钥将位于此路径:76H/0H/ acct H/6H
每个认证密钥将具有至少一个加密目标子密钥,用于 ECDH 加密和解密。
第一个加密子密钥将位于帐户acct的以下路径:76H/0H/ acct H/6H/0H
可以在 0H 之后的任何均匀强化索引处创建多个加密子密钥
每个验证密钥将至少有一个签名子密钥,用于 ECDSA 签名。
第一个签名子密钥将位于帐户acct的以下路径:76H/0H/ acct H/6H/1H
可以在 1H 后的任何奇数强化索引处创建多个签名子密钥。
当导出代表 GPG 公钥或密钥数据包的一系列 GPG 数据包时,将使用以下选项。
当然,必须使用公钥算法18和19,使用secp256k1曲线,编码OID为0x052b8104000a。根据需要,所有公钥都将被解压缩。仅在导出 ECDH 密钥时,使用的密钥标志将为 0x03010807,表示使用 AES 128 的 sha256 用于 gpg KDF 和密钥包装。
用户 ID 数据包将使用证书密钥的前 5 个单词或 bip39 助记符编码的原始 hash160 压缩地址。 AKA bip39mnemencode( RIPEMD( SHA256( 压缩公钥-of(76H/0H/ acct H/6H)) ) ).truncate(前 5)
所有密钥数据包都应使用 s2k。可以使用任何 s2k 方法。建议使用方法 3“迭代和加盐 S2K”。
所有签名数据包都将使用 RFC 6979 确定性签名。证书密钥签名数据包 (tag2) 的类型为 0x13“用户 ID 和公钥数据包的肯定认证”。公共算法当然是 0x13 ECDSA 类型。哈希算法必须是 0x08 SHA256 类型。散列子数据包将是:
未散列的 pubpackets 将是:
Sukey 签名数据包(也是标签 2)的类型为 0x18“子密钥绑定签名”。哈希算法也将是 0x08 SHA256。散列子数据包将是:
未散列的子数据包将是:
在子签名密钥包的情况下,另外
- -----BEGIN PGP PUBLIC KEY BLOCK-----
-
- mE8ESVwHgBMFK4EEAAoCAwRkZIqXqA5M0+ga0cy7c95jiANy+vuAmeLWNd/VEYUa2zpq7BDBknG8
- JjnIotlm0wSIM5wfmdSfBC5WMSFTwy7FtCNmYWN1bHR5IHN1cHJlbWUgb3RoZXIgcmViZWwgcHJv
- dGVjdIhxBBMTCAAZBQJJXAeAAhsBBAsJCAcFFQgJCgMEFgIDAQAKCRARgR9OITlbN0XMAQDUv6JC
- Yz0Oh37PAXSbpylSrfngs/XBqfo0w7xF5W1vjgD/QKtyqNqFqfqn5WaPdjCDgXzBAWIgk0wPQmjq
- +sWsgwW4UwRJXAeAEgUrgQQACgIDBMUHnrF7IyfX06q2L/nHI6cnTZM9TCTDsgcadYA2jh/HHkBj
- 2aV4+P/gKW+8w01RPLUd1H5P3novV2KrN/16OMMDAQgHiGEEGBMIAAkFAklcB4ACGwwACgkQEYEf
- TiE5WzfIewD9Hf5d95R54obyH+RlfUDyWIwRWdZ9ctumwlIAHXmM6YgA/186ZbEJAZxg9umRsgd0
- nQvv+dwKSIcUtWhytbiW1ykpuE8ESVwHgBMFK4EEAAoCAwTsvqcxGhIBS3KtIpAGYQQsrAaDAmWg
- 86BPN6RrrR+9bVh9sOk5ljugKdyVdpbhYjB+GmQh2Udk35+INJskljtYiMEEGBMIAAkFAklcB4AC
- GwIAagkQEYEfTiE5WzdfIAQZEwgABgUCSVwHgAAKCRDOt/H8tcYNaAnOAP4yLY1/CYI7dfh0cByR
- jD7LO5OlfPiG4lsMDdRjn4t/uwD/Qb4zSV9ocqWfKKZo9u86a1RZu1IiiirEPNBC0w2BpPaJ1QD9
- EM3Yv/Knp3y2p77rUxn0CUWAbNjEs4IVCejOdQIu504A/R53yZdE8DHaQCXZfcXN12vKCbqtP5t2
- UG6btS3AyK+Q
- =hpas
- -----END PGP PUBLIC KEY BLOCK-----
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。