Draft-BIP: Ordinal Numbers

Good afternoon list,

I've been working on a scheme of stable public identifiers that can be used for a variety of purposes.

The scheme is extremely simple and does not require protocol-level changes, but since different applications and wallets might use such identifiers, standardizing and publishing the scheme as a BIP seems warranted. The draft-BIP is hosted on GitHub, as well as reproduced below:

https://github.com/casey/ord/blob/master/bip.mediawiki

Briefly, newly mined satoshis are sequentially numbered in the order in which they are mined. These numbers are called "ordinal numbers" or "ordinals". When satoshis are spent in a transaction, the input satoshi ordinal numbers are assigned to output satoshis using a simple first-in-first-out algorithm.

At any time, the output that contains an ordinal can be determined, and the public key associated with that output can be used to sign challenges or perform actions related to the ordinal that it contains.

Such identifiers could be used for a variety of purposes, such as user accounts, PKI roots, or to issue stablecoins or NFTs. The scheme composes nicely with other Bitcoin applications, such as the Lightning Network or state chains.

I'm also working on an command-line tool that builds an index of ordinal ranges to answer queries about the whereabouts of a particular ordinal, or the ordinals contained in a particular output:

https://github.com/casey/ord/

The index is well tested but needs to be optimized before it can index the main chain in a reasonable amount of time and space. It's written in Rust, by myself and Liam Scalzulli.

I'm eager for feedback, both here, and on GitHub:

https://github.com/casey/ord/discussions/126

Best regards, Casey Rodarmor

PS After finishing the current draft, I discovered that a variation of this scheme was independently proposed a little under a decade ago by jl2012 on BitcoinTalk:

https://bitcointalk.org/index.php?topic=117224.0

---

<pre>
  BIP: ?
  Layer: Applications
  Title: Ordinal Numbers
  Author: Casey Rodarmor <casey@rodarmor•com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/casey/ord/discussions/126
  Status: Draft
  Type: Informational
  Created: 2022-02-02
  License: PD
</pre>

== Introduction ==

=== Abstract ===

This document defines a scheme for numbering and tracking satoshis across transactions. These numbers, "ordinal numbers" in the language of this document, can be used as a useful primitive for a diverse range of applications, including NFTs, reputation systems, and Lightning Network-compatible stablecoins.

=== Copyright ===

This work is placed in the public domain.

=== Motivation ===

Bitcoin has no notion of a stable, public account or identity. Addresses are single-use, and wallet accounts, while permanent, are not publicly visible. Additionally, the use of addresses or public keys as identifiers precludes private key rotation or transfer of ownership.

Many applications, some of which are detailed in this document, require stable, public identifiers tracking identity or ownership. This proposal is motivated by the desire to provide such a system of identifiers.

== Description ==

=== Design ===

Every satoshi is serially numbered, starting at 0, in the order in which it is mined. These numbers are termed "ordinal numbers", or "ordinals", as they are ordinal numbers in the mathematical sense. The word "ordinal" is nicely unambiguous, as it is not used elsewhere in the Bitcoin protocol[0].

The ordinal numbers of transaction inputs are transferred to outputs in first-in-first-out order, according to the size and order of the transactions inputs and outputs.

If a transaction is mined with the same transaction ID as outputs currently in the UTXO set, following the behavior of Bitcoin Core, the new transaction outputs displace the older UTXO set entries, destroying the ordinals contained in any unspent outputs of the first transaction.

For the purposes of the assignment algorithm, the coinbase transaction is considered to have an implicit input equal in size to the subsidy, followed by an input for every fee-paying transaction in the block, in the order that those transactions appear in the block. The implicit subsidy input carries the block's newly created ordinals. The implicit fee inputs carry the ordinals that were paid as fees in the block's transactions.

Underpaying the subsidy does not change the ordinal numbers of satoshis mined in subsequent blocks. Ordinals depend only on how many satoshis could have been mined, not how many actually were.

At any given time, the output in which an ordinal resides can be identified. The public key associated with this output can be used to sign messages, such as ownership challenges, concerning to the ordinals it contains. The specification of a standardized message format for such purposes is deferred to a later BIP.

