Rewrite BIP

bip.mediawiki

@@ -15,7 +15,7 @@
 
 === Abstract ===
 
-This document defines a scheme for asigning serial numbers to satoshis.
+This document defines a scheme for assigning serial numbers to sats.
 
 === Copyright ===
 
@@ -35,39 +35,39 @@ be used by Bitcoin applications.
 
 === Design ===
 
-Every satoshi is serially numbered, starting at 0, in the order in which it is
+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 satoshi in
-the totally supply. The word "ordinal" is nicely unambiguous, as it is not used
+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 transaction inputs are transferred to outputs in
-first-in-first-out order, according to the size and order of the transactions
-inputs and outputs.
+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 ordinals 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.
+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 ordinals. The implicit fee inputs carry the ordinals that
-were paid as fees in the block's transactions.
+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 satoshis mined
-in subsequent blocks. Ordinals depend only on how many satoshis could have been
+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 ===
 
-Ordinals are created and assigned with the following algorithm:
+Sats are numbered and transferred with the following algorithm:
 
 <pre>
 # subsidy of block at given height
@@ -105,60 +105,34 @@ def assign_ordinals(block):
 
 === Terminology and Notation ===
 
-Ordinals may be written as the ordinal number followed by the Romance-language
-ordinal indicator °, for example 13°.
-
-A satpoint may be used to indicate the location of an ordinal within an output.
-A satpoint consists of an outpoint, i.e., a transaction ID and output index,
-with the addition of the offset of the ordinal within that output. For example,
-if the ordinal in question is at offset 6 in the first output of a transaction
-  can be written as:
+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`
 
-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 an x'ed quad, similar to a
-Lightning Network short channel ID with an additional number indicating the
-offset of the ordinal within the output. For example, the ordinal at offset 100
-in the output at offset 1, in the coinbase transaction of block 83 can be
-written as:
-
-`83x0x1x100`
-
-Satoshis with ordinals that are not valuable or notable can be referred to as
-cardinal, as their identity does not matter, only the amount. A cardinal output
-is one whose ordinals are unimportant for the purpose at hand, for example an
-output used only to provide padding to avoid creating a transaction with an
-output below the dust limit.
-
 == Discussion ==
 
 === Rationale ===
 
 Ordinal numbers are designed to be orthogonal to other aspects of the Bitcoin
 protocol, and can thus be used in conjunction with other layer one and layer
-two techniques and applications, even ones that were not designed with ordinal
-numbers in mind.
+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
+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.
 
-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
+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 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 address 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.
+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.
@@ -175,17 +149,17 @@ 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.
+ownership of sub-sat values.
 
 === Transfer and the Dust Limit ===
 
-Any ordinal transfer can be accomplished in a single transaction, but the
+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 ordinals [0,10], the current
-dust limit is 5 satoshis, and Alice wishes to send send ordinals 4° and 6° to
-Bob, but retain ordinal 5°. Alice could construct a transaction with three
-outputs of size 5, 1, and 5, containing ordinals [0,4], 5, and [6,10]. The
+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.
 
@@ -194,12 +168,12 @@ 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.
+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 ===
 
@@ -211,9 +185,9 @@ 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.
+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.''
@@ -227,17 +201,17 @@ 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.
+they no longer have use for the sats that they contain.
 
 === Security ===
 
-The public key associated with an ordinal may change. This requires actively
+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 destroying ordinals by unintentionally
+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.
 
@@ -249,16 +223,16 @@ 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
+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 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.
+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 ===
 
@@ -273,7 +247,7 @@ 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
-100GiB. The same index including spent outputs is 10TiB.
+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)
@@ -282,27 +256,25 @@ practical.
 
 ==== Large Location Proofs ====
 
-A proof can be constructed that demonstrates that a particular ordinal is
-contained in a particular output, however the proofs are large. Such a proof
-consists of:
+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 ordinal
-- The coinbase transaction that created the ordinal
-- And for every spend of that ordinal:
+- 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 ordinal
-  - And, if the ordinal was used as fees, all prior transaction in the block in
+    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 ordinal in the outputs.
+    of the sat in the outputs.
 
 == 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].
+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 ==