path: root/bb/a7937091d142d56e5d6627c4527a3c192c2f51

Return-Path: <casey@rodarmor.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7C139C0011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Feb 2022 00:44:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 544EF40350
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Feb 2022 00:44:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=rodarmor.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MmHd97CoAzYD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Feb 2022 00:44:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 4D2B040324
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Feb 2022 00:44:06 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id z22so41047442edd.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Feb 2022 16:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rodarmor.com; s=google;
 h=mime-version:from:date:message-id:subject:to;
 bh=+7PiffsB0+zFLKrnpiJhbJL+5SmVgY7yW279qR2wu1M=;
 b=ZSEast5+XozS0iagDAi1P9vzKex8LFs6PDWtYaR0HzbPwN591W4BGZX8oWYYbFtMAh
 tIyKLwJTZM/wblwvoNMJZwCbX8d+PVjQx3vZeCLvAyTDz2P/aw0nxijyR+mpFm1NBhZQ
 g0fVb/iC/900R9t0n4z6W6DWX6rwsAp2k26AK87H9+ptYWNSCN2wPF9hB6cikVpyqfwa
 8xhR+xSXejCQ4tj5xJQwopkk+pJL133awBOk0mIvgMlrbUI48LyHjcYmI56E0FDxtZMB
 b5TboYOX1pmnlKzyoNu7VQVWnLyrwr2SiiXR+d7lconP0DTB71LP3vAXBm31M6SksdQ9
 iHgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=+7PiffsB0+zFLKrnpiJhbJL+5SmVgY7yW279qR2wu1M=;
 b=AxDfx5SPCL62qN9Ty7JyurFs3ys4/0kyh5iDxaM7VhUMz3iibf58o4edLZ/640+k1R
 a6xWp/KAzpa+y2axC4dW08zyD2zHYaDyR+e3iPo/5yox7Ba6nUcL8fx2/XqsvhIxnQ1N
 GKzD6l0NcZ9cnCAb10tKvq9wMsQVPaCWt5qb4J2q8v7Cwhomc7BlzZOnMxUYqcwYF7qU
 Jm41EeQPnp9fJ+T9OX0ABI0+i6V/Lkb+ZOJvR1/uy7kiOVhzAkGlzXS1viQVs4mDDo/y
 Bvr5XEVnmifYRQV6Dcl42wpnbJjK9m5/5tMpmkMJVESpNYjGAsXOaeP6o3pCm/RzeyJ+
 xIHA==
X-Gm-Message-State: AOAM532KaRGLQYZsGqPM2cB2dfEGC14ps2/EWypT4/DSRX0X4FMmd4A6
 AAew2iW309dSgPwXD4a801G/SiDrkQlsZv42Ori7a+Tzhoe/LA==
X-Google-Smtp-Source: ABdhPJx1pDZwDKEoK1LL1ZMTkjexQ1QZHHIGmR4mMHtEaDZ7bylcKNeBuuC6vdKR/8656w2aD8N/4xRf4pZCs667nGE=
X-Received: by 2002:a05:6402:3553:b0:412:d0aa:e7b0 with SMTP id
 f19-20020a056402355300b00412d0aae7b0mr22353966edd.309.1645577043715; Tue, 22
 Feb 2022 16:44:03 -0800 (PST)
MIME-Version: 1.0
From: Casey Rodarmor <casey@rodarmor.com>
Date: Tue, 22 Feb 2022 16:43:52 -0800
Message-ID: <CANLPe+OZ33vcZheOyo2RdrvWzQvj3RzZc6sHTafGwbqEG2G4pA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000243fa105d8a4c314"
X-Mailman-Approved-At: Wed, 23 Feb 2022 01:49:49 +0000
Subject: [bitcoin-dev] Draft-BIP: Ordinal Numbers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2022 00:44:09 -0000

--000000000000243fa105d8a4c314
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=3D117224.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>

=3D=3D Introduction =3D=3D

=3D=3D=3D Abstract =3D=3D=3D

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.

=3D=3D=3D Copyright =3D=3D=3D

This work is placed in the public domain.

=3D=3D=3D Motivation =3D=3D=3D

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.

=3D=3D Description =3D=3D