Ordinal aware software should not mix outputs containing meaningful ordinals with outputs used for other purposes to avoid inadvertent loss of valuable ordinals, or privacy leaks allowing links between funds. For this reason, ordinal aware software using BIP-32 hierarchical deterministic key generation should use a key derivation path specific to ordinals.

The suggested key derivation path is `m/44'/7303780'/0'/0`. This suggested derivation path has not been standardized and may change in the future[1].

=== Specification ===

Ordinals are created and assigned with the following algorithm:

    # subsidy of block at given height
    def subsidy(height):
      return 50 * 100_000_000 >> int(height / 210_000)

    # first ordinal of subsidy of block at given height
    def first_ordinal(height):
      start = 0
      for height in range(height):
        start += subsidy(height)
      return start

    # assign ordinals in given block
    def assign_ordinals(block):
      first = first_ordinal(block.height)
      last = first + subsidy(block.height)
      coinbase_ordinals = list(range(first, last))

      for transaction in block.transactions[1:]:
        ordinals = []
        for input in transaction.inputs:
          ordinals.extend(input.ordinals)

        for output in transaction.outputs:
          output.ordinals = ordinals[:output.value]
          del ordinals[:output.value]

        coinbase_ordinals.extend(ordinals)

      for output in block.transaction[0].outputs:
        output.ordinals = coinbase_ordinals[:output.value]
        del coinbase_ordinals[:output.value]

=== Terminology and Notation ===

Ordinals may be written as the ordinal number followed by the Romance-language ordinal indicator °, for example 13°.

A satpoint may be used to indicate the location of an ordinal within an output. A satpoint consists of an outpoint, i.e., a transaction ID and output index, with the addition of the offset of the ordinal within that output. For example, if the ordinal in question is at offset 6 in the first output of a transaction can be written as:

    680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6

A slot may be used to indicate the output of an ordinal without referring to a transaction ID, by substituting the block height and transaction index within the block for the transaction ID. It is written as a dotted quad. For example, the ordinal at offset 100 in the output at offset 1, in the coinbase transaction of block 83 can be written as:

    83.0.1.100

Satoshis with ordinals that are not valuable or notable can be referred to as cardinal, as their identity does not matter, only the amount. A cardinal output is one whose ordinals are unimportant for the purpose at hand, for example an output used only to provide padding to avoid creating a transaction with an output below the dust limit.

== Discussion ==

=== Rationale ===

Ordinal numbers are designed to be orthogonal to other aspects of the Bitcoin protocol, and can thus be used in conjunction with other layer-one techniques and applications, even ones that were not designed with ordinal numbers in mind.

Ordinal satoshis can be secured using current and future script types. They can be held by single-signature wallets, multi-signature wallets, time-locked, and height-locked in all the usual ways.

This orthogonality also allows them to be used with layer-two applications. A stablecoin issuer can promise to allow redemption of specific ranges of ordinals for $1 United States dollar each. Lightning Network nodes can then be used to create a USD-denominated Lightning Network, using existing software with very modest modifications.

By assigning ordinal numbers to all satoshis without need for an explicit creation step, the anonymity set of ordinal number users is maximized.

Since an ordinal number has an output that contains it, and an output has a public key that controls it, the owner of an ordinal can respond to challenges by signing messages using the public key associated with the controlling UTXO. Additionally, an ordinal can change hands, or its private key can be rotated without a change of ownership, by transferring it to a new output.

Ordinals require no changes to blocks, transactions, or network protocols, and can thus be immediately adopted, or ignored, without impacting existing users.

Ordinals do not have an explicit on-chain footprint. However, a valid objection is that adoption of ordinals will increase demand for outputs, and thus increase the size of the UTXO set that full nodes must track. See the objections section below.

The ordinal number scheme is extremely simple. The specification above is 15 lines of code.

Ordinals are fairly assigned. They are not premined, and are assigned proportionally to existing bitcoin holders.

Ordinals are as granular as possible, as bitcoin is not capable of tracking ownership of sub-satoshi values.

=== Transfer and the Dust Limit ===

