Skip to main content

Bitcoin's Taproot, Ordinals, Runes and how on-chain and secure they really are

· 7 min read
Quentin Faidide

Lately, I've been working on collecting data about Bitcoin Ordinals and Runes. I've been surprised at the amount of articles in the crypto news ecosystem that had misleading claims about how these protocols works. As someone who spent some time diving into the lower level implementation details of it, I felt like I had to share what I learnt.

feel free to share this article or drop a message with your feedback.

TL;DR

  • Ordinal and Rune protocol inscribe data in the Bitcoin blockchain.
  • Bitcoin always had ways to store arbitrary data in transactions scripts.
  • Bitcoin Taproot update offers ways to spend that can be better for privacy, and a scripting language (tapscript).
  • Ordinal inscriptions tie data to Bitcoin dust using taproot script, by spending the dust in a transaction input and inscribing the file content simultaneously.
  • A transfer of an ordinal inscription happens on-chain and if you get a transfer of the Bitcoin dust to you, you effectively have Bitcoin validated ownership of that dust. By ordinal protocol users consensus, you also own the inscription content that was earlier spent with the dust.
  • Rune protocol inscribe Runestones (asset creation or transfer) data in transactions using an old fashioned way, it does not uses tapscript or taproot.
  • Rune, as opposed to ordinal inscriptions, do not rely on Bitcoin validation and security for ownership, but on third party to ensure that the transfer, etching or minting is valid.
  • As Runes get more popular, new wallet clients could be vulnerable to disagreements, exploits, and double spendings.
  • The Rune protocol has a lighter footprint than BRC-20.
  • The Rune protocol has more attack vectors than BRC-20.

A reminder on how Bitcoin works

To make it simple, Bitcoin is a protocol for validating blocks, which are a sequence of transaction, each having inputs and outputs. These inputs and outputs all bear a script. For inputs the script is spending a transaction previous output. For outputs, the script is telling how this output should be spent. An output script can also be unspendable. Based on these scripts, the Bitcoin clients and explorer deduce an address for the output owner if it can. The types of inputs and outputs are generally standardized Bitcoin script formats and match the type of address.

A bitcoin transaction

The Bitcoin protocol ensures through proof of work and consensus that no invalid spending can occur. It could be summarized as the miner spending considerable time and ressources to prove its worth to others, hence the name.

info

When you look at your Wallet balance, it's effectively the sum of the unspent outputs that belong to your addresses. You may not realize it but your wallet manages multiple addresses other that the one you provide to receive funds, mostly for change management and privacy reasons.

Nulldata to store arbitrary data in transactions

Since the beginning of Bitcoin, arbitrary data has been inscribed in transactions scripts (most commonly using what is called nulldata outputs). This data is not validated in any means, and limited to a certain size.

In 2021, the Taproot update was adopted that offered a new more convenient and cheaper way to store data.

Taproot, tapscript, and the new way to store data

Taproot update is mostly defined through these specifications:

  • Schnorr Signatures (BIP 340)
  • Taproot (BIP 341)
  • Tapscript (BIP 342)

They can be grossly summarized as defining a new way to define and spend outputs, with a special scripting language that bears more advanced features regarding privacy and not revealing ownership in very specific conditions.

Tapscript is this scripting languge. It is similar to the previous Bitcoin script, but has replaced some cryptography related features, and, has less limits on the amount of data to be uploaded in the scripts. People thefore started writing data in these scripts.

Miner also agreed to give a rebate to whoever was using the taproot spendings, to create an incentive for wallets and services to implement it. They probably did not anticiate it would mainly be used for NFTs.

Ordinals and inscriptions

Given the input-to-output structure of the Bitcoin transactions, it is possible to trace every smallest subdivion of Bitcoin dust (called satoshis) from its current owner to its miner. Numbering satoshis in the order they were mined allowed for users to use it in a non-fungible manner (NFTs), as opposed to the common conception that all Satoshis are equal and that a Bitcoin is the same as another. This is what is called "Ordinal theory".

When spending satoshis, ordinal protocol users agree that if some data in a specific format is shipped in the tapscript of an input, then the satoshi owner also owns the data inscribed.

Files inscribed can have metadata, file type, and content.

Runes and Runestones

Rune protocol relies on storing data structures in the transaction outputs, but (contrary to what I read around) is not using tapscript. It relies on the very old nulldata output type.

Runestones (Rune protocol messages), are aggregated from the nulldata output content of a single transaction, and are of three types:

  • Etching: defining a Rune (an asset), who can mine it, and how much (supply control).
  • Minting: issuance of assets according to etching rules.
  • Edict: transfer of a Rune.

An invalid runestone is called a Cenotaph and can be shipped in the blockchain. It means that the Bitcoin blockchain might actually contains transfer that validity depends on external clients. Therefore ownership is not effectively build into the blockchain as for BRC-20 tokens. This represents a potential attack vector as adoption grows.

Runes security concerns

In practice, over time, all blockchain protocol clients are either updated, forked or reimplemented. When this will happen, as there is no Rune official specification other than the Rust source code of the first wallet client, one may introduce a bug in its client that has a different subset of Cenotaph from other clients. This would mean that a valid transfer to a user or exchange is not valid to another individual, and could lead to some exploits or bugs. It also introduce a new supply chain attack vector channel through a less popular software client, and can be considered an off-chain protocol that uses on-chain data storage.

I've personally came across a few articles who claimed Runes was on-chain and just as secure as Bitcoin. I believe such statements are misleading.

Ordinal security concerns

Ordinals, as they rely on the Satoshis (Bitcoin dust) ownership, don't bear the same double spending or off-chain client risks. The only risk is that the consensus on the inscription format would see a disagreement and that some inscriptions would either exist or not for some clients. It does poses a small risk, as one could imagine a Shroedinger inscription to be sold invalid, or for any other ill intentioned or not purpose. Nonetheless the risk of fraud in the future feels very low with Ordinals, with maybe the higher risk being to pass under the radar of anti money laundering systems by shipping and expensive inscription into an inexpensive Satoshi.

info

The threats mentioned here actually materialized in many ways. The ordinal specification does not exists, and the developers sometimes changed the numbering system or the validity of inscriptions. They also changed critical tags for inscriptions like the pointer, which creates a situation in which an ordinal inscription is either bound to a satoshi or not depending on the ord client version. Therefore we already experienced the kind of situation where web services had different inscription numbers and validity, as they don't generally update simultaneously.

Spread the word

If you liked this article, feel free to share it on LinkedIn, send it to your friends, or review it. You are also welcome to report any error, share your feedback or drop a message to say hi!