OP_RETURN論争の重要な論点は？（ビットコイナー反省会 Ep. 103）【文字起こし】
前回の「ビットコイナー反省会」は、ご覧になられましたか？
個人的には、【モバイルビットコインウォレットに関するアンケート調査】結果が気になります（近日中に公開予定とのこと）。
こんにちは！yutaro です。
さっそくですが「BTCインサイト」本日のトピックスはこちら：
OP_RETURN論争の重要な論点は？（ビットコイナー反省会 Ep. 103）【文字起こし】
Knotsを選ぶ前に知っておきたい、5つのリスクと冷静な判断基準【よくある誤解】
【スポンサー】Jade Plus By Blockstreamのご紹介
BTCインサイトは、ビットコイン保有者向けの究極のハードウェアウォレットJade Plusに支援されています。
Jade PlusはBlockstreamがプロデュースする最新ハードウェアウォレットで、以下のような優れた機能や特徴を持っています。
オフライン環境でのエアギャップ送金や、ファームウェアのアップデートに対応。外部からの攻撃を完全に遮断。
仮想セキュアエレメントを採用し、ハードウェアウォレットが盗難されても物理的に秘密鍵を抽出するはできません。
正規品デバイスチェック機能を搭載し、ハードウェアの改造やサプライチェーン攻撃を防ぎます。
最新最高のビットコインセキュリティに加え、美しいデザインとUXを兼ね備えています。
Jade Plusは、BlockstreamのパートナーでもあるDiamond Handsが運営する Lightning Base オンラインショプで購入できます。
ビットコイン/ライトニング決済割引と国内匿名配送もご活用ください。
OP_RETURN論争の重要な論点は？（ビットコイナー反省会 Ep. 103）【文字起こし】
(※本記事は、ビットコイナー反省会YouTubeで公開された東さん、丈さん、規新さんによるセッション動画をもとに要約・編集したものです)
導入：東さんの問いかけから始まる
「今日の本題はOP_RETURNです。規新君、ざっくり全体の文脈説明お願いできますか？」
規新さんの解説：提案の発端と技術背景
Peter Todd氏がBitcoin Coreに提出したプルリクエストが発端。
対象は
OP_RETURNの容量制限（83バイト）を撤廃する提案。この制限は、ノードがスパム防止のために設定していたものであり、コンセンサスレイヤーではなくリレーポリシーに関するもの。
背景には、OrdinalやInscriptionによりビットコインにデータを書き込むブームが起き、UTXOセットがダストで溢れ始めた問題がある。
「直近2週間のトランザクションの43%がデータ書き込み系。送金目的ではない取引が半分以上を占めています」
丈さんの最初の疑問：「なにが問題なの？」
OP_RETURNは"アンスペンダブル"なためUTXOに影響しないはず。
「別にデータ書いても問題ないのでは？」というスタンス。
Taproot、いわゆるOrdinalsを経由した書き込みの方が悪質とすら言える、との議論へ発展。
「OP_RETURNに書かれるデータはUTXOセットを汚さない。だったら書き込ませれば？」
東さんの補足：「経済合理性と実用性のズレ」
データ量が大きい場合、セグウィット（Segwit）署名領域を使った方が手数料が安い。
一方、OP_RETURNは構造がシンプルなので小容量トークンなどに向く。
現実的には大多数のデータ書き込みが署名領域に流れている。
「どうせみんな安い方に流れる。制限撤廃しても従う理由がないから意味がないのでは？」
L2プロジェクト「Citrea」から見る視点：提案のきっかけ
L2プロジェクト”Citrea”は、データの一部をOP_RETURNに書き込んでいたが制限によりTaprootを併用していた。
「できれば全部OP_RETURNに入れたい」という要望から制限撤廃の提案が生まれた。
東さん：「健全なプレイヤーが望んでるなら、制限解除の議論は合理的にも見える」
マイナーへの直接依頼問題：不健全か否か？
東さん、規新さん：現状、マイナーに対して直接依頼している状況で、制限解除しないとパブリックmempool（メンプール）を使わず、マイナーへ直接依頼する割合が増えていくと、競争が発生し、小規模マイナーが不利になる。
丈さん：「それも自由市場。避けられない」
「マイナーと直接やりとりが当たり前になると、fee marketや推定モデルが歪む可能性がある」
各自の立場の整理
規新さん：最初から撤廃支持。「上限撤廃する方が健全」
丈さん：撤廃OK派。ただし「どっちでも良い」姿勢が近い
東さん：中長期的には撤廃賛成。ただし「なぜ今？なぜこの順番？」という推進プロセスへの違和感が強い
コア vs 他の実装：OSSとガバナンスの構造問題
東さん：「Knotsなど他の実装への関心が高まるのは当然の流れ」
丈さん：「不満があるならフォークして競争すればいい」
規新さん：「コンセンサス部分だけ抽出して軽量化すべき」
東さん：「ビットコインコアの優先順位、ガバナンス構造のみに信頼を置きすぎるのは危うい」
(※原文はコチラ)
Knotsを選ぶ前に知っておきたい、5つのリスクと冷静な判断基準【よくある誤解】
(※本記事は、Seth For Privacy || Activate CTV + CSFS氏のX投稿をもとに要約・編集したものです)
今回は、Knots移行を検討している方に向けて、Bitcoin Coreとの違い、主なリスクと判断ポイントを中立的にまとめました。
1. KnotsはCoreと99.999%同じコード
KnotsはBitcoin Coreのソフトフォークにすぎず、完全な別実装（btcdやlibbitcoin等）ではありません。
セキュリティ修正やバグ修正は基本的にCoreのアップストリームに依存しており、Knots独自の改善は限られています。
つまり、Knotsを使う場合でもCoreの進捗に依存し続ける構造にあることを理解すべきです。
2. 更新はCoreより遅れがち
過去のリリース履歴をみると、Knotsの更新はCoreに対して1週間〜3ヶ月程度遅延する傾向があります。
セキュリティ脆弱性が公開前にパッチ適用されない可能性もあり、脆弱性が放置されるリスクがあります。
3. Luke Dashjr氏が唯一のメンテナー
KnotsのGitHubはLuke氏がフルコントロールしており、他の開発者からのマージ実績はゼロ。
コントリビューター記録も無効化されており、コードレビューや牽制の仕組みが存在しません。
結果として、彼の判断ミスや悪意があっても誰も気づけないという構造的リスクをはらんでいます。
4. セキュリティ運用にも不安材料あり
過去には、Luke氏がGPG署名鍵の漏洩や大量のBTCをホットウォレットに保管した事例があり、セキュリティ意識に疑問符がついています。
「オープンソースだから安心」ではなく、誰がメンテしているかのチェックも重要です。
5. Knotsはスパムを依然として検証し、保存する
Knotsを使っても、ブロックにマイニングされたトランザクション（≒スパム含む）は全て検証し、保存されます。
差分が出るのはmempoolの扱い程度で、ディスクにOP_RETURN、Inscription、JPEG等が保存されることには変わりありません。
使いたいなら止めない、でも“盲目的に使う”のは危険
Knotsを選ぶ自由は、ビットコインの”permissionless（非許可性）”の本質です。
とはいえ、自分でコードを精査できないなら、今は控えるのが賢明かもしれません。
Knotsの利用者が増え、より多くのセキュリティ研究者がKnotsとCoreの差分をレビューすることには一定の価値があります。
結果的にバグの早期発見や、Coreにも波及する恩恵が期待できるからです。
ただし、「ノードは自分の責任で運用するもの」。
使う自由がある以上、「使う前に理解しておくべき責任」もあることをお忘れなく。
(※原文はコチラ)
🌀 その他のトピックス
⚡ 役立つ記事や特集
💎 DH関連リンク集 🙌
気に入っていただけましたか？
月7ドルで【DH Magazine Pro】に参加して、ビットコインの最前線と世界のトレンドを楽しみつつ、Diamond Handsの活動を支援していただける方を募集中です！
詳細は以下のPro版の内容紹介記事をご確認ください。