=3D=3D=3D Design =3D=3D=3D

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].

=3D=3D=3D Specification =3D=3D=3D

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 =3D 0
      for height in range(height):
        start +=3D subsidy(height)
      return start

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

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

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

        coinbase_ordinals.extend(ordinals)

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

=3D=3D=3D Terminology and Notation =3D=3D=3D

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

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.

=3D=3D Discussion =3D=3D

=3D=3D=3D Rationale =3D=3D=3D

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.

=3D=3D=3D Transfer and the Dust Limit =3D=3D=3D

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=C2=B0 and 6=C2=B0 to Bob, but retain ordinal 5=C2=B0. 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.

=3D=3D=3D Objections =3D=3D=3D

- 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.

=3D=3D=3D Security =3D=3D=3D

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.

=3D=3D=3D Privacy considerations =3D=3D=3D

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.

=3D=3D=3D Fungibility considerations =3D=3D=3D

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.

=3D=3D=3D Backward compatibility =3D=3D=3D

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

=3D=3D=3D Compatibility with Existing and Envisaged Applications =3D=3D=3D

Ordinals are compatible with many current and planned applications.

=3D=3D=3D=3D Covenants =3D=3D=3D=3D

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

=3D=3D=3D=3D The Lightning Network =3D=3D=3D=3D

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.

=3D=3D=3D=3D Opendimes and Casascius coins =3D=3D=3D=3D

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

=3D=3D=3D=3D RGB =3D=3D=3D=3D

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/

=3D=3D=3D=3D State Chains =3D=3D=3D=3D

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/statec=
hains.pdf

=3D=3D Applications =3D=3D

=3D=3D=3D Accounts and Authentication =3D=3D=3D

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.

=3D=3D=3D Colored Coins =3D=3D=3D

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.

=3D=3D=3D The DNS =3D=3D=3D

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.

=3D=3D=3D Name Services =3D=3D=3D

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.

=3D=3D=3D NFTs =3D=3D=3D

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.

=3D=3D=3D PKI =3D=3D=3D

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

=3D=3D=3D Rare Sats =3D=3D=3D

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.

=3D=3D=3D Reputation Systems =3D=3D=3D

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.

=3D=3D=3D Stablecoins =3D=3D=3D

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.

=3D=3D=3D Voting and DAOs =3D=3D=3D

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.

=3D=3D Reference implementation =3D=3D

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

=3D=3D References =3D=3D

A variation of this scheme was independently invented a decade ago by
jl2012 on BitcoinTalk: https://bitcointalk.org/index.php?topic=3D117224.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'.

--000000000000243fa105d8a4c314
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Good afternoon list,<br><br>I&#39;ve been working on a =
scheme of stable public identifiers that can be <br>used for a variety of p=
urposes.<br><br>The scheme is extremely simple and does not require protoco=
l-level <br>changes, but since different applications and wallets might use=
 such <br>identifiers, standardizing and publishing the scheme as a BIP see=
ms <br>warranted. The draft-BIP is hosted on GitHub, as well as reproduced =
<br>below:<br><br><a href=3D"https://github.com/casey/ord/blob/master/bip.m=
ediawiki">https://github.com/casey/ord/blob/master/bip.mediawiki</a><br><br=
>Briefly, newly mined satoshis are sequentially numbered in the order in <b=
r>which they are mined. These numbers are called &quot;ordinal numbers&quot=
; or <br>&quot;ordinals&quot;. When satoshis are spent in a transaction, th=
e input satoshi <br>ordinal numbers are assigned to output satoshis using a=
 simple <br>first-in-first-out algorithm.<br><br>At any time, the output th=
at contains an ordinal can be determined, and <br>the public key associated=
 with that output can be used to sign <br>challenges or perform actions rel=
ated to the ordinal that it contains.<br><br>Such identifiers could be used=
 for a variety of purposes, such as user <br>accounts, PKI roots, or to iss=
