分離した証人: ビットコインの価値を下げるソフトフォーク

導入

この記事では、まず Segregated Witness (SW) を検証し、それがどのようにして設計された目的を達成できなかったのか、それがどのようにして Bitcoin に負担をかける取り返しのつかない技術的負債となったのか、そしてそれがどのようにしてお金の代替性を脅かしているのかを説明します。この記事を読んだ後、マイナーはなぜ次のことをすべきかが明らかになるはずです。1) SegWit ソフトフォークの有効化を拒否する。 2) Bitcoin Core と交渉して、ブロック供給量を増やすためにハードフォークとして SegWit を実装するという新たな合意に達するか、ブロック供給量を増やすために市場主導の実装計画のサポートに切り替える。

1. 問題は何ですか?

ビットコインは多くの課題に直面しています。最高レベルでは、これらの課題にはトランザクションのスケーラビリティとスケーリングが含まれます。 Segregated Witness は交易延展性を解決し、容量を一度だけ増加させるとともに、第 2 層のスケーリング ソリューションの基盤を築くと主張しています。これらの主張が真実ではない理由を説明する前に、SegWit が解決しようとしている問題を確認しましょう。

1.1 トランザクションのスケーラビリティ

トランザクションのスケーラビリティを一言で言うと何でしょうか?

トランザクションの展性は、単一のトランザクションに対して複数の有効なトランザクション ID を生成する機能です。

どのように機能しますか?

ビットコインの取引は次のコンポーネントで構成されます。

図1: ビットコインの取引図

なぜこれが問題なのでしょうか?

攻撃者は次の方法でユーザーを欺くことができます。アリスはボブからの支払いを必要としており、ボブはトランザクション (txid-a) をブロードキャストします。アリスはボブのトランザクション (txid-a) を検出し、署名を無効にして別の ID (txid-b) を生成することでトランザクションを変更します。アリスは txid-b をネットワークにブロードキャストします。txid-b はマイナーによって txid-a の代わりに受信され、受け入れられる可能性があります。このような場合、アリスはボブに対して取引が成功しなかったと主張し、再度支払いを要求することができます。ボブはブロックチェーン上の txid-a をチェックしますが、最新のブロックが表示されず、エラーが発生したと結論付けます。ボブがフルノードを実行しておらず、ウォレットを監視していない場合、アリスにさらに資金を支払うように騙される可能性があります。アリスは、ボブが何が起こっているのか気づくまで、攻撃を何度も繰り返し再生することができます。

これは、ライトニング ネットワークで解決すべき特に重要な問題です。ライトニング ネットワークでは、相手方が古いチャネル状態を密かに公開していないことを確認するために、ネットワークを常に監視する必要があります (事実上、あなたに送金されるはずの資金が盗まれます)。一貫したインデックス値を使用すると、このプロセスが容易になります。

どうすれば解決できるでしょうか?

デジタル署名は、インデックス値の生成に使用されるデータから分離、つまり「分離」する必要があります。つまり、インデックス値は常に同じであり、デジタル署名を無効にすることなく変更することはできないため、攻撃は無効になります。

1.2 容量拡張

ビットコインの現在のオンチェーン スケーリングの問題は、10 分ごとに生成されるブロックのサイズが最大 1 MB に制限されているという事実を指します。この制限により、ブロックに「含められる」トランザクションの数には制限があり、決済ネットワーク上で実行できるオンチェーン トランザクションの量に厳しい上限が設定されます。

この障壁は、ビットコインのユーザーベースとともにオンチェーントランザクションの需要が増加するにつれて問題になってきました (図 2)。 2016 年には、この制限が繰り返し発生したため、オンチェーン取引手数料が 213% 上昇し (図 3)、定期的な取引のバックログが一般的になりました。何も変わらなければ、この傾向はさらに悪化すると予想されます。このバックログの影響の 1 つは、ビットコインの消費者向けサービスに深刻な混乱が生じることです。これらのサービスの多くは、トランザクションがブロックに含まれないという同じ問題に関する多数のユーザー サポート チケットを受け取ったと報告しています。

オンチェーントランザクションの容量を増やすには、単一の変数を変更するだけでは不十分です。プロトコルにこのような変更を加えるには、ネットワークの「フォーク」が必要です。これにより、ブロックチェーンの履歴が特定の時点で分岐し、古いルールをサポートするブランチが放棄され、新しいルールをサポートするブランチが優先されます。

一部のユーザーが他のネットワークとは異なるプロトコルのソフトウェア バージョンを実行している場合、ネットワーク フォークが突然発生する可能性があります。また、フォークを回避するために、ネットワーク全体が他のピアからソフトウェアをアップグレードできるように事前に計画することもできます。 Bitcoin XT、Bitcoin Classic、Bitcoin Unlimited などの競合クライアントは、過半数のハッシュレートのサポートを獲得した後にハードフォークをトリガーできます。

二次署名ハッシュ

方法が何であれ、オンチェーンのスケーラビリティを脅かすより重大な問題が存在します。それは、二次署名ハッシュです。明確に言えば、この問題は 1MB のブロック サイズですでに存在していますが、ブロックが大きくなるとさらに深刻な問題になる可能性があります。

二次署名ハッシュ問題を一言で表すと何になりますか?

