导航：首页 > 互联网科技 >

比特币钱包隔离认证开发知识点有哪些

发表于：2024-11-26 作者：千家信息网编辑

千家信息网最后更新 2024年11月26日，这篇文章主要介绍"比特币钱包隔离认证开发知识点有哪些"，在日常操作中，相信很多人在比特币钱包隔离认证开发知识点有哪些问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"比特币

千家信息网最后更新 2024年11月26日比特币钱包隔离认证开发知识点有哪些

这篇文章主要介绍"比特币钱包隔离认证开发知识点有哪些"，在日常操作中，相信很多人在比特币钱包隔离认证开发知识点有哪些问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"比特币钱包隔离认证开发知识点有哪些"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

基本的隔离认证支持

钱包必须实现本节中的所有功能，以便在基本级别被视为segwit兼容：

发送到P2SH

兼容segwit的钱包必须支持pay-to-script-hash（BIP16）及其地址格式（BIP13）。
对于付款，钱包必须能够正确地将给定的P2SH地址转换为scriptPubKey，并创建一个交易。
为了接收付款，钱包必须能够基于P2WPKH脚本（在下文中定义）创建P2SH地址，并且能够识别对这些地址的支付。
这是强制性要求，即使钱包仅接受单签名付款。

创建P2SH-P2WPKH地址

P2SH-P2WPKH地址与比特币的原始单签名P2PKH地址（前缀为1的地址）相当。
与任何其他P2SH地址一样，P2SH-P2WPKH地址的前缀为3。
在使用P2SH-P2WPKH UTXO并暴露redeemScript之前，P2SH-P2WPKH地址与非segwit P2SH地址无法区分（例如非segwit多签名地址）。
当只有1个公钥用于接收付款时（如P2PKH），应使用P2SH-P2WPKH地址。
P2SH-P2WPKH使用与P2PKH相同的公钥格式，但有一个非常重要的例外：P2SH-P2WPKH中使用的公钥必须被压缩，即大小为33字节，并以0x02或0x03开头。使用任何其他格式（如未压缩的公钥）可能会导致不可撤销的资金损失。
创建P2SH-P2WPKH地址：
1.计算公钥（keyhash）的SHA256的RIPEMD160。尽管keyhash公式与P2PKH相同，但应避免重用keyhash以获得更好的隐私并防止意外使用未压缩密钥。
2.P2SH redeemScript始终为22个字节。它以OP_0开头，然后是keyhash的规范推送（如0x0014{20-byte keyhash}）。
3.与其他P2SH相同，scriptPubKey是OP_HASH160 hash260（redeemScript）OP_EQUAL，地址是对应的P2SH地址，前缀为3。

交易序列化

兼容segwit的钱包必须支持原始的交易格式，如nVersion|txins|txouts|nLockTime。
兼容segwit的钱包也必须支持新的序列化格式，如nVersion|marker|flag|txins|txouts|witness|nLockTime。
nVersion，txins，txouts和nLockTime的格式与原始格式相同。
marker必须是0x00。
flag必须是0x01。
witness是交易的所有见证数据的序列化。
每个txin都与见证字段相关联。作为结果，没有表示显示证据字段的数量，因为它是由txins的数量默认的。
每个见证字段以compactSize integer开始，以指示相应txin的堆栈项目数。然后是相应txin的见证堆栈项目数（如果有的话）。
每个见证堆栈项都以compactSize integer开头，以指示该项的字节数。
如果txin未与任何见证数据相关联，则其对应的见证字段精确为0x00，表示见证堆栈项的数量为零。
如果交易中的所有txins都没有与任何见证数据相关联，则交易必须以原始交易格式序列化，不包括marker, flag, witness。例如，如果没有txins来自segwit UTXO，它必须以原始交易格式序列化。（coinbase交易例外）
可以在BIP143的示例部分找到交易序列化的示例。钱包开发人员可以使用这些示例来测试他们的实现是否正确解析了新的序列化格式。

交易ID

在segwit下，每个交易将有2个ID。
txid的定义保持不变：原始序列化格式的double SHA256。
定义了一个新的wtxid，它是具有见证数据的新序列化格式的double SHA256。
如果交易没有任何见证数据，则其wtxid与txid相同。
txid仍然是交易的主要标识符：
当引用先前的输出时，它必须在txin中使用。
如果钱包或服务当前正在使用txid来识别交易，则预示着它将继续使用segwit。

P2SH-P2WPKH的签名生成和验证

对于非segwit UTXO的消费，签名生成算法不变。
对于P2SH-P2WPKH的消费： -scriptSig必须只包含一个redeemScript。
相应的见证字段必须包含2个项目，签名后跟公钥。
BIP143（见文末）中描述了一种用于segwit脚本的新签名生成算法。开发人员应仔细遵循说明，并使用BIP143中的P2SH-P2WPKH示例，以确保它们能够重现sighash。
BIP143签名生成算法涵盖了所花费的输入值，简化了air-gapped轻量钱包和硬件钱包的设计。
请注意，对于P2SH-P2WPKH，scriptCode总是26个字节，包括前导大小字节，如0x1976a914{20-byte keyhash}88ac，不是redeemScript，也不是scriptPubKey。
示例。

网络服务（可选）

