Add draft BIP

bip.mediawiki

@@ -0,0 +1,165 @@
+<pre>
+  BIP: ?
+  Layer: Applications
+  Title: Ordinal Numbers
+  Author: Casey Rodarmor <casey@rodarmor.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/casey/ord/discussions/126
+  Status: Draft
+  Type: Informational
+  Created: 2022-02-02
+  License: PD
+</pre>
+
+== Introduction ==
+
+=== Abstract ===
+
+This document defines a scheme for numbering and tracking satoshis across transactions. These numbers, "ordinal numbers" in the language of this document, can be used as a useful primitive for a diverse range of applications, including NFTs, reputation systems, and Lightning Network-compatible stablecoins.
+
+=== Copyright ===
+
+This work is placed in the public domain.
+
+=== Motivation ===
+
+Bitcoin has no notion of a stable, public account or identity. Addresses are single-use, and wallet accounts, while permanent, are not publicly visible. Additionally, the use of addresses or public keys as identifiers precludes private key rotation or transfer of ownership.
+
+Many applications, some of which are detailed in this document, require stable, public identifiers tracking identity or ownership. This proposal is motivated by the desire to provide such a system of identifiers.
+
+== Description ==
+
+=== Design ===
+
+Every satoshi is serially numbered, starting at 0, in the order in which it is mined. These numbers are termed "ordinal numbers", or "ordinals", as they are ordinal numbers in the mathematical sense. The word "ordinal" is nicely unambiguous, as it is not used elsewhere in the Bitcoin protocol[0].
+
+The ordinal numbers of transaction inputs are transferred to outputs in first-in-first-out order, according to the size and order of the transactions inputs and outputs.
+
+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, concering to the ordinals it contains. The specification of a standardized message format for such purposes is deferred to a later BIP.
+
+Ordinal aware software should not mix outputs containing meaningful ordinals with outputs used for other purposes to avoid inadvertent loss of valuable ordinals, or privacy leaks allowing links between funds. For this reason, ordinal aware software using BIP-32 hierarchical deterministic key generation should use a key derivation path specific to ordinals.
+
+The suggested key derivation path is `m/44'/7303780'/0'/0`. This suggested derivation path has not been standardized and may change in the future[1].
+
+=== Specification ===
+
+Ordinals are created and assigned with the following algorithm:
+
+<pre>
+# subsidy of block at given height
+def subsidy(height):
+  return 50 * 100_000_000 >> int(height / 210_000)
+
+# first ordinal of subsidy of block at given height
+def first_ordinal(height):
+  start = 0
+  for height in range(height):
+    start += subsidy(height)
+  return start
+
+# assign ordinals in given block
+def assign_ordinals(block):
+  first = first_ordinal(block.height)
+  last = first + subsidy(block.height)
+  coinbase_ordinals = list(range(first, last))
+
+  for transaction in block.transactions[1:]:
+    ordinals = []
+    for input in transaction.inputs:
+      ordinals.extend(input.ordinals)
+
+    for output in transaction.outputs:
+      output.ordinals = ordinals[:output.value]
+      del ordinals[:output.value]
+
+    coinbase_ordinals.extend(ordinals)
+
+  for output in block.transaction[0].outputs:
+    output.ordinals = coinbase_ordinals[:output.value]
+    del coinbase_ordinals[:output.value]
+</pre>
+
+== Discussion ==
+
+=== Rationale ===
+
+Ordinal numbers are designed to be orthogonal to other aspects of the Bitcoin protocol, and can thus be used in conjunction with other layer-one techniques and applications, even ones that were not designed with ordinal numbers in mind.
+
+Ordinal satoshis can be secured using current and future script types. They can be held by single-signature wallets, multi-signature wallets, time-locked, and height-locked in all the usual ways.
+
+This orthogonality also allows them to be used with layer-two applications. A stablecoin issuer can promise to allow redemption of specific ranges of ordinals for $1 United States dollar each. Lightning Network nodes can then be used to create a USD-denominated Lightning Network, using existing software with very modest modifications.
+
+By assigning ordinal numbers to all satoshis without need for an explicit creation step, the anonymity set of ordinal number users is maximized.
+
+Since an ordinal number has an output that contains it, and an output has a public key that controls it, the owner of an ordinal can respond to challenges by signing messages using the public key associated with the controlling UTXO. Additionally, an ordinal can change hands, or its private key can be rotated without a change of ownership, by transferring it to a new output.
+
+Ordinals require no changes to blocks, transactions, or network protocols, and can thus be immediately adopted, or ignored, without impacting existing users.
+
+Ordinals do not have an explicit on-chain footprint. However, a valid objection is that adoption of ordinals will increase demand for outputs, and thus increase the size of the UTXO set that full nodes must track. See the objections section below.
+
+The ordinal number scheme is extremely simple. The specification above is 15 lines of code.
+
+Ordinals are fairly assigned. They are not premined, and are assigned proportionally to existing bitcoin holders.
+
+Ordinals are as granular as possible, as bitcoin is not capable of tracking ownership of sub-satoshi values.
+
+=== Objections ===
+
+''Privacy: Ordinal numbers are public and thus reduce user privacy.''
+
+The appllications using ordinal numbers required them to be public, and reduce the privacy of only those users that decide to use them.
+
+''Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as ordinals received in a transaction may carry with them some public history.''
+
+As anyone can send anyone else any ordinals, any reasonable person will assume that a new owner of a particular ordinal cannot be understood to be the old owner, or have any particular relationship with the old owner.
+
+''Congestion: Adoption of ordinal numbers will increase the demand for transactions, and drive up fees.''
+
+Since Bitcoin requires the development of a robust fee market, this is a strong positive of the proposal.
+
+''UTXO set bloat: Adoption of ordinal numbers will increase the demand for entries in the UTXO set, and thus increase the size of the UTXO set, which all full nodes are required to track.''
+
+The dust limit, which makes outputs with small values difficult to create, should encourage users to create non-dust outputs, and to clean them up once they no longer have use for the ordinals that they contain.
+
+=== Security ===
+
+The public key associated with an ordinal may change. This requires actively following the blockchain to keep up with key changes, and requires care compared to a system where public keys are static. However, a system with static public keys suffers from an inability for keys to be rotated or accounts to change hands.
+
+Ordinal-aware software must avoid destroying ordinals by unintentionally relinquishing them in a transaction, either to a non-controlled output or by using them as fees.
+
+=== Privacy considerations ===
+
+Ordinals are opt-in, and should not impact the privacy of existing users.
+
+Ordinals are themselves public, however, this is required by the fact that many of the applications that they are intended to enable require public identifiers.
+
+Ordinal aware software should never mix satoshis which might have some publicly visible data associated with their ordinals with satoshis intended for use in payments or savings, since this would associate that publicly visible data with the users otherwise pseudonymous wallet outputs.
+
+=== Fungibility considerations ===
+
+Since any ordinal can be sent to any address at any time, ordinals that are transferred, even those with some public history, should be considered to be fungible with other satoshis with no such history.
+
+=== Backward compatibility ===
+
+Ordinal numbers are fully backwards compatible and require no changes to the bitcoin network.
+
+== Reference implementation ==
+
+This document, along with an implementation of an ordinal index that tracks the position of ordinals in the main chain, is available [https://github.com/casey/ord here].
+
+== References ==
+
+For other colored coin proposals see [https://en.bitcoin.it/wiki/Colored_Coins the Bitcoin Wiki entry].
+
+For aliases, an implementation of short on-chain identifiers, see BIP 15.
+
+== Acknowledgements ==
+
+TODO: Everyone who helped. All remaining errors are my own.
+
+[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'.