トランザクションの検証に必要な作業は、入力数に応じて関数 O(n²) で増加します。 （例：二次成長）

なぜこれが問題なのでしょうか?

特定のトランザクションは、多数の入力と出力を含むように設計される可能性があり、マイナーとフルノードは検証に大量の CPU 作業を費やす必要があります (図 4)。マイナーにとって、この検証時間により次のブロックの作業が遅れ、不利になる可能性があります。最悪のシナリオは、トランザクションの検証時間が次のブロックのマイニングの目標である 10 分を超えることです。フルノードは、トランザクションを検証せずにマイニングし、ネットワークのコンセンサスルールを損なわない限り、検証を完了せずにブロックを伝播しないため、これはマイナーとネットワーク全体に対するサービス拒否攻撃を開始するために使用される可能性があります。この攻撃はブロックが大きくなるにつれて悪化し、二次署名ハッシュを使用して、より多くの、またはより大きな悪意のあるトランザクションを収容できるようになります。

どのように機能しますか?

ハッシュされるデータの量が、追加のハッシュ操作を実行するたびに同じであれば、ハッシュの合計時間は直線的に増加します (表 1)。

ただし、追加のハッシュ操作あたりのデータ量が増加すると、ハッシュ操作の数が線形に増加しても、合計ハッシュ時間は 2 乗的に増加します (表 2)。 （表2）

Bitcoin では、各追加入力には (少なくとも) 1 つの追加ハッシュ操作が必要ですが、各追加入力によってトランザクションの全体的なサイズも増加し、そのため毎回ハッシュする必要があるデータの量も増加します。

どのように解決すればよいでしょうか?

BIP-143 、署名チェックを実行するときにデータをハッシュする方法を変更します。具体的には、入力値がシリアル化されてハッシュ化され（ハッシュ 1 と呼びます）、出力値が（ハッシュ 2 と呼びます）になります。各署名検証のハッシュデータは、[hash-1、hash-2、input_metadata、some_other_tx_metadata]です。ハッシュ 1 とハッシュ 2 はトランザクションがどんなに大きくなってもサイズが同じなので、毎回署名を検証して得られるデータのサイズはほぼ同じになり、線形スケーリングが実現されます。

Tom Zander 氏は、この問題を解決するための別のアプローチについて説明します。 Zander が提案した解決策は、 OP_CHECKSIG廃止し、新しいバージョンの OP_CHECKSIG (フォールバック NOP を使用) に置き換えることです。この新しいバージョンは、新しいインデックス値の計算に使用されたトランザクションの同じ領域 (例: 証明データを除いたすべてのデータ) に署名します。このデザインは現在開発中です。

これらの変更は、2 つの方法を採用した後に作成された新しい UTXO セットにのみ影響し、現在の UTXO セットには影響しないことに注意することが重要です。

2. 隔離された証人

2.1 仕様

Segregated Witness の説明では、5 つの BIP (141、142、143、144、145) が使用されます。BIP141 は SW 全般について説明します。 BIP142 は、SegWit のローカル pay-to-witness-public-key-hash (P2WPKH) の形式と、ローカル pay-to-witness-public-key-address (P2WSH) の形式を説明しています。 BIP143 では、SW でのトランザクション検証の詳細と、SW が二次署名ハッシュを解決する方法が紹介されています。 BIP144 では、SW の結果がネットワーク情報にもたらす変化について説明します。最後に、BIP145 では、Bitcoin Core クライアントの getblocktemplate JSON-RPC 呼び出しの変更について概説します。

この記事を書いている間に、SW の概要を高レベルで示す非常に優れたビデオが公開されました (図 5 を参照)。発見した問題を強調するために、以下に SW を詳しく示します。

https://youtu.be/DzBAG2Jp4bg （翻訳者注：動画の字幕はまだ翻訳されていません。翻訳後にyoukuにアップロードされます）

2.2 標準トランザクション

SW がどのように機能するかを理解するには、今日の標準的なトランザクションと比較する必要があります。検証する主なトランザクション タイプは、Pay to Public Key Hash ( P2PKH ) と Pay to Script ( P2SH ) の 2 つです。

図 6: 標準の P2PKH および P2SH トランザクション。 (A) トランザクション A の P2PKH 出力はトランザクション B によって消費され、トランザクション C によって消費される P2SH 出力を作成します。トランザクション B (B) とトランザクション C (C) は、スタック上の署名とハッシュを評価することによって検証されます。

P2PKH

図 6A は、P2PKH 出力と P2SH トランザクションへの標準入力を示しています。公開鍵スクリプトでは、標準の未使用出力に、署名スクリプトと組み合わせるとデジタル署名が有効かどうかを評価する一連の命令が含まれています (図 6B-C)。

未使用の P2PKH 出力の公開鍵スクリプトには次の内容が含まれます。

OP_DUP OP_HASH160 <pubeyHash> OP_EQUALVERIFY OP_CHECKSIG

トランザクションでは、誰かがこの出力を使用する場合、入力の署名スクリプト (図 6A-B) にある <signature> と <pubkey> を提供する必要があります。これにより、pubkey スクリプトの要件が満たされます。図 7 は、ノードがトランザクションを検証しようとしたときに、この出力がスタック上でどのように検証されるかを示しています。