Any ordinal transfer can be accomplished in a single transaction, but the resulting transaction may contain outputs below the dust limit, and thus be non-standard and difficult to get included in a block. Consider a scenario where Alice owns an output containing the range of ordinals [0,10], the current dust limit is 5 satoshis, and Alice wishes to send send ordinals 4° and 6° to Bob, but retain ordinal 5°. Alice could construct a transaction with three outputs of size 5, 1, and 5, containing ordinals [0,4], 5, and [6,10]. The second output is under the dust limit, and so such a transaction would be non-standard.

This transfer, and indeed any transfer, can be accomplished by breaking the transfer into multiple transactions, with each transaction performing one or more splits and merging in padding outputs as needed.

To wit, Alice could perform the desired transfer in two transactions. The first transaction would send ordinals [0,4] to Bob, and return as change ordinals [5,10] to Alice. The second transaction would take as inputs an output of at least 4 satoshis, the change input, and an additional input of at least one satoshi; and create an output of size 5 to Bob's address, and the remainder as a change output. Both transactions avoid creating any non-standard outputs, but still accomplish the same desired transfer of ordinals.

=== Objections ===

- Privacy: Ordinal numbers are public and thus reduce user privacy.

  The applications using ordinal numbers required them to be public, and
  reduce the privacy of only those users that decide to use them.

  Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as
  ordinals received in a transaction may carry with them some public
  history.

  As anyone can send anyone else any ordinals, any reasonable person
  will assume that a new owner of a particular ordinal cannot be
  understood to be the old owner, or have any particular relationship
  with the old owner.

- Congestion: Adoption of ordinal numbers will increase the demand for
  transactions, and drive up fees.

  Since Bitcoin requires the development of a robust fee market, this is
  a strong positive of the proposal.

- UTXO set bloat: Adoption of ordinal numbers will increase the demand
  for entries in the UTXO set, and thus increase the size of the UTXO
  set, which all full nodes are required to track.

  The dust limit, which makes outputs with small values difficult to
  create, should encourage users to create non-dust outputs, and to
  clean them up once they no longer have use for the ordinals that they
  contain.

=== Security ===

The public key associated with an ordinal may change. This requires actively following the blockchain to keep up with key changes, and requires care compared to a system where public keys are static. However, a system with static public keys suffers from an inability for keys to be rotated or accounts to change hands.

Ordinal-aware software must avoid destroying ordinals by unintentionally relinquishing them in a transaction, either to a non-controlled output or by using them as fees.

=== Privacy considerations ===

Ordinals are opt-in, and should not impact the privacy of existing users.

Ordinals are themselves public, however, this is required by the fact that many of the applications that they are intended to enable require public identifiers.

Ordinal aware software should never mix satoshis which might have some publicly visible data associated with their ordinals with satoshis intended for use in payments or savings, since this would associate that publicly visible data with the users otherwise pseudonymous wallet outputs.

=== Fungibility considerations ===

Since any ordinal can be sent to any address at any time, ordinals that are transferred, even those with some public history, should be considered to be fungible with other satoshis with no such history.

=== Backward compatibility ===

Ordinal numbers are fully backwards compatible and require no changes to the bitcoin network.

=== Compatibility with Existing and Envisaged Applications ===

Ordinals are compatible with many current and planned applications.

==== Covenants ====

Since ordinals are borne by outputs, they can be encumbered by covenants. BIP-119* specifies OP_CTV, which constraints outputs by pre-committing to a spending transaction template. This template commits to the number, value, and order of spending transaction outputs, which allows constraining how specific ordinals are spent in future transactions.

https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

==== The Lightning Network ====

The Lightning Network cannot be used to selectively transfer individual non-fungible ordinals, however it can be used to transfer arbitrary amounts of fungible ordinals. Channels can be created with inputs whose ordinals are all colored coins of the same type, for example colored coins honored for redemption by a stablecoin issuer. These channels can be used to conduct instant, low-fee USD-denominated off-chain payments, and would require only modest changes to existing Lightning Network nodes.

On channel close, fees would have to be paid by child-pays-for-parent, to avoid paying stablecoin ordinals as fees.

==== Opendimes and Casascius coins ====

