OP_RETURNはBitcoin Scriptの命令で、コードは0x6aです。出力スクリプトの先頭に置くと、その出力は使用不能だと証明できます。どんな署名でも解除できません。命令の後にはデータを置けます。支払い先のアドレスや送金そのものではなく、取引にデータを記録する方法です。
Janaは追加の金額を誰かに送るのではなく、情報を取引に添えたいと考えています。そこで出力をOP_RETURNで始めます。その出力を使おうとすると、命令の実行によってスクリプトの検証が失敗します。署名の内容は関係ありません。出力スクリプトの技術的な名前はscriptPubKeyです。重要なのは位置と実行であり、埋め込まれたデータ中の同じバイトは、実行される命令ではありません。実行されない分岐内のOP_RETURNも、先頭のOP_RETURNとは異なります。取引のどこかに名前やバイトがあるだけでは判断できません。 [1] [5]
Bitcoin Coreは一般的な形をNULL_DATAに分類します。名前は「中身がない」という意味ではありません。Solver関数は先頭のOP_RETURNと、その後がIsPushOnlyを満たすこと、つまりデータを積む命令だけであることを確認します。内容は文章、短く計算された指紋であるhash、別のプロトコル用の記録などです。この分類は意味の正しさを認めるものではなく、ノードの待機場所への受け入れも保証しません。記録しただけでファイルの所有権、作者、法的効果が成立するわけでもなく、別の規則や証拠が必要です。 [3]
ノードは、まだ使われておらず今後使える出力の集合UTXOを管理します。OP_RETURNで始まる出力は、誰も使えないと事前に分かります。IsUnspendableが判定し、AddCoinはUTXOキャッシュに追加しません。節約するのは現在の作業用状態の管理であって、履歴全体の保存場所ではありません。確認済み取引はブロックに残り、データは転送され、履歴のコピーに保存されます。UTXOから外してもデータは消えません。また、この出力に金額を割り当ててもマイナーへの報酬にはなりません。使用不能となり、後から署名しても取り戻せません。 [2] [6] [1]
コンセンサスの規則は、ノードがどのブロックを有効と判断するかを定めます。一方、ローカルのポリシーは未確認取引の待機場所mempoolに何を入れ、中継し、採掘用に提案するかを選びます。自分の資源を守るためです。運営者ごとに設定は異なり、中継を拒否された取引を含むブロックがコンセンサスに違反するとは限りません。Mempoolに入っても確認の約束にはなりません。datacarriersizeはローカルのデータ容量枠を設定するもので、ブロックの有効性を変更したり、確認済みの内容を消したりする設定ではありません。 [8]
よく引用される以前の既定値では、データ用出力は1個、スクリプトは最大83バイトで、通常は内容80バイトと命令部分でした。Bitcoin Core 30.0はdatacarriersizeの既定値を100000にし、複数のデータ用出力を許可しました。コードは、それぞれのscriptPubKey全体の長さを共通の容量枠から差し引きます。メッセージ本体だけを数えるのではなく、外側のスクリプト長を示すフィールドは含めません。他の取引制限は残ります。そのため83に設定して戻るのは容量枠であり、以前の出力数制限ではありません。特定バージョンでの変更であって、ネットワーク全体の不変の法則ではありません。 [7] [4] [8]
Janaは文書そのものの代わりにhashをOP_RETURNへ入れられます。後日原本を示せば、同じ方法で指紋を再計算し、記録と比較できます。ただし、正確なファイルのバイト列と計算方法を保存する必要があります。指紋は文書の代わりにはなりません。一致しても、内容が真実であること、Janaが書いたこと、作成の正確な時刻は証明しません。公開記録は人物を結び付ける可能性もあり、ハッシュ化した情報でも自動的に非公開になるわけではありません。費用はメッセージの長さだけでなく、取引全体とブロック空間への需要で決まります。 [1] [8]
通常のアプリのメッセージには、重要で厳密に定められた例外があります。BIP 141は、ブロックの最初の取引coinbaseでOP_RETURNを使い、witness commitmentを記録します。これは取引検証に必要な付随データとの暗号学的な結び付きです。対応するscriptPubKeyは最低38バイトで、0x6a24aa21a9edから始まります。複数の出力が一致するなら、最大インデックス、つまり並び順で最後に一致する出力を選びます。ブロックにwitnessデータがなければcommitmentは任意です。ここでネットワークが確認するのは決められた構造であり、OP_RETURNの後ろにある任意の文章の真実性ではありません。 [9]
まず、どのクライアント、バージョン、設定の話かを確認します。次に実際の取引をデコードし、scriptPubKeyと、バイト列への符号化で周囲に付くフィールドを分けて考えます。mempool_datacarrier.pyは実装の境界例を示すテストですが、本記事は実行していません。BIP 110は追加のコンセンサス制限を提案しましたが、すでに終了した提案であり、datacarriersizeで有効になる規則ではありません。古いバージョンの説明も、全ノードや将来のバージョンで同じ動作を約束しません。設定内容と、取引が実際に確認されたことは別の情報です。 [10] [8] [11]
メッセージとスクリプトの長さが異なる理由
Janaは32バイトのデータを添えたいと考えます。単純なスクリプトはOP_RETURN、直接データを積む命令、データ本体で構成され、1 + 1 + 32 = 34バイトです。これがscriptPubKeyの長さです。金額とスクリプト長のフィールドは出力の符号化の別部分なので、この合計には含みません。データ容量枠はスクリプトを測り、手数料は取引全体で考えます。この例は何も送信せず、特定ノードでの受け入れを証明するものでもありません。
理解を深めるには、この項目とあわせて次もお読みください Bitcoin Script, トランザクション, UTXO, Mempool, Transaction Fees, BIP 110. 次の項目からも参照されています Runes, BRC-20.
01この出力にbitcoinを割り当てるとマイナーが受け取りますか？+
いいえ。使用不能と証明できる出力に割り当てた金額は使えなくなります。手数料は入力総額と全出力総額の差です。OP_RETURNに金額を割り当てても、その金額が自動的に手数料になるわけではありません。
02大きなメッセージを許可するとBitcoin全体の規則が変わりますか？+
必ずしもそうではありません。ノードはブロックの有効性を変えずに、ローカル方針を変えて多くの取引を中継できます。クライアントの設定、コンセンサス規則、実際の取引確認を区別する必要があります。