碑文

碑文は任意のコンテンツをsatoshiに刻み込み、ビットコインネイティブなデジタルアーティファクト（一般的にNFTとして知られる）を作成します。碑文にはサイドチェーンや独立したトークンは必要ありません。

これらの碑文が刻まれたsatoshiは、ビットコイントランザクションを使用して転送し、ビットコインアドレスに送信し、ビットコインUTXOに保持することができます。これらのトランザクション、アドレス、UTXOは、個々のsatoshiを送信する際にオーディナルズ理論に従ってインプットとアウトプットの順序と価値を制御する必要があることを除いて、すべての点で通常のビットコイントランザクション、アドレス、UTXOです。

碑文のコンテンツモデルはウェブのものと同じです。碑文はコンテンツタイプ（MIMEタイプとも呼ばれる）とコンテンツ自体（バイト文字列）で構成されます。これにより、碑文のコンテンツをウェブサーバーから返すことができ、他の碑文のコンテンツを使用してリミックスするHTML碑文を作成することができます。

碑文のコンテンツは完全にオンチェーンで、taprootスクリプトパス支出スクリプトに格納されています。taprootスクリプトはコンテンツに対する制限が非常に少なく、さらにwitness割引を受けることで、碑文のコンテンツ保存を比較的経済的にします。

taproot script-path spendスクリプトは既存のtaproot出力からしか生成できないため、そのため、は2段階のcommit/revealプロセスを使用して刻印されます。まず、commitでは、銘文の内容を含むスクリプトに提出するtaproot出力を作成します。次に、reveal取引では、commit取引による出力を使用して、チェーン上の銘文の内容を表示します。

銘文の内容は、実行されていない条件のデータプッシュを使用してシリアル化され "エンベロープ"と呼ばれます。封筒はOP_FALSE OP_IF…OP_ENDIF任意の数のデータプッシュを構成し、ラップします。エンベロープは実際には空の操作なので、それらを含むスクリプトのセマンティクスは変更されません。となり、他のロックスクリプトと組み合わせて使用できます。

文字列「Hello,world！」を含むのテキスト銘文を以下のようにシリアル化されています：

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

まず文字列'ord'がプッシュされ、銘文と封筒の他の用途との曖昧さを解消します。

`OP_PUSH 1'は、次のプッシュにコンテンツタイプが含まれていることを示します。'OP_PUSH 0'は、後続のデータプッシュがコンテンツ自体を含むことを示す。の大規模な銘文は複数回のデータプッシュを使用しなければならない。taprootの少数の制限の一つは、単一のデータプッシュが520バイトを超えないことであります。

The inscription content is contained within the input of a reveal transaction, and the inscription is made on the first sat of its input if it has no pointer field. This sat can then be tracked using the familiar rules of ordinal theory, allowing it to be transferred, bought, sold, lost to fees, and recovered.

内容

銘文のデータモデルはHTTP応答のデータモデルであり、銘文がウェブサーバによってサービスされ、ウェブブラウザで閲覧することを可能にします。

フィールド

銘文には、オプションの本文の前にフィールドを含めることができます。各フィールドにはの2つのデータプッシュ、1つのラベルと1つの値。

現在、6つの定義されたフィールドがあります：

• content_type, with a tag of 1, whose value is the MIME type of the body.
• ポインタ、タグ2、詳細はポインタドキュメントを参照してください。
• 親、タグ3、詳細は出所を参照してください。
• メタデータ、タグ5、詳細はメタデータを参照してください。
• メタプロトコル、タグ7、値はメタプロトコル識別子です。
• content_encoding, with a tag of 9, whose value is the encoding of the body.
• デリゲート、タグ11、詳細はデリゲートを参照してください。

本文の先頭とフィールドの末尾には "空のデータ"でプッシュが表示されます。

認識できないラベルの解釈は、偶数か奇数かによって異なり、稲妻ネットワーク"は奇数"にすることができるというルールに従います。

ラベルさえも、作成、初期割り当て、または銘文の転送に影響を及ぼす可能性のあるフィールドのために使用されます。だから、識別できない銘文でも、フィールドも"未バインド"として表示されなければなりません。つまり、場所がありません。

奇数タグは、追加のメタデータなど、作成、初期フィールド、割り当て、または転送に影響を与えないために使用され、したがって、無視することが安全であることを選択します。

銘文の身分ID

銘文は取引を明らかにする入力に含まれている。彼らを一意に識別するために、彼らには以下の形式のIDが割り当てられています：

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

’i’の先頭部分は、トランザクションID（’txid’）である。iの後の数字はを定義します。新しい銘文は、取引で常に銘記されたインデックスの位置(0から開始)

銘文は、入力の中の異なる入力の中にあってもよく、同じ入力であってもよく、あるいは両者の組み合わせであってもよい。いずれにしても、パーサーは入力を連続的にチェックし、すべての銘文『封筒を検索するため、順序は明確です

Inscription Numbers

碑文には0から始まる碑文番号が割り当てられます。まずブロック内でのリベアルトランザクションの順序、次にそのトランザクション内でのリベアルエンベロープの順序によります。

多数の碑文番号を変更することなく修正できないordの歴史的なバグにより、公開されてすぐに手数料として使用された碑文は、公開されたブロック内で最後に表示されたかのように番号付けされます。

呪われた碑文は-1から始まって下方向にカウントされます。ブロック824544のジュビリー以降の呪われた碑文は名誉回復され、正の碑文番号が割り当てられます。

サンドボックス化

HTML と SVG 銘文はサンドボックス化され、チェーンの下の内容を引用しないようにして、銘文の不変性と独立性を保ちます。

これは、HTMLとSVGの銘文を iframes にロードし、銘文コンテンツを提供することによって行われる'sandbox'属性です。Content-Security-Policy”ヘッダ。

自己参照

碑文ID INSCRIPTION_ID を持つ碑文のコンテンツは、URLパス /content/<INSCRIPTION_ID> から提供される必要があります。

This allows inscriptions to retrieve their own inscription ID with:

let inscription_id = window.location.pathname.split("/").pop();

ID XのInstcriptionがID YのInscriptionに委譲する場合、つまりInscription Xに値Yを持つ委譲フィールドが含まれている場合、Inscription XのコンテンツはURLパス/content/Xから提供されなければならず、/content/Yからではありません。

これにより、委譲するInscriptionが自身のInscription IDを生成的な委譲コンテンツのシードとして使用することができます。

再刻印

以前に碑文が刻まれたsatは、碑文がウォレットにある場合、--reinscribe コマンドで再刻印することができます。これはsatに碑文を追加するのみで、初期の碑文を変更することはできません。

satpointでの再刻印: ord wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --satpoint <SATPOINT>

satでの再刻印 (satインデックスが必要): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>