Physical transfer of ordinals can be facilitated by loading them onto bitcoin bearer artifacts, such as Opendimes and Casascius coins.

==== RGB ====

RGB is a proposed scheme for using sequences of single-use seals to define state transitions of off-chain, client-side-validated state machines, for example smart contract platforms. Such chains of single-use seals could be addressed by an ordinal contained in the output that starts the chain of single-use seals.

https://rgb-org.github.io/

==== State Chains ====

The state chain proposal facilitates off-chain transfer of whole outputs, which could contain ordinals with specific meanings, for example stable coins or NFTs, allowing off-chain transfer of such digital assets.

https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf

== Applications ==

=== Accounts and Authentication ===

Ordinal numbers can serve as the basis for account and authentication schemes. The account issuer associates a newly created account with an ordinal number in an output controlled by the account owner. The account owner can then log in and take actions related to the account by signing messages with the private key associated with the public key associated with the output that contains the account ordinal. This key is only known to the account owner, preventing unauthorized access.

By transferring the ordinal to a new output, the owner can rotate their private key, or transfer the account to a new owner. Transferring an ordinal requires creating a transaction signed by the current outputs private key, preventing unauthorized transfer of accounts.

=== Colored Coins ===

Ordinals can be used as the basis for colored coin schemes. Unlike other colored coin schemes which use additional outputs or require manipulation of other parts of a transaction, ordinal-based colored coin schemes can take advantage of the full range of available script types, and other base-layer bitcoin features.

=== The DNS ===

The DNS root of trust could be defined not as a specific set of public keys, but as a specific set of ordinals, which would allow for easy key rotation and updates to the set.

=== Name Services ===

A scheme, not described in this document, could be used to assign names to ordinals based on their number. These names could then be used as account names. Many such names would be gibberish, but many would be human readable. A scheme which enumerated strings of the ASCII characters `a` through `z` would assign as names all length-10 and shorter permutations of these characters.

=== NFTs ===

An artist can issue an NFT by signing a message containing a hash of a work of art that they have created, along with the number of a particular ordinal. The owner of that ordinal is the owner of that NFT, allowing ownership to be proven, and the NFT to be bought and sold, and otherwise change hands.

Such NFTs could be used for art, in-game assets, membership systems, or any other kind of digital asset.

The signed message, which may contain arbitrary attributes and metadata, is not sensitive and can be widely disseminated and replicated, to ensure it is not lost.

Scarcity of such NFTs can be guaranteed by including in the NFT messages the total number of NFTs to be issued. If this promise is violated, the set of issued NFTs serves as an easy-to-verify fraud proof that the issuance limit was exceeded.

A judicious NFT issuer will create a new private key to sign a new set of NFTs and destroy it afterwards, to ensure the limited nature of the NFT set. Multi-party-computation can be used to provide additional assurances that overissuance cannot occur.

=== PKI ===

Instead of individual public keys serving as roots of trust for PKI systems, individual ordinals could be used, allowing for key rotation.

=== Rare Sats ===

Ordinal numbers are unique, which might encourage collectors and speculators to collect particular ordinals. Examples of potentially collectable ordinals include:

* The first ordinal in a block, difficulty adjustment period, or halving epoch. * Ordinals consisting only of a single repeating digit. * Ordinals with a large number of 8s, commonly held to be a lucky digit. * Low ordinals mined early in bitcoin's history. * Ordinals that were part of unusual blocks or transactions.

=== Reputation Systems ===

Ordinal numbers can serve as the basis for persistent reputation systems, for example one of Lightning Network node operators. Unlike the current system of associating reputation with public keys, an ordinal-based reputation system allows for key rotation and reputation transfer.

=== Stablecoins ===

A stablecoin issuer could promise to allow redemption of a range of ordinals for one United States dollar each, minus the price of one satoshi times the number of satoshis so redeemed. Such ordinals could be transacted on-chain and on a slightly modified Lightning Network, as well as other layers.

=== Voting and DAOs ===

A DAO or other organization may decide to allocate voting rights proportionally to ownership of a predetermined range of ordinals. Voting rights can thus be made transferable, and voting may be conducted by signing messages using public keys associated with the outputs holding vote-bearing ordinals.

