An ordinal envelope is a mechanism that allows Counterparty assets to be moved into and out of an individual satoshi via its Ordinal number.
From a technical perspective, this implementation is fairly straightforward. The challenge is convincing the Counterparty community that the rewards of integrating ord outweigh the potential risk to long term stability of the platform.
I’m writing this post to eventually publish as a CIP so will keep the same format for portability…
Abstract
Ordinal numbers are serial numbers for satoshis, assigned in the order in which they are mined, and preserved across transactions. They are described in Bitcoin BIP pr1408 and implemented with ord.
By integrating Ordinal numbers into the Counterparty federated node stack, they can be viewed through the lens of Counterparty’s account model as one-time use addresses.
This proposal covers at least one method for integration and starts the discussion of how Counterparty could view ord within the bitcoin ecosystem.
Motivation
Ordinal theory is similar to Counterparty in terms of platform consensus. They are both smart contracts deployed as node software rather than as on-chain logic (EVM). Users subscribe to the rules because it ensures all tokens are interoperable within the platform. Connecting the Ordinal and Counterparty ecosystems is prudent for increasing interoperability within the broader bitcoin ecosystem.
Rationale
Counterparty in its current state is not able to utilize the benefits of Bitcoin’s utxo model. By storing message information within a Bitcoin transaction it abstracts the transaction rules to the Counterparty layer. Storing assets within ordinal envelopes also gives Counterparty users the option to use their assets within the Ordinal ecosystem.
Important to note that when bridging the two platforms via the ordinal envelopes scheme, Ordinal software does not need to be Counterparty aware in the same way Bitcoin software is not Counterparty aware.
Overview
Ordinal envelopes are one-time use addresses that can be thought of as a sort of on-chain Opendime for assets. While an Opendime requires a user to destroy a physical device to send the contents, ordinal envelopes require a user to destroy a satoshi to send its contents. Once destroyed the Counterparty assets either complete their roundtrip journey back to the Counterparty platform or they’re sent to another envelope.
Ordinal envelopes as an address type
Counterparty interprets bitcoin addresses as account numbers. With the addition of enhanced sends (CIP9), addresses have been defined within the send message data rather than through the use of a dust output which allows for any arbitrary address scheme. Address type is identified by the first byte in the parameter.
Ordinal envelope addresses can be defined by the unique first byte ff followed by the ordinal number, ex. 2099994106992699. Envelope addresses are stored in the existing balances table in counterparty-lib. Assets can then be sent to envelope addresses using the existing enhanced send message type.
Emptying an envelope
While sending assets to an envelope does not require an additional message type, emptying an envelope does. The emptying tx requires rendering the envelope satoshi unspendable by adding it to the OP_RETURN output that contains the emptying tx message data (which includes the receiving address). Counterparty-lib can validate an emptying tx by identifying the ordinal number of the satoshi sent to the OP_RETURN output and searching for it in the balances table. All asset balances held by the envelope address are then transferred to the output address defined in the emptying tx message data.
Specification
TBD
API Changes
TBD
Implementation
TBD