図 7: P2PKH トランザクションのスクリプト検証 (図中の単語の説明、スタック: stack; スクリプト: script;)

最後の OP_CHECKSIG では、セカンダリ署名ハッシュの根本的な問題が見つかります。デフォルトでは、ほとんどのトランザクションには署名形式、具体的にはハッシュ タイプを持つ入力が含まれており、OP_CHECKSIG がスタックにプッシュされると、SIGHASH_ALL と呼ばれる検証メソッドがトリガーされます。

SIGHASH_ALLでは、トランザクションは次のように複製および変更されます (図 8)。

1. トランザクション内のすべての入力署名スクリプトが削除される

2. チェック対象の特定の入力については、署名スクリプトが、未使用の出力の公開鍵スクリプトであるサブスクリプトに置き換えられます（つまり、OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG）。

図8: トランザクションのコピーを作成し、入力の署名をチェックする際に二重SHA256ハッシュを計算する

このトランザクションのコピーは二重 SHA256 ハッシュ化されます。このハッシュは、支出者がデジタル署名し、署名スクリプトの入力 <signature> として提供したものです。ハッシュのデジタル署名を Pubkey と照合します。

检查签名（ Signature check(pubkey, signature, SHA256^2[transaction]) pubkey ，签名， ） SHA256 ^ 2 [交易] ）（译者注：原文：

チェックに合格すると、OP_CHECKSIG は TRUE 命令をスタックにプッシュし、トランザクションが受け入れられます。

このプロセスは、トランザクション内のすべての入力に対して繰り返す必要があり、各入力の二次署名を確認する作業が追加されます。

この問題は単なる理論上のものではなく、ビットコイン以前にも問題を引き起こしていたものです。ブロック 364,422 には、5,569 個の入力と 1 個の出力を持つ 1 つのトランザクション (999.651kB) が含まれています。トランザクションを検証するには約 1.2 GB のデータをハッシュする必要があり、検証には合計で約 11 ～ 25 秒かかります。

P2SH

P2SH トランザクション (マルチ署名トランザクションに似ています) は、図 6 に示すように、少し異なる動作をします。P2SH トランザクションでは、支出者が署名スクリプトに引き換えスクリプトを提供します。このスクリプトは、ハッシュされると、未使用の出力の公開鍵スクリプトの引き換えスクリプト ハッシュと一致します。この初期チェックを実行する pubkey スクリプトは次のとおりです。

OP_HASH160 <redeemScriptHash> OP_EQUAL

引き換えスクリプトは、入力の署名スクリプトで提供されます (図 6A)。デシリアライズされた引き換えスクリプトには、トランザクションが有効かどうかを判断するための一連の命令が含まれています (図 6C)。

引き換えスクリプトはさまざまな形式を採用できるため、ビットコインでサポートされているトランザクションの種類に非常に高い柔軟性が提供されます。最も一般的に使用される形式の 1 つは、マルチ署名トランザクションです。

 <OP_0> <署名_1> <署名_2> OP_2 <公開鍵_1> <公開鍵_2> <公開鍵_3> OP_3 OP_CHECKMULTISIG

この引き換えスクリプトでは、トランザクションが有効と見なされるためには、3 つの署名のうち 2 つが必要です。

このトランザクションを検証する特定の方法は、ちょっとしたハックであり、当時は物議を醸しましたが、技術的負債をあまり残さずに機能しました。古いノードは、引き換えスクリプトにある追加の検証手順を実行せず、引き換えスクリプトが未使用の出力の引き換えスクリプト ハッシュにハッシュされているかどうかのみをチェックします。ちなみに、おそらく BIP16 (P2SH を提案) の最も有害な遺産は、前例の名の下に攻撃を容易にするプロトコルを受け入れたことです。

2.3 分離された証人取引

SW は、トランザクション形式にマーカー、フラグ、および証人という新しいデータ フィールドを導入します。マーカーとフラグはそれぞれ 0 と 1 に設定されます (将来の拡張用)。 witness フィールドには、後で紹介する P2SH トランザクションの署名、公開鍵、witness スクリプトを含むシリアル化されたデータが含まれています。すべての署名データは witness フィールドに保持され、txid の計算には使用されないため、トランザクションは変更できなくなります。

現在のビットコインと同様に、SW トランザクションには、Pay to Witness 公開キーハッシュ (P2WPKH) と Pay to Witness スクリプトハッシュ (P2WSH) の 2 種類があり、それぞれ P2PKH トランザクションと P2SH トランザクションの置き換えに使用されます。 SW トランザクションには、P2SH-P2WPKH と P2SH-P2WSH という 2 つの他のタイプがあり、SW がアクティブ化されると、これら 2 つが主に使用されることになります (少なくとも最初は)。これらのトランザクションは、P2WPKH および P2WSH と同じ目的を達成しますが、引き換えスクリプト内にネストされています。その理由については以下で説明します。

P2WP

図 8 は、P2WPKH 出力を使用するトランザクションと、トランザクションが有効と見なされるために必要な検証手順を示しています。通常の P2PKH トランザクションとは異なり、公開鍵スクリプト (P2WPKH 出力内) には「証人プログラム」と呼ばれる特別な命令が含まれています。証人プログラムは、SW アップグレードされたクライアントに特定の種類のトランザクション検証をトリガーするように指示するデータ形式にすぎません。 P2PKH トランザクションをアクティブ化するには、証人プログラムで次の操作を行う必要があります。

