Надписи

Надписи содержат sat c произвольным содержанием, создавая цифровые артефакты, характерные для биткоина, более известные как NFT. Надписи не требуют сайдчейна или отдельного токена.

Эти надписанные sats могут передаваться с помощью биткоин-транзакций, отправляться на биткоин-адреса и храниться в биткоин UTXO. Эти транзакции, адреса и UTXO во всех отношениях являются обычными биткойн-транзакциями, адресами и UTXOS, за исключением того, что для отправки отдельных sats, транзакции должны контролировать порядок и значение входов и выходов в соответствии с ordinal theory.

Модель содержания надписей соответствует модели содержания web. Надпись состоит из типа содержимого, известного также как тип-MIME, и самого содержимого, которое представляет собой байтовую строку. Это позволяет возвращать содержимое надписи с веб-сервера, а также создавать HTML-надписи, использующие и переделывающие содержимое других надписей.

Содержимое надписей полностью находится on-chain и хранится в скриптах taproot script-path spend. Скрипты taproot имеют очень мало ограничений на содержимое и дополнительно получают скидку свидетеля, что делает хранение содержимого надписей относительно экономичным.

Поскольку траты taproot script-path spend могут осуществляться только из существующих выходов taproot, надписи делаются с помощью двухфазной процедуры commit/reveal. Во-первых, в транзакции commit создается выход taproot, фиксирующий скрипт, содержащий содержимое надписи. Во-вторых, в транзакции reveal созданный транзакцией commit выход расходуется, раскрывая содержимое on-chain надписи.

Сериализация содержимого надписи осуществляется с помощью data pushes внутри неисполняемых условий, называемых "конвертами". Конверты состоят из OP_FALSE OP_IF … OP_ENDIF обертывающих любое количество data pushes. Поскольку конверты являются фактически no-ops, они не изменяют семантику скрипта, в который включены, и могут быть объединены с любым другим блокирующим скриптом.

Текстовая надпись, содержащая строку "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 указывает, что следующий push содержит тип содержимого, а OP_PUSH 0 - что последующие push-файлы содержат само содержимое. Для больших надписей необходимо использовать несколько push данных, так как одно из немногих ограничений taproot заключается в том, что размер отдельных push данных не может превышать 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-ответ, что позволяет обслуживать содержимое надписей на веб-сервере и просматривать его в браузере.

Поля

Надписи могут включать поля перед необязательным текстом. Каждое поле состоит из двух push данных - тега и значения.

Currently, there are six defined fields:

content_type, with a tag of 1, whose value is the MIME type of the body.
pointer, with a tag of 2, see pointer docs.
parent, with a tag of 3, see provenance.
metadata, with a tag of 5, see metadata.
metaprotocol, with a tag of 7, whose value is the metaprotocol identifier.
content_encoding, with a tag of 9, whose value is the encoding of the body.
delegate, with a tag of 11, see delegate.

Начало основного текста и конец полей обозначаются пустым вводом данных.

Нераспознанные метки интерпретируются по-разному в зависимости от того, четные они или нечетные, в соответствии с правилом "нормально быть нечетным", используемым в Lightning Network.

Четные метки используются для полей, которые могут повлиять на создание, первичное присвоение или перенос надписи. Таким образом, надписи с нераспознанными четными полями должны отображаться как "несвязанные", т.е. без указания местоположения.

Нечетные теги используются для полей, которые не влияют на создание, первоначальное назначение или передачу, например, дополнительные метаданные, и поэтому их можно игнорировать.

ID надписей

Надписи содержатся во входах транзакции раскрытия. Для их однозначной идентификации им присваивается ID вида:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

Часть перед i - это ID транзакции (txid) транзакции раскрытия. Число после i определяет индекс (начиная с 0) новых надписей, заносимых в транзакцию раскрытия.

Надписи могут располагаться либо в разных входах, либо в одном входе, либо в комбинации обоих вариантов. В любом случае порядок следования понятен, так как синтаксический анализатор будет последовательно просматривать входы и искать все надписи-"конверты".

Вход	Inscription Count	Indices
0	2	i0, i1
1	1	i2
2	3	i3, i4, i5
3	0
4	1	i6

Inscription Numbers

Inscriptions are assigned inscription numbers starting at zero, first by the order reveal transactions appear in blocks, and the order that reveal envelopes appear in those transactions.

Due to a historical bug in ord which cannot be fixed without changing a great many inscription numbers, inscriptions which are revealed and then immediately spent to fees are numbered as if they appear last in the block in which they are revealed.

Inscriptions which are cursed are numbered starting at negative one, counting down. Cursed inscriptions on and after the jubilee at block 824544 are vindicated, and are assigned positive inscription numbers.

Песочница

Надписи HTML и SVG находятся в песочнице для предотвращения ссылок на off-chain содержимое, что позволяет сохранить неизменяемость и самодостаточность надписей.

Это достигается за счет загрузки HTML и SVG-надписей внутри iframe с атрибутом sandbox, а также предоставления содержимого надписей с заголовками Content-Security-Policy.

Self-Reference

The content of the inscription with ID INSCRIPTION_ID must served from the URL path /content/<INSCRIPTION_ID>.

This allows inscriptions to retrieve their own inscription ID with:

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

If an inscription with ID X delegates to an inscription with ID Y, that is to say, if inscription X contains a delegate field with value Y, the content of inscription X must be served from the URL path /content/X, not /content/Y.

This allows delegating inscriptions to use their own inscription ID as a seed for generative delegate content.

Reinscriptions

Previously inscribed sats can be reinscribed with the --reinscribe command if the inscription is present in the wallet. This will only append an inscription to a sat, not change the initial inscription.

Reinscribe with satpoint: ord wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --satpoint <SATPOINT>

Reinscribe on a sat (requires sat index): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>

Ordinal Theory Handbook