最近のビットコイン界隈ではOrdinals (特に大量のトランザクションを引き起こすBRC-20ミント)を強く問題視するおなじみのクセモノ開発者：Luke Dash Jrを起点とする波乱が起きていますね。（昨夜のビットコイナー反省会でも軽く触れました）

思ったより日本にもOrdinalsユーザーが多いようで、日本語でもこの話題がバズってるのを今朝見かけています。あんまり普段は視界にいないので驚きでした。

その中でも、こちらの記事は初心者向けにわかりやすく書かれていて参考になります。特に賛成派・反対派の意見の整理は良いと思いました。バズっているのもさればこそって納得感がありますね。

【NFT】ordinalsの存続に影響のある討論が現在進行形【bitcoin開発のお話】

とはいえ、記事の後半は解像度が低いなと感じる部分があったり、著者のTwitter上の意見に反論したくなったのでここでマンスプさせてください（笑）

決してビットコインがハードフォークするとかそういう話ではないので、読んでみてわかりやすかった人はぜひ拡散してください。トレーダーとかもビットコインの仕組みにちょっと詳しいとエッジを見つけられたりしますよね。(Defiを戦場とするbotterなんかは実感してると思います)

・コンセンサスルールとノードポリシー

・Bitcoinは一枚岩ではない

・まとめ(FAQ)

ちなみに自分はOrdinals/BRC-20はあまり好きではありませんが、止めようとするのも無駄だと思いますし、今日はフラットに技術的な内容にとどめます。

コンセンサスルールとノードポリシー

いきなり専門用語を出してしまう癖があるのですが、ここを抑えておけば8割の人の誤解は解けそうだったので説明します。

まず、コンセンサスルールというのはブロックチェーンの各ノードすべてが合意する、「このようなトランザクションは無効(有効)である」「このようなブロックは無効(有効)である」というルールです。例えば急にビットコインを100万枚新規発行するブロックは無効だし、電子署名なしに他人のコインを使うトランザクションも原則的には無効です。たくさんあるノードはコンセンサスルールへの合意によって１つのブロックチェーンを共有できるわけです。

ハードフォークやソフトフォークという言葉はコンセンサスルールの変更について言われるもので、ルールをより厳しくするのがソフトフォーク、緩和するのがハードフォークです。例えば急にOP_Returnの上限を1KBにしたらブロックサイズの上限を10MBにしたら、以前からのノードは不正とみなすのでハードフォークが発生し得ます。(※１) これを回避しつつ大量に任意のデータを記録するためにInscriptionsではTapscriptの中にコードに擬態させたデータを含めています。(専門用語が難しくてごめんなさい。サイズが大きくても許容されるスマートコントラクトに見せかけて任意のデータを埋め込んでいるということです)

追記12/15) OP_Returnのサイズ制限もTXあたり１つまでという制限も、どちらもコンセンサスルールではなくポリシールールのようなので訂正しました。

一方、今回のLuke Dash Jrの「バグFix」プルリクエストはBitcoin Coreのコンセンサスルールではなく「ポリシー」と呼ばれるものに関するものです。ビットコインでは参加者が自由にノードを動かすことができ、ノードを使うことで他人がコンセンサスルールに違反していないか監視したり、誰かに問い合わせたり依頼することなく自身の残高確認や送金ができます。ポリシーとはノード単位で決めてもよい動作設定のことで、既定の数値はありますがユーザー自身で変更できるものが大半です。言うなれば「自分はこうする」「自分はこうありたい」というタイプの設定で、他のノードからすると「好きにしてろ」というものです。

今回の提案はトランザクションリレーポリシーに関するもので、データ量(今回の場合はコードに見せかけて埋め込まれている文字列) がむやみに大きなトランザクションを隣のノードから受け取ったときに他のノードに転送しない、という設定がInscriptionsを見落としていることを修正するものです。コンセンサスルールではないので、Inscriptionsのトランザクションをネットワーク全体的に不正とみなす(禁止する) 性質のものではありません。また、ブロックチェーンなので当然遡って適用されるものではないので、過去のInscriptionsがなくなるわけでもありません。仮にそうしようと思ったらおよそ１年分のトランザクションを巻き戻す必要がありますが、誰もそんなことに同意してくれないでしょう。受け取ったビットコインが消えてしまうのですから。

