diff options
| author | Casey Rodarmor <casey@rodarmor.com> | 2022-02-22 16:43:52 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-23 00:44:09 +0000 |
| commit | d5e952c6d26e0187c3c81237e67c4425514dbc6c (patch) | |
| tree | 2199428cd45d062a19bfbd4a22f9100c503b0a94 | |
| parent | 04b9d9b27e45f885908f2c197ef636312b75aab9 (diff) | |
| download | pi-bitcoindev-d5e952c6d26e0187c3c81237e67c4425514dbc6c.tar.gz pi-bitcoindev-d5e952c6d26e0187c3c81237e67c4425514dbc6c.zip | |
[bitcoin-dev] Draft-BIP: Ordinal Numbers
| -rw-r--r-- | bb/a7937091d142d56e5d6627c4527a3c192c2f51 | 953 |
1 files changed, 953 insertions, 0 deletions
diff --git a/bb/a7937091d142d56e5d6627c4527a3c192c2f51 b/bb/a7937091d142d56e5d6627c4527a3c192c2f51 new file mode 100644 index 000000000..5d4fbf1ad --- /dev/null +++ b/bb/a7937091d142d56e5d6627c4527a3c192c2f51 @@ -0,0 +1,953 @@ +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'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 "ordinal numbers"= +; or <br>"ordinals". 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= +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's written in <br>R= +ust, by myself and Liam Scalzulli.<br><br>I'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><pre><br>=C2=A0 BIP: ?<b= +r>=C2=A0 Layer: Applications<br>=C2=A0 Title: Ordinal Numbers<br>=C2=A0 Aut= +hor: Casey Rodarmor <<a href=3D"mailto:casey@rodarmor.com">casey@rodarmo= +r.com</a>><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><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, "ordinal numbers" 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 "ordinal num= +bers", or "ordinals", <br>as they are ordinal numbers in the= + mathematical sense. The word <br>"ordinal" 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's newly create= +d ordinals. The implicit <br>fee inputs carry the ordinals that were paid a= +s fees in the block'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'/7303780'/0= +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 >> 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'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 'ord'.<br></div></di= +v> + +--000000000000243fa105d8a4c314-- + + |