ニュートラルなルール、ハードなコンセンサス、オープンな市場、そして許可のないイノベーションのためのケース
私が尊敬する多くの Bitcoin 関係者が BIP 110 を支持しています。彼らは、検証のアクセシビリティを維持し、ノードオペレーターを不要なコストやコンテンツから保護し、手頃な支払いを維持し、そして Bitcoin を汎用的なデータストレージではなく、サウンドマネーに集中させ続けることを望んでいます。これらは真剣な懸念事項です。私はその目的を共有します。しかし、その解決策については同意しません。(GitHub
この記事は、提案自体を批判するものであり、その背後にいる人々を批判するものではありません。私は善意を前提としています。Bitcoin が最も強固であるのは、敵を味方と誤解することなく、激しく意見を異にすることができるときです。
また、これはすべてのインスクリプション、トークン、ファイル、アプリケーションを擁護するものでもありません。中には、軽薄であったり、有害であったり、詐欺的なものもあるかもしれません。問題はより狭い範囲にあります。それは、現在有効で、手数料が支払われているトランザクションの争われている使用法を、コンセンサスを変更することで対処すべきかどうか、ということです。
以下のすべての理由が同じ重みを持つわけではなく、いくつかは互いに補強し合っています。この議論は累積的なものです。
BIP 110 の提案内容
この記事は、BIP 110 バージョン 1.0.0、すなわち「データ削減一時的ソフトフォーク」を扱います。これは、2026 年 6 月 25 日に Complete ステータスに進められました。BIP 3 において、Complete とは、著者が計画した作業を終了し、採用を推奨することを意味します。これは、Bitcoin がその提案を採用したことや、コミュニティがコンセンサスに達したことを意味するものではありません。BIP リポジトリは、公開が、提案が優れていること、コミュニティのコンセンサスを得ていること、または採用されようとしていることを確立するものではないことを明示的に述べています。(GitHub
約 1 年間のアクティブ期間中、BIP 110 は 7 つのコンセンサス制限を追加します。具体的には、新しい scriptPubKey を 34 バイトに制限し（OP_RETURN については 83 バイトの例外あり）、プッシュされるペイロードとスクリプト引数の witness アイテムの多くを 256 バイトに制限し、未定義の witness バージョンと Tapleaf バージョンの使用を禁止する（ただし、そのようなアウトプットの作成は引き続き許可）、Taproot アネックスを禁止し、Taproot コントロールブロックを 257 バイトに制限し、OP_SUCCESSx オペコードを含む Tapscript を拒否し、Tapscript 内での OP_IF または OP_NOTIF の実行を拒否します。(GitHub
この提案は、アクティベーション前に作成された未使用のトランザクションアウトプットを grandfather 条項で保護します。これは重要な安全策です。私は、BIP 110 が既存の Bitcoin を広範に没収するとは主張しません。私の異議はより狭い範囲にあります。それは、現在有効なトランザクション機能を将来に向けて削除し、アクティベーションをまたぐ稀な事前署名済みワークフローに影響を与え、技術的な選択肢を減らし、コンセンサス制限を使用して、それ以外は有効な使用のカテゴリーを思いとどまらせるという前例を作る可能性があることです。(GitHub
BIP 110 はまた、修正された BIP 9 デプロイメントを提案しています。BIP 9 で指定されている 95% のしきい値と比較して、55% のマイナーシグナリングしきい値を使用し、従来のタイムアウトと FAILED ステートを排除し、必須シグナリング期間を追加し、指定された高さまでに強制チェーン上でのロックインを保証し、52,416 アクティブブロック後に新しい EXPIRED ステートを追加します。(GitHub
他のソフトフォークと同様に、BIP 110 は中央当局によって強制されるものではありません。ユーザーは、どのソフトウェアとルールを強制するかを選択します。経済的に重要な参加者が実質的に異なるルールを強制し、圧力、不確実性、またはチェーンの分裂を生み出すときにリスクが発生します。
著者らは、リファレンス実装、テストベクトル、詳細な根拠、およびトレードオフについての率直な議論を提供しています。これらは、文書の実質的な強みです。この提案は、緊急性と一時的な期間が、より低いしきい値と意図的にシンプルで断固とした制限を正当化すると主張しています。私はその懸念と作業を尊重します。しかし、リスク計算については同意しません。(GitHub
I. ニュートラリティと第一原理
1. コンセンサスは Bitcoin の最も強力な介入手段です。 ソフトフォークは、以前のルールでは有効だった一部のブロックを、アップグレードされたノードにとって無効にします。その力は、明確で、深刻で、広く理解されている障害のために留保されるべきです。
2. それは確立されたコンセンサスの失敗の修復ではありません。 BIP 110 は、インフレーション、署名検証、二重支払い、または既知の重大なバグを修正するものではありません。それは争われている外部性とユースケースに対処するものであり、そのため、立証責任は特に高くあるべきです。
3. それは争われている判断をプロトコル法に格上げします。 この提案は、正当な使用と外部性に関する論争を、リレーポリシー、マイニングポリシー、および市場からコンセンサスの有効性へと移行させます。
4. Bitcoin は意図を読み取ることができません。 ネットワークは、バイトが画像、証明、コントラクト、メタデータ、認証レコード、または将来のアプリケーションを表すかどうかを知ることができません。
5. 構造的なプロキシは、 collateral リスクを生み出します。 意図が知り得ないため、この提案は、好ましくない目的と正当な目的の両方に役立つ可能性のある技術的形態を制限します。
6. 社会的メッセージは、コンセンサス変更の十分な根拠にはなりません。 仕様書は、アクティベーションをデータストレージが歓迎されないことを伝える方法として明示的に扱っています。コンセンサスは、主に不承認を表現するためではなく、説得力のある技術的または金銭的理由のために変更されるべきです。(GitHub
7. 不承認は無効性ではありません。 トランザクションは、些細で、投機的で、不快で、または無駄であっても、ルールに従い、包含に必要な手数料を支払うことができます。
8. それは、BIP 110 チェーン上の将来の経済的自由を狭めます。 アクティベーション前の UTXO は grandfather 条項で保護されていますが、アクティブ期間中に UTXO を作成するユーザーは、既存のコンセンサスよりも、それらを構成および使用するための有効な方法が少なくなります。
9. 許可のないシステムは、承認されていない実験を許容しなければなりません。 イノベーターに、構築する前に自分たちの使用が価値があることを証明するよう要求することは、許可のないイノベーションの意味を逆転させます。
10. それはプロトコル保守主義を逆さまにします。 ベースレイヤーでの保守主義は、保守的な使用哲学を支持するためにコンセンサスを変更することへの熱意ではなく、コンセンサスを変更することへの消極性を意味するべきです。
II. 立証責任は果たされていない
11. 「スパム」はコンセンサスのプリミティブではありません。 スパムとユーティリティを区別できるオペコードはありません。それらのラベルは人間の判断から生じます。
12. 「金銭的」と「非金銭的」はきれいに分離できません。 ペイメントチャネル、準備金の証明、カストディポリシー、スマートコントラクト、または決済コミットメントは、金融活動であると同時にデータでもあります。
13. 既知のユースケースは、設計空間の全体ではありません。 この提案は、既知のすべての金銭的ユースケースを保存すると述べています。イノベーションは、まだ知られていないものによって定義されます。
14. BIP 自体は、それが削除するノードの負担を定量化していません。 コストを説明していますが、関連する帯域幅、ストレージ、検証負荷、ハードウェアのしきい値、または獲得または喪失される可能性が高いノードオペレーターの数を見積もっていません。
15. それは分散化の利点を定量化していません。 BIP 110 が分散化を改善するという主張は、測定可能なモデルや目標と対になっていません。
16. それは支払いの軽減を定量化していません。 トランザクション手数料がどれだけ、どのくらいの期間下がるか、またはどれだけの支払いユーザーが利益を得るかを見積もっていません。
17. それは異なるコストを一つの診断に組み合わせています。 UTXO ステートの成長、初期同期の帯域幅、アーカイブストレージ、リレー負担、および検証時間は、異なる原因を持ち、異なる解決策を必要とする場合があります。
18. 緊急性は、運用上定義されるのではなく、主張されています。 この提案は、状況を緊急かつ危機的であると呼んでいますが、コンセンサス介入が必要となる客観的なしきい値を提供していません。
19. 過去のリレーポリシーの制限は、最適なコンセンサス制限の証明ではありません。 83 バイトのデフォルトは、不変のブロック有効性ルールになることなく、有用なポリシーである可能性があります。
20. 256 バイトのラインはヒューリスティックです。 その根拠は、部分的に圧縮画像サイズと大きな暗号整数に関連していますが、256 バイトが安全性とイノベーションの間の最適な境界であることを確立していません。(GitHub
III. 技術的範囲が広すぎる
21. 7 つの別個のコンセンサス変更がバンドルされています。 参加者は、ある制限を支持し、別の制限を拒否することはできません。彼らはパッケージ全体を受け入れるか拒否する必要があります。
22. 最も強い技術的懸念は、無関係な制限とバンドルされています。 大きな scriptPubKey は、UTXO ステートと検証コストを増加させる可能性があります。それが測定可能な危険を生み出すのであれば、それ自体で狭い範囲の提案に値し、6 つの追加制限を自動的にサポートするものではありません。(GitHub
23. 83 バイトの OP_RETURN ポリシーがコンセンサスになります。 これにより、設定可能なリレーおよびマイニングの優先事項が、ブロックの有効性ルールに変換されます。
24. 256 バイトの制限は、一般的なプリミティブを制約します。 これらは、プッシュされるペイロードとスクリプト引数の witness アイテムの広範なクラスを制限することにより、データストレージをターゲットにしています。
25. 未定義の witness バージョンと Tapleaf バージョンを使用することが無効になります。 これらのスペースは、将来のアップグレードのために予約されているため、今日では部分的に未使用です。
26. Taproot アネックスが無効になります。 BIP 341 は、将来の拡張のためにアネックスを予約しています。その意味が定義される前にユーザーがそれを使用すべきでないとしても、意図的なアップグレードパスを閉じるには、例外的な正当化が必要です。(GitHub
27. Taptree の深さが減少します。 257 バイトのコントロールブロックの上限は、明らかにされるスクリプトパスを 7 レベルに制限し、複雑なスクリプトツリーを制約する可能性があります。
28. OP_SUCCESSx は、実行されないブランチでも無効になります。 BIP 342 は、将来のソフトフォークのためのクリーンなアップグレードフックとしてこれらのオペコードを作成しました。(GitHub
29. 実行される OP_IF と OP_NOTIF が Tapscript で禁止されます。 著者らは、それらを冗長で一般的に悪用されると見なしていますが、実験的な使用法や Miniscript の効率性の可能性も認めています。
30. この提案は、スピードと引き換えに率直さを公然と受け入れています。 その根拠は、よりバランスの取れたアプローチにはより多くの開発とレビューが必要であり、より迅速な展開を目的としたよりシンプルな制限を選択すると述べています。緊急性は、コンセンサスコードにおける精度の代わりにはなりません。(GitHub
IV. 互換性と将来の選択肢を犠牲にする
31. 一度に複数のアップグレードパスを閉じます。 アネックス、将来の witness バージョン、将来の Tapleaf バージョン、および OP_SUCCESSx はすべて、Bitcoin の予約済み設計空間の一部です。(GitHub
32. 予約済みは役に立たないという意味ではありません。 それは、初期の設計者が、まだ出現していなかったニーズのために、オプション価値を意図的に保存したことを意味します。
33. 1 年間の閉鎖でも、開発タイムラインを混乱させる可能性があります。 著者らは、将来のソフトフォークには 1 年以上の調整が必要になると予想していますが、それは見積もりであり、保証ではありません。
34. BitVM スタイルの設計を複雑にする可能性があります。 仕様書は、コントロールブロックの制限が高度なオフチェーン契約を妨げる可能性があることを認めています。
35. Miniscript で生成された Tapleaf に影響を与える可能性があります。 この提案は、一部のコンパイラ出力に OP_IF が含まれる可能性があり、調整が必要になることを認めています。
36. 影響を受けるウォレットツールの変更が必要です。 後方互換性セクションは、ルールがアクティブな間、Miniscript コンパイラの修正が必要になると述べています。
37. 狭いながらも認められた資金アクセスのリスクを生み出します。 BIP は、アクティベーション後の UTXO が凍結されたり、予期せず使用されたりする可能性がある、稀な事前署名済み Taproot シナリオを率直に特定しています。
38. Grandfather 条項は価値がありますが、完全な絶縁ではありません。 アクティベーション前の UTXO は保護されていますが、デプロイメント中に影響を受けるアウトプットを作成または使用するワークフローは、依然として新しい制約に遭遇する可能性があります。
39. ユーザーは、影響を受ける可能性のある資金を移行するようアドバイスされています。 狭いクラスのユーザーであっても、移行を必要とする提案は、コストのかからないフィルターではありません。
40. 「既知のユースケースがない」ことは、安全性の証明ではありません。 プライベートシステム、未公開のコントラクト、実験的なウォレット、および将来のプロトコルは、完全に観察可能ではありません。(GitHub
V. 一時的なコンセンサスルールは依然として実際の複雑さを生み出す
41. 一時的なコンセンサスコードは、依然としてコンセンサスコードです。 それは、仕様化、実装、レビュー、テスト、デプロイ、監視、そして後に廃止される必要があります。
42. Grandfather 条項は、有効性を履歴依存にします。 同じ使用構造が、UTXO が作成された時期に応じて異なる扱いを受ける可能性があります。
43. 履歴依存のルールは、実装の複雑さを増加させます。 すべての実装は、関連する UTXO 作成高さを特定し、例外を同一に適用する必要があります。
44. アクティベーションは、1 つの重要な境界を作成します。 ソフトウェアと経済主体は、新しい制限がいつ開始されるかについて同意する必要があります。
45. 有効期限は、別の境界を作成します。 彼らはまた、制限がいつ終了し、以前に制限されていた動作が再び有効になるかについても同意する必要があります。
46. BIP 110 は新しい EXPIRED ステートを追加します。 これにより、使い慣れたデプロイメントステートマシンが新しいコンセンサス動作で拡張されます。
47. 従来の FAILED 結果を排除します。 提案されたデプロイメントは、通常の BIP 9 の方法で単純にタイムアウトすることはできません。
48. いくつかの調整ウィンドウを作成します。 自発的シグナリング、必須シグナリング、ロックイン、アクティベーション、および有効期限は、それぞれ逸脱の機会をもたらします。(GitHub
49. 一時的なルールは、永続的なアーティファクトを残す可能性があります。 ウォレットコード、運用手順、コントラクト、および機関のリスク管理は、デプロイメントよりも長持ちする変更を必要とする場合があります。
50. コンセンサスのブランチが増えると、バグの表面積が増えます。 テストベクトルは既知のリスクを軽減しますが、すべてのプライベートまたは将来の相互作用を列挙することはできません。
VI. 経済的およびセキュリティへの影響は不確かである
51. ノードの外部性は現実的ですが、不均一です。 すべての完全検証ノードはブロックをダウンロードして検証する必要がありますが、プルーニングされたノードは古い生のブロックデータを破棄し、履歴ストレージを制限できます。関連するコストは個別に測定されるべきです。(Bitcoin Core
52. 手数料受取人の問題は、データトランザクションに固有のものではありません。 マイナーは手数料を徴収しますが、バリデーターはすべてのトランザクションに対していくつかのコストを負担します。規模は異なるかもしれませんが、基本的な構造は普遍的です。
53. 技術的コストは直接測定されるべきです。 特定の量のデータと検証作業に対して、リソースコストはバイト、ステート、計算、および帯域幅から発生し、観測者がトランザクションの目的を承認するかどうかからは発生しません。
54. BIP 110 はデータの埋め込みを排除できません。 仕様書は、ユーザーがデータをより小さな断片に分割したり、許可された構造内に偽装したりできることを認めています。(GitHub
55. 回避はトランザクションをより非効率にする可能性があります。 断片化または難読化されたエンコーディングは、より多くの構造を消費し、根本的な需要を排除することなく分析を複雑にする可能性があります。
56. 手数料への影響はあいまいです。 ある使用を抑制すると、支払い手数料が下がり、総手数料収入が減少し、需要が他のエンコーディングにシフトし、またはこれら 3 つの組み合わせが生じる可能性があります。
57. 補助金が減少するにつれて、マイナー収入はより重要になります。 トランザクション手数料はブロック報酬の 1 つの要素であり、ブロック補助金は 210,000 ブロックごとに半減します。(Bitcoin Developer Docs
58. 総手数料需要の減少は、限界的にセキュリティを弱める可能性があります。 BIP 110 が総手数料需要を単に再配分するのではなく減少させる限り、他の条件が同じであれば、マイナー収入の減少はハッシュパワーをコミットするインセンティブを減らす可能性があります。
59. 多様な需要は、手数料市場をより回復力のあるものにすることができます。 支払い、チャネル、カストディシステム、金融アプリケーション、およびその他の使用は、同時にピークに達する必要はありません。
60. 仕様書はセキュリティのトレードオフをモデル化していません。 より安価な支払いとより低いノードコストを主張していますが、マイナー収入、ハッシュ投資、または長期的な手数料市場の深さへの可能性のある影響を見積もっていません。
VII. より良い市場とポリシーツールが存在する
61. Bitcoin はすでにコンテンツニュートラルな容量制約を持っています。 ブロック重量は、各ブロックのトランザクション容量に共通の制限を課します。(GitHub
62. 手数料はすでに限られたブロックスペースを配給しています。 ユーザーは入札によって緊急性を表明し、マイナーは自らのポリシーに基づいて有効なトランザクションを選択します。
63. ブロック制限と手数料市場は、ユーザーに目的の宣言を求めません。 トランザクションが十分に金銭的であるかどうかのセマンティックテストではなく、技術的な有効性とリソース制限を適用します。
64. リレーポリシーは、より強制力の低いツールであり続けます。 実装とノードオペレーターは、有効なブロックを再定義することなく、どの未確認トランザクションをリレーするかを選択できます。Bitcoin Core のデータキャリアポリシーは設定可能です。(GitHub
65. マイニングポリシーは依然として任意です。 マイナーは、すべての検証ノードにそれらを含むブロックを拒否することを強制することなく、自らのブロックテンプレートからトランザクションクラスを除外できます。
66. ポリシーは不完全ですが、不完全さは失敗ではありません。 マイナーへの直接提出は、リレーフィルターをバイパスできます。その制限は分析に値しますが、コンセンサスによる禁止への自動的な飛躍ではありません。
67. どのトランザクションも包含される権利を持っていません。 マイナーは自らのポリシーに基づいてトランザクションを拒否するかもしれませんが、以前は有効だったトランザクションをフォーク全体で無効にすることは、はるかに重大な行為です。
68. リソースの価格設定は、目的を分類することなく改善できます。 特定の構造が不均衡なコストを課す場合、Bitcoin はコンテンツニュートラルな制限、または測定可能なリソース使用に結びついた価格設定を研究できます。
69. プルーニングとオプショナルデータの設計は、継続的な研究に値します。 それらはすべての懸念を解決しないかもしれませんが、使用が歓迎されないことを信号することを部分的に意図したルールよりも、ストレージの負担により直接的に対処します。
70. BIP 自体は、ポリシーが一般的にスパムと戦うための正しい場所であることを認めています。 完全なフィルタリングを保証できないことは、それ自体でコンセンサスを使用しなければならないことを証明するものではありません。(GitHub
VIII. イノベーションと採用を阻害する
71. 冷却効果を生み出します。 現在有効な構造が、関連する使用を抑制するためにコンセンサスを通じて停止される可能性がある場合、開発者は Bitcoin を避けるかもしれません。
72. 既存のユースケースを特権化します。 「既知のすべての金銭的ユースケース」は現在を保護しますが、未来は保護しません。
73. 価値が発見される前にオプション価値を破壊します。 アップグレードフックの将来の最良の使用法は、まだ名前を持っていないかもしれません。
74. 安定した基盤は、長期的なコントラクトにとって重要です。 ウォレット、カストディシステム、ペイメントチャネル、および金融プロトコルは、有効なトランザクション構造が利用可能であり続けるという確信を必要とします。
75. スクリプトの設計空間を狭めます。 これにより、一部の構造がより大きく、より高価になり、洗練されなくなり、または一時的に不可能になる可能性があります。
76. 高度なコントラクト研究を遅らせる可能性があります。 BIP は、BitVM スタイルの作業がテストネットやサイドチェーンで待機または進行する必要があるかもしれないことを明示的に認めています。(GitHub
77. コンセンサスによって、実験を Bitcoin から遠ざけます。 テストネットとサイドチェーンは有用ですが、説得力のあるセキュリティケースなしに、ビルダーをベースレイヤーから追い出すべきではありません。
78. 将来のレイヤー 2 システムは、今日の未使用のフックに依存する可能性があります。 ベースレイヤーの選択肢は、頻繁なベースレイヤーのアクティビティを必要とせずに、スケールをサポートできます。
79. アプリケーションはお金を強化することができます。 より良いウォレット、カストディ、決済、クレジット、証券、および証明システムは、Bitcoin のユーティリティ、流動性、および需要を増加させる可能性があります。
80. Bitcoin は、お金とテクノロジーの間で選択する必要はありません。 その金銭的な強さは、安全なウォレット、コントラクト、カストディ、決済、およびイノベーションをサポートするオープンネットワークによって強化できます。
IX. アクティベーションメカニズムが攻撃的すぎる
81. 55% のしきい値は、BIP 9 からの大きな逸脱です。 BIP 9 は 95% のマイナー準備完了しきい値を指定しています。BIP 110 は 55% を提案しています。
82. 争われている制限は、より少ない自信ではなく、より多くの自信を要求するべきです。 一時的な期間は、調整の失敗を無害にするものではありません。
83. マイナーシグナリングは、すべての Bitcoin ユーザーに関する国民投票ではありません。 ハッシュパワーはトランザクションを順序付け、保護しますが、保有者、取引所、ウォレット、マーチャント、カストディアン、および企業が、経済的に受け入れるルールと資産を決定します。
84. 必須シグナリングは、非参加の意味を変えます。 指定されたウィンドウの間、強制ノードはビット 4 をシグナリングしないブロックを拒否します。
85. デプロイメントは、強制チェーン上の所定の高さまでにロックインするように設計されています。 これは、自発的な準備を観察することよりも強力です。
86. FAILED ステートがないことは、クリーンなオフランプを排除します。 十分な自発的サポートを集めることができない提案は、強制された調整なしに期限切れになることができるべきです。(GitHub
87. アクティベーションメカニズムはコンセンサスを製造できません。 ソフトウェアの状態を調整することはできますが、社会的および経済的な合意を作り出すことはできません。
88. divergent な執行はネットワークを分割する可能性があります。 経済的に重要な参加者が互換性のない有効性ルールを適用する場合、結果はチェーンの分裂または長期にわたる不確実性になる可能性があります。
89. 一時的な分裂は些細なことではありません。 流動性、カストディ、決済、会計、およびユーザーの信頼はすべて影響を受ける可能性があります。
90. ハードなコンセンサスは Bitcoin の免疫システムです。 争われているユースケース制限のハードルを下げることは、対象となるデータストレージ問題よりも深刻なリスクを生み出す可能性があります。
X. 前例は標的よりも危険である
91. ルールは期限切れになりますが、前例は期限切れになりません。 将来のキャンペーンは、好ましくない有効な活動を抑制するためにコンセンサスが使用される可能性があるという証拠として BIP 110 を引用することができます。
92. 同じロジックを再利用できます。 ある派閥は、別の使用を非金銭的、有害、法的リスクがある、またはサポートされていないとラベル付けし、その排除を求めることができます。
93. 「サポートされていない使用」は拡張可能なカテゴリーです。 Bitcoin には、承認された範囲を恒久的に定義できる中央のプロダクトマネージャーはいません。
94. 目的に基づく境界は、政治的な境界になります。 有効性が正当な使用に関する判断に依存するようになると、プロトコルの議論は価値観と権力をめぐる争いになります。
95. 今日の標的は、明日の標的を制限しません。 プライバシーツール、新しいカストディ、ステーブルコインの決済、トークンシステム、企業アプリケーション、またはその他の不人気な使用が、同様の議論に直面する可能性があります。これは予測ではありません。これはガバナンスリスクです。
96. すべての制限は例外的なものとして提示されます。 前例は、まさにその提唱者がユニークだと考えるケースによって作成されます。
97. 社会的結束は希少な資産です。 文化的な論争をコンセンサスにエンコードすることは、より深刻な脅威のために必要な信頼と調整能力を消費する可能性があります。
98. すべての利害関係者は、意見を聞く権利があります。 開発者、ノードオペレーター、マイナー、保有者、ウォレット、取引所、カストディアン、企業、および機関は、すべて異なるリスクと責任を負っています。
99. リスクにさらされている資本は、支配権を付与することなく考慮に値する。 大口保有者、マイナー、取引所、カストディアン、企業はコンセンサスを所有していない。開発者やノード運営者が単独で行動する場合も同様である。持続可能な合意には、それらすべての間の調整が必要である。
100. 企業の参加は、それがビットコインを強化する場合に正当である。 企業は、法律の下で、規模、説明責任、資本、継続性をもって組織化することを可能にする。彼らは特別な権限に値しないが、世界的な通貨ネットワークの部外者として扱われるべきでもない。
XI. より良い道は存在する
101. 参加者は、コンセンサスを変更することなくデータストレージに反対できる。 それを使用、促進、インデックス化、中継、またはマイニングすることを拒否できる。
102. より厳格なソフトウェアの選択は自主的なままにできる。 競合する実装や設定可能なポリシーは、オープンネットワークの特徴であり、欠陥ではない。
103. 介入の前に測定を改善できる。 帯域幅、ストレージ、検証時間、UTXO の増加、手数料の置き換え、ノード経済学に関する再現可能なデータを公開する。
104. 測定可能なリソースコストを対象にできる。 実証されたサービス拒否や検証リスクに結びついた狭いルールは、認識された目的に部分的に結びついた広範なパッケージよりも防御可能である。
105. データ配置を改善できる。 より良いコミットメント、オプションのストレージ、プルーニング、レイヤー 2 アーキテクチャは、機能を維持しながら負担を軽減できる。
106. 手数料市場の透明性を改善できる。 より良いツールとモデルは、誰が支払い、誰がコストを負担し、どの使用が実際に支払いを押しのけるかを示すことができる。
107. 研究が続く間、アップグレードのフックを保持できる。 未使用の容量は、将来のソフトフォークの経路を保護する場合、必ずしも無駄ではない。
108. 圧倒的な一致を待つことができる。 待つことのコストは、不必要なフォークのコストと比較して測定されるべきである。緊急の説得力のある証拠と広範な合意がない場合、抑制がより安全なデフォルトである。
109. 同盟者を敵に変えることなく意見を異にすることができる。 BIP 110 の支持者はビットコインを守ろうとしている。敬意ある対応は、より大きなリスクを生み出す解決策を拒否しつつ、彼らの懸念に対処することである。
110. 提案された治療法は、病状よりも危険である。 BIP 110 はコンセンサスを使用して、有効な活動を狭め、将来の選択肢を制約し、展開を複雑にし、後で消去できない先例を確立するだろう。それにより、これは Bitcoin Iatrogenic Proposal となる。
中立性の守護者
ビットコインの強みは、全員があらゆる使用に同意することではない。その強みは、意見の相違が中立なルールとハードコンセンサスによって封じ込められることにある。
手数料はブロックスペースの価格を決める。ノードはポリシーを選択し、コンセンサスを検証する。マイナーはブロックを構築する。保有者は資本を配分する。開発者はコードを提案する。企業はインフラとアプリケーションを構築する。プロトコルの変更は、検証、セキュリティ、有用性、資本が圧倒的な一致に達した場合にのみ成立すべきである。
これは、すべてのインスクリプション、トークン、ファイル、アプリケーションを擁護するものではない。これは、市場が有用なものに報い、そうでないものを放棄する一方で、ビットコインがオープンであり続けることを可能にする中立なルールの擁護である。
ビットコインはベースレイヤーでは保守的であるべきである。私にとって、それは BIP 110 を拒否することを意味する。
ビットコインには純粋性の守護者は必要ない。
必要なのは中立性の守護者である。
主要な情報源
この分析は、主に BIP 110 バージョン 1.0.0、BIP 3 のプロセスとステータスの定義、BIP 9 のアクティベーション設計、BIP 141、341、342、Bitcoin Core のデータキャリアポリシードキュメント、Bitcoin Core のプルーニングドキュメント、および Bitcoin 開発者のブロック報酬リファレンスに基づいている。(GitHub
