Bitcoin (BTC) Taproot升级于区块709632激活,钱包支持保持可选

钱包与交易所面对的bc1p问题

比特币协议的升级能否惠及普通用户,最终取决于两类参与者:界面上提供Taproot选项的钱包,以及必须接受bc1p地址的交易所和硬件签名设备。Taproot是Bitcoin (BTC)协议的一次软分叉,于2021年在主网区块高度709632激活,引入了遵循版本1见证规则的Pay-to-Taproot(P2TR)输出。这次改动只影响币的花费方式,不改变持有人拥有的资产:收款方收到的仍是BTC,不存在独立的Taproot代币,比特币价格与供应时间表也完全不在此范围内。

该升级由三项相互配套的提案组成。BIP 340规定了secp256k1曲线上的Schnorr签名,这种代数结构与Bitcoin此前依赖的ECDSA不同,且天然适合多方签名协议。BIP 341定义了Taproot输出格式、其承诺结构以及花费规则。BIP 342又称Tapscript,规定了这类输出内部的脚本执行规则。三者彼此衔接,但各自描述的是不同层次,把它们当成一个单一功能是最常见的理解错误。

在地址层面,主网Taproot输出通常以bc1p开头,采用Bech32m编码;原生隔离见证版本0地址则以bc1q开头,使用Bech32编码。两者都运行在同一条区块链上,不存在第二个Bitcoin网络,手动修改前缀也不会带来任何转换。前缀依附于Segregated Witness的版本编号体系,该体系划分了带编号的见证版本,Taproot占据版本1。激活之后旧输出依然有效,迁移完全自愿:把币转入Taproot输出仍需支付一笔链上手续费。软分叉也没有触及Proof of Work共识层,这就是兼容性工作集中在钱包端而非协议本身的原因。

Key Path与Script Path各司其职

一个Taproot输出有两种花费方式,链上观察者看到的一切都由这条分界线决定。Key Path用一个对输出公钥校验的Schnorr签名来授权花费,不披露任何替代脚本。在协作型设计中,例如MuSig类的多方协议,多个参与者可以联合产出单一签名,链上看起来与单人持有者无异,链上分析难以可靠区分单独花费与协作花费。Script Path则适用于已承诺条件被触发的情况:花费者揭示所选脚本、提供满足条件的数据,并证明该脚本属于输出的承诺。未使用的分支保持隐藏,但被触发的脚本及其证明数据会公开出现在链上。

两种路径的典型用途因此不同:直接支付和协作式多方花费走Key Path,时间锁、备用条件及其他应急安排走Script Path。对任何正在转移资金的人而言,有两个误解必须澄清。其一,多签不会在激活后自动坍缩为一个签名,它需要合适的多方签名协议加上钱包支持,旧式多签中的币也不会被转换。其二,跨输入签名聚合同样不是本次升级自动提供的功能。至于隐私,Taproot减少了花费条件的披露,让不同设计收敛为外观一致的Key Path花费,但金额、输出结构和交易之间的关联依旧公开可分析,因此bc1p地址并非匿名保证。

手续费也并非一律更低。成本取决于交易的虚拟大小、所选的sat/vB费率以及内存池竞争情况,而创建Taproot输出的数据成本与后续花费它的数据成本并不相同,两个阶段必须放在一起评估。以两方托管安排为例:正常运行时双方通过Key Path协作签名,一个带时间锁的备用脚本则事先被承诺在输出里,只有协作失败时才会被揭示并执行。这一概念具有普适性,但密钥、脚本、备份和签名协议都必须正确搭建,效果才能真正成立。

钱包支持仍在决定普及节奏

协议层面的工作已经尘埃落定:BIP 341固定了输出、承诺与花费规则,运行现行共识规则的节点无需额外配置即可验证P2TR花费。尚未解决的是外围工具。一个能在Taproot地址收款的钱包,未必能签署Key Path花费,硬件设备或自定义多签方案也必须重建才能安全使用新路径。如今被归入Bitcoin DeFi的项目所依托的扩展脚本设计空间,以及后来承载Bitcoin Ordinals铭文的版本1见证结构,都建立在同一套规则之上。在签名器、硬件设备与充值平台就bc1p达成一致之前,采用率将保持自愿选择且分布不均。