BRC-19

Pay to True Return

Attaching data to an unspendable output means the coins attached to it are gone for good, which some argue is the wrong way to think about Bitcoin. This offers a way to carry data on an output that can still be spent afterwards.

Ty Everett28 Mar 2023changed 14 Apr 20232 min read

Why: Data-storage outputs that can never be spent and hold no value don't count as real Bitcoin tokens, so this exists to make on-chain data outputs spendable and valuable instead.
What: BRC-19 is a script pattern for OP_RETURN data outputs that replaces OP_FALSE with OP_TRUE and requires at least one satoshi, so the output is a spendable token rather than dead data.
How: A developer builds the output script with OP_TRUE followed by OP_RETURN and the data pushes, and attaches at least one satoshi of value to the output.

What this lets you do

Store arbitrary data on-chain in an output that is spendable
Turn an old-style unspendable data output into a real token
Attach at least one satoshi to a data-carrying output
Avoid the fully-open redemption default by adding your own spending conditions

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-19 accurately, including what it depends on.

The specification

Read the original

Abstract

In one view of Bitcoin, only spendable output scripts with satoshis attached constitute valid Bitcoin tokens, because Bitcoin tokens are UTXOs. Since traditional BRC-18 scripts are not compatible with this view, we propose a methodology for creating OP_RETURN scripts that are spendable and contain satoshis. This provides a way for software to automatically convert non-compliant OP_RETURNs into proper Bitcoin tokens while encouraging developers to consider the spendability constraints that govern their tokens.

Motivation

Bitcoin is a token system, and as such, every output should be spendable and have value in satoshis. This fundamental principle ensures that Bitcoin remains a secure and reliable system that can be trusted by users around the world. However, traditional BRC-18 scripts, employing the OP_FALSE OP_RETURN pattern, are not compatible with this view.

OP_FALSE OP_RETURN outputs are non-spendable and carry no value, which means they cannot be considered tokens under this definition. This creates a problem for developers who want to store data on the blockchain using OP_RETURN, as it goes against the basic principles of the Bitcoin token system.

To address this issue, we propose a new methodology for creating OP_RETURN scripts that are spendable and contain satoshis. This provides a way for software to automatically convert non-compliant OP_RETURNs into proper Bitcoin tokens while encouraging developers to consider the spendability constraints that govern their tokens.

By adding the cost of one single satoshi and the fully-open spendability constraints to OP_RETURN outputs, developers will be encouraged to consider the actual constraints that govern their tokens. This will drive them towards script patterns that protect what their tokens represent and promote a more robust and secure token system for Bitcoin.

This standard offers a solution that maintains the fundamental principles of the Bitcoin token system while providing a practical way for developers to store data on the blockchain using OP_RETURN. By adopting this methodology, we can ensure that Bitcoin remains a secure and reliable system that can be trusted by users worldwide.

Specification

We specify the same script template as BRC-18, except that instead of OP_FALSE being the first opcode, it is replaced with OP_TRUE. We also stipulate that at least one satoshi must be locked in the output.

For example:

.lock
  TRUE RETURN
  <data1>
  <data2>
  <data3>

Risks and Limitations

Because BRC-18 implementers did not define the constraints under which their Bitcoin tokens would be unlocked, we have defined a fully-open system in which anyone can redeem these tokens. If implementers see this as a problem, they should consider being cognisant of the mechanisms that define the spendability constraints of their Bitcoin outputs.

Was this helpful?

Summary