== Reference implementation ==

This document, along with an implementation of an ordinal index that tracks the position of ordinals in the main chain, is available on GitHub: https://github.com/casey/ord

== References ==

A variation of this scheme was independently invented a decade ago by jl2012 on BitcoinTalk: https://bitcointalk.org/index.php?topic=117224.0

For other colored coin proposals see the Bitcoin Wiki entry: https://en.bitcoin.it/wiki/Colored_Coins

For aliases, an implementation of short on-chain identifiers, see BIP 15.

[0] With the exception of being word #1405 in the BIP-39 Portuguese word
    list. Me perdoe!
[1] 7303780 is the decimal representation of the ASCII string 'ord'.

Well done, your bip looks well presented for discussion. You say to number each satoshi created? For a 50 BTC block reward that is 5,000,000,000 ordinal numbers, and when some BTC is transferred to another UTXO how do you determine which ordinal numbers, say if I create a transaction to pay-to another UTXO. The system sounds expensive eventually to cope with approximately 2,100,000,000,000,000 ordinals. If I understand ordinals 0 to 5,000,000,000 as assigned to the first Bitcoin created from mining block-reward. Say if I send some Bitcoin to another UTXO then first-in-first-out algorithm splits those up to assign 1 to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to 5,000,000,000 are assigned to the change plus if any fee?-DA.

On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:

> Briefly, newly mined satoshis are sequentially numbered in the order
> in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input
> satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.

​Well done, your bip looks well presented for discussion.

Thank you!

You say to number each satoshi created? For a 50 BTC block reward that is

> 5,000,000,000 ordinal numbers, and when some BTC is transferred to another
> UTXO how do you determine which ordinal numbers, say if I create a
> transaction to pay-to another UTXO.
>

It uses a first-in-first out algorithm, so the first ordinal number of the first input becomes the first ordinal number of the first output.

The system sounds expensive eventually to cope with approximately

> 2,100,000,000,000,000 ordinals.
>

A full index is expensive, but it doesn't have to track 2.1 individual entries, it only has to track contiguous ordinal ranges, which scales with the number of outputs–all outputs, not just unspent outputs–since an output might split an ordinal range.

If I understand ordinals 0 to 5,000,000,000 as assigned to the first

> Bitcoin created from mining block-reward. Say if I send some Bitcoin to
> another UTXO then first-in-first-out algorithm splits those up to assign 1
> to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to 5,000,000,000
> are assigned to the change plus if any fee?-DA.
>

That's correct, assuming that the 1 BTC output is first, and the 4 BTC output is second. Although it's actually 0 to 99,999,999 that go to the first output, and 100,000,000 to 499,999,999 that are assigned to the second output, less any fees.

At the moment it is indisputable that a particular satoshi cannot be proven, an amount of Bitcoin is a bag of satoshi's and no-one can tell which ones are any particular ones **so even if you used the system of ordinals privately, and it might make interesting for research, I cannot see that it would be sensible to be adopted** as it can only cause trouble. If I receive some Bitcoin I cannot know if some or any of those have been at any point in the past been stolen, I assume the transaction is honest, and in all likelihood it is likely that it is. The least reasonable thing I could expect is some claimed former holder of some ordianls turning up to challenge me that it was their stolen Bitcoin was some of what I received.

NACK

-DA.

On 2022-02-23 18:02, damian@willtech•com•au wrote:

> Well done, your bip looks well presented for discussion. You say to
> number each satoshi created? For a 50 BTC block reward that is
> 5,000,000,000 ordinal numbers, and when some BTC is transferred to
> another UTXO how do you determine which ordinal numbers, say if I
> create a transaction to pay-to another UTXO. The system sounds
> expensive eventually to cope with approximately 2,100,000,000,000,000
> ordinals. If I understand ordinals 0 to 5,000,000,000 as assigned to
> the first Bitcoin created from mining block-reward. Say if I send some
> Bitcoin to another UTXO then first-in-first-out algorithm splits those
> up to assign 1 to 100,000,000 to the 1 BTC that I sent, and
> 100,000,001 to 5,000,000,000 are assigned to the change plus if any
> fee?-DA.
>
> On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order
>> in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input
>> satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.