OP_0 <20-byte-pubkey-hash>

ここで、OP_0 (または 0) はバージョン番号、<20-byte-pubkey-hash> は公開鍵 (図 8 の pubkeyHash) の RIPEMD-160 ハッシュ値 (HASH160) です。この証人プログラムは、標準の P2PKH トランザクションの公開鍵スクリプトに含まれるのと同じ操作に従ってトランザクションを検証します (図 6B)。署名と公開鍵は証人フィールドから取得されるため、トランザクションの署名スクリプトは空のままになります。

残念ながら、このタイプのトランザクションのネイティブ アドレス形式の作成は「遅れている」ため、通常のユーザーとウォレットは P2SH トランザクション内にネストされた P2WPKH アドレスを作成する必要があります。つまり、SW トランザクションは番号 3 から始まり、別の方法で準備および処理する必要があります (図 8)。

図8CはP2WSHトランザクションとその後の検証手順を示しています。 pubkey スクリプト内の witness プログラムの形式は次のとおりです。

OP_0 <32-byte-witnessScript-hash>

ここで、OP_0 (または 0) はバージョン番号、<32 バイト - witnessScript-hash> は、witness スクリプト (witnessScript とも呼ばれます、図 8C) の SHA256 ハッシュです。この証明プログラムは、署名と公開鍵の後の最後の項目として証人フィールドにある証人スクリプトに含まれる指示に従ってトランザクションを検証します。

図8: ローカルP2WPKH-P2WSH出力の使用

証人プログラムのハッシュ長によってトランザクションの種類と検証方法が決まることを強調することが重要です: P2WPKH (20 バイト) 対 P2WSH (32 バイト)。 P2WPKH と同様に、P2WSH にはネイティブのアドレス形式がないため、既存のウォレットと互換性を持たせるには、P2WSH を P2SH トランザクション内にネストする必要があります (後述)。明確に言うと、これはネイティブの P2WPKH または P2WSH トランザクションを実行できないことを意味するのではなく、現時点では特別なアドレス形式が欠けているだけです。

P2WPKH トランザクションを既存のウォレットと互換性を持たせるには、P2SH トランザクション内にネストする必要があります (図 9)。まず、P2WPKH と P2WSH で署名スクリプトを空にするのではなく、通常の BIP16 P2SH トランザクションと同様の引き換えスクリプトを含めます (図 6)。同様に、pubkey スクリプトには次の内容が含まれています。

OP_HASH160 <redeemScriptHash> OP_EQUAL

ノードはまず、トランザクション内の引き換えスクリプトが未使用出力の公開鍵スクリプトと等しいことを確認します (図 9B)。そうであれば、償還スクリプトはデシリアライズされて証人プログラムが生成されます。

OP_0 <20-byte-pubkey-hash>

証人フィールドから、署名と公開鍵が抽出され、標準のP2PKHスクリプトを使用して評価されます（図9C）

図9: P2SH-P2WPKH/P2WSHトランザクションの使用

P2SH-P2WPKH と同様に、P2SH-P2WSH トランザクションの公開鍵スクリプトには、引き換えスクリプトを検証するための手順が含まれています。

OP_HASH160 <redeemScriptHash> OP_EQUAL

署名スクリプト フィールドには引き換えスクリプトが含まれており、デシリアライズされると P2WSH 証人プログラムが含まれます。

OP_0 <32-byte-witnessScript-hash>

署名、公開鍵、および証人スクリプトは証人フィールドから解凍され、アップグレードされたノードによって検証される最終スクリプトが作成されます。アップグレードされていないノードは、P2SH-P2WPKH/P2WSH を誰でも使用できるトランザクションとして認識し、常に有効なものとして扱います。

2.4 SWの成功の側面

SW の利点を評価するときは、これらの利点は SW UTXO セットにのみ適用されることを覚えておく必要があります。宣伝されているメリットを実現するには、ユーザーが SW 出力を作成し、仕様に準拠する必要があります。これを念頭に置いて、SW の主な利点をいくつか紹介します。

ビットコインのオンチェーン取引能力の向上

署名データは証人フィールドに移動されるため、SW 出力を使用する場合は、非 SW 出力を使用する場合よりもブロック内で占めるスペースが少なくなります。非証人データのみが基本サイズにカウントされ、証人データは SW トランザクションの合計サイズを計算するときに除外されます (図 10)。トランザクション データのバイトあたりの料金を計算する場合、証人データは非証人データの 25% に相当します。たとえば、400 バイトの証人データには、100 バイトの非証人データと同じトランザクション料金が発生します。

非証人データ * 4 + 証人データ < 4MB

ブロック内のすべてのトランザクションが SW 出力で消費されると仮定すると、1MB のブロックは標準形式のトランザクションに比べて 1.7 ～ 2 倍のトランザクション数を伝送できるようになります。

図10: 標準トランザクションとSWトランザクションのトランザクション容量の違い

トランザクションの可塑性と二次署名ハッシュの排除