如果钱包通过对等网络发送和接收交易，则需要网络服务。
支持Segwit的节点将表示他们可以通过服务位提供见证：NODE_WITNESS=(1<<3)。
没有任何见证数据的交易（因此以原始格式序列化）可以发送到有或没有NODE_WITNESS支持的节点。
花费segwit UTXO（因此以新格式序列化）的交易必须仅发送到具有NODE_WITNESS支持的节点。
花费segwit UTXO但剥离见证数据（因此以原始格式序列化）的交易可以发送到没有NODE_WITNESS支持的节点。但是，这些交易在激活segwit后无效，并且在块中不会被接受。
有关网络服务的详细信息，请参阅BIP144（见文末）。

用户隐私

在segwit交易很普遍之前，这种交易类型可以使比特币跟踪更容易。
使用P2SH-P2WPKH作为默认变化时的输出也可能会对隐私产生影响。

交易费用估算

替代交易大小，定义了一个新的度量，称为"virtual size"（vsize）。
交易的vsize等于原始序列化大小的3倍，加上新格式序列化的大小，将结果除以4并向上舍入到下一个整数。例如，如果一个交易是200字节的新格式序列化，并且变为99字节，删除了marker,flag,witness，则vsize为(99*3+200)/4=125并向上舍入。
非segwit交易的vsize只是它本身的大小。
交易费应通过比较vsize与其他交易而不是大小来估算。
开发人员应注意不要在费用估算中犯off-by-4-times错误。

激活

从块高度481824开始，所有SegWit就绪节点都开始执行新的SegWit共识规则。

向后兼容性

应继续支持发送和接收传统的P2PKH支付（前缀为1的地址）。

复杂的脚本支持

如果钱包支持除单一签名之外的脚本类型，例如多重签名，则必须满足以下基本要求：

####　创建P2SH-P2WSH地址

P2SH-P2WSH地址与比特币的原始P2SH地址相当，后者允许表示具有固定大小地址的任意复杂脚本。
与任何其他P2SH和P2SH-P2WPKH地址一样，P2SH-P2WSH地址具有前缀3.在UTXO用完之前，它们无法区分。
要创建P2SH-P2WSH地址：
1.定义一个名为witnessScript的脚本。
2.计算witnessScript（scripthash）的SHA256。请注意使用单个SHA256，而不是双SHA256和RIPEMD160（SHA256）。
3.P2SH redeemScript总是34个字节。它以OP_0开头，然后是scripthash的规范推送（即0x0020{32-byte scripthash}）。
4.与任何其他P2SH相同，scriptPubKey是OP_HASH160 hash260(redeemScript) OP_EQUAL，地址是对应的P2SH地址，前缀为3。

对脚本的限制

脚本评测不能失败，并且必须在评测后留下一个且只有一个TRUE堆栈项。否则，评估失败。
P2SH-P2WSH脚本中的任何公钥必须是压缩密钥，否则资金可能永久丢失。
如果使用OP_IF或OP_NOTIF，则其参数必须是空向量（对于false）或0x01（对于true）。使用其他值可能导致永久性资金损失。（BIP草案）。
如果OP_CHECKSIG或OP_CHECKMULTISIG返回失败，则所有签名必须为空向量。否则，资金可能会永久丢失。（BIP146）。
witnessScript的默认策略限制为3600字节。除了witnessScript，最多可以有100个见证堆栈项，每个最多80个字节。超出这些限制的交易不得转发或包含在一个区块中。
许多原始脚本的共识限制，例如10000字节脚本大小，201 nOpCount，仍然适用于P2SH-P2WSH。
P2SH的520字节脚本大小限制不适用于P2SH-P2WSH。它被3600字节的策略限制和10000字节的共识限制所取代。

P2SH-P2WSH的签名生成和验证

对于P2SH-P2WSH的消费：
scriptSig必须只包含一个redeemScript。
相应见证字段的最后一个见证项必须是witnessScript。
新的BIP143签名生成算法适用于：
在不使用任何OP_CODESEPARATOR的情况下，scriptCode是witnessScript，前面是一个compactSize integer，用于witnessScript的大小。例如，如果脚本是OP_1（0x51），则序列化的scriptCode是（0x0151）。
对于包含OP_CODESEPARATOR的任何异常脚本，请参阅BIP143以获取确切的语义。
在witnessScript之前的任何见证堆栈项目都用作脚本评测的输入堆栈。输入堆栈不会被解释为脚本。例如，不需要使用0x4c(OP_PUSHDATA1)来"push"大项。
要验证签名生成和堆栈序列化的正确性，请始终根据BIP143中的示例进行测试。
示例。

Segwit本机地址（可选）

初始segwit支持不需要以下功能。

本地Pay-to-Witness-Public-Key-Hash（P2WPKH）

Native P2WPKH是一个22字节的scriptPubKey。它以OP_0开头，然后是keyhash的规范推送（即0x0014{20-byte keyhash}）。
与P2SH-P2WPKH相同，keyhash是压缩公钥的RIPEMD160（SHA256）。
当使用原生P2WPKH时，scriptSig必须为空，见证堆栈格式和签名生成规则与P2SH-P2WPKH相同（包括使用压缩公钥的要求）。
示例。

本地Pay-to-Witness-Script-Hash（P2WSH）

原生P2WSH是一个34字节的scriptPubKey。它以OP_0开头，然后是scripthash的规范推送（即0x0020{32-byte scripthash}）。
与P2SH-P2WSH相同，scripthash是witnessScript的SHA256。
当使用原生P2WSH时，scriptSig必须为空，见证堆栈格式和签名生成规则与P2SH-P2WSH相同（包括使用压缩公钥的要求）。
示例。