​The least reasonable thing I could expect is some claimed former holder of some ordianls turning up to challenge me that it was their stolen Bitcoin was some of what I received.

I think it's unlikely that this would come to pass. A previous owner of an ordinal wouldn't have any particular reason to expect that they should own it after they transfer it. Similar to how noting a dollar bill's serial number doesn't give you a claim to it after you spend it. From the BIP:

​Since any ordinal can be sent to any address at any time, ordinals that are transferred, even those with some public history, should be considered to be fungible with other satoshis with no such history. <https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility>

Not all people who have been stolen from believe that they have lost the right and title to what has been stolen and in many cases they have not. I do not excuse Bitcoin that it is impossible to have any individual Bitcoin identified but also I do not care, if I receive Bitcoin honestly I do not care what their history was. What if they were taken from a brothel? It is not a matter for an ordinal to determine if a satoshi is fungible. It is truth in effect that each satoshi is newly created to the new UTXO and the old satoshi destroyed. -DA.

  On 2022-02-23 18:31, Casey Rodarmor wrote:

>> ​The least reasonable thing I could expect is some claimed former
>> holder of some ordianls turning up to challenge me that it was their
>> stolen Bitcoin was some of what I received.
>
> I think it's unlikely that this would come to pass. A previous owner
> of an ordinal wouldn't have any particular reason to expect that they
> should own it after they transfer it. Similar to how noting a dollar
> bill's serial number doesn't give you a claim to it after you spend
> it. From the BIP:
>
>> ​Since any ordinal can be sent to any address at any time,
>> ordinals that are transferred, even those with some public history,
>> should be considered to be fungible with other satoshis with no such
>> history. [1]
>
>
>
> Links:
> ------
> [1]
> https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility

> The system sounds expensive eventually to cope with approximately 2,100,000,000,000,000 ordinals.

What about zero satoshis? There are transactions, where zero satoshis are created or moved. Typical users cannot do that, but miners can, we currently have such transactions in the blockchain, for example 9f0b871e28fa19e2308e2fa74243bf2dcf23b160754df847d5f1e41aabe499d1 (check the last two inputs).

On 2022-02-24 01:53:36 user damian--- via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> Well done, your bip looks well presented for discussion. You say to

number each satoshi created? For a 50 BTC block reward that is 5,000,000,000 ordinal numbers, and when some BTC is transferred to another UTXO how do you determine which ordinal numbers, say if I create a transaction to pay-to another UTXO. The system sounds expensive eventually to cope with approximately 2,100,000,000,000,000 ordinals. If I understand ordinals 0 to 5,000,000,000 as assigned to the first Bitcoin created from mining block-reward. Say if I send some Bitcoin to another UTXO then first-in-first-out algorithm splits those up to assign 1 to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to 5,000,000,000 are assigned to the change plus if any fee?-DA.

On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:

> Briefly, newly mined satoshis are sequentially numbered in the order
> in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input
> satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.

​What about zero satoshis?

A zero satoshi input or output carries no ordinals, so an ordinal index can ignore them.

I think the proposal is interesting in that it could be an interesting way to solve the dust problem. While most solutions to dust focus on reducing how much are created and encouraging consolidating utxos to avoid them becoming dust, this proposal could utilize dust for valuable purposes. Why use valuable Bitcoin for NFTs or colored coins when dust can be split into it's unit satoshis and used with no loss of utility?

Simple and elegant. I like it. If we're giving ACKs: ACK. Tho TBH I don't see any reason NACK this - seems like this doesn't affect consensus, doesn't affect relay, doesn't affect anything except people that run this algorithm on the blockchain. If people want to do something like this, people are going to do it whether or not the bitcoin community wants them to. A standard would be good rather than everyone doing their own thing.

One thought I had was: what happens if/when it comes to pass that we increase payment precision by going sub-satoshi on chain? It seems like it would be fairly simple to extend that to ordinals by having fraction ordinals like 1.1 or 4.85. Could be an interesting thought to add to the proposal.

> If a transaction is mined with the same transaction ID as outputs