署名データを新しい証人フィールドに移動します。デジタル署名を変更しても、SW トランザクションの txid は変更されなくなります。スケーラビリティの修正により、未確認トランザクション (ライトニング ネットワークなど) を使用する第 2 層システムのセキュリティが強化されました。 SW は、署名チェックのためにトランザクション データをハッシュする方法も変更し、プロセスが 2 次ではなく線形に増加するようにします。

下位互換性。

2 週間の投票期間の後、95% のブロックが新しいルールへの切り替えの意向を示した後に、SW の採用が開始されます。このソフトフォークが有効化されると、アップグレードされていないノードとの下位互換性が確保されます。 SW 機能を利用したいユーザーは、非 SW トランザクションを無効にするリスクなしに、自由に SW 機能を利用できます。さらに、SW はビットコインのスクリプト言語をアップグレードするための基盤を築き、シュノア署名やマーケライズド抽象構文木 (MAST) への道を開きます。これらはどちらもエキサイティングで歓迎すべき進歩です。

SW の利点のより完全なリストは、Bitcoin Core の Web サイトでご覧いただけます。

3. 分離証人に関する問題

Segregated Witness は確かに Bitcoin ネットワークにいくつかの改善をもたらしますが、これらの利点がソフトフォークとしての SW の危険性を上回るのに十分ではない理由をここで検証します。

3.1 SWは証人データの増加を刺激するための経済的インセンティブ政策を策定する

SW では理論上、最大ブロック サイズ制限は約 4 MB です。ただし、これはブロック全体が非常に小さな「基本サイズ」で占められている場合にのみ当てはまります (たとえば、入力 1 つ、出力 1 つの P2WPKH)。実際には、現在の平均トランザクション サイズと実行されるトランザクションの種類に基づいて、ブロック サイズの制限は、SW 後に最大 1.7 MB に制限されると予想されます。

(図 10: すべてのトランザクションが SW 未使用出力を使用すると仮定 - 非常に誇張した仮定)。

しかし、4 MB という理論上の制限によって重要な疑問が生じます。マイナーとフルノード オペレーターは、たとえトランザクション容量の約 40% しかサポートできない場合でも、システムが 4 MB の制限を処理できることを確認する必要があります。なぜ？悪意のある攻撃者は、経済的インセンティブを利用して、大規模で複雑な証人データではなく、小さな基本データを使用してトランザクションを設計するためです。この問題は、証人スクリプト (つまり、P2SH-P2WSH または P2SH-P2WSH) のスクリプト サイズ制限が通常の P2SH 引き換えスクリプト (つまり、520 バイトから 3,600 バイト [ポリシー] または 10,000 バイト [コンセンサス]) よりも高いという事実によってさらに悪化します。これらの潜在的な問題は、将来的にブロック サイズの制限が増加するにつれてさらに悪化するだけであり、たとえば、最大 2 MB の基本データ サイズでは、8 MB の悪意のあるブロックが作成される可能性があります。この問題はスケーラビリティを妨げ、将来の容量増加を困難にします。

3.2 SWは解決しようとした問題に適切に対処できなかった

ソフトフォークによって SW が有効化されると、ビットコインには実質的に 2 種類の UTXO (非 SW UTXO と SW UTXO) が存在することになり、それぞれセキュリティと経済特性が異なります。線形署名ハッシュとスケーラビリティ修正は、SW UTXO にのみ使用できます。最も深刻なのは、非 SW UTXO の成長に対して強制力のある制約が存在しないことです。これは、ネットワーク (アップグレードされたノードであっても) が、ソフトフォーク前に存在していた、またはソフトフォーク後に作成された非 SW 出力のトランザクションの展性や二次署名ハッシュに対して依然として脆弱であることを意味します。

ソフトフォークの強制力が欠如しているため、ビットコインのユーザーと開発者は、SW が防ぐのとまったく同じ種類の攻撃に対して脆弱な状態になります。非 SW 出力を使用すると SW 出力よりもコストがかかりますが、それでも意欲的な攻撃者に対する抑止力としては比較的弱いものとなります。

また、従来の UTXO の総数のうち何パーセントが SW 出力に移行されるかもわかりません。サトシのようなビットコインの長期保有者（彼が100万ビットコインを所有していると仮定）は、おそらく非SW出力でコインを維持するでしょう（彼らが移動した場合、それはサトシ対SWの重要な投票になります！）。これにより、複数のクラスの UTXO が焼却または盗難から保護される必要があるため、ビットコインの将来のソフトフォークとハードフォークはより困難になります。

重要な問題は、2 つの UTXO タイプが共存すると、将来的に開発者やマイナーが非 SW UTXO を破壊したくなる可能性があることです。これは根拠のない質問だと思う人もいるかもしれないが、この記事で指摘する必要があるのは、ビットコイン コアの有力者の意見である。例えば、グレッグ マクスウェル氏は「未拘束の UTXO は削除して使用不可にすべきだ」、ゼイモス氏は「破滅的なインフレを防ぐために、古いコインは盗まれる前に破壊すべきというのが暫定的なコンセンサスだ」と主張した。

SW 出力の安全特性は非 SW 出力の安全特性よりもわずかに優れているため、懲罰的措置を講じる十分な根拠となります。