ue stablecoins or NFTs. The scheme <br>composes nicely with other Bitcoin a=
pplications, such as the Lightning <br>Network or state chains.<br><br>I&#3=
9;m also working on an command-line tool that builds an index of ordinal <b=
r>ranges to answer queries about the whereabouts of a particular ordinal, <=
br>or the ordinals contained in a particular output:<br><br><a href=3D"http=
s://github.com/casey/ord/">https://github.com/casey/ord/</a><br><br>The ind=
ex is well tested but needs to be optimized before it can index <br>the mai=
n chain in a reasonable amount of time and space. It&#39;s written in <br>R=
ust, by myself and Liam Scalzulli.<br><br>I&#39;m eager for feedback, both =
here, and on GitHub:<br><br><a href=3D"https://github.com/casey/ord/discuss=
ions/126">https://github.com/casey/ord/discussions/126</a><br><br>Best rega=
rds,<br>Casey Rodarmor<br><br>PS After finishing the current draft, I disco=
vered that a variation of <br>this scheme was independently proposed a litt=
le under a decade ago by <br>jl2012 on BitcoinTalk:<br><br><a href=3D"https=
://bitcointalk.org/index.php?topic=3D117224.0">https://bitcointalk.org/inde=
x.php?topic=3D117224.0</a><br><br>---<br><br>&lt;pre&gt;<br>=C2=A0 BIP: ?<b=
r>=C2=A0 Layer: Applications<br>=C2=A0 Title: Ordinal Numbers<br>=C2=A0 Aut=
hor: Casey Rodarmor &lt;<a href=3D"mailto:casey@rodarmor.com">casey@rodarmo=
r.com</a>&gt;<br>=C2=A0 Comments-Summary: No comments yet.<br>=C2=A0 Commen=
ts-URI: <a href=3D"https://github.com/casey/ord/discussions/126">https://gi=
thub.com/casey/ord/discussions/126</a><br>=C2=A0 Status: Draft<br>=C2=A0 Ty=
pe: Informational<br>=C2=A0 Created: 2022-02-02<br>=C2=A0 License: PD<br>&l=
t;/pre&gt;<br><br>=3D=3D Introduction =3D=3D<br><br>=3D=3D=3D Abstract =3D=
=3D=3D<br><br>This document defines a scheme for numbering and tracking sat=
oshis <br>across transactions. These numbers, &quot;ordinal numbers&quot; i=
n the language of <br>this document, can be used as a useful primitive for =
a diverse range of <br>applications, including NFTs, reputation systems, an=
d Lightning <br>Network-compatible stablecoins.<br><br>=3D=3D=3D Copyright =
=3D=3D=3D<br><br>This work is placed in the public domain.<br><br>=3D=3D=3D=
 Motivation =3D=3D=3D<br><br>Bitcoin has no notion of a stable, public acco=
unt or identity. Addresses <br>are single-use, and wallet accounts, while p=
ermanent, are not publicly <br>visible. Additionally, the use of addresses =
or public keys as <br>identifiers precludes private key rotation or transfe=
r of ownership.<br><br>Many applications, some of which are detailed in thi=
s document, require <br>stable, public identifiers tracking identity or own=
ership. This proposal <br>is motivated by the desire to provide such a syst=
em of identifiers.<br><br>=3D=3D Description =3D=3D<br><br>=3D=3D=3D Design=
 =3D=3D=3D<br><br>Every satoshi is serially numbered, starting at 0, in the=
 order in which <br>it is mined. These numbers are termed &quot;ordinal num=
bers&quot;, or &quot;ordinals&quot;, <br>as they are ordinal numbers in the=
 mathematical sense. The word <br>&quot;ordinal&quot; is nicely unambiguous=
, as it is not used elsewhere in the <br>Bitcoin protocol[0].<br><br>The or=
dinal numbers of transaction inputs are transferred to outputs in <br>first=
-in-first-out order, according to the size and order of the <br>transaction=
s inputs and outputs.<br><br>If a transaction is mined with the same transa=
ction ID as outputs <br>currently in the UTXO set, following the behavior o=
f Bitcoin Core, the <br>new transaction outputs displace the older UTXO set=
 entries, destroying <br>the ordinals contained in any unspent outputs of t=
he first transaction.<br><br>For the purposes of the assignment algorithm, =
the coinbase transaction <br>is considered to have an implicit input equal =
in size to the subsidy, <br>followed by an input for every fee-paying trans=
action in the block, in <br>the order that those transactions appear in the=
 block. The implicit <br>subsidy input carries the block&#39;s newly create=
