Balenciaga on Nostr: 比特币钱包备份方案简史 ...
比特币钱包备份方案简史
制作比特币钱包备份时，我们希望根据自身需要和风险情况，找出下列特性的最优组合方案：
冗余性：存有几份完整的备份副本。
安全性：第三方获得完整的备份副本的难度。
复杂性：用来创建、保护和找回副本的系统的复杂程度。
健壮性：面对不利的政治、社会、时间和环境条件，备份能否安然无恙。
跨钱包兼容性：备份能否用于不同的钱包。
虽然上述特性之间不存在绝对对立，但是试图增强一个特性往往需要我们在另一个特性上做出妥协。
确定性 vs 非确定性
我们将要讨论某些确定性和非确定性操作。确定性和非确定性的定义如下：
确定性：只要输入相同，每次生成的输出必定相同。
非确定性：输入相同，每次生成的输出可能不同。
私钥 可能会经由确定性或非确定性方法生成，详见下文。
地址 通过确定性方法由一个或多个公钥和锁定脚本单独或共同生成。
确定性和比特币脚本
虽然地址生成本身是确定性的，但是从备份的角度来看，备份中仍有必要包含钱包所用的脚本和派生路径。如果没有这些，通过此备份找回的钱包可能会不知道被发送至某一地址的代币属于它，也不知道如何花费这些代币！
这里有一些“脚本模板”可以为你提供捷径：
“标准”地址类型（例如，P2PKH、P2WPK、P2WPKH）本质上是特定脚本的模板。钱包可以利用这些模板通过一组特定密钥暴力生成通用地址类型。
请注意这些捷径本质上依赖的是隐含信息，而非让备份 明面上 包含所有必要数据。因此，这类备份的健壮性较弱。如果将来有一天隐含信息丢失了，依赖它的备份可能会失去作用，或者需要大量（甚至于不可能完成的）暴力破解。
关于如何在备份中显式包含使用一个或多个密钥的脚本，查看下文的“输出描述符”章节。
比特币备份技术发展史
我们将跟随比特币骨灰级用户 Alice 的视角，看她这些年来是如何好好保护钱包备份的。
理想情况下，Alice 的备份应该具备冗余性、安全性、健壮性和低复杂性。即使是在她本人失联的情况下，也可由她选择的受益者轻松安全地访问。
早期比特币软件
就最早期的 Bitcoin Software 版本（Satoshi 客户端，也就是如今的“Bitcoin Core”）而言，备份采用的是原始手段。Alice 能采取的最佳措施就是定期备份 wallet.dat 文件（由软件钱包创建并使用）。虽然此系统复杂程度较低，但它既不安全、健壮，也不具备很强的冗余性 —— 除非 Alice 手动创建很多副本。
发送或接收交易时，软件会动态生成新的密钥。也就是说，每当 Alice 执行一笔交易或生成一个新的收款地址时，她都要重新备份更新后的 wallet.dat 文件，因为该文件中包含了以往备份中不存在的新密钥。
如果 Alice 勤勤恳恳地为她的 wallet.dat 文件创建了多个冗余副本，那么她每执行一笔交易就得更新 所有副本。说它容易出错、用户体验差已经很客气了。
备份 wallet.dat 文件的好处之一是交易和钱包元数据同样会被备份。这里面也包括了分配给地址的“标签”，这样 Alice 就可以记住每个币（更具体地说是 UTXO）来自何处或被送往何处。详见后文。
密钥池（Key Pool）
后来，比特币软件新增了“密钥池（Key Pool）“ 功能。默认情况下，密钥池中包含 100 个私钥可用于未来交易。这意味着，从技术角度来说，用户无需在每次交易后都进行备份。
软件提前生成 100 个随机的非确定性私钥，并将它们保存在 wallet.dat 文件内。Alice 进行交易（收付款）时，软件会从密钥池中选择一个私钥用来生成一个新的找零或收款地址。紧接着会再生成一个新的私钥补充到密钥池中，确保未使用的地址数量为 100 个。请注意，Alice 的当前备份中不包含新生成的私钥，但是其余 99 个都在。
引入密钥池后，Alice 的备份虽说没那么容易出错了，但她需要追踪密钥池的状态。备份的复杂性本质上没有变化，因为 Alice 必须确保同步更新备份的所有副本，否则就要承担降低冗余性的风险。
这意味着，Alice 需要定期备份钱包，只是可以选择延长时间间隔而已。当时，指南上说的是你只需“大约每 30 笔交易”备份一次即可。Alice 担心自己会忘了上次备份后执行的交易数量，于是仍选择每笔交易备份一次。
纸钱包
2011 年中，纸钱包变成了热议话题；它为 Alice 这样的用户提供了一种简单的方法，让他们能够轻松形成复杂性极低的有形实体备份，并且容易实现冗余性。纸钱包的安全性非常低 —— 只要是拿到副本的人都可以立即访问并卷走钱包里的资金，除非钱包还使用了强大的 BIP38 密语。
纸钱包通常会存储转化成钱包导入格式（Wallet Import Format, WIF）的单个私钥及其对应的 P2PKH 地址，并使用二维码表示，以便用户使用手机相机或网络摄像头扫描。安全生成并打印出来之后，Alice 就可以放心将比特币发送到自己的地址。
花费比特币时，Alice 必须将私钥导入她的钱包软件，后者会生成对应的 scriptPubKey 并扫描区块链以找到匹配的 UTXO。使用这些 UTXO 作为交易输入，软件钱包就可以构建并签署交易，并将其广播至点对点网络或挖出包含此交易的区块。
但是，纸钱包的缺点也很多。
从协议的角度来看，最大的问题是纸钱包实际上只支持备份单个密钥，这是在鼓励用户重复使用地址，不利于保护隐私性。此外，虽然比特币离线存储（在纸上）时可能是安全的，但你在花费比特币时仍需将你的私钥加载到计算机上才能生成交易，使得你容易遭受一切针对此计算机的攻击。
确定性钱包
又被叫作：非分层确定性钱包
2011 年，其它比特币钱包实现开始使用 确定性 密钥派生形式。通过这些方案，用户能够根据单个随机生成的“种子”确定性地生成大量新密钥。确定性钱包主要有两大优点：
可以备份单个对象（种子）
可以派生新的地址用于执行每笔交易，而不会导致以前的备份失效。
这样一来，Alice 就可以增加备份的冗余性，同时还能保留为每笔交易使用新地址的最佳做法。
备份单个种子也为更加健壮的备份存储介质开辟了新的可能性，因为种子无需备份在数字介质上，尽管在引入 BIP39 之前几乎没人探索过新的可能性。
BIP32 和分层确定性钱包
HD：分层确定性
BIP32：分层确定性钱包
2012 年初提出的 BIP32 试图改进早期的确定性钱包设计，并使用预先确定的层次结构和派生路径语法支持根据单个种子派生多条子密钥链：
HD wallet chain derivation
这使得单个备份可以对应多个独立的钱包，从理论上来说甚至可以对应多种密码获币，只要用户记住并备份使用的派生路径即可。
虽然 BIP32 并未显著改进非分层确定性钱包的备份体验（二者实际上都需要备份单个种子），但它确实为未来的钱包设计提供了一个重要基石。
请注意，BIP32 的提议者之一 gmaxwell 后来评论道：
BIP32 根本无法代替备份，最多只能保护密钥材料。它没有采取任何保护元数据的措施，但元数据可能会起到绝对关键的作用……
以及
我有点后悔发明目前最常用的公钥派生方法了 —— 出现了使用过度和损害安全性的问题（通常是因为用户没有理解其影响）。
备份元数据可能会起到重要乃至关键的作用，但是 BIP32 方案并未涉及这方面。
P2SH
2012 年中，P2SH 地址类型问世。使用 P2SH 地址时，接收方会对其用来锁定比特币的（赎回）脚本运行哈希计算，并使用得到的哈希值生成地址。之后，只有当接收方想要花费此比特币时，才需要将赎回脚本作为 ScriptSig 的一部分公开。欲知更多详情，请阅读 BIP16。
从备份的角度来看，这意味着使用 P2SH 地址收款的钱包除了私钥（们）之外还有个新的东西需要备份：解锁脚本（通常被叫作 redeemScript）。
此数据无法像 主/子私钥 和公钥（以及 P2PK 或 P2PKH 地址）那样以确定性方式由种子派生而得。
从下方来自 transactionfee.info 的图中，我们可以看到 P2SH 地址直到 2014 年以后才真正得到广泛使用。
p2sh usage graph
Alice 本人没有使用过 P2SH 地址，因为手抄比特币脚本实在太容易出错，而且可用工具有限，钱包兼容性也很差。
硬件钱包，BIP39 和 BIP44
BIP39：用来生成确定性密钥的助记词
BIP44：确定性钱包的多账户分层结构
2013 年，第一代“硬件钱包”Trezor 初次亮相。第一版 Trezor 的设计目标很简单：让用户能够将其私钥存储在安全、离线且静态交互（airgapped）的设备内，并使用该设备内的私钥签署有效的比特币交易。
Trezor 采用的是分层确定性钱包设计。为了弥补其不足，Trezor 团队 (SatoshiLabs) 设计了 BIP39，注明了随机种子与助记词之间如何进行双向转化。这意味着，确定性或分层确定性钱包的用户再也无需备份一长串用来表示种子的字母数字（或十六进制）字符串，只需备份 12 或 24 个（英语）单词即可。
十六进制种子示例：
3d1d3da431ce5f2f26a4fd3b481c285edac280cebdbc3fbbf7739c2ccbb73f99acc816687daa86ef51a7fb95c19f170da5aafbf49a9e4177abc4cad13a3c7ca2
助记词示例：
check day then tiger collect join hotel hawk absorb ginger wash track crowd hero scale
你可以在这个网站上生成自己的 BIP39 助记词，以了解更多助记词、种子和根密钥的例子，但是请勿真的将通过该网站生成的钱包用于交易。
BIP39 极大拓宽了种子备份方案的可能性。用户开始在存储介质上肆意发挥创造力。现在，Alice 能够增强其备份的健壮性。
但是，硬件钱包依然存在一个问题，虽然从理论上来说，硬件钱包已经能够根据种子生成签署交易所需的私钥了，但是它们可能不知道应该通过哪条 BIP32 派生路径这么做。
BIP44 试图通过为 BIP32 派生描述符的不同部分指定含义来解决该问题。BIP44 实现后，硬件钱包就能知道应该跟随哪条 BIP32 派生路径（例如，表示为 m/44’/0’/0’/0/0 的形式）派生密钥和地址。
硬件钱包、BIP39 和 BIP44 对 Alice 的影响是，Alice 不仅可以安全地生成助记词，还能轻松实现备份冗余性。Alice 可以使用在线（热）钱包（通过 xPub 主公钥）生成收款地址，并安全地使用硬件钱包离线签署交易。
助记词备份方案
BIP39 之后，很多有趣的助记词存储设计得到了试验：1、2、3、4、5、6 。
SegWit（隔离见证）
BIP141：Segregated Witness（共识层）
BIP49：基于 P2WPKH-nested-in-P2SH（P2WPKH 嵌套在 P2SH 中）的账户的派生方案
BIP84：基于 P2WPKH 的账户的派生方案
SegWit 生效之前，钱包和签名设备需要在备份时考虑以下地址类型：
P2PK
P2PKH
P2SH
2017 年的 SegWit 升级引入了新的标准地址脚本，即，Pay-To-Witness-PubKey-Hash (P2WPKH) 和 Pay-To-Witness-Script-Hash (P2WSH)，二者都使用了新的 bech32 地址编码。
这意味着需要新的派生规范来帮助钱包决定如何根据种子派生这几类地址以及花费地址上的余额。P2WPKH 的相关规范都写在了 BIP84 里。
除此之外，新的 SegWit 地址类型也可以用旧的（兼容性更好的）P2SH 格式“包裹”起来，例如，P2SH-P2WPKH。这意味着未升级的旧版钱包仍能向支持 SegWit 的钱包付款。BIP49 详述了 P2SH 包裹下的 P2WPKH 地址的派生。
SegWit 本身并没有为备份方案带来很大改变，但它确实开始在交易费层面上降低了复杂脚本的成本，并满足了大量使用多签、门限多签乃至更复杂脚本的新型比特币应用和服务的需求。
就像 P2SH 那样，如果 Alice 想要使用自定义脚本作为 P2WSH 的一部分，她需要单独备份此脚本，但这里是作为“见证脚本（witness script）”的一部分。
另外需要注意的是，备份方案的复杂性正在呈指数级增加。比特币每经历一次技术迭代，都会出现需要额外备份的信息，这是个需要解决的问题。
Taproot、脚本和备份
在 Taproot 的进一步支持和激励下，用户能够使用更为复杂的自定义脚本。用表格列出需要备份的信息似乎是个不错的主意……
Bitcoin Core 开发者 Gloria Zhao 绘制了一张很有用的表格，展示了各种地址类型及要求，其中加粗的脚本元素需要额外备份。
Output Type scriptPubKey scriptSig redeem script witness
P2PK OP_CHECKSIG
P2PKH OP_DUPOP_HASH160OP_EQUALVERIFYOP_CHECKSIG
P2SH OP_HASH160OP_EQUAL (arbitrary)
P2WPKH 0
P2WSH 0
P2SH-P2WPKH OP_HASH160OP_EQUAL 0
P2SH-P2WSH OP_HASH160OP_EQUAL 0
P2TR (key path) 1
P2TR (script path) 1
制作比特币钱包备份时，我们希望根据自身需要和风险情况，找出下列特性的最优组合方案：
冗余性：存有几份完整的备份副本。
安全性：第三方获得完整的备份副本的难度。
复杂性：用来创建、保护和找回副本的系统的复杂程度。
健壮性：面对不利的政治、社会、时间和环境条件，备份能否安然无恙。
跨钱包兼容性：备份能否用于不同的钱包。
虽然上述特性之间不存在绝对对立，但是试图增强一个特性往往需要我们在另一个特性上做出妥协。
确定性 vs 非确定性
我们将要讨论某些确定性和非确定性操作。确定性和非确定性的定义如下：
确定性：只要输入相同，每次生成的输出必定相同。
非确定性：输入相同，每次生成的输出可能不同。
私钥 可能会经由确定性或非确定性方法生成，详见下文。
地址 通过确定性方法由一个或多个公钥和锁定脚本单独或共同生成。
确定性和比特币脚本
虽然地址生成本身是确定性的，但是从备份的角度来看，备份中仍有必要包含钱包所用的脚本和派生路径。如果没有这些，通过此备份找回的钱包可能会不知道被发送至某一地址的代币属于它，也不知道如何花费这些代币！
这里有一些“脚本模板”可以为你提供捷径：
“标准”地址类型（例如，P2PKH、P2WPK、P2WPKH）本质上是特定脚本的模板。钱包可以利用这些模板通过一组特定密钥暴力生成通用地址类型。
请注意这些捷径本质上依赖的是隐含信息，而非让备份 明面上 包含所有必要数据。因此，这类备份的健壮性较弱。如果将来有一天隐含信息丢失了，依赖它的备份可能会失去作用，或者需要大量（甚至于不可能完成的）暴力破解。
关于如何在备份中显式包含使用一个或多个密钥的脚本，查看下文的“输出描述符”章节。
比特币备份技术发展史
我们将跟随比特币骨灰级用户 Alice 的视角，看她这些年来是如何好好保护钱包备份的。
理想情况下，Alice 的备份应该具备冗余性、安全性、健壮性和低复杂性。即使是在她本人失联的情况下，也可由她选择的受益者轻松安全地访问。
早期比特币软件
就最早期的 Bitcoin Software 版本（Satoshi 客户端，也就是如今的“Bitcoin Core”）而言，备份采用的是原始手段。Alice 能采取的最佳措施就是定期备份 wallet.dat 文件（由软件钱包创建并使用）。虽然此系统复杂程度较低，但它既不安全、健壮，也不具备很强的冗余性 —— 除非 Alice 手动创建很多副本。
发送或接收交易时，软件会动态生成新的密钥。也就是说，每当 Alice 执行一笔交易或生成一个新的收款地址时，她都要重新备份更新后的 wallet.dat 文件，因为该文件中包含了以往备份中不存在的新密钥。
如果 Alice 勤勤恳恳地为她的 wallet.dat 文件创建了多个冗余副本，那么她每执行一笔交易就得更新 所有副本。说它容易出错、用户体验差已经很客气了。
备份 wallet.dat 文件的好处之一是交易和钱包元数据同样会被备份。这里面也包括了分配给地址的“标签”，这样 Alice 就可以记住每个币（更具体地说是 UTXO）来自何处或被送往何处。详见后文。
密钥池（Key Pool）
后来，比特币软件新增了“密钥池（Key Pool）“ 功能。默认情况下，密钥池中包含 100 个私钥可用于未来交易。这意味着，从技术角度来说，用户无需在每次交易后都进行备份。
软件提前生成 100 个随机的非确定性私钥，并将它们保存在 wallet.dat 文件内。Alice 进行交易（收付款）时，软件会从密钥池中选择一个私钥用来生成一个新的找零或收款地址。紧接着会再生成一个新的私钥补充到密钥池中，确保未使用的地址数量为 100 个。请注意，Alice 的当前备份中不包含新生成的私钥，但是其余 99 个都在。
引入密钥池后，Alice 的备份虽说没那么容易出错了，但她需要追踪密钥池的状态。备份的复杂性本质上没有变化，因为 Alice 必须确保同步更新备份的所有副本，否则就要承担降低冗余性的风险。
这意味着，Alice 需要定期备份钱包，只是可以选择延长时间间隔而已。当时，指南上说的是你只需“大约每 30 笔交易”备份一次即可。Alice 担心自己会忘了上次备份后执行的交易数量，于是仍选择每笔交易备份一次。
纸钱包
2011 年中，纸钱包变成了热议话题；它为 Alice 这样的用户提供了一种简单的方法，让他们能够轻松形成复杂性极低的有形实体备份，并且容易实现冗余性。纸钱包的安全性非常低 —— 只要是拿到副本的人都可以立即访问并卷走钱包里的资金，除非钱包还使用了强大的 BIP38 密语。
纸钱包通常会存储转化成钱包导入格式（Wallet Import Format, WIF）的单个私钥及其对应的 P2PKH 地址，并使用二维码表示，以便用户使用手机相机或网络摄像头扫描。安全生成并打印出来之后，Alice 就可以放心将比特币发送到自己的地址。
花费比特币时，Alice 必须将私钥导入她的钱包软件，后者会生成对应的 scriptPubKey 并扫描区块链以找到匹配的 UTXO。使用这些 UTXO 作为交易输入，软件钱包就可以构建并签署交易，并将其广播至点对点网络或挖出包含此交易的区块。
但是，纸钱包的缺点也很多。
从协议的角度来看，最大的问题是纸钱包实际上只支持备份单个密钥，这是在鼓励用户重复使用地址，不利于保护隐私性。此外，虽然比特币离线存储（在纸上）时可能是安全的，但你在花费比特币时仍需将你的私钥加载到计算机上才能生成交易，使得你容易遭受一切针对此计算机的攻击。
确定性钱包
又被叫作：非分层确定性钱包
2011 年，其它比特币钱包实现开始使用 确定性 密钥派生形式。通过这些方案，用户能够根据单个随机生成的“种子”确定性地生成大量新密钥。确定性钱包主要有两大优点：
可以备份单个对象（种子）
可以派生新的地址用于执行每笔交易，而不会导致以前的备份失效。
这样一来，Alice 就可以增加备份的冗余性，同时还能保留为每笔交易使用新地址的最佳做法。
备份单个种子也为更加健壮的备份存储介质开辟了新的可能性，因为种子无需备份在数字介质上，尽管在引入 BIP39 之前几乎没人探索过新的可能性。
BIP32 和分层确定性钱包
HD：分层确定性
BIP32：分层确定性钱包
2012 年初提出的 BIP32 试图改进早期的确定性钱包设计，并使用预先确定的层次结构和派生路径语法支持根据单个种子派生多条子密钥链：
HD wallet chain derivation
这使得单个备份可以对应多个独立的钱包，从理论上来说甚至可以对应多种密码获币，只要用户记住并备份使用的派生路径即可。
虽然 BIP32 并未显著改进非分层确定性钱包的备份体验（二者实际上都需要备份单个种子），但它确实为未来的钱包设计提供了一个重要基石。
请注意，BIP32 的提议者之一 gmaxwell 后来评论道：
BIP32 根本无法代替备份，最多只能保护密钥材料。它没有采取任何保护元数据的措施，但元数据可能会起到绝对关键的作用……
以及
我有点后悔发明目前最常用的公钥派生方法了 —— 出现了使用过度和损害安全性的问题（通常是因为用户没有理解其影响）。
备份元数据可能会起到重要乃至关键的作用，但是 BIP32 方案并未涉及这方面。
P2SH
2012 年中，P2SH 地址类型问世。使用 P2SH 地址时，接收方会对其用来锁定比特币的（赎回）脚本运行哈希计算，并使用得到的哈希值生成地址。之后，只有当接收方想要花费此比特币时，才需要将赎回脚本作为 ScriptSig 的一部分公开。欲知更多详情，请阅读 BIP16。
从备份的角度来看，这意味着使用 P2SH 地址收款的钱包除了私钥（们）之外还有个新的东西需要备份：解锁脚本（通常被叫作 redeemScript）。
此数据无法像 主/子私钥 和公钥（以及 P2PK 或 P2PKH 地址）那样以确定性方式由种子派生而得。
从下方来自 transactionfee.info 的图中，我们可以看到 P2SH 地址直到 2014 年以后才真正得到广泛使用。
p2sh usage graph
Alice 本人没有使用过 P2SH 地址，因为手抄比特币脚本实在太容易出错，而且可用工具有限，钱包兼容性也很差。
硬件钱包，BIP39 和 BIP44
BIP39：用来生成确定性密钥的助记词
BIP44：确定性钱包的多账户分层结构
2013 年，第一代“硬件钱包”Trezor 初次亮相。第一版 Trezor 的设计目标很简单：让用户能够将其私钥存储在安全、离线且静态交互（airgapped）的设备内，并使用该设备内的私钥签署有效的比特币交易。
Trezor 采用的是分层确定性钱包设计。为了弥补其不足，Trezor 团队 (SatoshiLabs) 设计了 BIP39，注明了随机种子与助记词之间如何进行双向转化。这意味着，确定性或分层确定性钱包的用户再也无需备份一长串用来表示种子的字母数字（或十六进制）字符串，只需备份 12 或 24 个（英语）单词即可。
十六进制种子示例：
3d1d3da431ce5f2f26a4fd3b481c285edac280cebdbc3fbbf7739c2ccbb73f99acc816687daa86ef51a7fb95c19f170da5aafbf49a9e4177abc4cad13a3c7ca2
助记词示例：
check day then tiger collect join hotel hawk absorb ginger wash track crowd hero scale
你可以在这个网站上生成自己的 BIP39 助记词，以了解更多助记词、种子和根密钥的例子，但是请勿真的将通过该网站生成的钱包用于交易。
BIP39 极大拓宽了种子备份方案的可能性。用户开始在存储介质上肆意发挥创造力。现在，Alice 能够增强其备份的健壮性。
但是，硬件钱包依然存在一个问题，虽然从理论上来说，硬件钱包已经能够根据种子生成签署交易所需的私钥了，但是它们可能不知道应该通过哪条 BIP32 派生路径这么做。
BIP44 试图通过为 BIP32 派生描述符的不同部分指定含义来解决该问题。BIP44 实现后，硬件钱包就能知道应该跟随哪条 BIP32 派生路径（例如，表示为 m/44’/0’/0’/0/0 的形式）派生密钥和地址。
硬件钱包、BIP39 和 BIP44 对 Alice 的影响是，Alice 不仅可以安全地生成助记词，还能轻松实现备份冗余性。Alice 可以使用在线（热）钱包（通过 xPub 主公钥）生成收款地址，并安全地使用硬件钱包离线签署交易。
助记词备份方案
BIP39 之后，很多有趣的助记词存储设计得到了试验：1、2、3、4、5、6 。
SegWit（隔离见证）
BIP141：Segregated Witness（共识层）
BIP49：基于 P2WPKH-nested-in-P2SH（P2WPKH 嵌套在 P2SH 中）的账户的派生方案
BIP84：基于 P2WPKH 的账户的派生方案
SegWit 生效之前，钱包和签名设备需要在备份时考虑以下地址类型：
P2PK
P2PKH
P2SH
2017 年的 SegWit 升级引入了新的标准地址脚本，即，Pay-To-Witness-PubKey-Hash (P2WPKH) 和 Pay-To-Witness-Script-Hash (P2WSH)，二者都使用了新的 bech32 地址编码。
这意味着需要新的派生规范来帮助钱包决定如何根据种子派生这几类地址以及花费地址上的余额。P2WPKH 的相关规范都写在了 BIP84 里。
除此之外，新的 SegWit 地址类型也可以用旧的（兼容性更好的）P2SH 格式“包裹”起来，例如，P2SH-P2WPKH。这意味着未升级的旧版钱包仍能向支持 SegWit 的钱包付款。BIP49 详述了 P2SH 包裹下的 P2WPKH 地址的派生。
SegWit 本身并没有为备份方案带来很大改变，但它确实开始在交易费层面上降低了复杂脚本的成本，并满足了大量使用多签、门限多签乃至更复杂脚本的新型比特币应用和服务的需求。
就像 P2SH 那样，如果 Alice 想要使用自定义脚本作为 P2WSH 的一部分，她需要单独备份此脚本，但这里是作为“见证脚本（witness script）”的一部分。
另外需要注意的是，备份方案的复杂性正在呈指数级增加。比特币每经历一次技术迭代，都会出现需要额外备份的信息，这是个需要解决的问题。
Taproot、脚本和备份
在 Taproot 的进一步支持和激励下，用户能够使用更为复杂的自定义脚本。用表格列出需要备份的信息似乎是个不错的主意……
Bitcoin Core 开发者 Gloria Zhao 绘制了一张很有用的表格，展示了各种地址类型及要求，其中加粗的脚本元素需要额外备份。
Output Type scriptPubKey scriptSig redeem script witness
P2PK OP_CHECKSIG
P2PKH OP_DUPOP_HASH160OP_EQUALVERIFYOP_CHECKSIG
P2SH OP_HASH160OP_EQUAL (arbitrary)
P2WPKH 0
P2WSH 0
P2SH-P2WPKH OP_HASH160OP_EQUAL 0
P2SH-P2WSH OP_HASH160OP_EQUAL 0
P2TR (key path) 1
P2TR (script path) 1