セキュリティと経済性が異なる 2 つの UTXO タイプの存在も、ビットコインの代替性を悪化させます。マイナーと完全な検証ノードは、ブロードキャストしないこと、またはブロック内で 1 種類のトランザクションのみを使用することを決定できます。一方で、これは強制（つまり強制的なソフトフォーク）に向けた前向きな一歩ですが、古いウォレットやアップグレードされていないウォレットに資金を持っているビットコインの初心者ユーザーにとってはマイナス面です。さらに、Lightning Network などのプロジェクトでは、改変の可能性があるため、非 SW P2SH 出力 (つまり、マルチ署名 P2SH アドレス) を使用する双方向支払いチャネルの形成を拒否するのは当然のことです。本質的には、これはビットコインが生成される出力の種類に応じて、その額面価値が経済的に同じように扱われないことを意味します。

ソフトウェア開発においては、ユーザーが行動を変えてより優れたセキュリティ対策を採用するという仮定は、特にパッチが継続して拡張される場合、本質的に失敗する運命にあることが広く理解されています。 HTTPS の導入とそれに続く非常に遅い動作速度は、ほとんどの読者がよく知っている例です。

3.3 SWは開発者に、利益を保証することなく複雑な要件を満たすことを要求する

ソフトフォークである SW は、取り返しのつかない技術的負債を大量に伴い、開発者がユーザーの資金を永久に失う機会を何度も与えます。たとえば、P2SH-P2WPKH または P2SH-P2WSH アドレスの作成には、圧縮された公開鍵を厳密に使用する必要があり、そうしないと資金が回復不能に失われる可能性があります。同様に、資金の損失を防ぐために、SW トランザクションでは OP_IF、OP_NOTIF、OP_CHECKSIG、および OP_CHECKMULTISIG の使用を慎重に処理する必要があります。将来、一部の開発者が SW トランザクション形式の複雑さを十分に理解できずに、ユーザーの資金の損失を引き起こす可能性は否定できません。

優先順位の点では、SW は、Bitcoin 取引所 (BitPay、Coinbase、Blockchain.info など) が毎日受け取る主要な顧客サポート チケットに対するソリューションではありません。 SW を有効化しても、ビットコインのトランザクション容量が急激に増加するわけではありませんが、SW 出力トランザクションが使用されるにつれて、徐々に大きな割合を占めるようになります。さらに、トランザクションのバックログの頻繁な増加からもわかるように、オンチェーン トランザクションの需要の増加は、SW によって提供されるブロック供給の増加上限をはるかに超える可能性があります。

ブロック サイズ制限 (BBSI) を直接増やすハード フォークにより、多くのウォレットと SPV クライアントは、SW などの独自のソフトウェアを書き直すことなく、新しい容量の増加からすぐに恩恵を受けることができます。 SW とは異なり、BBSI を使用する場合、ビットコインを使用するアプリケーションはトランザクションの形式や署名を変更する必要がありません。

過去のビットコインのソフトフォークの経験に基づくと、アップグレードはエコシステム内で一定期間にわたって展開される傾向があります。本稿執筆時点では、アップグレードを公に約束している 78 の企業とプロジェクトのうち、SW と互換性があるのは 28 社 (36%) のみです。取引量が一定のまま増加し続けないと仮定すると、ビットコイン取引とネットワークユーザーがオンチェーンのコスト圧力を軽減するために使用したい容量の増加は、しばらくの間は感じられないでしょう。容量の増加と非 SW UTXO の増加の予測不可能性は、ユーザーの成長とセキュリティの両方の観点からビットコイン取引を見ると特に問題になります。対照的に、BBSI は即時かつ予測可能な容量増加を実現します。

SW アップグレードの自発性は、ゲーム理論における最初の発動者は誰かという問題によって影響を受けます。トランザクション署名を、一部のノードには見えない新しい証人フィールドに移動することはリスクのあるアップグレードであり、合理的なアクターは、最初に行動して他の人が資金を失ったり問題に遭遇したりするのを待つよりも、他の人に先にリスクを負わせることを好むでしょう。さらに、自発的な SW アップグレードは、ゲーム理論の「フリーライダー」問題にも悩まされます。他のユーザーがアップグレードしてデータを Witness フィールドに移動すると、アップグレードしないユーザーや SW トランザクションを使用しないユーザーもメリットを得ることができます。 SW がソフトフォークを通じて承認された場合、これらの要因により、ビットコインの取引容量と手数料はさらに予測不可能になります。

3.4 経済の歪みと価格統制

ソフトフォークとして、Segregated Witness は経済的インセンティブ ポリシーを変更し、ビットコインに影響を与える唯一の経済的要因であるブロック サイズ スペースを変更します。まず、大規模で複雑な P2WSH トランザクションの署名データ（つまり、UTXO データのトランザクション コストの 4 分の 1）を補助します。ただし、署名の証明は UTXO よりもコストがかかるため、計算コストの観点から正当化できません。割引自体は、科学的またはデータに基づいた推論に基づくものではなく、恣意的に決定されているようです。

第二に、ブロックスペースはビットコインの主要な経済資源の 1 つであり、市場におけるさまざまな金融派生商品が摩擦なく運営されるのを防ぐ、集中型のトップダウン計画です。 SW は、オンチェーントランザクションの 1 MB の容量制限を維持することを目的としたソフトフォークであり、すべてのビットコインユーザーにオンチェーン料金が発生します。取引手数料が上昇しています。手数料市場は、手数料を負担する必要のない当事者（開発者）によって作成された中心的な経済計画です。手数料はビットコインブロックサプライヤー（マイナー）によって徴収されます。これは「手数料市場」と呼ばれていますが、単なる市場です。経済史は一貫して、非市場要因が商品やサービスの供給を妨げると、その結果コストが消費者に転嫁されることを私たちに教えてきました。 SW をソフトフォークとして採用することは、この種の経済計画を肯定するさらなるプロトコル変更の悪い前例となります。