d ordinals. The implicit <br>fee inputs carry the ordinals that were paid a=
s fees in the block&#39;s <br>transactions.<br><br>Underpaying the subsidy =
does not change the ordinal numbers of satoshis <br>mined in subsequent blo=
cks. Ordinals depend only on how many satoshis <br>could have been mined, n=
ot how many actually were.<br><br>At any given time, the output in which an=
 ordinal resides can be <br>identified. The public key associated with this=
 output can be used to <br>sign messages, such as ownership challenges, con=
cerning to the ordinals <br>it contains. The specification of a standardize=
d message format for such <br>purposes is deferred to a later BIP.<br><br>O=
rdinal aware software should not mix outputs containing meaningful <br>ordi=
nals with outputs used for other purposes to avoid inadvertent loss <br>of =
valuable ordinals, or privacy leaks allowing links between funds. For <br>t=
his reason, ordinal aware software using BIP-32 hierarchical <br>determinis=
tic key generation should use a key derivation path specific <br>to ordinal=
s.<br><br>The suggested key derivation path is `m/44&#39;/7303780&#39;/0&#3=
9;/0`. This <br>suggested derivation path has not been standardized and may=
 change in <br>the future[1].<br><br>=3D=3D=3D Specification =3D=3D=3D<br><=
br>Ordinals are created and assigned with the following algorithm:<br><br>=
=C2=A0 =C2=A0 # subsidy of block at given height<br>=C2=A0 =C2=A0 def subsi=
dy(height):<br>=C2=A0 =C2=A0 =C2=A0 return 50 * 100_000_000 &gt;&gt; int(he=
ight / 210_000)<br><br>=C2=A0 =C2=A0 # first ordinal of subsidy of block at=
 given height<br>=C2=A0 =C2=A0 def first_ordinal(height):<br>=C2=A0 =C2=A0 =
=C2=A0 start =3D 0<br>=C2=A0 =C2=A0 =C2=A0 for height in range(height):<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 start +=3D subsidy(height)<br>=C2=A0 =C2=A0 =C2=
=A0 return start<br><br>=C2=A0 =C2=A0 # assign ordinals in given block<br>=
=C2=A0 =C2=A0 def assign_ordinals(block):<br>=C2=A0 =C2=A0 =C2=A0 first =3D=
 first_ordinal(block.height)<br>=C2=A0 =C2=A0 =C2=A0 last =3D first + subsi=
dy(block.height)<br>=C2=A0 =C2=A0 =C2=A0 coinbase_ordinals =3D list(range(f=
irst, last))<br><br>=C2=A0 =C2=A0 =C2=A0 for transaction in block.transacti=
ons[1:]:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ordinals =3D []<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 for input in transaction.inputs:<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ordinals.extend(input.ordinals)<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 for output in transaction.outputs:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 output.ordinals =3D ordinals[:output.value]<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 del ordinals[:output.value]<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 c=
oinbase_ordinals.extend(ordinals)<br><br>=C2=A0 =C2=A0 =C2=A0 for output in=
 block.transaction[0].outputs:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 output.ordina=
ls =3D coinbase_ordinals[:output.value]<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 del =
coinbase_ordinals[:output.value]<br><br>=3D=3D=3D Terminology and Notation =
=3D=3D=3D<br><br>Ordinals may be written as the ordinal number followed by =
the <br>Romance-language ordinal indicator =C2=B0, for example 13=C2=B0.<br=
><br>A satpoint may be used to indicate the location of an ordinal within a=
n <br>output. A satpoint consists of an outpoint, i.e., a transaction ID an=
d <br>output index, with the addition of the offset of the ordinal within t=
hat <br>output. For example, if the ordinal in question is at offset 6 in t=
he <br>first output of a transaction can be written as:<br><br>=C2=A0 =C2=
=A0 680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6<br=
><br>A slot may be used to indicate the output of an ordinal without <br>re=
ferring to a transaction ID, by substituting the block height and <br>trans=
action index within the block for the transaction ID. It is written <br>as =
a dotted quad. For example, the ordinal at offset 100 in the output <br>at =
offset 1, in the coinbase transaction of block 83 can be written as:<br><br=
>=C2=A0 =C2=A0 83.0.1.100<br><br>Satoshis with ordinals that are not valuab=
le or notable can be referred <br>to as cardinal, as their identity does no=
t matter, only the amount. A <br>cardinal output is one whose ordinals are =
unimportant for the purpose at <br>hand, for example an output used only to=
 provide padding to avoid <br>creating a transaction with an output below t=
