比特币钱包出现<strong>「Taproot」</strong>选项，代表什么？以<code>bc1p</code>开头的地址，与常见的<code>bc1q</code>又有什么不同？
Taproot 是Bitcoin 的协议升级，结合Schnorr 签名、花费条件承诺与新的脚本规则，让部分交易可以用较精简的方式完成，也能减少不必要的条件揭露。
不过，它不是匿名工具，也不保证所有交易都比较便宜。理解它的关键，是区分Key Path 与Script Path 两种花费方式。
Taproot 是Bitcoin（比特币）的一次软分叉升级，于2021 年在主网区块高度709,632 启用。它引入P2TR（Pay-to-Taproot）输出，使用版本1 见证规则。
使用者收到的仍是BTC，不是另外发行的Taproot 代币；旧版有效输出也不会因此自动失效。
Taproot 常与三份提案一起介绍：
它们互相配合，但不是三个名称指向完全相同的东西。
数字签名让节点验证交易是否获得相应授权。 BIP 340 定义在secp256k1 曲线上使用的Schnorr 签名规格，与Bitcoin 传统使用的ECDSA 不同。
Schnorr 的代数结构有助于设计多方共同签署等协议。不过，BIP 340 本身不是「按一下就把所有人的签名合并」的完整钱包方案。
不会自动发生。若采用合适的多方签署协议，例如MuSig 类型设计，多方可协作产生对应公钥的签名，让某些付款以单一Key Path 签名完成。
钱包与参与者仍需配合该协议；旧有多签资产不会因Taproot 启用就自动转换。
也不能将这项能力误写成「一笔交易的所有输入已自动共用一个签名」。跨输入签名聚合不是本次Taproot 升级普遍自动提供的功能。
Taproot 输出可让花费者透过对应的金钥路径，或在设计中存在且可满足时，透过脚本路径花费。
Key Path 以能通过输出公钥验证的Schnorr 签名授权花费，不必揭露背后是否存在其他备用脚本。
在协作式多方设计中，参与者若能共同完成相应签署，便可能走这条路径。从这部分链上资料，不一定能看出究竟是单人还是多方协作。
若使用已承诺的脚本路径，花费者需提供选中的脚本、满足条件的资料，以及证明它属于输出承诺的必要资料。
它不要求将每一条未使用的备用脚本全文公开，但使用到的条件与证明仍会揭露。脚本路径不是免费，也不是隐藏所有资讯。
假设两名参与者设计一个共同保管方案：平常合作时，透过合适的协作签署机制走Key Path；另承诺一条带时间条件的备援脚本。
若合作顺利，花费时不必公开备援脚本内容。若需要使用备援，便揭露并满足该路径的条件。
这是设计概念，不代表任何两个钱包地址都能直接组成此方案。金钥、脚本、备份及签署协议必须正确建构，才有相应效果。
Taproot 的隐私效果，主要来自减少花费条件的不必要揭露，以及让部分不同设计以相近的Key Path 花费形式呈现。
例如，一个具有备援脚本的输出，若最终由Key Path 花费，不必公开那条脚本。使用Script Path 时，也只需揭露相关路径的必要资料。
但转帐金额、输出、交易连结及其他公开资料仍可能被分析。使用bc1p 不会自动让地址失去追踪性，也不保证外界无法辨识使用者。
对一般用户而言，避免重用地址、理解找零及资金混合使用带来的关联，仍有实际意义。
不一定。费用与实际交易的虚拟大小、选择的sat/vB，以及市场需求有关。
Key Path 在某些复杂协作情境中能节省原本需要公开的脚本与签名资料；Script Path 则需计入脚本、证明及满足条件的资料。
也要分清楚「建立Taproot 收款输出」与「之后花费该输出」的资料成本，不能只比较其中一个环节就宣称所有情况都更省。
当Mempool竞争改变，即使交易结构不变，总费用也可能不同。
Bitcoin 主网Taproot 地址常以bc1p 开头，对应P2TR、版本1 见证程式，使用Bech32m 编码。
bc1q 则是常见的版本0 见证地址开头，使用Bech32。两者都在Bitcoin 主网使用，不代表两条不同的BTC 链。
地址前缀只方便辨识，不能取代完整校验。也不能手动把bc1q 改成bc1p 来转换，应由支持相应设计的钱包生成。
SegWit 隔离见证建立见证版本及相关交易结构；Taproot 则利用版本1 定义新的输出与花费规则。
因此，Taproot 可以放在SegWit 的版本架构中理解，但不能将它与最初版本0 的具体功能混为一谈。
从UTXO角度看，资产依然是输出，花费时仍要符合授权条件。改变的是条件如何承诺、如何满足，以及资料如何被验证。
Tapscript 是BIP 342 定义的脚本规则，配合Taproot 的脚本路径使用Schnorr 验证，并调整部分操作码及限制。
Bitcoin 原本就能透过脚本表达特定花费条件，例如多方授权与时间限制。 Taproot 扩充了相关设计空间，但不代表Bitcoin 因此完整采用Ethereum相同的帐户、Gas 与执行模型。
若从智能合约角度理解，应先看要表达的条件与执行环境，而不是只因出现脚本就推论所有链功能相同。
检查钱包是否能建立Taproot 地址、签署其花费，并确认自己使用的硬体钱包或多签流程也支持所选方案。
「能发送到Taproot 地址」与「能管理并花费Taproot 资产」是不同能力，不要只看产品名称。
在Bitcoin 收款页取得对应地址，不手动更改格式。若使用硬体钱包，可在装置上核对地址。
确认发送端选择Bitcoin 主网，并接受接收端提供的完整地址。若平台不接受，先查官方文件，不要用删字或改前缀的方式尝试通过。
取得TxID，核对金额与输出。 Taproot 不会免除等待确认；若接收方是平台，仍须符合其入帐规则。
首次操作可依最低金额与费用安排适当测试，不需要为了名称较新而一次移动全部资产。
不需要因为升级就认定旧地址不能使用。若要把旧输出转入Taproot，仍须建立链上交易，支付当次费用。
是否调整，可依钱包相容性、未来花费需求及备份方式判断。特别是自订脚本或共同保管方案，除了保管金钥，也须确保找回资产所需的设定资料有妥善备份。
不是。它是Bitcoin 升级，使用的资产仍是BTC。
不是。它是Bitcoin 主网常见Taproot 地址形式，仍须核对完整地址与所选网路。
不会。它可减少特定条件揭露，但金额与交易关联等资料仍可能被分析。
不一定。要比较输入、输出、花费路径及费率，不能只看地址名称。
不会。需要相应的多方签署协议与钱包支持。
不必公开每条未使用脚本的全文，但仍需公开所使用的脚本及必要证明，不能视为完全隐藏。
不是。 Taproot 定义版本1 见证规则，与原始版本0 SegWit 的具体设计不同。
不能把Taproot 当成任意撤回交易的功能。花费与确认仍须遵循Bitcoin 规则。
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
浏览量