3.5 ソフトフォークのリスク

このセクションでは、ビットコインのプロトコルと経済に SegWit よりも大きな影響を与えることがあるソフトフォークについて、より広範に批判します。ソフトフォークは、ノードオペレーターの同意なしにフルノードのセキュリティを低下させます。 SW ソフトフォークは、ノードをアップグレードするか、SPV ノードにダウングレードしてセキュリティ損失を無条件に受け入れるかを強制します。

アップグレードされていないノードによって完全な検証ノードの数が減少すると、ビットコイン ネットワーク全体の整合性が低下します。これは、アップグレードされていないノードは、引き換えスクリプト ハッシュが未使用の出力の公開鍵スクリプト ハッシュと一致するかどうかを確認するための初期チェックのみを実行するためです。 P2WSH トランザクションの場合、償還スクリプトに無効な証明手順が含まれている可能性があります。これは、アップグレードされていないノードがそれを検証する方法を知らず、ノードがネットワーク上で無効なトランザクションを盲目的に継続することを意味します。

ソフトフォークである SW は脆弱です。コミュニティは変更（トランザクション容量の増加など）を望んでいますが、ソフトフォークを介してそれらの変更を実施するということは、マイナーがロビー活動の主要なターゲットになることを意味します（そして、すでにそうなっているのです）。この場合、ソフトフォークは変更が容易になるため、リスクが伴います。変化した性質が小さく、かつ広く有益であれば、それは望ましいことです。しかし、この文脈では、ビットコインのユーザー（つまり、マイナー以外の全員）は、このような急激な変化によって最も影響を受けるにもかかわらず、同意またはオプトアウトする機会がないため、ソフトフォークは悪いものです。それは、法学のルールを破り、厳格で時間のかかる法的手続きを回避して「法律を変える」人気のある国家元首のようなものだ。大衆は、こうした法改正の詳細を気にかけたり理解したりしないことが多いため、人気のない新しい指導者が権力を握るまでは、大衆にとって非常に危険であり、その頃には状況を逆転させるには遅すぎる。対照的に、ハードフォークを介して SegWit を有効にすると、マイナーだけでなくコミュニティ全体がプロトコルに加えられた変更を決定できるようになります。変更に明確に同意できないユーザーは、ソフトフォークを使用するのではなく、変更を採用しないことを明示的に選択できます。

3.6 一度有効化されたSWは元に戻すことはできず、ビットコインのコードベースに永久に残る必要がある。

SWによって生成された重要な欠陥がしばらくして発見され、それを撤回することを検討するのに十分深刻である場合、誰でもネイティブSW形式で出力を使用することができ、それが壊滅的な資金の損失につながります。

4。道路のフォーク

SWは、トランザクションのスケーラビリティを修正し、「第2層」を介してビットコイン拡張の基礎を築こうとします。そのため、SWサポーターはそれを「スケーリングソリューション」と呼びます。これは、ビットコインの現在の苦境に対する2つの矛盾する解決策につながります。

ビットコインコアスケーリングロードマップの支持者は、オンチェーントランザクション容量を制限して、より高い取引料金を奨励し、完全に検証するノードを実行するコストを削減する必要があると考えています。オンチェーンスケーリングに優先順位を付けることを好む人は、オンチェーン容量が増加してユーザーの成長を増やすことができ、完全に検証するノードを実行する分野は、鉱山労働者、企業、および機関の最大の財政的インセンティブを持つ人々に自然に移行すると考えています。人気のあるトーキングポイントの主張に反して、これはビットコインシステムの分散化された信頼のない性質を損なうものではありません。このシフトは、中本のコンセンサスによって意図されたものです。

図11：ノードのバランスへのサトシの影響、および消費者のSPVへの移行

Re：スケーラビリティ

このデザインは、完全なブロックチェーンを必要としない軽量クライアントの概要を示しています。デザインのPDFでは、簡素化された支払い確認と呼ばれます。軽量のクライアントは、トランザクションを送信および受信することができます。ブロックを生成することはできません。支払いを確認するためにノードを信頼する必要はなく、独自のトランザクションを確認できます。

軽量クライアントはまだ実装されていませんが、必要に応じて実装する計画です。現在、誰もが完全なネットワークノードを実行しています。

私は100kを超えるノードを決して持っていないことを期待していますが、おそらく少ないです。より多くのノードが結合する価値がない平衡に到達します。残りは軽量のクライアントであり、数百万人に数えられる可能性があります。

バランスサイジングの場合、多くのノードは、1つまたは2つのネットワークノードがLAN上に残りの農場に供給されるサーバーファームになります。

非常に明確なトレードオフがあります。ブロックサイズを小さく保つことにより、裕福な個人と機関のみがチェーン上の取引料を購入することができ、ユーザーは完全なノードを実行するコストを購入することができます。 Satoshiが予測したように、ブロックサイズを増やすことで、ユーザーは取引の代金を支払う余裕がありますが、裕福な個人または機関のみが完全に検証するノードを実行する余裕があります（図12）。