he dust limit.<br><br>=3D=3D Discussion =3D=3D<br><br>=3D=3D=3D Rationale =
=3D=3D=3D<br><br>Ordinal numbers are designed to be orthogonal to other asp=
ects of the <br>Bitcoin protocol, and can thus be used in conjunction with =
other <br>layer-one techniques and applications, even ones that were not de=
signed <br>with ordinal numbers in mind.<br><br>Ordinal satoshis can be sec=
ured using current and future script types. <br>They can be held by single-=
signature wallets, multi-signature wallets, <br>time-locked, and height-loc=
ked in all the usual ways.<br><br>This orthogonality also allows them to be=
 used with layer-two <br>applications. A stablecoin issuer can promise to a=
llow redemption of <br>specific ranges of ordinals for $1 United States dol=
lar each. Lightning <br>Network nodes can then be used to create a USD-deno=
minated Lightning <br>Network, using existing software with very modest mod=
ifications.<br><br>By assigning ordinal numbers to all satoshis without nee=
d for an <br>explicit creation step, the anonymity set of ordinal number us=
ers is <br>maximized.<br><br>Since an ordinal number has an output that con=
tains it, and an output <br>has a public key that controls it, the owner of=
 an ordinal can respond <br>to challenges by signing messages using the pub=
lic key associated with <br>the controlling UTXO. Additionally, an ordinal =
can change hands, or its <br>private key can be rotated without a change of=
 ownership, by <br>transferring it to a new output.<br><br>Ordinals require=
 no changes to blocks, transactions, or network <br>protocols, and can thus=
 be immediately adopted, or ignored, without <br>impacting existing users.<=
br><br>Ordinals do not have an explicit on-chain footprint. However, a vali=
d <br>objection is that adoption of ordinals will increase demand for outpu=
ts, <br>and thus increase the size of the UTXO set that full nodes must tra=
ck. <br>See the objections section below.<br><br>The ordinal number scheme =
is extremely simple. The specification above <br>is 15 lines of code.<br><b=
r>Ordinals are fairly assigned. They are not premined, and are assigned <br=
>proportionally to existing bitcoin holders.<br><br>Ordinals are as granula=
r as possible, as bitcoin is not capable of <br>tracking ownership of sub-s=
atoshi values.<br><br>=3D=3D=3D Transfer and the Dust Limit =3D=3D=3D<br><b=
r>Any ordinal transfer can be accomplished in a single transaction, but <br=
>the resulting transaction may contain outputs below the dust limit, and <b=
r>thus be non-standard and difficult to get included in a block. Consider <=
br>a scenario where Alice owns an output containing the range of ordinals <=
br>[0,10], the current dust limit is 5 satoshis, and Alice wishes to send <=
br>send ordinals 4=C2=B0 and 6=C2=B0 to Bob, but retain ordinal 5=C2=B0. Al=
ice could <br>construct a transaction with three outputs of size 5, 1, and =
5, <br>containing ordinals [0,4], 5, and [6,10]. The second output is under=
 the <br>dust limit, and so such a transaction would be non-standard.<br><b=