したがって、今回の変更提案はハードフォーク・ソフトフォークというようなネットワーク全体を巻き込む問題ではなく、本来は各ノード運営者に任されるべき設定値の問題です。そして個人的にはマイニングの健全性を損なってしまうリスクや副作用を懸念して反対意見に同調します。(※２)

細かいことを言うと今回挙動の修正が提案されている-datacarriersizeというオプションは周りのノードに転送するトランザクションのほか自身が採掘するブロックに含めるトランザクションにも適用されますが、採掘する側にとってはInscriptionsの手数料は良いことしかないのでマイナーがこの設定を使うことはないでしょう。

Bitcoinは一枚岩ではない

もう１つ指摘しておきたいところですが、Bitcoin Core開発者という肩書は所属を表すものではなく、Bitcoin Coreにコードが組み入れられた人という意味で使われます。なぜならBitcoin Coreのソフトウェアを触っている開発者たちは「公式」のようなものではなく、彼らの間でも意見が一致しない部分が多大にあるからです。

皮肉にもその最たる例の１つがLuke Dash Jrで、以前からかなり異色の開発者として有名でした。意見が合わないことで開発が進まないのが日常茶飯事なビットコイン開発の世界にとって、忖度なしに自分の意見を言える空気を作ってくれているような気さえしてきます。意見を言うだけで個人攻撃されるのは可哀想です。(また、おそらくCVEを提出したのはLukeじゃなくてそのへんのOrdinalsアンチだと思います。Lukeはそういうの好きじゃないと思うので)

したがってこれをきっかけにBitcoinの開発メンバーが離脱したり、政府の権威を使って進めているといった見方はさすがに違うんじゃないかと思います。(どちらかというとフェイクサトシによるスラップ訴訟やアンチによる脅迫問題のほうが過去にはBitcoin開発者の引退に繋がっています)

まとめ (FAQ)

・今回の「脆弱性修正」はInscriptionsを含むトランザクションやブロックを無効とするものではなく、ノード間のトランザクション伝播に関するもの。
仮に修正が行われても、トランザクションを直接マイナーに提出する方法で乗り越えられる。収益がほしいマイナーはこぞって受け付けるだろう。

・InscriptionsやBRC-20は消える？使えなくなる？→たぶん従来どおり使える。ウォレットがトランザクションを提出する先を変更すれば今回の修正内容は迂回可能。具体的にはマイナーに直接提出する方法が既にある。

・過去のInscriptionsはどうなる？→ブロックチェーンが巻き戻されるわけではないので影響はない。仮にバグ修正が実装されても迂回可能だから送れなくなるということもない。

・Bitcoinが分裂・分岐する？→今回の議論対象はコンセンサスルールではないので、ハードフォーク等は筋違いである。投機目的で便乗フォークが生まれる可能性はあるが、問題の解決にはならない。

・CVEが掲載されたから(国家の権威に頼っている/重大な問題である/修正される可能性が高い)→CVEの提出は誰でもできる。権威を根拠にBitcoinの開発方針が決定されることはない。仮に修正されても自分のノードにパッチを当てることを強制されるわけでもない(設定を使わなければ良い)。

※１…ソフトフォークでもチェーンが分岐するシナリオも考えられます。例えば特定のマイナーがOP_Returnに記載できるデータ量を小さくするソフトフォークを行ったり、Inscriptionsが入ったブロックに後続のブロックをつなげないケースを想定すると、そのマイナーが行ったことはソフトフォークですがチェーンが分岐し得ます。(既存のノードが選ぶ「最長のチェーン」とソフトフォークが選ぶ「こだわりのチェーン」が分岐するケース)

※２…ちなみにLukeの提案に対する反対意見で筋が良いものに「Inscriptionsの手数料収入を狙って大手のマイナーが別経路でトランザクションを受け付けるようになるとマイニングの自由競争が阻害されるほか手数料推定も難しくなる」というものがあります。