currently in the UTXO set, following the behavior of Bitcoin Core, the new transaction outputs displace the older UTXO set entries, destroying the ordinals contained in any unspent outputs of the first transaction.

What you mean by "the same transaction id" here is unclear. I was interpreting the proposal to mean that UTXOs are all assigned a set of ordinals, and when that UTXO is spent, it transfers it's ordinals to outputs in the transaction the UTXO is spent in. Is that what you mean by this sentence? If so, I'd suggest rewording.

@Damian

> If I receive some Bitcoin I cannot know if some or any of those have been

at any point in the past been stolen, I assume the transaction is honest, and in all likelihood it is likely that it is.

This isn't true at all. Some bitcoins are indeed known to be stolen and even blacklisted by some companies/governments. I don't see how ordinals changes anything related to this.

@vjudeu

> What about zero satoshis?

Those could be used for NFTs but not something like colored coins. It would be a strict subset of ability, tho its an interesting idea in its own right.

On Thu, Feb 24, 2022, 02:15 damian--- via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> Not all people who have been stolen from believe that they have lost the
> right and title to what has been stolen and in many cases they have not.
> I do not excuse Bitcoin that it is impossible to have any individual
> Bitcoin identified but also I do not care, if I receive Bitcoin honestly
> I do not care what their history was. What if they were taken from a
> brothel? It is not a matter for an ordinal to determine if a satoshi is
> fungible. It is truth in effect that each satoshi is newly created to
> the new UTXO and the old satoshi destroyed. -DA.
>
>   On 2022-02-23 18:31, Casey Rodarmor wrote:
> >> ​The least reasonable thing I could expect is some claimed former
> >> holder of some ordianls turning up to challenge me that it was their
> >> stolen Bitcoin was some of what I received.
> >
> > I think it's unlikely that this would come to pass. A previous owner
> > of an ordinal wouldn't have any particular reason to expect that they
> > should own it after they transfer it. Similar to how noting a dollar
> > bill's serial number doesn't give you a claim to it after you spend
> > it. From the BIP:
> >
> >> ​Since any ordinal can be sent to any address at any time,
> >> ordinals that are transferred, even those with some public history,
> >> should be considered to be fungible with other satoshis with no such
> >> history. [1]
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> what happens if/when it comes to pass that we increase payment precision by going sub-satoshi on chain?

When we talk about future improvements, there could be even bigger problem with ordinal numbers: what if/when we introduce some Monero-like system and hide coin amounts? (for example by using zero satoshi, because we have to use something that will be backward-compatible). Zero is quite interesting amount, because it means "skip amount checking for old clients". That can be used in many ways to introduce many protocols (and also to add fractional satoshis on-chain, because 0.4 satoshis could be represented as zero), so if that amounts will be simply ignored, then I wonder how it would be possible to connect some future protocol based on that with ordinal numbers.

> When we talk about future improvements, there could be even bigger

problem with ordinal numbers: what if/when we introduce some Monero-like system and hide coin amounts? (for example by using zero satoshi, because we have to use something that will be backward-compatible). Zero is quite interesting amount, because it means "skip amount checking for old clients". That can be used in many ways to introduce many protocols (and also to add fractional satoshis on-chain, because 0.4 satoshis could be represented as zero), so if that amounts will be simply ignored, then I wonder how it would be possible to connect some future protocol based on that with ordinal numbers.

Ordinal numbers are inherently public, so it seems reasonable that they don't work with transactions that are private or have obfuscated values.

> One thought I had was: what happens if/when it comes to pass that we

increase payment precision by going sub-satoshi on chain? It seems like it would be fairly simple to extend that to ordinals by having fraction ordinals like 1.1 or 4.85. Could be an interesting thought to add to the proposal.

I think it's probably premature to make a concrete proposal, since any proposal made now might be inapplicable to the actual form that a precision increase takes.

> What you mean by "the same transaction id" here is unclear. I was

interpreting the proposal to mean that UTXOs are all assigned a set of ordinals, and when that UTXO is spent, it transfers it's ordinals to outputs in the transaction the UTXO is spent in. Is that what you mean by this sentence? If so, I'd suggest rewording.

