SegWit は、署名など支出の権利を確認するデータを、取引の基本的な識別子の計算に使う部分から分けた Bitcoin のルール変更です。ブロック容量の測り方も変えました。利用者にとってはブロック容量を節約できる支払いにつながる場合があり、開発者にとっては取引をつなげる際の信頼性向上につながります。
送信時、ウォレットは以前受け取ったどの資金を使い、受取人と、必要なら自分へのお釣りにどの金額を新しく作るか指定します。その資金を使う権利の証明も必要です。署名やその他の検証データがその役割を担います。SegWit はそれらを witness と呼ぶ部分に置きました。ここで witness は支出条件を満たす証拠を指し、支払いに立ち会う人ではありません。データを捨てたり Bitcoin の外へ移したりしたわけではなく、SegWit のルールを適用するノードは引き続き検証します。 [1]
ウォレットは txid で支払いを追跡します。後の取引も、その識別子を使って支出する資金を指定します。以前は、受取人や金額を変えなくても、一部の署名データを変えるだけで txid が変わることがありました。これは未承認の支払いをつなげる際の問題でした。SegWit は witness を含めずに txid を計算するため、witness だけの変更では変わりません。取引全体をこの問題から守るには、すべての入力が SegWit を使う必要があります。受取人や入力を変えれば、今でも txid は変わり得ます。安定した参照は、支払いチャネルを使う決済網 Lightning Network にも役立ちました。一方、もう一つの識別子 wtxid は witness を含みます。 [1] [4]
SegWit はすべてのバイトを同じに数える代わりに「重み」を導入しました。基本データの 1 バイトは 4 単位の重み、追加の witness データの 1 バイトは 1 単位です。ブロック全体の上限は 4,000,000 単位です。たとえば基本データ 100 バイトと追加の witness 100 バイトの取引は、重みが 500 単位、仮想サイズが 125 vB になります。このサイズから、選んだ sat/vB の料率で手数料を計算します。節約は取引の構成次第で、ブロック内の場所への需要は引き続き料率に影響します。重みの上限は、どのブロックも同じメガバイト数になることや、SegWit の支払いが必ず安いことを意味しません。 [1]
Bitcoin のメインネットでは、ネイティブなバージョン 0 の SegWit アドレスは bc1q で始まります。P2WPKH と P2WSH は、鍵で管理する一般的な支払いと、ルールの集合であるスクリプトを使う支払いという二つの支出条件を区別します。SegWit を従来の P2SH 形式で包むとアドレスは 3 で始まりますが、3 だけでは SegWit の証拠になりません。Taproot は witness バージョン 1 と bc1p アドレスを使います。つまり bc1 は単一の支払い形式ではありません。普段は送信側ウォレットの形式対応と受取人のアドレス全体を確認してください。どの先頭文字も、それだけで匿名性を約束しません。 [1] [2] [3]
変更は Soft Fork、つまり以前のルールと両立する厳格化として設計されました。ただし古いノードは SegWit の新しい条件を自分で完全に検証するわけではありません。Witness はブロック最初の coinbase 取引にある witness commitment によって、暗号学的にブロックへ結び付けられます。署名は完全な検証で無視してよい任意の添付ではないのです。BIP 141 は重みを「基本サイズの 3 倍に全体サイズを加えたもの」とも表します。仮想サイズは重みを 4 で割って切り上げた値です。同じ計上方法の説明であり、別々の二つの上限ではありません。 [1]
理解を深めるには、この項目とあわせて次もお読みください トランザクション, Transaction Fees, Lightning Network, Taproot. 次の項目からも参照されています トランザクション, Transaction Fees, Taproot, Lightning Network.