r>This transfer, and indeed any transfer, can be accomplished by breaking <=
br>the transfer into multiple transactions, with each transaction <br>perfo=
rming one or more splits and merging in padding outputs as needed.<br><br>T=
o wit, Alice could perform the desired transfer in two transactions. <br>Th=
e first transaction would send ordinals [0,4] to Bob, and return as <br>cha=
nge ordinals [5,10] to Alice. The second transaction would take as <br>inpu=
ts an output of at least 4 satoshis, the change input, and an <br>additiona=
l input of at least one satoshi; and create an output of size 5 <br>to Bob&=
#39;s address, and the remainder as a change output. Both <br>transactions =
avoid creating any non-standard outputs, but still <br>accomplish the same =
desired transfer of ordinals.<br><br>=3D=3D=3D Objections =3D=3D=3D<br><br>=
- Privacy: Ordinal numbers are public and thus reduce user privacy.<br><br>=
=C2=A0 The applications using ordinal numbers required them to be public, a=
nd <br>=C2=A0 reduce the privacy of only those users that decide to use the=
m.<br><br>=C2=A0 Fungibility: Ordinal numbers reduce the fungibility of Bit=
coin, as <br>=C2=A0 ordinals received in a transaction may carry with them =
some public <br>=C2=A0 history.<br><br>=C2=A0 As anyone can send anyone els=
e any ordinals, any reasonable person <br>=C2=A0 will assume that a new own=
er of a particular ordinal cannot be <br>=C2=A0 understood to be the old ow=
ner, or have any particular relationship <br>=C2=A0 with the old owner.<br>=
<br>- Congestion: Adoption of ordinal numbers will increase the demand for =
<br>=C2=A0 transactions, and drive up fees.<br><br>=C2=A0 Since Bitcoin req=
uires the development of a robust fee market, this is <br>=C2=A0 a strong p=
ositive of the proposal.<br><br>- UTXO set bloat: Adoption of ordinal numbe=
rs will increase the demand <br>=C2=A0 for entries in the UTXO set, and thu=
s increase the size of the UTXO <br>=C2=A0 set, which all full nodes are re=
quired to track.<br><br>=C2=A0 The dust limit, which makes outputs with sma=
ll values difficult to <br>=C2=A0 create, should encourage users to create =
non-dust outputs, and to <br>=C2=A0 clean them up once they no longer have =
use for the ordinals that they <br>=C2=A0 contain.<br><br>=3D=3D=3D Securit=
y =3D=3D=3D<br><br>The public key associated with an ordinal may change. Th=
is requires <br>actively following the blockchain to keep up with key chang=
es, and <br>requires care compared to a system where public keys are static=
. <br>However, a system with static public keys suffers from an inability f=
or <br>keys to be rotated or accounts to change hands.<br><br>Ordinal-aware=
 software must avoid destroying ordinals by unintentionally <br>relinquishi=
ng them in a transaction, either to a non-controlled output <br>or by using=
 them as fees.<br><br>=3D=3D=3D Privacy considerations =3D=3D=3D<br><br>Ord=
inals are opt-in, and should not impact the privacy of existing <br>users.<=
br><br>Ordinals are themselves public, however, this is required by the fac=
t <br>that many of the applications that they are intended to enable requir=
e <br>public identifiers.<br><br>Ordinal aware software should never mix sa=
toshis which might have some <br>publicly visible data associated with thei=
r ordinals with satoshis <br>intended for use in payments or savings, since=
 this would associate that <br>publicly visible data with the users otherwi=
se pseudonymous wallet <br>outputs.<br><br>=3D=3D=3D Fungibility considerat=
ions =3D=3D=3D<br><br>Since any ordinal can be sent to any address at any t=
ime, ordinals that <br>are transferred, even those with some public history=
, should be <br>considered to be fungible with other satoshis with no such =
history.<br><br>=3D=3D=3D Backward compatibility =3D=3D=3D<br><br>Ordinal n=
umbers are fully backwards compatible and require no changes to <br>the bit=
coin network.<br><br>=3D=3D=3D Compatibility with Existing and Envisaged Ap=
plications =3D=3D=3D<br><br>Ordinals are compatible with many current and p=
lanned applications.<br><br>=3D=3D=3D=3D Covenants =3D=3D=3D=3D<br><br>Sinc=
e ordinals are borne by outputs, they can be encumbered by <br>covenants. B=
IP-119* specifies OP_CTV, which constraints outputs by <br>pre-committing t=
o a spending transaction template. This template commits <br>to the number,=
 value, and order of spending transaction outputs, which <br>allows constra=
ining how specific ordinals are spent in future <br>transactions.<br><br><a=
 href=3D"https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki">ht=
