From f013681216d8b8b091183c362c54796cf9b5fdff Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Fri, 20 Jan 2023 14:54:55 -0800 Subject: [PATCH 01/11] New BIP: Ordinal Numbers Ordinal numbers are serial numbers for sats, assigned when mined and preserved across transactions. --- bip-0000.mediawiki | 288 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 288 insertions(+) create mode 100644 bip-0000.mediawiki diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki new file mode 100644 index 0000000000..92b49f3fd0 --- /dev/null +++ b/bip-0000.mediawiki @@ -0,0 +1,288 @@ +
+  BIP: ?
+  Layer: Applications
+  Title: Ordinal Numbers
+  Author: Casey Rodarmor 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/casey/ord/discussions/126
+  Status: Draft
+  Type: Informational
+  Created: 2022-02-02
+  License: PD
+
+ +== Introduction == + +=== Abstract === + +This document defines a scheme for assigning serial numbers to sats. + +=== Copyright === + +This work is placed in the public domain. + +=== Motivation === + +Bitcoin has no notion of stable, public accounts or identities. Addresses are +single-use, and wallet accounts are private. Additionally, the use of addresses +or public keys as stable identifiers precludes transfer of ownership or key +rotation. + +This proposal is motivated by the desire to provide stable identifiers that may +be used by Bitcoin applications. + +== Description == + +=== Design === + +Every sat 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, giving the order of each sat in the +totally supply. The word "ordinal" is nicely unambiguous, as it is not used +elsewhere in the Bitcoin protocol. + +The ordinal numbers of sats in transaction inputs are transferred to output +sats 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 sats contained in +any unspent outputs of the first transaction. This rule is required to handle +the two pairs of mainnet transactions with duplicate transaction IDs, namely +the coinbase transactions of blocks 91812/91842, and 91722/91880, mined before +[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP-34] made +the creation of transactions with duplicate IDs impossible. + +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 sats. The implicit fee inputs carry the sats that were +paid as fees in the block's transactions. + +Underpaying the subsidy does not change the ordinal numbers of sats mined +in subsequent blocks. Ordinals depend only on how many sats could have been +mined, not how many actually were. + +=== Specification === + +Sats are numbered and transferred with the following algorithm: + +
+# subsidy of block at given height
+def subsidy(height):
+  return 50 * 100_000_000 >> height // 210_000
+
+# first ordinal of subsidy of block at given height
+def first_ordinal(height):
+  start = 0
+  for height in range(height):
+    start += subsidy(height)
+  return start
+
+# assign ordinals in given block
+def assign_ordinals(block):
+  first = first_ordinal(block.height)
+  last = first + subsidy(block.height)
+  coinbase_ordinals = list(range(first, last))
+
+  for transaction in block.transactions[1:]:
+    ordinals = []
+    for input in transaction.inputs:
+      ordinals.extend(input.ordinals)
+
+    for output in transaction.outputs:
+      output.ordinals = ordinals[:output.value]
+      del ordinals[:output.value]
+
+    coinbase_ordinals.extend(ordinals)
+
+  for output in block.transaction[0].outputs:
+    output.ordinals = coinbase_ordinals[:output.value]
+    del coinbase_ordinals[:output.value]
+
+ +=== Terminology and Notation === + +A satpoint may be used to indicate the location of a sat 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 sat in question is at offset 6 in the first output of a transaction, its +satpoint is: + +`680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6` + +== 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 and layer +applications, even ones that were not designed with ordinal numbers in mind. + +Ordinal sats 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. + +By assigning ordinal numbers to all sats without the need for an explicit +creation step, the anonymity set of ordinal number users is maximized. + +Since a sat has an output that contains it, and an output has a public key that +controls it, the owner of a sat can respond to challenges by signing messages +using the address associated with the controlling UTXO. Additionally, a sat 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-sat values. + +=== Transfer and the Dust Limit === + +Any single-sat 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 sats [0,10], the current +dust limit is 5 sats, and Alice wishes to send send sat 4 and 6 to Bob, but +retain ordinal 5. Alice could construct a transaction with three outputs of +size 5, 1, and 5, containing sats [0,4], 5, and [6,10], respectively. 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 sats [0,4] to Bob, and return as change sat [5,10] to +Alice. The second transaction would take as inputs an output of at least 4 +sats, the change input, and an additional input of at least one sat; 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 sats. + +=== Objections === + +''Privacy: Ordinal numbers are public and thus reduce user privacy.'' + +The applications using ordinal numbers required them to be public, and reduce +the privacy of only those users that decide to use them. + +''Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as ordinals +received in a transaction may carry with them some public history.'' + +As anyone can send anyone else any sats, any reasonable person will assume that +a new owner of a particular sat 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 sats that they contain. + +=== Security === + +The public key associated with a sat 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 losing valuable sats 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 sats which might have some publicly +visible data associated with their ordinals with sats 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 sat can be sent to any address at any time, sat that are transferred, +even those with some public history, should be considered to be fungible with +other sats with no such history. + +=== Backward compatibility === + +Ordinal numbers are fully backwards compatible and require no changes to the +bitcoin network. + +=== Drawbacks === + +==== Large Index Size ==== + +Indexes supporting fast queries related to ordinals are slow to build and +consume large amounts of space. + +An O(1) index that maps UTXOs to the ordinals that they contain is currently +100 GiB. The same index including spent outputs is 10 TiB. + +An O(1) index supporting the opposite mapping, that of individual ordinals to +the UTXO that contains them, is likely to be intractable. However, an O(n) +index where n is the number of times an ordinal has changed hands, is fast and +practical. + +==== Large Location Proofs ==== + +A proof can be constructed that demonstrates that a particular sat is contained +in a particular output, however the proofs are large. Such a proof consists of: + +- Block headers +- A Merkle path to the coinbase transaction that created the sat +- The coinbase transaction that created the sat +- And for every spend of that sat: + - The spend transaction + - The transactions that created the inputs before the input that was spent, + to determine the values of the preceding inputs, to determine the position + of the sat + - And, if the sat was used as fees, all prior transaction in the block in + which it was spent, and the coinbase transaction, to determine the location + of the sat in the outputs. + +== Reference implementation == + +This document and an implementation of an index that tracks the position of +sats in the main chain are maintained [https://github.com/casey/ord here]. + +== References == + +A variation of this scheme was independently invented a decade ago by jl2012 +[https://bitcointalk.org/index.php?topic=117224.0 on the Bitcoin Forum]. + +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 +[https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki BIP 15]. From 9f81a71b9c6d80b8e447e7422d8da907d186175b Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Tue, 14 Feb 2023 04:58:50 -0600 Subject: [PATCH 02/11] Update bip-0000.mediawiki Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com> --- bip-0000.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index 92b49f3fd0..318a932dcd 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -69,7 +69,7 @@ mined, not how many actually were. Sats are numbered and transferred with the following algorithm: -
+```python
 # subsidy of block at given height
 def subsidy(height):
   return 50 * 100_000_000 >> height // 210_000

From 7c7de8bda7e3452d01701fea32c2020eaf23dd76 Mon Sep 17 00:00:00 2001
From: Casey Rodarmor 
Date: Tue, 14 Feb 2023 04:58:56 -0600
Subject: [PATCH 03/11] Update bip-0000.mediawiki

Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com>
---
 bip-0000.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki
index 318a932dcd..58a6428776 100644
--- a/bip-0000.mediawiki
+++ b/bip-0000.mediawiki
@@ -38,7 +38,7 @@ be used by Bitcoin applications.
 Every sat 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, giving the order of each sat in the
-totally supply. The word "ordinal" is nicely unambiguous, as it is not used
+total supply. The word "ordinal" is nicely unambiguous, as it is not used
 elsewhere in the Bitcoin protocol.
 
 The ordinal numbers of sats in transaction inputs are transferred to output

From 7950891da6a463afd64f66815457dada7c70a939 Mon Sep 17 00:00:00 2001
From: Casey Rodarmor 
Date: Sun, 21 May 2023 22:47:31 -0700
Subject: [PATCH 04/11] Change license to CC0

---
 bip-0000.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki
index 58a6428776..06a8c066da 100644
--- a/bip-0000.mediawiki
+++ b/bip-0000.mediawiki
@@ -8,7 +8,7 @@
   Status: Draft
   Type: Informational
   Created: 2022-02-02
-  License: PD
+  License: CC0-1.0
== Introduction == From 93a7ae6980dcd80ab9f064d19b09d8f3324b37fe Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 21 May 2023 22:52:44 -0700 Subject: [PATCH 05/11] Fix code formatting --- bip-0000.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index 06a8c066da..e262acd7b1 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -69,7 +69,7 @@ mined, not how many actually were. Sats are numbered and transferred with the following algorithm: -```python + # subsidy of block at given height def subsidy(height): return 50 * 100_000_000 >> height // 210_000 @@ -101,7 +101,7 @@ def assign_ordinals(block): for output in block.transaction[0].outputs: output.ordinals = coinbase_ordinals[:output.value] del coinbase_ordinals[:output.value] - + === Terminology and Notation === @@ -111,7 +111,7 @@ the addition of the offset of the ordinal within that output. For example, if the sat in question is at offset 6 in the first output of a transaction, its satpoint is: -`680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6` +680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6 == Discussion == From b802f83b86d9b0bd1f0882481b0176df2411ba35 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 21 May 2023 22:53:41 -0700 Subject: [PATCH 06/11] Fix list formatting --- bip-0000.mediawiki | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index e262acd7b1..95e7644164 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -259,17 +259,13 @@ practical. A proof can be constructed that demonstrates that a particular sat is contained in a particular output, however the proofs are large. Such a proof consists of: -- Block headers -- A Merkle path to the coinbase transaction that created the sat -- The coinbase transaction that created the sat -- And for every spend of that sat: - - The spend transaction - - The transactions that created the inputs before the input that was spent, - to determine the values of the preceding inputs, to determine the position - of the sat - - And, if the sat was used as fees, all prior transaction in the block in - which it was spent, and the coinbase transaction, to determine the location - of the sat in the outputs. +* Block headers +* A Merkle path to the coinbase transaction that created the sat +* The coinbase transaction that created the sat +* And for every spend of that sat: +** The spend transaction +** The transactions that created the inputs before the input that was spent, to determine the values of the preceding inputs, to determine the position of the sat +** And, if the sat was used as fees, all prior transaction in the block in which it was spent, and the coinbase transaction, to determine the location of the sat in the outputs. == Reference implementation == From bfff9020db56d18a69d193f3432a4ce6741d1097 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 21 May 2023 23:24:03 -0700 Subject: [PATCH 07/11] Note underpayment of block reward --- bip-0000.mediawiki | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index 95e7644164..e4d9961e6c 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -103,6 +103,11 @@ def assign_ordinals(block): del coinbase_ordinals[:output.value] +A miner may underpay the block reward, in which case +coinbase_ordinals will not be empty when +assign_ordinals returns. These sats are lost and not assigned to +any output of the coinbase transaction. + === Terminology and Notation === A satpoint may be used to indicate the location of a sat within an output. A From b9506fbcddc33d282ed12ed86dd8bab4bc60b47a Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 21 May 2023 23:26:52 -0700 Subject: [PATCH 08/11] Note date of index sizes --- bip-0000.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index e4d9961e6c..27f59f18c2 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -251,8 +251,8 @@ bitcoin network. Indexes supporting fast queries related to ordinals are slow to build and consume large amounts of space. -An O(1) index that maps UTXOs to the ordinals that they contain is currently -100 GiB. The same index including spent outputs is 10 TiB. +As of January, 2023, an O(1) index that maps UTXOs to the ordinals that they +contain is 100 GiB. The same index including spent outputs is 10 TiB. An O(1) index supporting the opposite mapping, that of individual ordinals to the UTXO that contains them, is likely to be intractable. However, an O(n) From bda5cc7c6f65bb4c74de0a3e7e660cbe61cea8a8 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Mon, 30 Oct 2023 15:07:16 -0700 Subject: [PATCH 09/11] Update comments-uri link --- bip-0000.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index 27f59f18c2..a508bd3f53 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -4,7 +4,7 @@ Title: Ordinal Numbers Author: Casey Rodarmor Comments-Summary: No comments yet. - Comments-URI: https://github.com/casey/ord/discussions/126 + Comments-URI: https://github.com/ordinals/ord/discussions/126 Status: Draft Type: Informational Created: 2022-02-02 From d1a5fda43ee927ad1ddcf3e33234d128976a8a46 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Fri, 6 Sep 2024 15:33:06 -0700 Subject: [PATCH 10/11] Fix typo and improve style --- bip-0000.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index a508bd3f53..d5b68483ab 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -191,8 +191,8 @@ the privacy of only those users that decide to use them. received in a transaction may carry with them some public history.'' As anyone can send anyone else any sats, any reasonable person will assume that -a new owner of a particular sat cannot be understood to be the old owner, or -have any particular relationship with the old owner. +the new owner of a particular sat cannot be understood to be the previous +owner, or have any particular relationship with the previous owner. ''Congestion: Adoption of ordinal numbers will increase the demand for transactions, and drive up fees.'' @@ -235,9 +235,9 @@ the users otherwise pseudonymous wallet outputs. === Fungibility considerations === -Since any sat can be sent to any address at any time, sat that are transferred, -even those with some public history, should be considered to be fungible with -other sats with no such history. +Since any sat can be sent to any address at any time, sats that are +transferred, even those with some public history, should be considered to be +fungible with other sats with no such history. === Backward compatibility === From bcb21c5b3e2fba4f9f41eaa4db7c020cea59cbc0 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sat, 7 Sep 2024 12:36:05 -0700 Subject: [PATCH 11/11] Update current index size --- bip-0000.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index d5b68483ab..3a6a0b3ba4 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -251,8 +251,8 @@ bitcoin network. Indexes supporting fast queries related to ordinals are slow to build and consume large amounts of space. -As of January, 2023, an O(1) index that maps UTXOs to the ordinals that they -contain is 100 GiB. The same index including spent outputs is 10 TiB. +As of September, 2024, an O(1) index that maps UTXOs to the ordinals that they +contain is 93 GiB. An O(1) index supporting the opposite mapping, that of individual ordinals to the UTXO that contains them, is likely to be intractable. However, an O(n)