Skip to content

Latest commit

 

History

History
104 lines (69 loc) · 4.44 KB

bip.mediawiki

File metadata and controls

104 lines (69 loc) · 4.44 KB

  BIP: ??
  Title: Standard for the inscription of metadata.
  Author: Piotr Swierzy <[email protected]>
          Bartosz Solka <[email protected]>
          Maciej Malik <[email protected]>
          Mariusz Jasuwienas <[email protected]>
  Comments-Summary: No comments yet.
  Comments-URI: ??
  Status: Draft
  Type: Informational
  Created: 2023-03-16
  License: PD

Table of Contents

Abstract

This document specifies a standard to additionally inscribe inscriptions with metadata

Motivation

Casey Rodarmor introduced in his Ordinal Theory Handbook https://docs.ordinals.com/inscriptions.html a mechanism to inscribe sats with arbitrary content, creating bitcoin-native digital artifacts. The proposed mechanism allows to inscribe an arbitrary sat with the content type, and the content itself.

This allows for the creation of ordinals that contain arbitrary data, but it does not define a standard to additionally append data describing the ordinal itself.

This standard describes how to additionally inscribe the sat with its metadata.

Description

Design

Inscriptions inscribe sats with arbitrary content, creating bitcoin-native digital artifacts, more commonly known as NFTs. Inscriptions do not require a sidechain or separate token.

The inscription content model described in Ordinal Theory Handbook https://docs.ordinals.com/inscriptions.html is that of the web. An inscription consists of a content type, also known as a MIME type, and the content itself, which is a byte string. This allows inscription content to be returned from a web server, and for creating HTML inscriptions that use and remix the content of other inscriptions.

Inscription content is entirely on-chain, stored in taproot script-path spend scripts. Taproot scripts have very few restrictions on their content, and additionally receive the witness discount, making inscription content storage relatively economical.

Based on this it is proposed to additionally optionally inscribe the sat with:

  • Metadata standard name -- defines the standard of the content structure which the metadata content follows.
  • Metadata content -- the metadata content itself. It should follow the defined metadata standard.
Since taproot script spends can only be made from existing taproot outputs, inscriptions are made using a two-phase commit/reveal procedure. First, in the commit transaction, a taproot output committing to a script containing the inscription content is created. Second, in the reveal transaction, the output created by the commit transaction is spent, revealing the inscription content on-chain.

Inscription content is serialized using data pushes within unexecuted conditionals, called "envelopes". Envelopes consist of an OP_FALSE OP_IF … OP_ENDIF wrapping any number of data pushes. Because envelopes are effectively no-ops, they do not change the semantics of the script in which they are included, and can be combined with any other locking script.

Specification

A metadata inscription is serialized as follows: 

OP_FALSE
OP_IF
  OP_PUSH "metadata"
  OP_1
  OP_PUSH "<metadata standard name>"
  OP_0
  OP_PUSH "<metadata content>"
OP_ENDIF

According to the Casey's Rodarmor Ordinal Theory Handbook. Metadata script should be placed after OP_ENDIF op code. Entire structure of the inscription with metadata should look as follows: 

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_1
  OP_PUSH "text/plain;charset=utf-8"
  OP_0
  OP_PUSH "Hello, world!"
OP_ENDIF
OP_FALSE
OP_IF
  OP_PUSH "metadata"
  OP_1
  OP_PUSH "<metadata standard name>"
  OP_0
  OP_PUSH "<metadata content>"
OP_ENDIF

This way, it stays fully backward compatible with already existing inscriptions and any other tools, like wallets.

Discussion

Rationale

First the string 

metadata
is pushed, to disambiguate inscriptions from other uses of envelopes. 

OP_1
indicates that the next push contains the metadata standard name which can be used by applications to understand how to interpret the metadata content, and OP_0 indicates that subsequent data pushes contain the metadata content itself. Multiple data pushes must be used for large inscriptions, as one of taproot's few restrictions is that individual data pushes may not be larger than 520 bytes.

References

See ordinal number theory https://github.com/casey/ord/edit/master/bip.mediawiki

For the Ordinal Theory Handbook see https://docs.ordinals.com/overview.html