tps://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki</a> <br><br>=
=3D=3D=3D=3D The Lightning Network =3D=3D=3D=3D<br><br>The Lightning Networ=
k cannot be used to selectively transfer individual <br>non-fungible ordina=
ls, however it can be used to transfer arbitrary <br>amounts of fungible or=
dinals. Channels can be created with inputs whose <br>ordinals are all colo=
red coins of the same type, for example colored <br>coins honored for redem=
ption by a stablecoin issuer. These channels can <br>be used to conduct ins=
tant, low-fee USD-denominated off-chain payments, <br>and would require onl=
y modest changes to existing Lightning Network <br>nodes.<br><br>On channel=
 close, fees would have to be paid by child-pays-for-parent, <br>to avoid p=
aying stablecoin ordinals as fees.<br><br>=3D=3D=3D=3D Opendimes and Casasc=
ius coins =3D=3D=3D=3D<br><br>Physical transfer of ordinals can be facilita=
ted by loading them onto <br>bitcoin bearer artifacts, such as Opendimes an=
d Casascius coins.<br><br>=3D=3D=3D=3D RGB =3D=3D=3D=3D<br><br>RGB is a pro=
posed scheme for using sequences of single-use seals to <br>define state tr=
ansitions of off-chain, client-side-validated state <br>machines, for examp=
le smart contract platforms. Such chains of <br>single-use seals could be a=
ddressed by an ordinal contained in the <br>output that starts the chain of=
 single-use seals.<br><br><a href=3D"https://rgb-org.github.io/">https://rg=
b-org.github.io/</a> <br><br>=3D=3D=3D=3D State Chains =3D=3D=3D=3D<br><br>=
The state chain proposal facilitates off-chain transfer of whole <br>output=
s, which could contain ordinals with specific meanings, for <br>example sta=
ble coins or NFTs, allowing off-chain transfer of such <br>digital assets.<=
br><br><a href=3D"https://github.com/RubenSomsen/rubensomsen.github.io/blob=
/master/img/statechains.pdf">https://github.com/RubenSomsen/rubensomsen.git=
hub.io/blob/master/img/statechains.pdf</a> <br><br>=3D=3D Applications =3D=
=3D<br><br>=3D=3D=3D Accounts and Authentication =3D=3D=3D<br><br>Ordinal n=
umbers can serve as the basis for account and authentication <br>schemes. T=
he account issuer associates a newly created account with an <br>ordinal nu=
mber in an output controlled by the account owner. The account <br>owner ca=
n then log in and take actions related to the account by signing <br>messag=
es with the private key associated with the public key associated <br>with =
the output that contains the account ordinal. This key is only <br>known to=
 the account owner, preventing unauthorized access.<br><br>By transferring =
the ordinal to a new output, the owner can rotate their <br>private key, or=
 transfer the account to a new owner. Transferring an <br>ordinal requires =
creating a transaction signed by the current outputs <br>private key, preve=
nting unauthorized transfer of accounts.<br><br>=3D=3D=3D Colored Coins =3D=
=3D=3D<br><br>Ordinals can be used as the basis for colored coin schemes. U=
nlike other <br>colored coin schemes which use additional outputs or requir=
e <br>manipulation of other parts of a transaction, ordinal-based colored c=
oin <br>schemes can take advantage of the full range of available script ty=
pes, <br>and other base-layer bitcoin features.<br><br>=3D=3D=3D The DNS =
=3D=3D=3D<br><br>The DNS root of trust could be defined not as a specific s=
et of public <br>keys, but as a specific set of ordinals, which would allow=
 for easy key <br>rotation and updates to the set.<br><br>=3D=3D=3D Name Se=
rvices =3D=3D=3D<br><br>A scheme, not described in this document, could be =
used to assign names <br>to ordinals based on their number. These names cou=
ld then be used as <br>account names. Many such names would be gibberish, b=
ut many would be <br>human readable. A scheme which enumerated strings of t=
he ASCII <br>characters `a` through `z` would assign as names all length-10=
 and <br>shorter permutations of these characters.<br><br>=3D=3D=3D NFTs =
=3D=3D=3D<br><br>An artist can issue an NFT by signing a message containing=
 a hash of a <br>work of art that they have created, along with the number =
of a <br>particular ordinal. The owner of that ordinal is the owner of that=
 NFT, <br>allowing ownership to be proven, and the NFT to be bought and sol=