There are two pairs of old transactions with duplicate IDs, from blocks 91812 and 91842, and 91722 91880. (It's no longer possible to create transactions with duplicate IDs, since the BIP 34 soft fork that required the height be included in coinbase transaction inputs, making them have guaranteed unique IDs.)

This section of the spec defines what ordinal ranges such duplicate transactions contain. It tries to match the behavior of Bitcoin Core, which considers the second transaction with a given ID to render unspendable current UTXOs created by a transaction with the same ID.

I'll add some detail to this part of the BIP, and talk about why this rule is needed.

>  what if/when we introduce some Monero-like system and hide coin amounts?

I really don't see a world where bitcoin goes that route. Hiding coin amounts would make it impossible to audit the blockchain and verify that there hasn't been inflation and the emission schedule is on schedule. It would inherently remove unconditional soundness from bitcoin and replace it with computational soundness. Even if bitcoin did adopt it, it would keep backwards compatibility with old style addresses which could continue to use ordinals.

On Thu, Feb 24, 2022 at 3:03 PM Casey Rodarmor <casey@rodarmor•com> wrote:

> > One thought I had was: what happens if/when it comes to pass that we
> increase payment precision by going sub-satoshi on chain? It seems like it
> would be fairly simple to extend that to ordinals by having fraction
> ordinals like 1.1 or 4.85. Could be an interesting thought to add to the
> proposal.
>
> I think it's probably premature to make a concrete proposal, since any
> proposal made now might be inapplicable to the actual form that a precision
> increase takes.
>
> > What you mean by "the same transaction id" here is unclear. I was
> interpreting the proposal to mean that UTXOs are all assigned a set of
> ordinals, and when that UTXO is spent, it transfers it's ordinals to
> outputs in the transaction the UTXO is spent in. Is that what you mean by
> this sentence? If so, I'd suggest rewording.
>
> There are two pairs of old transactions with duplicate IDs, from blocks
> 91812 and 91842, and 91722 91880. (It's no longer possible to create
> transactions with duplicate IDs, since the BIP 34 soft fork that required
> the height be included in coinbase transaction inputs, making them have
> guaranteed unique IDs.)
>
> This section of the spec defines what ordinal ranges such duplicate
> transactions contain. It tries to match the behavior of Bitcoin Core, which
> considers the second transaction with a given ID to render unspendable
> current UTXOs created by a transaction with the same ID.
>
> I'll add some detail to this part of the BIP, and talk about why this rule
> is needed.
>

> I really don't see a world where bitcoin goes that route. Hiding coin amounts would make it impossible to audit the blockchain and verify that there hasn't been inflation and the emission schedule is on schedule. It would inherently remove unconditional soundness from bitcoin and replace it with computational soundness. Even if bitcoin did adopt it, it would keep backwards compatibility with old style addresses which could continue to use ordinals.

Nit: it isn't technically correct to say that amount hiding "inherently removes unconditional soundness". Such commitments can be either perfectly hiding or perfectly binding; it isn't even logically possible for them to be both, sadly. But we are not forced to choose perfect binding; El Gamal commitments, for example, are perfectly binding but only computationally hiding.

> El Gamal commitments, for example, are perfectly binding but only

computationally hiding.

That's very interesting. I stand corrected in that respect. Thanks for the information Adam!

On Fri, Feb 25, 2022, 05:17 AdamISZ <AdamISZ@protonmail•com> wrote:

> > I really don't see a world where bitcoin goes that route. Hiding coin
> amounts would make it impossible to audit the blockchain and verify that
> there hasn't been inflation and the emission schedule is on schedule. It
> would inherently remove unconditional soundness from bitcoin and replace it
> with computational soundness. Even if bitcoin did adopt it, it would keep
> backwards compatibility with old style addresses which could continue to
> use ordinals.
>
> Nit: it isn't technically correct to say that amount hiding "inherently
> removes unconditional soundness". Such commitments can be either perfectly
> hiding or perfectly binding; it isn't even logically possible for them to
> be both, sadly. But we are not forced to choose perfect binding; El Gamal
> commitments, for example, are perfectly binding but only computationally
> hiding.
>