资讯详情

比特币隔离见证(SegWit)实战指南:Dapp-Learning 源码解析与 bitcoinjs-lib 地址交易构建

📅 2026/10/12 3:09:25 | 华诺云谱 👁 阅读
比特币隔离见证(SegWit)实战指南:Dapp-Learning 源码解析与 bitcoinjs-lib 地址交易构建
示例工程区块链【免费下载链接】Dapp-LearningDapp learning project for developers at all stages. Becoming and cultivating sovereign individuals. Nonprofit organization.项目地址https://gitcode.com/gh_mirrors/da/Dapp-Learning点击查看免费下载本文以 Dapp-Learning 仓库 BTC/Basic/SegWit 目录下的技术文档与 example.js、example-extended.js 两份可运行示例为核心系统讲解隔离见证Segregated WitnessSegWit的原理、交易序列化格式、区块权重计算、地址类型与采用数据并给出基于 bitcoinjs-lib 从地址生成、交易构建、txid/wtxid 计算到闪电网络通道资金交易的一整套可复现代码。读者阅读后能够理解 SegWit 为何是比特币扩容与二层网络的地基并具备直接用 JavaScript 构建 SegWit 应用的能力。什么是隔离见证隔离见证Segregated Witness简称 SegWit是比特币协议的一项重大升级于 2017 年 8 月通过软分叉方式激活。这项技术通过将交易的签名数据见证数据witness data与交易数据分离解决了比特币网络中的几个关键问题并为后续的扩展性改进如 Taproot、闪电网络奠定了基础。SegWit 的名称直接反映了其核心概念将交易的“见证”witness即签名数据从交易的主要部分“隔离”segregate出来。这种结构上的变化不仅解决了技术问题还为比特币网络带来了显著的性能和安全性提升。在 Dapp-Learning 的 BTC 知识库总览 中SegWit 被列在“基本功能—支付地址”分类之下P2WPKH、Bech32 编码均为已完成专题是理解后续 TaprootSegWit v1、PSBT、闪电网络等进阶内容的前置基础。隔离见证的工作原理传统交易结构的问题在 SegWit 之前比特币交易将交易数据和签名数据见证数据存储在同一区块内。这种设计存在两个突出问题交易延展性Transaction Malleability交易 IDtxid根据整个交易数据包括签名计算。由于签名数据可以在不改变交易有效性的情况下被第三方修改如改写 DER 编码的冗余字节交易 ID 可能在交易被确认前发生变化这就是“交易延展性”问题。它破坏了“基于未确认交易构建后续交易”的应用场景——引用方拿到的 txid 随时可能失效。区块空间效率低签名数据通常占据交易大小的很大一部分但对于验证交易历史并不总是必需的。在传统交易格式中签名被嵌入每个输入input的scriptSig中白白占用了宝贵的区块空间。SegWit 的解决方案SegWit 通过以下三种方式解决上述问题分离见证数据将签名数据见证数据从交易的主要部分移出存储到交易结构末尾独立的见证数据段中。锁定脚本scriptPubKey不再直接包含签名输入脚本在花费时也可以为空签名统一放到 witness 字段。新的交易 ID 计算方式引入wtxid含见证数据的交易哈希同时保留向后兼容的txid计算方式。SegWit 交易的txid仅基于不含签名数据的内容计算签名无论怎样被篡改都不会改变txid从而消除了交易延展性问题而wtxid仍然覆盖全部交易内容含见证数据用于节点间的完整交易传播与识别。区块权重计算Block Weight引入“区块权重”概念见证字节以更低的权重计入区块大小从而在不修改传统 1MB 区块大小上限的前提下有效增加了每个区块可容纳的交易数量。具体规则详见下文“区块权重计算”一节。SegWit 的主要优势1. 解决交易延展性通过将签名数据从交易 ID 计算中分离出来SegWit 彻底解决了交易延展性问题。这对构建依赖未确认交易的复杂交易链如闪电网络通道的承诺交易、HTLC 退款路径至关重要——链上引用不再可能因签名被改写而失效。Dapp-Learning 的 签名算法模块 对 ECDSA 与 Schnorr 的底层实现做了单独讲解可作为理解签名与 txid 关系的延伸阅读。2. 增加区块容量SegWit 通过引入区块权重概念使每个区块可以容纳更多交易。理论上SegWit 可以将区块有效容量提高到约 2.1MB4MB而不需要增加传统的 1MB 区块大小限制。具体提升幅度取决于区块内见证数据占比见下文“性能数据对比”。3. 降低交易费用由于每个区块可容纳更多交易网络拥堵得到缓解交易费用随之降低。使用 SegWit 地址的交易通常比传统地址P2PKH的交易费用更低——在相同费率下原生 SegWit 交易体积更小天然支付的绝对费用更少。4. 为二层解决方案铺平道路SegWit 的实施为闪电网络Lightning Network等二层扩展方案的开发和部署创造了条件。交易延展性被消除后闪电网络的承诺交易commitment transaction与哈希时间锁定合约HTLC才能在链下安全地相互引用和更新状态。详见本文“SegWit 与闪电网络”一节以及仓库内 闪电网络技术原理文档。5. 脚本版本控制SegWit 引入脚本版本控制机制witness version使得未来可以更平滑地引入新的脚本功能。SegWit v0 承载 P2WPKH / P2WSH而 Taproot 正是 SegWit v1P2TR地址以bc1p开头它建立在这一版本化机制之上。关于 v0 与 v1 的详细对比可阅读仓库内 Taproot 详解文档 的“Segwit 版本区别”一节。SegWit 地址类型SegWit 主要引入两类地址1. P2SH-P2WPKH兼容地址以3开头与传统 P2SH 地址外观相同采用 Base58Check 编码。构造方式将 P2WPKH 的见证程序0014{20字节公钥哈希}作为赎回脚本redeem script再封装进 P2SH。是一种过渡性方案允许旧钱包尚不支持 Bech32向 SegWit 地址发送资金同时享受 SegWit 的部分好处更小的花费脚本、消除延展性。适用场景需要与旧钱包、旧交易所、旧支付网关兼容时。2. P2WPKH原生 SegWit 地址以bc1q开头使用 Bech32 编码SegWit v0witness version 0程序长度 20 字节。提供 SegWit 的全部好处更低的交易费用、更小的交易体积、更好的安全性与校验能力Bech32 自带更强的错误检测。适用场景现代钱包、交易所的默认首选。此外还有面向复杂脚本的P2WSH原生 SegWit 脚本哈希同样以bc1q开头但见证程序为 32 字节脚本哈希以及基于 SegWit v1 的P2TRTaprootbc1p开头。P2WSH 通常用于多重签名与复杂条件脚本P2TR 则是 SegWit v1 对单签/多签/脚本路径的统一封装。这四种类型的锁定脚本与花费见证数据结构在 Taproot 文档 的“锁定脚本和解锁脚本的对比”表中做了对照。SegWit 的采用情况自 2017 年激活以来SegWit 的采用率稳步增长。截至 2023 年超过 80% 的比特币交易使用了 SegWit显著提升了网络整体效率与容量。以下为文档给出的采用率趋势数据年份采用率2017~10%2018~30%2019~50%2020~65%2021~75%2022~80%2023~85%按地址类型分布当前比特币网络中的地址类型分布大致如下原生 SegWit 地址P2WPKH/P2WSH约 45%兼容 SegWit 地址P2SH-P2WPKH约 15%Taproot 地址P2TR约 25%传统地址P2PKH/P2SH约 15%这一趋势表明比特币生态正在逐步迁移到更高效的地址类型特别是 Taproot 激活后更多用户开始采用基于 SegWit v1 的新技术。在 example-extended.js 中这些采用率与性能数据被封装进getSegWitAdoptionAndPerformanceData()函数源码注释明确说明其为静态示例数据实际应用应从链上 API 获取最新值可作为演示或测试数据源直接使用。性能数据对比不同地址类型的交易大小与费用对比假设费率为 10 聪/字节交易类型传统地址 (P2PKH)兼容SegWit (P2SH-P2WPKH)原生SegWit (P2WPKH)Taproot (P2TR)1输入1输出192字节 / 1,920聪132字节 / 1,320聪109字节 / 1,090聪98字节 / 980聪2输入2输出374字节 / 3,740聪254字节 / 2,540聪208字节 / 2,080聪186字节 / 1,860聪这些数据显示与传统地址相比原生 SegWit 地址可节省约 45% 的交易费用兼容 SegWit 地址可节省约 30% 的交易费用Taproot 地址可节省约 50% 的交易费用区块容量提升传统区块最大 1MB约容纳 2,000 笔交易SegWit 区块最大可达 4MB约容纳 4,0008,000 笔交易这种容量提升使比特币网络的吞吐量从传统的 37 TPS每秒交易数提高到 714 TPS。需要说明的是上述采用率、地址分布、区块容量与 TPS 均为文档给定的近似估算值实际数值随网络状态动态变化引用时应注意其时间口径。SegWit 的技术实现细节交易序列化格式SegWit 引入了一种新的交易序列化格式BIP 144这是理解其工作原理的关键。下面对比传统交易与 SegWit 交易的序列化结构传统交易格式[4字节] 版本 [变长] 输入数量 [输入列表] 每个输入包含 [32字节] 上一笔交易ID [4字节] 输出索引 [变长] 脚本长度 [变长] 脚本包含签名数据 [4字节] 序列号 [变长] 输出数量 [输出列表] 每个输出包含 [8字节] 金额 [变长] 脚本长度 [变长] 脚本 [4字节] 锁定时间SegWit 交易格式[4字节] 版本 [1字节] 标记 (0x00) [1字节] 标志 (0x01) [变长] 输入数量 [输入列表] 每个输入包含 [32字节] 上一笔交易ID [4字节] 输出索引 [变长] 脚本长度 [变长] 脚本不包含签名数据通常为空 [4字节] 序列号 [变长] 输出数量 [输出列表] 每个输出包含 [8字节] 金额 [变长] 脚本长度 [变长] 脚本 [见证数据] 每个输入的见证数据 [变长] 见证数据项数量 [变长] 见证数据签名、公钥等 [4字节] 锁定时间关键区别SegWit 交易在版本之后添加了标记字节0x00与标志字节0x01用于标识该交易携带见证数据。签名数据从输入脚本移到了交易末尾的见证数据段。txid的计算不包括见证数据而wtxid包含见证数据从而解决交易延展性问题。以上结构在 example-extended.js 的explainSegWitTransactionFormat()函数中有等价的程序化描述其examples字段还给出了两种典型见证程序的形态P2WPKHscriptPubKey 0014{20字节公钥哈希}见证数据为[签名, 公钥]P2WSHscriptPubKey 0020{32字节脚本哈希}见证数据为[签名1, 签名2, ..., 见证脚本]区块权重计算SegWit 引入“区块权重”取代传统的字节数作为区块容量度量单位其规则为非见证字节的权重为 4即传统交易数据按 4 倍权重计费见证字节的权重为 1区块权重上限为 4,000,000 权重单位对应传统交易的 1MB 区块大小限制即 1,000,000 非见证字节 × 4若区块全部由见证数据构成最大序列化体积理论上可达约 4MB正是因为见证字节权重更低同样的 1MB 上限内可以打包更多交易SegWit 区块的有效容量才会在 2.1MB4MB 之间浮动取决于见证数据占比。explainSegWitTransactionFormat()中的weightCalculation数组正是对这四条规则的代码化表达而parseSegWitTransaction()则通过tx.virtualSize()虚拟大小即 weight/4与tx.weight()直接读取一笔交易在权重体系下的实际占用量。SegWit 与闪电网络SegWit 的延展性修复与脚本版本化能力是闪电网络得以成立的前提。结合仓库内 闪电网络技术原理文档两者的关系可归纳为通道资金交易闪电网络通道开通时双方将资金存入一个 2-of-2 多重签名地址P2WSH。这笔资金交易是链上交易而 SegWit 的多签脚本P2WSH为其提供了更低的手续费与更小的脚本体积。承诺交易的可引用性通道内每笔余额更新都会生成新的承诺交易且这些交易在通道关闭前都处于未确认状态。只有 SegWit 消除了交易延展性承诺交易之间才能安全地相互引用以对方的未确认交易为输入构建撤销/惩罚交易。HTLC 实现闪电网络中的哈希时间锁定合约HTLC依赖 SegWit 提供的脚本版本控制功能使得复杂的条件支付成为可能——哈希锁定HASH160 提供原像解锁与时间锁定CLTV/CSV 超时退款组合在同一份见证脚本中。通道关闭效率当闪电网络通道关闭时最终结算交易会广播到比特币区块链。使用 SegWit 可以降低这些结算交易的费用提高结算效率。实际应用示例在 Dapp-Learning 的 example-extended.js 中createLightningChannelFundingTx函数演示了如何创建一笔与闪电网络兼容的通道资金交易——这是建立闪电网络通道的第一步。其核心流程为以双方节点公钥构建 2-of-2 多重签名脚本bitcoin.payments.p2ms({ m: 2, pubkeys })并遵循 BIP-69 对公钥排序、封装为 P2WSH 地址作为通道输出、将剩余资金找零回本地节点的 P2WPKH 地址最后返回包含channelAddress与witnessScript的完整通道信息。详细流程见下文“代码实战”一节。代码实战创建 SegWit 地址和交易本仓库的 SegWit 专题包含两个可运行示例example.js基础功能与 example-extended.js高级功能。两者均基于bitcoinjs-lib库需要先安装依赖npm install bitcoinjs-lib两个示例统一使用主网参数const bitcoin require(bitcoinjs-lib); const network bitcoin.networks.bitcoin; // 主网基础功能example.jsexample.js 对外导出五个函数createSegWitAddresses、createSegWitTransaction、calculateSegWitTransactionId、estimateSegWitTransactionFee、validateSegWitAddress。1. 创建不同类型的 SegWit 地址createSegWitAddresses()一次性生成三类地址P2WPKH原生 SegWitbitcoin.payments.p2wpkh({ pubkey, network }).address以bc1q开头P2SH-P2WPKH兼容 SegWitbitcoin.payments.p2sh({ redeem: p2wpkh, network }).address以3开头P2WSH原生 SegWit 脚本哈希先用三把随机公钥构建 2-of-3 多重签名脚本p2ms bitcoin.payments.p2ms({ m: 2, pubkeys, network })再封装为bitcoin.payments.p2wsh({ redeem: p2ms, network }).address。返回对象同时包含私钥与公钥的十六进制表示。需要注意的是私钥仅用于本地演示生产环境严禁打印或泄露私钥。2. 构建 SegWit 交易createSegWitTransaction(utxo, toAddress, amount, fee, keyPair, changeAddress, addressType p2wpkh)演示了完整的交易构建流程通过TransactionBuilder添加输入utxo.txid/utxo.vout与输出计算找零change utxo.value - amount - fee当change 0时追加找零输出按地址类型签名原生 P2WPKH 直接txb.sign(0, keyPair, null, null, utxo.value)兼容 P2SH-P2WPKH 则需要传入赎回脚本p2sh.redeem.output作为签名时的脚本调用txb.build().toHex()输出交易十六进制。注意SegWit 输入签名需要提供该输入的金额utxo.value这是因为 BIP 143 的签名摘要sighash中包含了输入金额与传统交易仅哈希脚本不同。3. 计算 txid 与 wtxidcalculateSegWitTransactionId(txHex)用两行核心代码展示了 txid 与 wtxid 的区别const txid tx.getId(); // 传统txid不含见证数据 const wtxid tx.getHash(true).reverse().toString(hex); // wtxid含见证数据返回对象中的isSame字段在非 SegWit 交易上为true两者一致在 SegWit 交易上则为false——这正是“签名被改写不影响 txid”这一特性的直接体现。4. 估算交易大小与费用estimateSegWitTransactionFee(inputCount, outputCount, addressType p2wpkh, feeRate 10)使用近似公式估算交易体积P2WPKH10 inputCount * 67.75 outputCount * 31字节P2SH-P2WPKH10 inputCount * 91 outputCount * 31字节P2PKH10 inputCount * 148 outputCount * 34字节然后以fee ceil(txSize * feeRate)计算建议费用。这套估算公式与“性能数据对比”表中的数值相互印证是交易构建前进行费用预估的实用工具。5. 验证 SegWit 地址validateSegWitAddress(address)依次尝试fromBase58Check与fromBech32解析Base58 且版本为scriptHash→ 判定为 P2SH可能是 P2SH-P2WPKH 兼容 SegWitBase58 且版本为pubKeyHash→ 判定为 P2PKH 传统地址Bech32 且version 0程序长度 20 字节 → P2WPKH32 字节 → P2WSH其余情况返回“无效地址”。高级功能example-extended.jsexample-extended.js 在基础版之上扩展了八个高级函数并额外支持识别P2TRTaprootversion 1地址。6. 批量生成 SegWit 地址batchGenerateSegWitAddresses(count, addressType p2wpkh)一次性生成多个地址支持p2wpkh、p2sh-p2wpkh、p2wsh三种类型P2WSH 分支使用m: 1的单签名 P2MS 脚本构造返回数组中的每个元素包含privateKey、publicKey、address、type字段。7. 批量处理 SegWit 交易batchSegWitTransaction(utxos, outputs, keyPair, changeAddress, addressType p2wpkh)支持多个 UTXO 与多个输出汇总totalInput与totalOutput用estimateSegWitTransactionFee估算手续费逐一添加输入、输出计算并添加找零totalInput - totalOutput - fee对每个输入按地址类型签名返回{ txHex, txid, fee, changeAmount }可直接用于广播。该函数是交易所批量提款、钱包 UTXO 合并等场景的核心封装。8. 创建 SegWit 多重签名地址createSegWitMultisigAddress(m, n, addressType p2wsh)支持 m-of-n 多重签名生成n个密钥对与公钥构建p2ms多签脚本并封装p2wsh原生直接输出 P2WSH 地址与见证脚本witnessScriptp2sh-p2wsh兼容额外包一层 P2SH输出以3开头的地址与赎回脚本redeemScript。返回对象完整保留pubkeys、privateKeys、redeemScript、witnessScript便于后续签名协作。9. 创建闪电网络通道资金交易createLightningChannelFundingTx(utxo, localPubkey, remotePubkey, localAmount, remoteAmount, keyPair, fee)是“SegWit 与闪电网络”一节的落地代码构造 2-of-2 多签脚本并按 BIP-69 要求对公钥排序[localPubkey, remotePubkey].sort((a, b) a.compare(b))封装为 P2WSH 地址作为通道资金输出channelAmount localAmount remoteAmount找零输出使用本地节点的 P2WPKH 地址返回{ txHex, txid, channelAddress, witnessScript, localAmount, remoteAmount, totalAmount }。10. 解析 SegWit 交易结构parseSegWitTransaction(txHex)将一笔交易反序列化并提取txid、wtxid、version、locktime、hasWitnesses、virtualSize、weight、byteLength并逐输入输出识别其类型p2pkh / p2sh / p2wpkh / p2wsh与地址。其中virtualSize()虚拟大小与weight()权重直接对应上文“区块权重计算”一节的概念是理解 SegWit 体积核算的直观工具。11. SegWit 与 Taproot 对比compareSegWitWithTaproot(inputCount, outputCount)与compareSegWitAndTaproot()分别从费用节省与特性维度对比 SegWit v0 与 Taprootv1估算四种地址类型p2pkh / p2sh-p2wpkh / p2wpkh / p2tr的交易大小与费用并计算节省百分比特性对比涵盖脚本执行OP_CHECKSIGvs Schnorr 的OP_CHECKSIGADD、隐私Taproot 使所有输出外观一致、多签效率Schnorr 密钥聚合、脚本复杂度MAST 只公开被执行的分支等方面演进路径总结为SegWitv0解决延展性 → TaprootSegWit v1在 v0 基础上提供更高级的脚本功能与隐私保护。采用率与性能数据函数getSegWitAdoptionAndPerformanceData()将文档中的采用率表、地址分布、交易大小/费用对比、区块容量、吞吐量及交易所/钱包案例封装为结构化数据源码注明为静态示例数据实际应用应从链上 API 获取最新值可配合上述函数用于单元测试或教学演示。SegWit 的最佳实践地址选择优先使用原生 SegWit 地址bc1q开头提供最低的交易费用、最佳的安全性与性能适用于支持 Bech32 地址格式的现代钱包与交易所。兼容性考虑如需与旧钱包或旧服务兼容可选用 P2SH-P2WPKH 地址3开头。其费用优势略低于原生 SegWit但仍显著优于传统 P2PKH 地址。多签名场景对于多签名钱包P2WSH原生或 P2SH-P2WSH兼容提供更高的安全性与更低的费用复杂脚本应优先使用 SegWit 版本以获得费用优势。更复杂的条件脚本则可以考虑升级到 TaprootP2TR MAST。交易构建费用估算使用estimateSegWitTransactionFee函数准确估算交易费用。SegWit 交易的费用计算与传统交易不同见证字节权重为 1需按虚拟大小计费正确估算可避免支付过高费用。批量处理需要处理多个交易或合并 UTXO 时使用batchSegWitTransaction函数可更有效地管理 UTXO 集合同时优化交易费用。与闪电网络集成使用createLightningChannelFundingTx创建与闪电网络兼容的通道资金交易确保通道资金交易使用正确的 2-of-2 多签名脚本格式P2WSH并遵循 BIP-69 公钥排序。实际应用场景1. 交易所集成交易所可以通过实现 SegWit 显著降低提款交易费用同时提高处理速度。以下示例展示了批量提款的处理方式// 交易所批量处理提款示例 const withdrawals [ { address: bc1q..., amount: 1000000 }, // 用户A提款 { address: bc1q..., amount: 2500000 }, // 用户B提款 // 更多提款... ]; const tx batchSegWitTransaction(availableUTXOs, withdrawals, exchangeKeyPair, exchangeChangeAddress, p2wpkh); // 广播交易...2. 钱包应用钱包应用可以为用户提供多种地址类型选择并解释每种类型的优缺点// 为用户生成不同类型的地址 const addressOptions { legacy: bitcoin.payments.p2pkh({ pubkey: userKeyPair.publicKey, network }).address, segwitCompatible: bitcoin.payments.p2sh({ redeem: bitcoin.payments.p2wpkh({ pubkey: userKeyPair.publicKey, network }), network }).address, segwitNative: bitcoin.payments.p2wpkh({ pubkey: userKeyPair.publicKey, network }).address };3. 多签名钱包企业与组织可以使用 SegWit 多签名地址增强资金安全性// 创建3-of-5多签名企业钱包 const corporateWallet createSegWitMultisigAddress(3, 5, p2wsh); // 保存地址和赎回脚本信息...4. 闪电网络节点运行闪电网络节点的用户可以使用 SegWit 创建通道资金交易// 开设新的闪电网络通道 const channelFunding createLightningChannelFundingTx( selectedUTXO, localNodePubkey, remoteNodePubkey, myChannelAmount, theirChannelAmount, myKeyPair, estimatedFee ); // 广播资金交易并等待确认...结论隔离见证是比特币历史上最重要的技术升级之一。它不仅解决了交易延展性这一长期困扰生态的关键问题还通过区块权重机制提高了网络的交易容量与效率同时为闪电网络、Taproot 等创新方案铺平了道路。随着越来越多的用户与服务采用 SegWit比特币网络的性能与可用性持续提升。通过 Dapp-Learning 仓库 BTC/Basic/SegWit 中的 example.js 与 example-extended.js开发者可以快速上手 SegWit 的各项功能——从基本的地址生成、交易构建、txid/wtxid 计算到复杂的批量处理、多签名与闪电网络通道资金交易。这些可复用的工具函数为构建现代、高效的比特币应用提供了坚实基础。进一步深入学习可继续阅读仓库内的 BTC 知识库总览、Taproot 详解 与 闪电网络技术原理 等关联专题。参考资料BIP 141Segregated Witness隔离见证核心提案定义见证数据分离与区块权重BIP 143Transaction Signature Verification for Version 0 Witness Program定义 v0 见证程序的签名摘要算法签名需包含输入金额BIP 173Base32 address format for native v0-16 witness outputs定义 Bech32 编码与bc1q原生 SegWit 地址BIP 144Segregated WitnessPeer Services定义新的交易序列化格式与 wtxid 传播仓库源码example.js、example-extended.js赞分享示例工程区块链【免费下载链接】Dapp-LearningDapp learning project for developers at all stages. Becoming and cultivating sovereign individuals. Nonprofit organization.项目地址https://gitcode.com/gh_mirrors/da/Dapp-Learning点击查看免费下载相关推荐RunCat 365完全指南让任务栏猫咪成为你的系统健康伴侣RunCat 365完全指南让任务栏猫咪成为你的系统健康伴侣 你是否曾希望有个可爱的小助手在任务栏里帮你监控系统状态RunCat 365正是这样一款独特的W桌面应用Dapp-Learning 比特币多签实战OP_CHECKMULTISIG 操作码原理、P2SH/P2WSH 链上交易与 bitcoinjs-lib 代码拆解Dapp Learning 比特币多签实战OP_CHECKMULTISIG 操作码原理、P2SH/P2WSH 链上交易与 bitcoinjs lib 代码拆解示例工程区块链比特币 Taproot 实战指南Dapp-Learning 示例中的 P2TR 地址生成与 Schnorr 签名交易比特币 Taproot 实战指南Dapp Learning 示例中的 P2TR 地址生成与 Schnorr 签名交易 本文以开源仓库 Dapp Learnin示例工程区块链上一篇3分钟掌握终极AI编程助手OpenCode完全免费开源方案下一篇从零开始用scdl打造你的个人音乐宇宙 创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