d, and <br>otherwise change hands.<br><br>Such NFTs could be used for art, =
in-game assets, membership systems, or <br>any other kind of digital asset.=
<br><br>The signed message, which may contain arbitrary attributes and meta=
data, <br>is not sensitive and can be widely disseminated and replicated, t=
o <br>ensure it is not lost.<br><br>Scarcity of such NFTs can be guaranteed=
 by including in the NFT messages <br>the total number of NFTs to be issued=
. If this promise is violated, the <br>set of issued NFTs serves as an easy=
-to-verify fraud proof that the <br>issuance limit was exceeded.<br><br>A j=
udicious NFT issuer will create a new private key to sign a new set <br>of =
NFTs and destroy it afterwards, to ensure the limited nature of the <br>NFT=
 set. Multi-party-computation can be used to provide additional <br>assuran=
ces that overissuance cannot occur.<br><br>=3D=3D=3D PKI =3D=3D=3D<br><br>I=
nstead of individual public keys serving as roots of trust for PKI <br>syst=
ems, individual ordinals could be used, allowing for key rotation.<br><br>=
=3D=3D=3D Rare Sats =3D=3D=3D<br><br>Ordinal numbers are unique, which migh=
t encourage collectors and <br>speculators to collect particular ordinals. =
Examples of potentially <br>collectable ordinals include:<br><br>* The firs=
t ordinal in a block, difficulty adjustment period, or halving epoch.<br>* =
Ordinals consisting only of a single repeating digit.<br>* Ordinals with a =
large number of 8s, commonly held to be a lucky digit.<br>* Low ordinals mi=
ned early in bitcoin&#39;s history.<br>* Ordinals that were part of unusual=
 blocks or transactions.<br><br>=3D=3D=3D Reputation Systems =3D=3D=3D<br><=
br>Ordinal numbers can serve as the basis for persistent reputation <br>sys=
tems, for example one of Lightning Network node operators. Unlike the <br>c=
urrent system of associating reputation with public keys, an <br>ordinal-ba=
sed reputation system allows for key rotation and reputation <br>transfer.<=
br><br>=3D=3D=3D Stablecoins =3D=3D=3D<br><br>A stablecoin issuer could pro=
mise to allow redemption of a range of <br>ordinals for one United States d=
ollar each, minus the price of one <br>satoshi times the number of satoshis=
 so redeemed. Such ordinals could be <br>transacted on-chain and on a sligh=
tly modified Lightning Network, as <br>well as other layers.<br><br>=3D=3D=
=3D Voting and DAOs =3D=3D=3D<br><br>A DAO or other organization may decide=
 to allocate voting rights <br>proportionally to ownership of a predetermin=
ed range of ordinals. Voting <br>rights can thus be made transferable, and =
voting may be conducted by <br>signing messages using public keys associate=
d with the outputs holding <br>vote-bearing ordinals.<br><br>=3D=3D Referen=
ce implementation =3D=3D<br><br>This document, along with an implementation=
 of an ordinal index that <br>tracks the position of ordinals in the main c=
hain, is available on <br>GitHub: <a href=3D"https://github.com/casey/ord">=
https://github.com/casey/ord</a><br><br>=3D=3D References =3D=3D<br><br>A v=
ariation of this scheme was independently invented a decade ago by <br>jl20=
12 on BitcoinTalk: <a href=3D"https://bitcointalk.org/index.php?topic=3D117=
224.0">https://bitcointalk.org/index.php?topic=3D117224.0</a><br><br>For ot=
her colored coin proposals see the Bitcoin Wiki entry:<br><a href=3D"https:=
//en.bitcoin.it/wiki/Colored_Coins">https://en.bitcoin.it/wiki/Colored_Coin=
s</a> <br><br>For aliases, an implementation of short on-chain identifiers,=
 see BIP <br>15.<br><br>[0] With the exception of being word #1405 in the B=
IP-39 Portuguese word <br>=C2=A0 =C2=A0 list. Me perdoe!<br>[1] 7303780 is =
the decimal representation of the ASCII string &#39;ord&#39;.<br></div></di=
v>

--000000000000243fa105d8a4c314--