図12：サトシのビットコインの将来のネットワークトポロジに関する予測

スケーラビリティとトランザクション率

すべてのユーザーがネットワークノードである現在のシステムは、大規模な予想される構成ではありません。これは、独自のNNTPサーバーを実行している各usenetユーザーのようになります。

このデザインにより、ユーザーはユーザーになることができます。ノードを実行することがより負担がかかるほど、ノードが少なくなります。これらのノードが少なくなり、大きなサーバーファームが少なくなります。残りは、トランザクションのみを行い、ブロックを生成しないクライアントノードです。

引用：Bytemaster 2010年7月28日、08：59：42 PM

さらに、支払いが可能であることを確認するのに10分かかります。今日のクレジットカードをスワイプするのと同じくらい速くする必要があります。

ファーストフードマシンのスレッドをご覧ください。ここでは、支払いプロセッサが実際に非常に優れている（クレジットカードよりも低い詐欺率）、潜在的に10秒以下になるほど速く支払いを検証する方法をリストしました。あなたが私を信じていないか、それを望んでいないなら、私はあなたを説得しようとする時間がありません、ごめんなさい。

これらのビジョンの中には、まだ未知の要因があります。

1. Lightning Networkおよび/またはその他の第2層の支払い層は、チェーン上のトランザクションのボリュームを削減し、したがって料金を削減できます

2.フルノードを実行するコストは、ハードウェア、ソフトウェア、帯域幅が改善するにつれて大幅に低下する可能性があります

言い換えれば、LNは鎖でのトランザクションの量をわずかに減らすことができます。または、10GBブロックでフルノードを実行するコストは20年後には無視できる可能性があります。たぶん両方が真実です。

4.1料金市場とブロック容量市場

表向きは、ブロックサイズを約1MBにキャッピングすることを好む人は、ビットコインの分散型トポロジが劣化するかどうかを懸念しています。ただし、これは真実ではありません。これは、私たちが知る限り、十分に「分散化」されるために必要な最小数のノードのターゲットを計算できなかったためです。この定性的な議論は、草の根の議論として使用して、ブロックサイズの増加を拒否したり、反対することは不可能であるため、何も拒否したりすることができます。もちろん、これは同時に同意することは不可能です。

分散型シナリオの前に、経験的措置が欠けており、ブロックサイズを制約する理由としてこの議論を拒否しなければなりません。これは、鉱山労働者が取引手数料を最大化できるように、人工的にブロックスペースリソースを制限する可能性が高くなります。

もう1つのより合理的なオプションは、サプライチェーンの取引を鉱夫（ブロックキャパシティマーケット）によって調整して、供給と需要に基づいて各ブロックに請求される総取引料金を最適化できるようにすることです。これは、時間が経ち、取引量が増加するにつれて、限界チェーンの取引手数料を効果的に減らすことができることを意味します。時間と競争を伴うオンチェーン取引の価格は、特定のレベルの需要での限界供給コストに近づきます。

図13：自然に新たな市場ベースの取引手数料（ソース）に対する中本atoshiの影響（ソース）

総流通量は21,000,000ビットコインに達するでしょう。ブロックが採掘されると、ネットワーク全体のノードに配布され、その量は 4 年ごとに半分に削減されます。

最初の4年間: 10,500,000コイン

今後4年間: 5,250,000コイン

今後4年間: 2,625,000コイン

今後4年間: 1,312,000コイン

…等

ビットコインの量が枯渇した場合、システムは必要に応じて取引手数料をサポートできます。これはオープンな市場競争に基づいており、トランザクションを自由に処理するノードが常に存在する可能性があります。

サトシ・ナカモト

パスワードメーリングリスト

「cryptoqraphy」をメジャーに送信することで、登録解除… @ metzdowd.com

結論は

検疫証人は、8年間の歴史の中で最も根本的で無責任なプロトコルのビットコインの顔をアップグレードするものです。 SWソフトフォークの実装により、ビットコインマイナーは困難で不公平な立場になり、コミュニティコンセンサスや正直なトレードオフなしでビットコインプロトコルの複雑で物議を醸す変更を実行するように圧力をかけられます。コードの変更のスケールは些細なものとはほど遠いものであり、コードベースのほぼすべての部分がSWの影響を受けます。

ビットコインの取引能力の増加は大幅に遅れていますが、SWは、トランザクションのスケーラビリティとスケーラビリティに対する専門的かつ効果のないソリューションを表しています。ソフトフォークとして、SWはより多くの技術的責任をプロトコルに導入します。これは、設計目的を達成することができません。ハードフォークとして、真のオンチェーン拡張と組み合わせて、SWはトランザクションの延性と二次シグネチャハッシュハッシュを効果的に緩和できます。これらの各問題は、ビットコインの将来にとってはあまりにも重要です。ソフトフォークとしてSWに賭けることは、常にビットコインに縛られる荷物になります。

この記事の著者は、延性とスケーラビリティを修正するために一生懸命働くクリーニングテクノロジーソリューションは、恒久的な技術的債務を備えたビットコインプロトコルよりも優れていることを望んでいます。