SegWit 修改了比特币规则，将签名等用于验证花费权限的数据，与计算交易基本标识符的部分分开，同时改变了区块容量的计量方式。对用户而言，付款可能更节省空间；对开发者而言，在一笔交易之上构建下一笔交易更加可靠。
发送时，钱包会指定使用哪些之前收到的资金，以及为收款人和可能返还给你的找零生成哪些新金额。它还必须证明有权花费这些资金。签名和其他验证数据就承担这个任务。SegWit 将它们放在名为 witness 的部分中。这里的 witness 指满足花费条件的证据，不是见证付款的某个人。数据没有被丢弃，也没有移到比特币之外：执行 SegWit 规则的节点仍会检查它们。 [1]
钱包用 txid 跟踪付款，后续交易也通过它指明要花费哪笔资金。以前，改变某些签名数据就可能改变 txid，即使收款人和金额都没变。这让尚未确认的交易很难可靠衔接。SegWit 计算 txid 时不包含 witness，所以只改变 witness 不会改变 txid。要让整笔交易免受这一问题影响，所有输入都必须使用 SegWit；改变收款人或输入仍可能改变 txid。更稳定的引用也帮助了 Lightning Network，这是一种通过支付通道进行付款的网络。另一个标识符 wtxid 则包含 witness。 [1] [4]
SegWit 引入了重量，不再对所有字节一视同仁。一个基础数据字节占 4 个重量单位，一个额外的 witness 字节占 1 个单位。整个区块的上限是 4,000,000 个单位。例如，一笔交易有 100 个基础字节和额外 100 个 witness 字节，重量就是 500，虚拟大小为 125 vB。这个大小用来按所选 sat/vB 费率计算手续费。因此，节省多少取决于交易结构，区块空间的需求仍会影响费率。重量上限既不表示每个区块都有相同的兆字节大小，也不保证每笔 SegWit 付款都更便宜。 [1]
在比特币主网上，原生版本 0 的 SegWit 地址以 bc1q 开头。P2WPKH 和 P2WSH 区分两种花费条件：通常由密钥控制的付款，以及使用脚本、也就是一组规则的付款。SegWit 还可以封装在较早的 P2SH 格式中，地址以 3 开头；但单凭 3 不能证明它使用 SegWit。Taproot 使用 witness 版本 1 和 bc1p 地址。因此，bc1 前缀不只代表一种付款类型。日常使用时，应检查发送钱包是否支持相应格式，并核对完整收款地址；这些前缀本身都不承诺匿名性。 [1] [2] [3]
这项改动按 Soft Fork 设计，即与旧规则兼容的更严格规则。不过，旧节点自己并不会完整执行 SegWit 的新条件。区块的第一笔交易 coinbase 中有一项 witness commitment，通过密码学方式把 witness 绑定到区块。因此，签名不是完整验证时可以忽略的可选附件。BIP 141 也把重量写成基础大小的三倍加上总大小；虚拟大小则是重量除以四并向上取整。这些是对同一套计量方式的描述，不是两个不同的上限。 [1]
要获得更完整的理解，请将本词条与以下词条结合阅读： 交易, Transaction Fees, Lightning Network, Taproot. 反向关联还来自： 交易, Transaction Fees, Taproot, Lightning Network.