New BIP: Ordinal Numbers

casey commented at 11:46 pm on January 20, 2023: none

Ordinal numbers are serial numbers for sats, assigned when mined and preserved across transactions.

I originally posted an earlier draft of the BIP to bitcoin-dev in February of last year.

We’ve implemented a wallet and block explorer, with public instances on mainnet, signet, and testnet, and a wallet that uses sat control to ensure specific sats are transferred to specific outputs. Constructing such transactions is tricky, especially given the dust limit and doing proper fee estimation, but once you get the details right it works well, and the fact that such transactions are otherwise normal Bitcoin transactions means that existing bitcoin infrastructure can be leveraged.

Since we’ve been using ordinal numbers in production and getting some users of the software it seemed appropriate to request a BIP number.

I’ve never applied for a BIP number before, so definitely let me know if anything should be changed or can be improved!

kallewoof commented at 11:34 pm on February 7, 2023: member

@luke-jr I think this qualifies for a BIP assignment.

Edit: I spoke in haste. Will return with feedback.

in bip-0000.mediawiki:46 in 5b71a8255a outdated

41+totally supply. The word "ordinal" is nicely unambiguous, as it is not used
42+elsewhere in the Bitcoin protocol.
43+
44+The ordinal numbers of sats in transaction inputs are transferred to output
45+sats in first-in-first-out order, according to the size and order of the
46+transactions inputs and outputs.

unknown commented at 9:29 am on February 13, 2023:

I like ordinals and inscriptions. However, the concept of assigning serial numbers to sats or transferring them based on size and order isnt a part of bitcoin protocol. So ordinals do not really require a BIP and could work at layer 2 or externally.

Note: This repo is considered an official bitcoin repo for improvements. However, you can always maintain such docs outside this repo and could be used by other bitcoin projects if necessary.

apoelstra commented at 1:45 pm on February 13, 2023:

BIPs are not just about layer 1 protocols. As an example, BIPs 173/350 (bech32 and bech32m) define an address format that never touches the p2p layer at all. BIP32 describes a key derivation scheme that is not even visible on the blockchain or p2p layer.

Essentially, to get a BIP, you just need to post something on the mailing list and then post a well-formatted well-specified document here. It doesn’t need to be something that anybody needs to use, or even something that anybody should use. I guess it needs to be sorta Bitcoin-related, but this meets that threshold :).

michaelfolkson commented at 2:29 pm on February 13, 2023:

Agreed. This doc could be maintained outside the BIPs repo but if the author wants a BIP I don’t see a reason to prevent this.

From BIP 2:

Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

The “must represent a net improvement” is a bit of a grey area but when unsure I think the BIP editors should lean towards giving the BIP number. If people want to use ordinals a specification on how to use ordinals (ideally using block space as efficiently as possible) seems like a net improvement to me.

Semisol changes_requested

Semisol commented at 5:26 pm on February 13, 2023: none

NACK. I currently do not see why this needs to be a BIP since:

it is not a part of the Bitcoin protocol
it isn’t useful to a majority of Bitcoin users

BullishNode commented at 5:52 pm on February 13, 2023: none

NACK.

Outside of the scope of Bitcoin Improvement Proposals.

I suggest you start a new Ord Improvement Proposal repository for standards relating to your software/system, if not done already.

luke-jr commented at 5:33 am on February 14, 2023: member

Seems within scope to me, even if ultimately rejected by the community.

Edit: Though since this is essentially an attack on Bitcoin, I would encourage the author to withdraw it and abandon it entirely.

casey commented at 8:21 am on February 14, 2023: none

Thank you Luke, I appreciate it.

Users have already begun financially relying on the details of ordinals, so I think at least for clarity it should be a BIP.

A number like 1337 or 4000 might be good. It’s fun, and also suggests that it’s way off in the stratosphere, away from the other, more serious BIPs. Also, having a larger number than the 300 series might signal nicely to those concerned that it’s a worse idea than Drivechain.

casey commented at 8:22 am on February 14, 2023: none

I’m very open to style, license, and scope feedback, since I’ve never submitted a BIP here for review.

in bip-0000.mediawiki:41 in 5b71a8255a outdated

36+=== Design ===
37+
38+Every sat is serially numbered, starting at 0, in the order in which it is
39+mined. These numbers are termed "ordinal numbers", or "ordinals", as they are
40+ordinal numbers in the mathematical sense, giving the order of each sat in the
41+totally supply. The word "ordinal" is nicely unambiguous, as it is not used

unknown commented at 9:29 am on February 14, 2023:

0total supply. The word "ordinal" is nicely unambiguous, as it is not used

in bip-0000.mediawiki:72 in 5b71a8255a outdated

67+
68+=== Specification ===
69+
70+Sats are numbered and transferred with the following algorithm:
71+
72+<pre>

unknown commented at 9:31 am on February 14, 2023:

0```python

unknown approved

unknown commented at 9:33 am on February 14, 2023: none

ACK

Added 2 suggestions:

Fix typo
Syntax highlighting for code

casey commented at 10:59 am on February 14, 2023: none

ACK

Added 2 suggestions:

Fix typo

Syntax highlighting for code

Nice, fixed! Thank you 👍

in bip-0000.mediawiki:11 in 7716e7c6cc outdated

 6+  Comments-Summary: No comments yet.
 7+  Comments-URI: https://github.com/casey/ord/discussions/126
 8+  Status: Draft
 9+  Type: Informational
10+  Created: 2022-02-02
11+  License: PD

Semisol commented at 11:22 am on February 14, 2023:

Why is Public Domain no longer acceptable for new BIPs?

In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.

(BIP-0002)

in bip-0000.mediawiki:104 in 5b71a8255a outdated

 99+    coinbase_ordinals.extend(ordinals)
100+
101+  for output in block.transaction[0].outputs:
102+    output.ordinals = coinbase_ordinals[:output.value]
103+    del coinbase_ordinals[:output.value]
104+</pre>

unknown commented at 12:21 pm on February 14, 2023:

0</source>

unknown commented at 12:23 pm on February 14, 2023: none

Sorry my earlier suggestion in https://github.com/bitcoin/bips/pull/1408/commits/b46f8a9b411ffd82327ae658fd63a767baea9e1d was incorrect as it works only for markdown files and this is a mediawiki file.

in bip-0000.mediawiki:72 in b46f8a9b41 outdated

68@@ -69,7 +69,7 @@ mined, not how many actually were.
69 
70 Sats are numbered and transferred with the following algorithm:
71 
72-<pre>
73+```python

unknown commented at 12:26 pm on February 14, 2023:

0<source lang="python">

junderw commented at 3:51 pm on February 14, 2023: contributor

I don’t think this should be a BIP, but rather it should be managed separately like BOLTs for lightning, EIPs for Ethereum, and SLIPs for Satoshi Labs proposals.

NACK.

michaelfolkson commented at 4:07 pm on February 14, 2023: contributor

Is this going to need a series of BIPs or is a single BIP number going to be sufficient @casey?

I don’t think this should be a BIP, but rather it should be managed separately like BOLTs for lightning, EIPs for Ethereum, and SLIPs for Satoshi Labs proposals. @junderw: It has been discussed previously by at least one BIP editor that BOLTs could potentially become BIPs in future. So BOLTs aren’t in same bracket as Ethereum EIPs which are for a totally different blockchain. I’m not sure about the history on SLIPs. It seems to me that some of those could have possibly been BIPs too and perhaps could be in future.

I get why people don’t like this proposal but there are other BIPs that are disliked too and we should try to be consistent with the guidelines from BIP 2 of what should and shouldn’t be a BIP even if we dislike a particular proposal.

Semisol commented at 5:05 pm on February 14, 2023: none

@junderw: It has been discussed previously by at least one BIP editor that BOLTs could potentially become BIPs in future. So BOLTs aren’t in same bracket as Ethereum EIPs which are for a totally different blockchain. I’m not sure about the history on SLIPs. It seems to me that some of those could have possibly been BIPs too and perhaps could be in future.

BOLTs should stay separate. It has grown into something that would ideally have its own proposals.

I get why people don’t like this proposal but there are other BIPs that are disliked too and we should try to be consistent with the guidelines from BIP 2 of what should and shouldn’t be a BIP even if we dislike a particular proposal.

API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications: Nope, only 1
Useful to a reasonable amount of Bitcoin users: no
also that this is widely rejected

michaelfolkson commented at 7:04 pm on February 14, 2023: contributor

Ugh, looked into some of the cheerleaders for this and it is the Ethereum, anti Bitcoin maximalists, “we need to change Bitcoin culture” time wasting trolls.

edit: Think this is going to be a time wasting attack vector for the BIP editors so leaning towards not giving it this a BIP number now.

ghost commented at 0:26 am on February 15, 2023: none

Seems within scope to me, even if ultimately rejected by the community.

Edit: Though since this is essentially an attack on Bitcoin, I would encourage the author to withdraw it and abandon it entirely.

Spreading misinformation that coinjoin transactions are affected because of ordinals is an attack on bitcoin. Doesn’t look good for a BIP editor to get involved in such things. Maybe read this thread when you get time: https://web.archive.org/web/20230215002302/https://twitter.com/1440000bytes/status/1624540320309596160

junderw commented at 4:25 am on February 15, 2023: contributor

Spreading misinformation that coinjoin transactions are affected because of ordinals is an attack on bitcoin. Doesn’t look good for a BIP editor to get involved in such things. Maybe read this thread when you get time: https://web.archive.org/web/20230215002302/https://twitter.com/1440000bytes/status/1624540320309596160

This is hugely irrelevant to this PR discussion.

in bip-0000.mediawiki:57 in 7716e7c6cc outdated

52+the two pairs of mainnet transactions with duplicate transaction IDs, namely
53+the coinbase transactions of blocks 91812/91842, and 91722/91880, mined before
54+[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP-34] made
55+the creation of transactions with duplicate IDs impossible.
56+
57+For the purposes of the assignment algorithm, the coinbase transaction is

vicariousdrama commented at 5:51 am on February 15, 2023:

This paragraph and next could use more clarification. If the input order is coinbase subsidy + inputs of fee-paying transactions, what is the result when a miner forgoes either the subsidy and/or fees? Which ordinals are “burned” those from the subsidy, or those from the fees paid? E.g., at time of writing, subsidy is 625,000,000 sats. If fees paid are another 10,000,000 and the miner erroneously accepts 322,500,000 does that burn effectively burn the ordinals of all the fees paid and part of the subsidy that should have been ?

ghost commented at 6:41 am on February 15, 2023: none

This is hugely irrelevant to this PR discussion.

This is relevant to PR discussion as BIP editor who is expected to merge this pull request has accused author of attacking bitcoin and involved in sharing misleading things on social media related to this PR.

Let me share something that is irrelevant to this PR: #1408 (comment)

It doesn’t matter who uses bitcoin and it can be used for things you don’t like or by people you don’t like.

Semisol commented at 7:39 am on February 15, 2023: none

This is relevant to PR discussion as BIP editor who is expected to merge this pull request has accused author of attacking bitcoin and involved in sharing misleading things on social media related to this PR.

Anyone may have opinions and share their thoughts. This does not impact the merging of this BIP

Let me share something that is irrelevant to this PR: #1408 (comment)

It doesn’t matter who uses bitcoin and it can be used for things you don’t like or by people you don’t like.

It’s not something a subset of people “don’t like” – it is misuse of the network, which was meant for financial transactions (the whitepaper, name and code point to this) for data storage (which was not an intended use case, and any ways to do that were limited, like OP_RETURN being capped at 80 bytes)

casey commented at 8:03 am on February 15, 2023: none

I’d like to just comment here with my understanding of the BIP process, since there seem to be many misunderstandings. An accepted BIP does not indicate endorsement by the BIP repo maintainers, Bitcoin Core, or the larger Bitcoin community.

A BIP is more akin to a form of technical documentation or standard.

Similarly, a BIP number is also not an endorsement, merely an identifier which allows the Bitcoin community to more easily reference and discuss the BIP in question.

A lot of the comments here are off topic, according to my understanding of this repo’s purpose.

If my understanding is wrong, please let me know, and I’ll close this PR!

ghost commented at 11:03 am on February 15, 2023: none

Anyone may have opinions and share their thoughts. This does not impact the merging of this BIP @Semisol See #1104 as an example how opinions of editor(s) can delay merging of PRs

Semisol commented at 11:57 am on February 15, 2023: none

See #1104 as an example how opinions of editor(s) can delay merging of PRs

Also, what happens if merging of this gets delayed? It doesn’t prevent you from using ordinals or inscribing what is in my opinion bullshit.

vikbtc commented at 7:43 pm on February 15, 2023: none

NACK. This BIP is antithetical to the goals of Bitcoin, an open financial network. Eliminating fungibility and enabling new types of tracking across transactions is not a feature, but a bug to be fixed.

BullishNode commented at 7:46 pm on February 15, 2023: none

ACK

This would aid users by having a better known and recognized standard. Similar to BIP32

Standards relating to tokenization schemes and NFTs are completely irrelevant to Bitcoin.

As mentionned in my previous comment, if Ord wants to standardize its codebase and practices, they should create their own Ordinals Improvement Proposals.

eragmus commented at 8:13 pm on February 15, 2023: none

for data storage (which was not an intended use case, and any ways to do that were limited, like OP_RETURN being capped at 80 bytes) @Semisol It was not actually limited in practice, since customers of miners’ blockspace have been storing arbitrary data in Bitcoin via p2ms regardless, due to the lack of OP_RETURN flexibility, which was worse for Bitcoin than OP_RETURN (occupied nodes’ RAM), yet done anyway because “you cannot stop the free market”; if you try, you will end up with sub-optimal outcomes and an inefficient market. Inscriptions is better than the real alternative of p2ms, and so is an improvement even in just this simple way to Bitcoin’s functioning.

Arbitrary data (with its inherent mix of pros and cons) has been stored in Bitcoin throughout its history, prior to Inscriptions, so Inscriptions is really nothing new:

It’s not something a subset of people “don’t like” – it is misuse of the network, which was meant for financial transactions (the whitepaper, name and code point to this) @Semisol However, it is exactly about what people do not like, and it is exactly not a misuse of the network.

In reality, the market demand (fee market is competitive, fee rate determines priority; if the non-financial tx with higher fee rate outcompetes the financial tx with lower fee rate, then this is the free market speaking about where real economic value lies, as an example) is what actually determines for which use the miners sell their finite blockspace to their customers (those paying for transactions) – and is what determines good/desirable vs. bad/undesirable/spam/nonsense/stupid/etc. The individual opinion of someone is not what determines which uses are valid or invalid, as of course it is the miners who “own” that blockspace, so it is only the miners who make that determination (and if users for example try to stop nodes from relaying certain transactions to miners, ahem, it only incentivizes miners to create alternative channels for users to directly send transactions to miners, which as you may imagine creates all kinds of unintended consequences that are bad for Bitcoin – you must remember the bottom line realities of the network, upon which the unstoppable free market operates, in order to avoid making mistakes that make what is seen as a problem become even worse).

Miners are incentivized to increase their total revenue per block, as a course of normal business, and also as they try to offset their exponentially-declining subsidy revenue (which is meant to be replaced with fee revenue, hence the name ‘subsidy’). As such, miners do not care to pass moral or any other such judgement to choose to censor technically-valid bitcoin transactions (and since Bitcoin is supposed to be a censorship-resistant network, we would hope so!).

At best, Bitcoin is designed so that miners simply behave as rational economic actors, which means they should be optimizing their fee revenue, which in turn is good for Bitcoin as it encourages censorship-resistance, and also increases Bitcoin’s “security budget” (relevant when considering Bitcoin inherently exists in an adversarial environment in which hostile hashrate must be assumed to exist) – by encouraging higher-fee transactions that are economically meaningful on the base layer (this is what determines ‘value’, not any moral or other judgment).

Anything that increases demand for Bitcoin’s supply of blockspace, thus allowing bocks to be filled with a floor of lower fee-rate transactions to create a competitive fee-rate market, acts to boost fee-rate pressure, thus helping to increase the fee-to-subsidy ratio of each block and improving Bitcoin’s security. Since security is the number 1 priority of any Bitcoin user, without which everything else is irrelevant, the number 1 priority should be to boost demand for blockspace.

Inscriptions simply popularizes another demand for blockspace (arbitrary data stored by customers desiring the best decentralized network on Earth), beyond the existing demands from SoV (store of value) and MoE (medium of exchange) (low-value high-volume MoE transactions go on second layers, high-value low-volume MoE transactions go on base layer) uses that so far have not been sufficient to reliably fill blocks & generate enough fee pressure to offset the subsidy (fee-to-subsidy ratio of 100%).

Inscriptions theoretically (and so far in practice, however the fee-to-subsidy ratio of each blocks is still only 3.5%, since this only picked up steam 2 weeks ago) achieves this boost in blockspace demand by filling blocks and increasing economic activity on the base layer (vs. the last 1.5 years that have been marred with many non-full blocks and thus paltry fees – objectively bad from the point of view of network security), thus objectively it is not a misuse of the network, and rather it is “good for bitcoin” for anyone who cares about Bitcoin’s security and security sustainability (vis a vis the hashrate sustaining itself without the exponentially-declining subsidy), and who is able and willing to truly appreciate what a censorship-resistant network requires to function successfully in an adversarial environment. Really, it is a matter of being focused on priorities, so that the number 1 priority of security and security sustainability is able to rise in your mind to the top of consideration (over lesser considerations of judging uses as ‘good’ vs. ‘bad’/’nonsense’/‘spam’).

Disclaimer: I have not used Inscriptions nor do I intend to use it anytime soon, so I am not speaking in my own interest, I am only speaking in the interest of Bitcoin.

eragmus commented at 8:20 pm on February 15, 2023: none

Eliminating fungibility and enabling new types of tracking across transactions is not a feature, but a bug to be fixed. @vikbtc From my understanding, this is actually FUD.

The Ordinals system is voluntary, and it is a way of designating sats as having different numismatic value, based on fixed properties, so simplistically:

rarest
rarer
rare
unrare
unrarer
unrarest

This classification doesn’t make sats less fungible, since it’s only judging based on “rarity”, with the idea to add numismatic market value on top of the underlying bitcoin market value of the sats. It does not make sense to not accept sats on basis of rarity labeling, so it doesn’t hurt fungibility.

It’s like fiat coins, which can all be judged numismatically on such a scale of “rarest” to “unrarest”. This aspect does not hurt fungibility of the coins, and it only potentially helps you with more value for the coins if you recognize the numismatic value of the coins.

So, Ordinals (system of having sats of different rarities) does not hurt you, only potentially helps you.

Note: Ordinals and Inscriptions are two different things. I have commented about Inscriptions in my previous post.

vicariousdrama commented at 8:49 pm on February 15, 2023: none

Concept ACK for BIP assignment. It’s informational, and good for consistency for those that seek to adopt it. It has no bearing on consensus rules, but appropriately takes into consideration changes over time.

vostrnad commented at 0:50 am on February 16, 2023: contributor

Concept ACK for BIP assignment. While this proposal is controversial, not useful to most users, and argued by some to be outright malicious, these were never reasons to reject a BIP.

in bip-0000.mediawiki:255 in 7716e7c6cc outdated

245+
246+Indexes supporting fast queries related to ordinals are slow to build and
247+consume large amounts of space.
248+
249+An O(1) index that maps UTXOs to the ordinals that they contain is currently
250+100 GiB. The same index including spent outputs is 10 TiB.

vostrnad commented at 0:57 am on February 16, 2023:

The word “currently” is not specific, these numbers should instead be accompanied by something like “as of block height X” and maybe the blockchain size at that time to put them in perspective.

in bip-0000.mediawiki:68 in 7716e7c6cc outdated

63+
64+Underpaying the subsidy does not change the ordinal numbers of sats mined
65+in subsequent blocks. Ordinals depend only on how many sats could have been
66+mined, not how many actually were.
67+
68+=== Specification ===

vostrnad commented at 1:04 am on February 16, 2023:

Specification in BIPs is (as far as I understand) usually given in plain English with well-defined notation where necessary, not in code (reference implementation can be included in the BIP’s corresponding folder). This is (again, as far as I understand) not a hard requirement for merging, just something to consider.

viresinnumeris-1 commented at 2:27 pm on February 16, 2023: none

This discussion is getting more and more off-track. Let’s get back to the issue under discussion: Should this PR be assigned a BIP?

Referring to BIP-2 (BIP process, revised), it is stated that the idea should first be submitted to the dev mailing list for discussion and public vetting. The author of this PR did submit a draft BIP on Feb 23 2022, but it garnered very little discussion. In fact, of the two devs who bothered to respond, one gave it an ACK and the other a NACK. This hardly qualifies as a discussion or vetting, and most certainly not a community consensus.

So instead of the author seeking further discussion or community feedback before opening a PR here, we find ordinals suddenly live on the mainnet around the same time that this PR is opened. That is literally not what the BIP workflow is about. This is akin to zero-day behavior.

If the author chooses not respect BIP guidelines and processes, why bother seeking a BIP number here?

Assigning this PR a BIP number would send to the community a strong signal that BIP-2 is no longer relevant.

Hard NACK on BIP number assignment.

michaelfolkson commented at 2:55 pm on February 16, 2023: contributor

@viresinnumeris-1: A couple of things to push back on. This is a proposed Informational BIP, not a Standards BIP. Unlike standards (e.g. soft fork proposals) which should clearly be formalized prior to going live, informational BIPs don’t have this requirement. There could be a future informational BIP for say Miniscript or SLIP39 years after widespread use.

Similarly community consensus is not required for an informational BIP. From BIP 2:

Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.

Whether this gets allocated a BIP number or not seems ultimately down to the BIP editors’ discretion to me and whether or not this is going to be used by trolls to waste their time.

itme-brain commented at 3:27 pm on February 16, 2023: none

NACK

This should be managed in a separate repo for the Ordinal Project similar to BOLTs. This could be OIP-001.

ghost commented at 3:46 pm on February 16, 2023: none

@viresinnumeris-1: A couple of things to push back on. This is a proposed Informational BIP, not a Standards BIP. Unlike standards (e.g. soft fork proposals) which should clearly be formalized prior to going live, informational BIPs don’t have this requirement. There could be a future informational BIP for say Miniscript or SLIP39 years after widespread use.

Similarly community consensus is not required for an informational BIP. From BIP 2:

Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.

Whether this gets allocated a BIP number or not seems ultimately down to the BIP editors’ discretion to me and whether or not this is going to be used by trolls to waste their time. @michaelfolkson Agree with this. I would not be surprised if most of the reviewers have not read other BIPs that are already maintained in this repository. I would not blame anyone though as initially I was also not sure and wanted to avoid this controversy so suggested it being maintained elsewhere like a few other proposals used in bitcoin projects. I agree with @apoelstra and ACKed it with some suggestions in review.

Although I do not understand what exactly would reviewers achieve by NACKing and not getting this merged as one of the reviewer mentioned ordinals can work without this BIP. Maybe reasons are political or gain some twitter points?

junderw commented at 5:13 pm on February 16, 2023: contributor

Whether this gets allocated a BIP number or not seems ultimately down to the BIP editors’ discretion to me and whether or not this is going to be used by trolls to waste their time.

This is basically what it comes down to, IMO.

Semisol commented at 7:01 pm on February 16, 2023: none

Concept ACK for BIP assignment. While this proposal is controversial, not useful to most users, and argued by some to be outright malicious, these were never reasons to reject a BIP.

At least it should meet the 2 compatible implementations requirement 😅

vostrnad commented at 7:07 pm on February 16, 2023: contributor

@Semisol That’s a requirement for moving a BIP to Final status, not for BIP assignment.

raphjaph commented at 7:15 pm on February 16, 2023: contributor

Concept ACK for BIP assignment. While this proposal is controversial, not useful to most users, and argued by some to be outright malicious, these were never reasons to reject a BIP.

At least it should meet the 2 compatible implementations requirement 😅

https://ordinals.com/preview/6f46a2a830a90e406245b188631cd15ffea31b8be146255ec39d4d46bbe15663i0

ghost commented at 7:21 pm on February 16, 2023: none

Concept ACK for BIP assignment. While this proposal is controversial, not useful to most users, and argued by some to be outright malicious, these were never reasons to reject a BIP.

At least it should meet the 2 compatible implementations requirement 😅

Apart from thing shared by @vostrnad , I would like to inform you that your drama, misinformation and use of reaction emojis do not affect bitcoin.

Maybe try these things in nostr repo and sell your NIP 5 identifiers as cash grab.

in bip-0000.mediawiki:103 in 7716e7c6cc outdated

 98+
 99+    coinbase_ordinals.extend(ordinals)
100+
101+  for output in block.transaction[0].outputs:
102+    output.ordinals = coinbase_ordinals[:output.value]
103+    del coinbase_ordinals[:output.value]

brandonblack commented at 7:03 am on February 17, 2023:

This portion of the spec means that when a miner underpays the subsidy, the first sat destroyed is the last sat from the fee of the last transaction. While it would complicate the spec slightly, there are 2 alternatives I think worth considering:

fees go first, then subsidy
compute lost_sats = len(fee_ordinals)+subsidy(block.height)-sum(outs) and then before appending fee ordinals do coinbase_ordinals = coinbase_ordinals[:-lost_sats]

Psifour commented at 6:44 pm on August 12, 2023:

Despite facilitating non-fungible behavior, there is nothing in this that inhibits treating the sats as fully-fungible which means that the value of a single ‘fee sat’ is the same as the value of a single ‘subsidy sat’. Given that, the priority should be on the single large range from the subsidy as that is the simpler range to track/store/lookup whereas the fee will be made, typically, of many small ranges.

Semisol commented at 2:35 pm on February 17, 2023: none

Concept ACK for BIP assignment. While this proposal is controversial, not useful to most users, and argued by some to be outright malicious, these were never reasons to reject a BIP.

At least it should meet the 2 compatible implementations requirement 😅

ordinals.com/preview/6f46a2a830a90e406245b188631cd15ffea31b8be146255ec39d4d46bbe15663i0

that does not implement ordinals it just extracts the inscription from a TX

make an ordinals wallet

vicariousdrama commented at 2:41 pm on February 17, 2023: none

At least it should meet the 2 compatible implementations requirement 😅

//snipped

that does not implement ordinals it just extracts the inscription from a TX

There is no requirement for an Informational BIP to have 2 compatible implementations to be accepted as a BIP and assigned a number.

kallewoof commented at 11:23 pm on February 17, 2023: member

BIP assignments are not endorsements, merely a way to conveniently refer to various proposals.

There have even in the past been proposals that all pull requests are automatically assigned their pull request number (e.g. this would be BIP 1408), but this has not been embraced (yet), and I think having some kind of filter between opening a pull request and number assignment has been useful so far, but this has also consistently been misinterpreted as some form of approval or endorsement, so perhaps it’s time we switch to PR ID.

brandonblack commented at 0:14 am on February 18, 2023: contributor

If a second compatible implementation becomes a main blocker to assigning a BIP number, in a week or so I can publish a ~1kloc JS project that builds a (relatively) efficient SQL TX graph and supports looking up and tracking any Ordinal or Inscription. It’s not really intended for public use, but does some specific useful jobs.

ChrisMartl commented at 10:21 am on February 18, 2023: none

for data storage (which was not an intended use case, and any ways to do that were limited, like OP_RETURN being capped at 80 bytes)

@Semisol It was not actually limited in practice, since customers of miners’ blockspace have been storing arbitrary data in Bitcoin via p2ms regardless, due to the lack of OP_RETURN flexibility, which was worse for Bitcoin than OP_RETURN (occupied nodes’ RAM), yet done anyway because “you cannot stop the free market”; if you try, you will end up with sub-optimal outcomes and an inefficient market. Inscriptions is better than the real alternative of p2ms, and so is an improvement even in just this simple way to Bitcoin’s functioning.

Arbitrary data (with its inherent mix of pros and cons) has been stored in Bitcoin throughout its history, prior to Inscriptions, so Inscriptions is really nothing new:

http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

https://ourbigbook.com/cirosantilli/cool-data-embedded-in-the-bitcoin-blockchain

https://fc18.ifca.ai/preproceedings/6.pdf

It’s not something a subset of people “don’t like” – it is misuse of the network, which was meant for financial transactions (the whitepaper, name and code point to this)

@Semisol However, it is exactly about what people do not like, and it is exactly not a misuse of the network.

In reality, the market demand (fee market is competitive, fee rate determines priority; if the non-financial tx with higher fee rate outcompetes the financial tx with lower fee rate, then this is the free market speaking about where real economic value lies, as an example) is what actually determines for which use the miners sell their finite blockspace to their customers (those paying for transactions) – and is what determines good/desirable vs. bad/undesirable/spam/nonsense/stupid/etc. The individual opinion of someone is not what determines which uses are valid or invalid, as of course it is the miners who “own” that blockspace, so it is only the miners who make that determination (and if users for example try to stop nodes from relaying certain transactions to miners, ahem, it only incentivizes miners to create alternative channels for users to directly send transactions to miners, which as you may imagine creates all kinds of unintended consequences that are bad for Bitcoin – you must remember the bottom line realities of the network, upon which the unstoppable free market operates, in order to avoid making mistakes that make what is seen as a problem become even worse).

Miners are incentivized to increase their total revenue per block, as a course of normal business, and also as they try to offset their exponentially-declining subsidy revenue (which is meant to be replaced with fee revenue, hence the name ‘subsidy’). As such, miners do not care to pass moral or any other such judgement to choose to censor technically-valid bitcoin transactions (and since Bitcoin is supposed to be a censorship-resistant network, we would hope so!).

At best, Bitcoin is designed so that miners simply behave as rational economic actors, which means they should be optimizing their fee revenue, which in turn is good for Bitcoin as it encourages censorship-resistance, and also increases Bitcoin’s “security budget” (relevant when considering Bitcoin inherently exists in an adversarial environment in which hostile hashrate must be assumed to exist) – by encouraging higher-fee transactions that are economically meaningful on the base layer (this is what determines ‘value’, not any moral or other judgment).

Anything that increases demand for Bitcoin’s supply of blockspace, thus allowing bocks to be filled with a floor of lower fee-rate transactions to create a competitive fee-rate market, acts to boost fee-rate pressure, thus helping to increase the fee-to-subsidy ratio of each block and improving Bitcoin’s security. Since security is the number 1 priority of any Bitcoin user, without which everything else is irrelevant, the number 1 priority should be to boost demand for blockspace.

Inscriptions simply popularizes another demand for blockspace (arbitrary data stored by customers desiring the best decentralized network on Earth), beyond the existing demands from SoV (store of value) and MoE (medium of exchange) (low-value high-volume MoE transactions go on second layers, high-value low-volume MoE transactions go on base layer) uses that so far have not been sufficient to reliably fill blocks & generate enough fee pressure to offset the subsidy (fee-to-subsidy ratio of 100%).

Inscriptions theoretically (and so far in practice, however the fee-to-subsidy ratio of each blocks is still only 3.5%, since this only picked up steam 2 weeks ago) achieves this boost in blockspace demand by filling blocks and increasing economic activity on the base layer (vs. the last 1.5 years that have been marred with many non-full blocks and thus paltry fees – objectively bad from the point of view of network security), thus objectively it is not a misuse of the network, and rather it is “good for bitcoin” for anyone who cares about Bitcoin’s security and security sustainability (vis a vis the hashrate sustaining itself without the exponentially-declining subsidy), and who is able and willing to truly appreciate what a censorship-resistant network requires to function successfully in an adversarial environment. Really, it is a matter of being focused on priorities, so that the number 1 priority of security and security sustainability is able to rise in your mind to the top of consideration (over lesser considerations of judging uses as ‘good’ vs. ‘bad’/’nonsense’/‘spam’).

Disclaimer: I have not used Inscriptions nor do I intend to use it anytime soon, so I am not speaking in my own interest, I am only speaking in the interest of Bitcoin. @eragmus: Speaking also in the interest of Bitcoin and using BIP-0002: “[…] collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.“, express following concern:

What are the economical incentives for a rational actor to run a bitcoin Full-Node (if not running as Lightning-Node for whatever reason)?

This actor/role in the bitcoin network provides storage resource and verification processing (energy/time) mostly for free. If such kind of rational actors do not agree to provide storage for non-financial-transaction-bits (since once the e.g. 1 TB SSD is full, these actors will not buy a SSD of bigger capacity and provide this resource to the bitcoin network) then, they will change to run a Light-Node (to participate sovereignly in the network). This rational action could have the total effect to reduce the decentralization and security of the bitcoin network. Miner-actors can finance themselves OTC over the short/middle term. Although, over the long run the network could have its time counted.

It would be in interest of all the bitcoin network’s stakeholders to take decisions/actions in consensus and strengthen the incentives of Full-Node-Runners to provide storage resource. Focusing only on the economical/financial incentives of miner-actors ceteris paribus would destabilize the storage resources allocation, centralize and insecure the network against malicious actions/actors.

In consequence, as @luke-jr proposed: the autor of this proposal is encouraged to withdraw it and abandon it entirely. The autor of this proposal is free to pursue innovations and ideas in e.g. an OIP-0001 or the likes.

junderw commented at 2:11 pm on February 18, 2023: contributor

so perhaps it’s time we switch to PR ID.

This could be useful. But if we were to do this, an automated system similar to that used in the EIP repo should be set up.

ie. Automatically change the state of a submitted BIP to “stale” when it stays in the initial state for too long without any activity.

This “stale” state probably won’t be appropriate for informational BIPs, but definitely should be used for other types of BIPs… there also needs to be some way to automate checking if the BIP is well formatted. (ie. it won’t be auto-accepted until the BIP is formatted in a certain way.)

Looking at a few PRs on the EIP repo and looking at how the authors interact with the bot might be helpful.

michaelfolkson commented at 2:18 pm on February 18, 2023: contributor

I think having some kind of filter between opening a pull request and number assignment has been useful so far, but this has also consistently been misinterpreted as some form of approval or endorsement, so perhaps it’s time we switch to PR ID.

Personally I’d rather just accentuate this in a revised BIP 2 (BIP 3?) and then point to this statement whenever an allocation of a BIP number gets misinterpreted. I also like the filter rather than opening the floodgates to an infinite number of pull request numbers allocated to incomplete, weak proposals Ethereum style.

junderw commented at 2:30 pm on February 18, 2023: contributor

pull request numbers allocated to incomplete, weak proposals Ethereum style.

If BIP numbers have no meaning or endorsement, it shouldn’t matter.

If BIP numbers have meaning or imply endorsement, it does matter.

michaelfolkson commented at 2:37 pm on February 18, 2023: contributor

If BIP numbers have no meaning or endorsement, it shouldn’t matter.

If BIP numbers have meaning or imply endorsement, it does matter.

This is moving off the topic of this PR. A BIP number does have a meaning as discussed many times in previous comments. You are a correct in that being assigned one doesn’t imply endorsement. There is a bar that needs to be met for a BIP number to be assigned if you read BIP 2 to ensure we don’t get poor quality, nonsensical BIPs. BIP numbers are also convenient in the sense that the Taproot BIPs could have been 12345, 6839482 and 378957823 rather than BIP 340, 341 and 342.

eragmus commented at 4:28 pm on February 18, 2023: none

@michaelfolkson The issue is that misinformation-derived politics, due to various reasons (like emotional decision-making, appeal to authority of “Satoshi vision”, and other weaknesses), has dominated this BIP discussion and polluted it.

On the other hand, one can argue that anyone can participate, and so even if there is lots of noise, there is still some signal that comes through (related and unrelated to the BIP approval process). If it was an automatic BIP approval process, the mix of reactions wouldn’t occur which, beside their value on their own, also means people wouldn’t have an opportunity to learn more about the BIP and BIP process.

So, I think overall, maybe it is best to leave the process the way it is. It is messy, but the non-emotional people who understand the BIP process are still able to make the final decision (even if they, like Luke, push their personal, and IMO misguided, opinion on the BIP itself in their comments here, personal opinion which AFAIK is irrelevant to the BIP process).

michaelfolkson commented at 4:38 pm on February 18, 2023: contributor

I’m not going to comment on this again. If it was up to me (it clearly isn’t, I’m not a BIP editor) and this PR meets the criteria for a BIP number according to BIP 2 guidelines I’d allocate the BIP number. The author hasn’t indicated he wants a series of BIP numbers and assuming this is limited to a single BIP it should be possible to limit the extent that trolls can cause havoc with this and waste time. I don’t think the PR author is a troll (currently) but he seems happy to engage with people from other blockchain communities who are cheerleading this on to try to cause havoc and attract attention.

eragmus commented at 5:10 pm on February 18, 2023: none

@ChrisMartl Thanks for your comment, replies below:

Speaking also in the interest of Bitcoin and using BIP-0002: “[…] collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.“, express following concern:

What are the economical incentives for a rational actor to run a bitcoin Full-Node (if not running as Lightning-Node for whatever reason)?

This actor/role in the bitcoin network provides storage resource and verification processing (energy/time) mostly for free.

There are no direct financial incentives for a rational actor to run a Bitcoin full node, if not running a lightning node, as you suggested, since then the actor wouldn’t receive any payment for running the full node.

However, the runner of the full node presumably owns bitcoin, in which case it is in the runner’s indirect financial interest that the Bitcoin network works well. Part of this includes doing their part to decentralize the network, which includes running the full node. So, it can be thought of a relatively tiny investment to help support their bitcoin investment, not to mention the various non-direct and non-indirect financial interests in running the full node for their own benefit.

If such kind of rational actors do not agree to provide storage for non-financial-transaction-bits (since once the e.g. 1 TB SSD is full, these actors will not buy a SSD of bigger capacity and provide this resource to the bitcoin network) then, they will change to run a Light-Node (to participate sovereignly in the network).

What is the reason not to upgrade the 1 TB SSD, once full? Storage cost is one of which falls in price the fastest. The storage can only increase max about 210 GB per year, no further, and we are at about 550 GB, so that means at least 2 years more. By then, prices will likely have fallen even further (in 2 years, price for an example 2 TB SSD has fallen 63% from about $440 to $160 – https://3cmls.co/US/B08RK2SR23, so might be $60 in another 2 years, which would be 25% cheaper than the average price of 1 TB SSD now).

And anyway, segwit already locked in the max of about 210 GB storage increase per year, and segwit had consensus, so this should be expected and supported and assumed by a runner of a full node, irrespective of the form the txs take (’normal’ txs or arbitrary data txs).

Plus, arbitrary data txs have already occurred throughout Bitcoin’s history via p2ms, before Inscriptions-based arbitrary data ever became a thing, so this is not actually a new phenomenon. Full node runners have always hosted arbitrary data.

This rational action could have the total effect to reduce the decentralization and security of the bitcoin network.

Sure, everyone makes their own decisions, so full node runners must choose too. On the other hand, there have been reports from many that demand to run full nodes has jumped dramatically (one report indicated more demand to run full nodes in a matter of weeks/months recently than in prior 5 years total), so while there may be some loss due to ideological reasons, there may also be some gain due to new users entering Bitcoin. We will have to wait to see the full net effect on full nodes.

It would be in interest of all the bitcoin network’s stakeholders to take decisions/actions in consensus

Ordinals and Inscriptions do not require consensus to operate. They are not forks of any kind.

Ordinals are simply an arbitrary way of thinking about sats that categories sats into different levels of “rarity”, like with the numismatic value of fiat coins. Meanwhile, Inscriptions are technically-valid Bitcoin txs that allow arbitrary data storage. Both are enabled via a custom wallet that lets one distinguish and work with sats, functionality that is required by both.

and strengthen the incentives of Full-Node-Runners to provide storage resource.

Already discussed previously in this message, so won’t repeat.

Focusing only on the economical/financial incentives of miner-actors ceteris paribus

Just to be clear, the miners are critical elements of the network, in terms of the security they provide. The full nodes’ contribution to security is not even in the same realm as that provided by miners. It has always been known that the miners’ compensation, via subsidy, is exponentially falling every 4 years, and so it requires to be compensated for by fees (generated by txs on the base layer). This means blocks should be full to generate fee pressure and a fee market, so that high-enough-fee rate txs (economically competitive txs) become the norm on the base layer. It is very very very important to focus on incentives of miners; it is IMO the most important element of the Bitcoin network, since without security everything falls apart.

would destabilize the storage resources allocation, centralize and insecure the network against malicious actions/actors.

Already discussed previously in this message, so won’t repeat. But, even encountering a net reduction of for example 5,000 full nodes out of 100,000+ full nodes does not move the needle.

In consequence, as @luke-jr proposed: the autor of this proposal is encouraged to withdraw it and abandon it entirely. The autor of this proposal is free to pursue innovations and ideas in e.g. an OIP-0001 or the likes.

Withdrawing the proposal would achieve nothing materially positive; it would only maybe negatively affect the situation, since it could make it harder to improve the proposal, and maybe make it harder to have a single source of truth re: the proposal.

Abandoning it would do nothing to change the operation of it, either. This development is an example of Bitcoin’s permissionless innovation characteristic: it’s already released into the wild, so now the free market has taken over and will decide to what degree Ordinals & Inscriptions gain traction.

Based on comments by experts of the BIP process (not the people who have used their comments and emojis to indicate disapproval of the BIP itself), including Luke himself, this BIP is legitimate and lacks any good reason not to be accepted.

I hope my message has helped clarify why, on the aspect of financial incentive for full node runners and possible incentive of Inscriptions to reduce full nodes, the situation is not so clearly negative as may first be imagined.

eragmus commented at 5:16 pm on February 18, 2023: none

If it was up to me (it clearly isn’t, I’m not a BIP editor) and this PR meets the criteria for a BIP number according to BIP 2 guidelines I’d allocate the BIP number. @michaelfolkson Great.

The author hasn’t indicated he wants a series of BIP numbers and assuming this is limited to a single BIP it should be possible to limit the extent that trolls can cause havoc with this and waste time. I don’t think the PR author is a troll (currently) but he seems happy to engage with people from other blockchain communities who are cheerleading this on to try to cause havoc and attract attention.

Btw, gentle point: I notice from your comments that you are generalizing support by people from other blockchain communities for this as being the main or only supporters for this, and thus attributing bad intentions from those supporters. The reality is there are many Bitcoiners who support, or are neutral (happy to let free market play itself out) about, this development. Maybe your source of information is being colored by the circles you find yourself within, look more broadly than those circles. – “Havoc” and “trolls” and “wasting time” and whatever are not the ways to describe the Bitcoiners who support this (or leaning towards supporting it), or are neutral to it – in fact, those descriptions could be attributed to those opposed to this, since they are reacting emotionally instead of reasoning from first principles about this development.

viresinnumeris-1 commented at 6:51 am on February 19, 2023: none

Ugh this PR has truly degenerated into a cesspit brigaded by shitcoin apologists and nft trolls. No, don’t bother with more smoke. We know who you are.

Bitcoin’s ecosystem will eventually sort you out, but I suppose an early thank you is in order for helping to further harden Bitcoin against spam.

ChrisMartl commented at 1:08 pm on February 19, 2023: none

@eragmus: Thanks a lot for your comments. Replies below as well:

@ChrisMartl Thanks for your comment, replies below:

Speaking also in the interest of Bitcoin and using BIP-0002: “[…] collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.“, express following concern:

What are the economical incentives for a rational actor to run a bitcoin Full-Node (if not running as Lightning-Node for whatever reason)? This actor/role in the bitcoin network provides storage resource and verification processing (energy/time) mostly for free.

There are no direct financial incentives for a rational actor to run a Bitcoin full node, if not running a lightning node, as you suggested, since then the actor wouldn’t receive any payment for running the full node.

However, the runner of the full node presumably owns bitcoin, in which case it is in the runner’s indirect financial interest that the Bitcoin network works well. Part of this includes doing their part to decentralize the network, which includes running the full node. So, it can be thought of a relatively tiny investment to help support their bitcoin investment, not to mention the various non-direct and non-indirect financial interests in running the full node for their own benefit.

A node runner will reach his/her own interest participating in the bitcoin network running a Light-Node (pruned bitcoin node), since this one actor will try to profit from the decentralization achieved by other Full-Node-Runners without spending in a storage device with bigger capacity. Since this actor/role would be not motivated anymore to support the network decentralization based on ideological motives (giving storage resource for free only for financial-transactional-bits) would act probably only pursuing his/her own economical/financial interests. Also every actor in the bitcoin network is free to quit or liquidate completely his/her saving/investments at anytime permissionless.

If such kind of rational actors do not agree to provide storage for non-financial-transaction-bits (since once the e.g. 1 TB SSD is full, these actors will not buy a SSD of bigger capacity and provide this resource to the bitcoin network) then, they will change to run a Light-Node (to participate sovereignly in the network).

What is the reason not to upgrade the 1 TB SSD, once full? Storage cost is one of which falls in price the fastest. The storage can only increase max about 210 GB per year, no further, and we are at about 550 GB, so that means at least 2 years more. By then, prices will likely have fallen even further (in 2 years, price for an example 2 TB SSD has fallen 63% from about $440 to $160 – https://3cmls.co/US/B08RK2SR23, so might be $60 in another 2 years, which would be 25% cheaper than the average price of 1 TB SSD now).

As exposed above. His/her ideological motives; which is a fact to consider among the bitcoin network participants.

And anyway, segwit already locked in the max of about 210 GB storage increase per year, and segwit had consensus, so this should be expected and supported and assumed by a runner of a full node, irrespective of the form the txs take (’normal’ txs or arbitrary data txs).

Plus, arbitrary data txs have already occurred throughout Bitcoin’s history via p2ms, before Inscriptions-based arbitrary data ever became a thing, so this is not actually a new phenomenon. Full node runners have always hosted arbitrary data.

The SegWit in addition with Taproot created a freedom degree in the protocol to include less restrictive non-financial-transaction-bits, which is now been exploited by the Ordinal/Inscription implementation. This changed the characteristics and properties for the blockchain (Timechain) usage without consensus, but de facto. This consensus missing is clearly evidenced in the discussion and divisions expressed among bitcoin network participants on the different social media platforms and protocols (including this formal and official plenum for Bitcoin Improvement Proposals).

This rational action could have the total effect to reduce the decentralization and security of the bitcoin network.

Sure, everyone makes their own decisions, so full node runners must choose too. On the other hand, there have been reports from many that demand to run full nodes has jumped dramatically (one report indicated more demand to run full nodes in a matter of weeks/months recently than in prior 5 years total), so while there may be some loss due to ideological reasons, there may also be some gain due to new users entering Bitcoin. We will have to wait to see the full net effect on full nodes.

It would be in interest of all the bitcoin network’s stakeholders to take decisions/actions in consensus

Ordinals and Inscriptions do not require consensus to operate. They are not forks of any kind.

Which at the same time, following this argument, implies the not necessity for creating a BIP number or in its defect an informative BIP for the bitcoin community. Ordinals and Inscription did not follow the social consensus workflow, but put in the wild de facto through exploiting a freedom degree created from previous formal consensus.

Ordinals are simply an arbitrary way of thinking about sats that categories sats into different levels of “rarity”, like with the numismatic value of fiat coins. Meanwhile, Inscriptions are technically-valid Bitcoin txs that allow arbitrary data storage. Both are enabled via a custom wallet that lets one distinguish and work with sats, functionality that is required by both.

and strengthen the incentives of Full-Node-Runners to provide storage resource.

Already discussed previously in this message, so won’t repeat.

Focusing only on the economical/financial incentives of miner-actors ceteris paribus

Just to be clear, the miners are critical elements of the network, in terms of the security they provide. The full nodes’ contribution to security is not even in the same realm as that provided by miners. It has always been known that the miners’ compensation, via subsidy, is exponentially falling every 4 years, and so it requires to be compensated for by fees (generated by txs on the base layer). This means blocks should be full to generate fee pressure and a fee market, so that high-enough-fee rate txs (economically competitive txs) become the norm on the base layer. It is very very very important to focus on incentives of miners; it is IMO the most important element of the Bitcoin network, since without security everything falls apart.

The bitcoin network (including some miner-actors) was able to survive in the free market for quite more than 14 years. Exponentially falling subsidy every 4 years was clear exposed at the very beginning of bitcoin network design and operation in the wild. This fee pressure and market competition should be assumed by every miner-actor and do not require any intervention from the bitcoin community to provide any miner support via non-financial-transactional-fee compensation. If the bitcoin network can not survive with its original design and operation without intervention tried to be achieved via Ordinal/Inscription implementation, then its existence will be wiped out by the free market; which is our common ideology or efficient economical way of thinking.

would destabilize the storage resources allocation, centralize and insecure the network against malicious actions/actors.

Already discussed previously in this message, so won’t repeat. But, even encountering a net reduction of for example 5,000 full nodes out of 100,000+ full nodes does not move the needle.

In consequence, as @luke-jr proposed: the autor of this proposal is encouraged to withdraw it and abandon it entirely. The autor of this proposal is free to pursue innovations and ideas in e.g. an OIP-0001 or the likes.

Withdrawing the proposal would achieve nothing materially positive; it would only maybe negatively affect the situation, since it could make it harder to improve the proposal, and maybe make it harder to have a single source of truth re: the proposal.

Since Ordinal/Inscription is not a bitcoin community proposal there is not evidence at all its withdrawal could have any negative effects for Bitcoin.

Abandoning it would do nothing to change the operation of it, either. This development is an example of Bitcoin’s permissionless innovation characteristic: it’s already released into the wild, so now the free market has taken over and will decide to what degree Ordinals & Inscriptions gain traction.

Based on comments by experts of the BIP process (not the people who have used their comments and emojis to indicate disapproval of the BIP itself), including Luke himself, this BIP is legitimate and lacks any good reason not to be accepted.

A reason to not accept this proposal is not in keeping with the Bitcoin philosophy; in which a social consensus ex-ante shall be reached.

I hope my message has helped clarify why, on the aspect of financial incentive for full node runners and possible incentive of Inscriptions to reduce full nodes, the situation is not so clearly negative as may first be imagined.

A hope also, a help could be provided to a deeper understanding of this situation.

BrashRatel commented at 2:48 pm on February 20, 2023: none

NACK

See BIP-2 - “Reasons for rejecting BIPs include … … not in keeping with the Bitcoin philosophy.”

BIP # should not be provided since “Ordinal Numbers” are not part of Bitcoin. If this alternate scheme is listed in a BIP, it will be used to further this attack on the philosophy bitcoin.

nvk commented at 4:02 pm on February 20, 2023: none

It is common practice to have BIPs that are not used by many, neither implemented on core nor ever activated (Ie 300+301)

In my view they are simply documenting things people want to do with bitcoin. I don’t see any issues with assigning a number and merging.

If anything, it is likely going to decrease the level of unproductive noise this project is causing.

“merge, and move on” since this use is unlikely to stop until a fee market is much higher.

BullishNode commented at 4:47 pm on February 20, 2023: none

In my view they are simply documenting things people want to do with bitcoin. I don’t see any issues with assigning a number and merging.

But this is not about what people do with the Bitcoin protocol or Bitcoin Wallets, but with what people do with the ordinals NFT protocol and monkeypics wallets. Whether or not that scheme uses Bitcoin is irrelevant.

The Liquid Network, for example, is not has no BIP. Neither is RGB. Neither is Taro. Neither is Fedimint. Even Lightning specs are not BIPs. Etc.

vostrnad commented at 4:59 pm on February 20, 2023: contributor

@BullishNode Taro does have a BIP proposal, six of them in fact: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020196.html

BullishNode commented at 5:44 pm on February 20, 2023: none

@BullishNode Taro does have a BIP proposal, six of them in fact: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020196.html

Didn’t know that, thanks. I see that it has been almost one year. Any idea why they haven’t been assigned?

phyro commented at 3:25 am on February 21, 2023: none

But this is not about what people do with the Bitcoin protocol or Bitcoin Wallets, but with what people do with the ordinals NFT protocol and monkeypics wallets. Whether or not that scheme uses Bitcoin is irrelevant.

As far as I can tell, this BIP describes ordinals and not inscriptions. Ordinals are essentially like augmented reality glasses for Bitcoin that enable tracking of sats. This technology alone doesn’t seem to have any direct connection to NFTs or jpegs. As for the so-called “inscriptions”, those could be classified as spam, but this BIP does not touch on this topic.

In my opinion, the backlash this PR received was unwarranted. Those who do not find the idea of these AR glasses appealing can simply not put them on (which is the default setting anyway). The real question at hand is whether or not a BIP that provides a means for individuals to augment their interpretation of the chain is allowed. Personally, I believe we shouldn’t block this, and therefore support merging this.

luke-jr commented at 5:14 pm on February 21, 2023: member

Based on comments by experts of the BIP process, including Luke himself, this BIP is legitimate and lacks any good reason not to be accepted.

To be clear, I did not say this. Only that scope is not an issue. (Also: I am not hereby saying there is or isn’t reason to accept or reject)

ghost commented at 9:30 pm on February 21, 2023: none

BIP # should not be provided since “Ordinal Numbers” are not part of Bitcoin. If this alternate scheme is listed in a BIP, it will be used to further this attack on the philosophy bitcoin.

Maybe we should replace the word “philosophy” in BIP 2 with “politics”, it would make more sense.

Ironically, the people who blame others for spamming are the ones spamming this pull request and educating others how to use their money. Love this “philosophy”.

To be clear, I did not say this. Only that scope is not an issue. (Also: I am not hereby saying there is or isn’t reason to accept or reject)

Since Bitcoin is permissionless until now, I have added this BIP that will remain on bitcoin blockchain forever: https://ordinals.com/content/e14ced60a7ec3626adc579b4a3bbadbbba872c2a8a06344971bac0d68b590c33i0

I am also working on https://bips.wiki that will be a mirror for this repo same as https://bips.xyz, however there will be some changes and everyone experiencing gatekeeping issues can always add proposals. This repo is considered “official” repo for bitcoin proposals although there isn’t any and there shouldn’t be.

Nostr has been trying to decentralize NIPs, maybe bitcoin developers can learn something: https://github.com/nostr-protocol/nips/issues/162

Topkek-190 commented at 8:00 am on March 1, 2023: none

NACK. This BIP is antithetical to the goals of Bitcoin, an open financial network. Eliminating fungibility and enabling new types of tracking across transactions is not a feature, but a bug to be fixed.

Off-topic, but is Bitcoin really fungible?

loon3 commented at 3:32 am on March 2, 2023: none

It is common practice to have BIPs that are not used by many, neither implemented on core nor ever activated (Ie 300+301)

In my view they are simply documenting things people want to do with bitcoin. I don’t see any issues with assigning a number and merging.

If anything, it is likely going to decrease the level of unproductive noise this project is causing.

“merge, and move on” since this use is unlikely to stop until a fee market is much higher.

Came here looking for a BIP number to reference to find the conversation has devolved to the point of someone threatening to fork the BIP repo.

Can we just give this a number and move on?

loon3 commented at 5:16 am on March 6, 2023: none

Will reference this as BIP pr1408. This convention could be used going forward to identify BIPs that lack official numbers.

eragmus commented at 3:22 pm on March 7, 2023: none

To be clear, I did not say this. Only that scope is not an issue. (Also: I am not hereby saying there is or isn’t reason to accept or reject) @luke-jr True, but then why are you not saying whether there is, or is not, reason to accept or reject it (and of course giving the reason why or why not)?

Isn’t it your role to accept or reject BIPs, based on whether they meet the BIP rules (and not based on personal opinion of whether it is “good or bad for bitcoin”)? If not, who has this role?

ChrisMartl commented at 7:03 pm on March 8, 2023: none

To be clear, I did not say this. Only that scope is not an issue. (Also: I am not hereby saying there is or isn’t reason to accept or reject)

@luke-jr True, but then why are you not saying whether there is, or is not, reason to accept or reject it (and of course giving the reason why or why not)?

If you want to agree with the BIPs on this repository and follow them, then you should recognize and agree also with BIP0002. That BIP gives, among others, reasons for rejection; one of them, “[..] not in keeping with the Bitcoin philosophy”. Such not philosophy keeping was already exposed in various arguments above.

Isn’t it your role to accept or reject BIPs, based on whether they meet the BIP rules (and not based on personal opinion of whether it is “good or bad for bitcoin”)? If not, who has this role?

Since Bitcoin Network (technically as well as socially) needs agreement between its parties to exists (or at least to keep the probability of its survival) and since this proposal has not demonstrated social agreement (name it if you want: “consensus”) between its relevant participants, in particular participants running full-nodes, and following BIP0002, the logical consequence is the rejection of this proposal.

luke-jr commented at 8:58 pm on March 11, 2023: member

Isn’t it your role to accept or reject BIPs, based on whether they meet the BIP rules (and not based on personal opinion of whether it is “good or bad for bitcoin”)?

The trouble is the “not in keeping with the Bitcoin philosophy” rule. I’m not sure how to apply it, and it seems to be debated in the community whether it’s applicable here.

Since Bitcoin Network (technically as well as socially) needs agreement between its parties to exists (or at least to keep the probability of its survival) and since this proposal has not demonstrated social agreement (name it if you want: “consensus”) between its relevant participants, in particular participants running full-nodes, and following BIP0002, the logical consequence is the rejection of this proposal.

This logical consequence (putting aside the philosophical debate mentioned earlier) would imply the BIP should be assigned a number and merged, but with a Status change to Rejected. However, even then, the Status of this kind of BIP is based primarily on software implementations rather than social acceptance.

viresinnumeris-1 commented at 1:24 pm on March 12, 2023: none

@luke-jr You’ve nailed it.

It is clear from BIP 2 that “in keeping with Bitcoin’s philosophy” applies to all BIP, regardless of type. Which makes perfect sense. We cannot simply assign a number to every Informational BIP that meets all the technical requirements but is antithetical to what Bitcoin stands for philosophically. The BIP list would end up looking absurd and devolve into an EIP list.

Until Bitcoin’s philosophy is clearly and unambiguously addressed in BIP 2, merging this PR would set the wrong precedent by tacitly acknowledging that this PR is in keeping with Bitcoin’s philosophy, which, judging by the obvious schism, is highly debatable if not outright dubious.

As it stands, there is simply no way to equitably merge this PR without first defining Bitcoin’s philosophy in BIP 2. The charitable thing to do here would be to close this PR. The author is free to open a new PR after BIP 2 has been updated.

Topkek-190 commented at 3:39 am on March 13, 2023: none

What is “Bitcoin’s philosophy” and how is Ordinals antithetical to it? Wasn’t that precedent already established by The Times 03/Jan/2009 Chancellor on brink of second bailout for banks?

Bitcoin’s philosophy is to facilitate transactions, what people decide to do with those transactions (serially number them, store arbitrary data in them) shouldn’t be controlled by any central authority. A valid transaction that pays fees cannot be spam.

Psifour commented at 7:37 am on March 13, 2023: none

All quotes in this comment are sourced from BIP 2.

I can accept that a certain amount of discussion as to the community ‘consensus’ is still pending, but to claim that is a reason to deny a BIP is disingenuous as this is an Informational BIP and therefore it “do[es] not necessarily represent a Bitcoin community consensus”.

BIPs “must have a champion” and a “draft must be written in BIP style as described [in BIP 2].” Both of these are true for this proposal.

Allowed Reasons for Rejection Are: “include[s] a duplication of effort” - There are no outstanding drafts that address this system. “disregard for formatting rules” - The proposed draft exemplifies the formatting rules “being too unfocused or too broad” - Proposal seeks to define exactly one feature “being technically unsound” - All technical aspects are sound and have been implemented in reference software “not providing proper motivation or addressing backwards compatibility” - No backwards compatibility concerns and the motivation is documented. “not in keeping with the Bitcoin philosophy” - The single most salient point of contention would be in regards to privacy, but §10 (Privacy) of the Bitcoin White Paper is fully compatible with this proposal as it introduces no information that was not already available to all users operating a full node. In many ways it provides countless opportunities to educate users about why the final paragraph of section 10 is so important, by demonstrating in a very direct way how simple it is to subvert the anonymity of users who do not practice good hygiene in regards to key/coin control.

Additionally a BIP MUST: “be a clear and complete description of the proposed enhancement” - This proposal includes all relevant material needed to implement a client that would be fully compatible with the reference implementation. “must represent a net improvement” - This directly enables users to create/use stable identifiers with no direct tangible case for negatives that outweigh it. “must be solid and must not complicate the protocol unduly” - Reference implementation has no mandatory implementation in Bitcoin protocol and therefore cannot complicate it.

Additionally, the complaint that it needs to be implemented on independent software(s) is factually false as that criteria applies specifically when checking for “de facto adoption” and “[is] not to be used as reasons to oppose or reject a BIP”

It should be clear at this point, to any unbiased reader, that the refusal to assign a BIP number is not related to this proposal, but is a byproduct of the reference implementation of this proposal also implementing a system that uses SegWit in a way that hurts people’s feelings. Having read the discussion the majority of technical/network concerns are concerned with features that are NOT part of this BIP (and make me question if said users actually read the proposed BIP or just Twitter).

ChrisMartl commented at 9:34 pm on March 13, 2023: none

“must represent a net improvement” - This directly enables users to create/use stable identifiers with no direct tangible case for negatives that outweigh it.

Could this sentence be please reformulated or elaborated to improve the understanding of its intended meaning? It is neither clear nor obvious what it is stated. A net improvement could not be recognized. What is “stable identifiers”? What is “no direct tangible case”? What is “negatives that outweigh”?

Psifour commented at 10:36 pm on March 13, 2023: none

What is “stable identifiers”?

These are a primitive that enables the creation various complex application-layer features. It is a feature that is meaningful to developers who have an interest in any form of opt-in and/or pseudonymous transferable identity.

What is “no direct tangible case” and “negatives that outweigh”?

There have been no reasonable arguments made that this feature has direct drawbacks for the ecosystem at large that match/exceed the value provided to those that benefit from the above positives. In short, there are positives and I have yet to see a good argument for negatives (restricted to the scope of this proposed BIP).

To elaborate: Indexes of Ordinals (as defined in this BIP) are not required by full nodes (as this is an Informational BIP) and as such do not increase the storage/network requirements for full nodes (aka does not harm decentralization). This does not impact the ability to spend/transfer/hold sats and as such doesn’t undermine the selective-fungibility of the monetary layer.

In summary; The content of this BIP has no negative impact on full node operators as it is purely opt-in, does/can not create a fork (as it has no changes to consensus/standardness), and includes no writes to the chain (even if implemented in their chosen software). This combined with providing features to those who benefit from them make it an unequivocal net improvement.

I was tired when I drafted that last night and I hope this is a sufficient expansion upon that point.

ChrisMartl commented at 0:04 am on March 14, 2023: none

doesn’t undermine the selective-fungibility of the monetary layer.

What is meant with “selective” in “selective-fungibility”?

What supports the statement of do not undermining sat’s fungibility?

This proposal intends clearly the provision of sat identification and discrimination; which creates a social sat non-fungible treatment.

Indexes of Ordinals (as defined in this BIP) are not required by full nodes (as this is an Informational BIP) and as such do not increase the storage/network requirements for full nodes (aka does not harm decentralization).

A scenario in which “Ordinals’ Indexes” are used in combination to identify insertions of arbitrary data in the witness structure (maybe a concept like “Inscriptions”) can harm full-node (archival-node) decentralization and effectively increments Timechain storage requirement prematurely.

With above, negative impact on full-node operators and general users could be identified. The proposal’s positive/negative ratio does not evidence greater benefits than disadvantages.

Psifour commented at 2:09 am on March 14, 2023: none

What is meant with “selective” in “selective-fungibility”?

I can already (regardless of the existence of this BIP) prove sat origination due to the UTXO-model being perfectly designed to aid in building network graphs. As such, this BIP “doesn’t undermine the selective-fungibility of the monetary layer” as it operates within the “selective-fungibility” that is inherent to Bitcoin’s model while maximizing every factor that one can in regards to maintaining privacy and fungibility.

I am very grateful for the way Casey implemented and documented this as it will hamper the ability of others (who may not share his alignment with Bitcoin ethos) to release competing standards (see “include[s] a duplication of effort” in BIP 2) that do not acknowledge and attempt to minimize/mitigate these risks.

The entire second half of your comment is what I already addressed above, you are opposed due to an implementation you disagree with, but your complaint is with BIP 141 which, explicitly allowed the expansion to 4MB of data per block. This BIP does not change block sizes, the protocol, the standard implementation of a Bitcoin node, etc and as such, it cannot increase the storage required beyond what was already defined in previous BIPs.

ChrisMartl commented at 7:51 am on March 14, 2023: none

I can already (regardless of the existence of this BIP) prove sat origination due to the UTXO-model being perfectly designed to aid in building network graphs. As such, this BIP “doesn’t undermine the selective-fungibility of the monetary layer” as it operates within the “selective-fungibility” that is inherent to Bitcoin’s model while maximizing every factor that one can in regards to maintaining privacy and fungibility.

Since “selective-fungibility” was not concretized in regards of intended meaning in the reply, it will be assumed “selective-fungibility” refers to “optional”, “possible” fungibility reached, for example, through multi-party transaction.

Can you elaborate, evidence that the usage of the “Ordinal” concept does not undermine an optional (“selective”) fungibility intended through multi-party transaction?

Can you elaborate on the statement “while maximizing every factor that one can in regards to maintaining privacy and fungibility”, how privacy will be maintained or, in its defect, not be undermined?

I am very grateful for the way Casey implemented and documented this as it will hamper the ability of others (who may not share his alignment with Bitcoin ethos) to release competing standards (see “include[s] a duplication of effort” in BIP 2) that do not acknowledge and attempt to minimize/mitigate these risks.

Can you elaborate on which risks are you referring?

Can you elaborate on which Bitcoin Ethos the author of this proposal is following or is aligned with?

The disagreement expressed in the reply above refers with this proposal and, among others, its usage in combination with insertions of arbitrary data. Both creates or, better said, powers, potentiates, facilitates incentives to introduce arbitrary data that otherwise would be meaningless and evidently did not happen before in its actual extend, thus not creating any marginal economical value with it. Additionally, making a portion of Full-Node operators to consider to change their operations and participation in the Bitcoin network via pruned node, specially when their non-volatile storage gets used completely.

Regardless of the disagreement expressed above, the existence or not of Ordinal concept (or name it if you want, Ordinal project) is completely transparent and orthogonal with Bitcoin and Bitcoin Core; its technological implementation or similar is exogenous and independent from Bitcoin Core and Bitcoin network; its usage in combination with insertions of arbitrary data has effectively effects in the Timechain; effects that impact in a non-beneficial way to full-nodes (and with it, their operators). No net benefits with this proposal could be identified nor recognized. No reason for BIP number assignment or, in its defect, an assignment with status different than “Rejected” could not be justified.

satoshi0770 commented at 7:27 pm on March 15, 2023: none

The trouble is the “not in keeping with the Bitcoin philosophy” rule. I’m not sure how to apply it, and it seems to be debated in the community whether it’s applicable here.

believe this is the only crux here. outcome would be, “bitcoin philosophy” for this repo is under the discretion of the maintainers of this repo. no matter how it looks, mechanically and literally, this is what it comes down to.

Psifour commented at 11:31 pm on March 15, 2023: none

“bitcoin philosophy” for this repo is under the discretion of the maintainers of this repo

I would strongly condemn such a definition, but it is, technically, in the purview of the repo owners/maintainers to apply such a definition. It would highlight the risks inherent to having a centralized repo for BIPs, but I actually believe that the current editors do a relatively good job of keeping their biases separate from their role here.

ChrisMartl commented at 7:15 am on March 16, 2023: none

believe this is the only crux here.

Indeed it is not. Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” As exposed above, this proposal do not represent a net improvement; in logical consequence, this proposal could not be accepted. If the negation of “Accepted” ist “Rejected”, then it is clearly and evident what the final state for this proposal would be.

outlaw6696 commented at 11:13 am on March 16, 2023: none

Reject all l am the original one habent put one dime in my pocket but im sure e ery one else has have put some to other crypto proje ts amd habent been able to touch Thoes either every developer out there has been against me and i have put out 8 nodes and every person wants to some how cut me out and every one of mine is runnig strong i try to work with everyone but saying this keep your hands off githud already jumped in my packets ive suplied the whole crypto unveser out of my persona l wallets and not a dime inmine im getting mine so dont think about it

On Thu, Mar 16, 2023, 2:16 AM ChrisMartl @.***> wrote:

believe this is the only crux here.

Indeed it is not. Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” As exposed above, this proposal do not represent a net improvement; in logical consequence, this proposal could not be accepted. If the negation of “Accepted” ist “Rejected”, then it is clearly and evident what the final state for this proposal would be.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1408#issuecomment-1471433045, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOWRZZPHE2MYJT4FJTQDXZTW4K447ANCNFSM6AAAAAAUCBXU4U . You are receiving this because you are subscribed to this thread.Message ID: @.***>

casey force-pushed on May 22, 2023

New BIP: Ordinal Numbers

Ordinal numbers are serial numbers for sats, assigned when mined and
preserved across transactions.

f013681216

Update bip-0000.mediawiki

Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com>

9f81a71b9c

Update bip-0000.mediawiki

Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com>

7c7de8bda7

Change license to CC0 7950891da6

Fix code formatting 93a7ae6980

Fix list formatting b802f83b86

Note underpayment of block reward bfff9020db

casey force-pushed on May 22, 2023

Note date of index sizes b9506fbcdd

casey commented at 6:33 am on May 22, 2023: none

I believe I have addressed all the comments and suggestions regarding content and formatting, namely:

Changed license from public domain to CC0
Fixed the code formatting to use <source> tags
Fixed the list formatting
Noted what happens if the block reward is underpaid
Added dates to the index sizes @luke-jr and @kallewoof, what do you think? Is this ready for a BIP number?

ChrisMartl commented at 7:35 am on May 28, 2023: none

Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” As exposed above, this proposal do not represent a net improvement; in logical consequence, this proposal could not be accepted. If the negation of “Accepted” ist “Rejected”, then it is clearly and evident what the final state for this proposal would be.

ChrisMartl commented at 7:44 am on May 28, 2023: none

Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” As exposed above, this proposal do not represent a net improvement; in logical consequence, this proposal could not be accepted. If the negation of “Accepted” ist “Rejected”, then it is clearly and evident what the final state for this proposal would be.

This proposal (thus indirectly; directly through its combination with “Inscriptions”) represent a prohibitive increase in the cost of operation of archival-full-nodes, which impacts the degree of archival-full-node decentralization; thus diminishing the Bitcoin system value proposition.

vicariousdrama commented at 3:02 pm on May 28, 2023: none

This proposal (thus indirectly; directly through its combination with “Inscriptions”) represent a prohibitive increase in the cost of operation of archival-full-nodes, which impacts the degree of archival-full-node decentralization; thus diminishing the Bitcoin system value proposition.

Ordinals and Inscriptions represent a net improvement IMHO for node operators.

For Ordinals…

This is an opt-in specification that thousands of people have adopted. Node operators do not have to do anything to either support it, or oppose it. There is no additional burden placed on a node operators for the concept of Ordinals as a numbering standard for those that choose to accept it.

Indirectly for those concerned about Inscriptions…

Consider the Bitcoin whitepaper. It’s 184kb in size. Storage of the Bitcoin Whitepaper before Ordinals and Inscriptions

0Transaction: 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
1Size: 198.72 KB
2Fees Paid: 59617500
3Fee Rate: 300 sat/vB

Storage as an Inscription referencing an Ordinal

0Transaction: a67424465d4692388f47c9af16a4b901411c2db5968cdd20c68841e37ee832f7
1Size: 185.95 KB : reduction of over 6%
2Fees Paid: 744928 : reduction of over 98%
3Fee Rate: 160 sat/vB : reduction of over 94%

These types of reductions are beneficial to node operators as

less space is consumed for the same data, reducing local storage costs and network costs
they do not bloat the UTXO set, reducing memory needs as well

ChrisMartl commented at 9:44 am on May 30, 2023: none

This proposal (thus indirectly; directly through its combination with “Inscriptions”) represent a prohibitive increase in the cost of operation of archival-full-nodes, which impacts the degree of archival-full-node decentralization; thus diminishing the Bitcoin system value proposition.

Ordinals and Inscriptions represent a net improvement IMHO for node operators.

What do you mean exactly by “node operators”? Do you mean mining-node operators or archival-full-node operators?

For Ordinals…

This is an opt-in specification that thousands of people have adopted. Node operators do not have to do anything to either support it, or oppose it. There is no additional burden placed on a node operators for the concept of Ordinals as a numbering standard for those that choose to accept it.

There are hints the “adoption” does not correspond with thousands of entities: https://block21m.substack.com/p/most-bitcoin-inscriptions-belong-d6d

Indirectly for those concerned about Inscriptions…

Consider the Bitcoin whitepaper. It’s 184kb in size. Storage of the Bitcoin Whitepaper before Ordinals and Inscriptions
0Transaction: 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
1Size: 198.72 KB
2Fees Paid: 59617500
3Fee Rate: 300 sat/vB
Storage as an Inscription referencing an Ordinal
0Transaction: a67424465d4692388f47c9af16a4b901411c2db5968cdd20c68841e37ee832f7
1Size: 185.95 KB : reduction of over 6%
2Fees Paid: 744928 : reduction of over 98%
3Fee Rate: 160 sat/vB : reduction of over 94%
These types of reductions are beneficial to node operators as

less space is consumed for the same data, reducing local storage costs and network costs

they do not bloat the UTXO set, reducing memory needs as well

Words playing about the “net benefit” meaning does not change the fact, that the ROM resource from archival-full-nodes have being consumed faster since the publication of this Bitcoin’s orthogonal arbitrary bitstream insertions without any kind of compensation (thus neither representing in any case a “reduction of local storage, nor cost reduction). See picture:

By the way, Ordinal-Theory/Inscriptions contributed (indirectly; through insertions’ ideas) with the UXTO bloating being experienced more or less since Q2 2023. See picture:

Clearly and evidently not a “net benefit”.

okeygo commented at 9:33 am on June 18, 2023: none

Many like me are here to protect the code from any change that may distract from taking Bitcoin to replace economic transactions and ultimatey the sovereing electronic cash that was envisioned from its discovery and early development.

Those who want to build something else, even with the best of intentions and good will, just go the route of forking. I am not against people collecting, if they own those sats do whatever you like with them, burn them, paint them… the protocol and consensus is here to offer honest money that can not be printed arbitrarily and transact without middle men and keep an immutable history of transaction in a bullet proof ledger.

My full nodes and mining nodes will never approve any change that wants to convert Bitcoin into something else. Any attacker should be aware of this. Go to other codes to print fake money and scam people, here is not the place.

ghost commented at 8:02 pm on June 29, 2023: none

14:19 The bar for getting a number is having had discussion, and having one of the BIP editors notice. 14:20 ACKing a BIP is meaningless, it’s just a mechanism for publishing ideas.

https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-06-08#928785 @luke-jr @kallewoof do you agree with this?

luke-jr commented at 10:44 pm on July 2, 2023: member

@zkfrio The process is documented in BIP 2. Please read prior discussion before not-adding-anything-new.

ghost commented at 9:56 am on July 3, 2023: none

I have read all the comments and do not understand which part of BIP 2 stops editors from providing a BIP number to informational doc added in this pull request.

I can see some blocksize increase BIPs present in the repository. Were they reviewed with the same BIP 2 rules?

casey commented at 4:49 am on August 12, 2023: none

Would the BIP editors mind commenting with what’s needed to get this BIP over the line, or if it can’t be assigned a BIP number and merged, why not? Thank you!

ChrisMartl commented at 7:27 am on August 12, 2023: none

Would the BIP editors mind commenting with what’s needed to get this BIP over the line, or if it can’t be assigned a BIP number and merged, why not? Thank you!

Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” A net improvement could not be identified as shown previously. We hope, your question has been answered.

in bip-0000.mediawiki:32 in b9506fbcdd outdated

27+single-use, and wallet accounts are private. Additionally, the use of addresses
28+or public keys as stable identifiers precludes transfer of ownership or key
29+rotation.
30+
31+This proposal is motivated by the desire to provide stable identifiers that may
32+be used by Bitcoin applications.

katesalazar commented at 11:50 am on August 12, 2023:

wallet accounts are private

“wallet accounts”? Is that a thing?

“the use of addresses or public keys as stable identifiers precludes transfer or ownership or key rotation”

What does this mean?

desire to provide stable identifiers that may be used by Bitcoin applications

Why not justify the need from within the system instead of from outside? Maybe something like «unequivocally identifying the original system’s currency units (“sats”) is necessary for easily determining ownership in an eventual smaller currency units system (“sub-sats”)» replacing this paragraph?

unknown commented at 11:12 pm on August 12, 2023:

“wallet accounts”? Is that a thing?

You can suggest a better thing to rephrase it

in bip-0000.mediawiki:72 in b9506fbcdd outdated

67+
68+=== Specification ===
69+
70+Sats are numbered and transferred with the following algorithm:
71+
72+<source lang="python">

katesalazar commented at 11:53 am on August 12, 2023:

Do you mean Python 3? Shouldn’t you note that in some fashion before this line?

unknown commented at 11:17 pm on August 12, 2023:

It works for syntax highlighting of mediawiki file. It is also used in other BIPs.

in bip-0000.mediawiki:70 in b9506fbcdd outdated

65+in subsequent blocks. Ordinals depend only on how many sats could have been
66+mined, not how many actually were.
67+
68+=== Specification ===
69+
70+Sats are numbered and transferred with the following algorithm:

katesalazar commented at 11:56 am on August 12, 2023:

Is Python 3 ‘process standard’?

in bip-0000.mediawiki:134 in b9506fbcdd outdated

129+Ordinal sats can be secured using current and future script types. They can be
130+held by single-signature wallets, multi-signature wallets, time-locked, and
131+height-locked in all the usual ways.
132+
133+By assigning ordinal numbers to all sats without the need for an explicit
134+creation step, the anonymity set of ordinal number users is maximized.

katesalazar commented at 12:03 pm on August 12, 2023:

I don’t understand how this improves anonimity.

However, currency units form a finite set. Therefore, the ways to order them form a finite set as well. There is nothing “new” you can “create” here. You can remove a word like “create” here, for such “creation” of sats was done in 2008. You can choose any algorithm for ordering currency units into “ordinals”, but any of all those algorithms exists since 2008.

Psifour commented at 6:44 pm on August 12, 2023:

It is contrasting with alternative methods of creating a similar system that would be reliant on a user-initiated process. By not having a step in which you ‘create’ or ‘assign’ the ordinal numbers that is initiated by the users, you can be sure that they are evenly distributed meaning that they inherit the bitcoin anonymity set (aka maximized within the bounds of the existing set).

unknown commented at 11:18 pm on August 12, 2023:

anonymity set of ordinal

in bip-0000.mediawiki:136 in b9506fbcdd outdated

131+height-locked in all the usual ways.
132+
133+By assigning ordinal numbers to all sats without the need for an explicit
134+creation step, the anonymity set of ordinal number users is maximized.
135+
136+Since a sat has an output that contains it, and an output has a public key that

katesalazar commented at 12:08 pm on August 12, 2023:

You are writing of “pay to _ public key _” schemes here, but you wanted to write generically of any utxo redemption scheme.

Psifour commented at 6:44 pm on August 12, 2023:

I read this as P2TR key-path spends, but that we read this differently indicates an opportunity for improvement. Abstraction to UTXO redemption (without discussion of keys where possible), may help to standardize the reading.

in bip-0000.mediawiki:146 in b9506fbcdd outdated

141+
142+Ordinals require no changes to blocks, transactions, or network protocols, and
143+can thus be immediately adopted, or ignored, without impacting existing users.
144+
145+Ordinals do not have an explicit on-chain footprint. However, a valid objection
146+is that adoption of ordinals will increase demand for outputs, and thus

katesalazar commented at 12:11 pm on August 12, 2023:

Users are free to bloat the UTXO set in any way allowed by consensus. This paragraph, and consequential paragraphs, can be removed.

unknown commented at 11:19 pm on August 12, 2023:

Using bitcoin isn’t bloating

in bip-0000.mediawiki:151 in b9506fbcdd outdated

146+is that adoption of ordinals will increase demand for outputs, and thus
147+increase the size of the UTXO set that full nodes must track. See the
148+objections section below.
149+
150+The ordinal number scheme is extremely simple. The specification above is 15
151+lines of code.

katesalazar commented at 12:13 pm on August 12, 2023:

You already have your glory in authorship, there is no need for this triumphal lap. This paragraph can be removed completely.

in bip-0000.mediawiki:154 in b9506fbcdd outdated

149+
150+The ordinal number scheme is extremely simple. The specification above is 15
151+lines of code.
152+
153+Ordinals are fairly assigned. They are not premined, and are assigned
154+proportionally to existing bitcoin holders.

katesalazar commented at 12:16 pm on August 12, 2023:

Opinion paragraph can be removed completely.

Psifour commented at 6:51 pm on August 12, 2023:

Also, redundant with L133

in bip-0000.mediawiki:157 in b9506fbcdd outdated

152+
153+Ordinals are fairly assigned. They are not premined, and are assigned
154+proportionally to existing bitcoin holders.
155+
156+Ordinals are as granular as possible, as bitcoin is not capable of tracking
157+ownership of sub-sat values.

katesalazar commented at 12:20 pm on August 12, 2023:

You can try better at future-proof.

Ordinals are as granular as possible

If (only if) it’s not already clear by this line, you can write that ordinals as granular as sats.

not capable of tracking ownership of sub-sat values

Yet. You can try better at future-proof. Try better.

in bip-0000.mediawiki:195 in b9506fbcdd outdated

190+''Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as ordinals
191+received in a transaction may carry with them some public history.''
192+
193+As anyone can send anyone else any sats, any reasonable person will assume that
194+a new owner of a particular sat cannot be understood to be the old owner, or
195+have any particular relationship with the old owner.

katesalazar commented at 12:24 pm on August 12, 2023:

Yes. Besides, every currency units are defined since 2008. All of them carry history since then, actually.

unknown commented at 11:22 pm on August 12, 2023:

I think you should read that again and it’s good for privacy

in bip-0000.mediawiki:201 in b9506fbcdd outdated

196+
197+''Congestion: Adoption of ordinal numbers will increase the demand for
198+transactions, and drive up fees.''
199+
200+Since Bitcoin requires the development of a robust fee market, this is a strong
201+positive of the proposal.

katesalazar commented at 12:25 pm on August 12, 2023:

I agree with this opinion, but please add references supporting these sentences.

in bip-0000.mediawiki:209 in b9506fbcdd outdated

204+entries in the UTXO set, and thus increase the size of the UTXO set, which all
205+full nodes are required to track.''
206+
207+The dust limit, which makes outputs with small values difficult to create,
208+should encourage users to create non-dust outputs, and to clean them up once
209+they no longer have use for the sats that they contain.

katesalazar commented at 12:27 pm on August 12, 2023:

There is always use in an UTXO, can’t this be written in some other form?

in bip-0000.mediawiki:213 in b9506fbcdd outdated

208+should encourage users to create non-dust outputs, and to clean them up once
209+they no longer have use for the sats that they contain.
210+
211+=== Security ===
212+
213+The public key associated with a sat may change. This requires actively

katesalazar commented at 1:29 pm on August 12, 2023:

Again “the public key associated with a sat” is a needless simplification. Can’t you write of an unlocking script or something more general?

in bip-0000.mediawiki:221 in b9506fbcdd outdated

216+static public keys suffers from an inability for keys to be rotated or accounts
217+to change hands.
218+
219+Ordinal-aware software must avoid losing valuable sats by unintentionally
220+relinquishing them in a transaction, either to a non-controlled output or by
221+using them as fees.

katesalazar commented at 1:32 pm on August 12, 2023:

All sats are valuable, did you mean rare ordinals?

unknown commented at 11:24 pm on August 12, 2023:

Ordinal-aware software

in bip-0000.mediawiki:233 in b9506fbcdd outdated

228+of the applications that they are intended to enable require public
229+identifiers.
230+
231+Ordinal aware software should never mix sats which might have some publicly
232+visible data associated with their ordinals with sats intended for use in
233+payments or savings, since this would associate that publicly visible data with

katesalazar commented at 1:35 pm on August 12, 2023:

Aren’t rare or inscribed ordinals a form of savings?

Psifour commented at 6:47 pm on August 12, 2023:

Mixing of sats without intentionality should be avoided (even prior to this proposal), if those sats could potentially result in undermining your privacy. This should be a given if the end-user isn’t reusing addresses. However, it is a useful inclusion for the large number of new developers who are building on bitcoin now who may not share our knowledge about, or culture of, protecting privacy.

You may be correct that this isn’t necessary as it is technically just a ‘don’t do stupid privacy exposing things with your UTXOs’.

casey commented at 9:11 pm on August 12, 2023: none

Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” A net improvement could not be identified as shown previously. We hope, your question has been answered.

I am happy to argue that users who choose to use this BIP benefit from it, and users who choose not to use it aren’t. However, I’d like to hear from a BIP editor whether or not this is what’s preventing this BIP from being accepted.

ghost commented at 11:55 pm on August 12, 2023: none

Again, no a net benefit for Bitcoin:

These BIPs are net benefit for Bitcoin:

https://github.com/bitcoin/bips/blob/master/bip-0100.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki (Pieter Wuille)

https://github.com/bitcoin/bips/blob/master/bip-0104.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki

ChrisMartl commented at 7:45 am on August 13, 2023: none

Following BIP0002: “For a BIP to be accepted it must meet certain minimum criteria. […] The enhancement must represent a net improvement.” A net improvement could not be identified as shown previously. We hope, your question has been answered.

I am happy to argue that users who choose to use this BIP benefit from it, and users who choose not to use it aren’t. However, I’d like to hear from a BIP editor whether or not this is what’s preventing this BIP from being accepted.

Well, users (regular Bitcoin node operators) who do not want to use it are FORCED to receive and store the arbitrary data (frequently unwanted content interpretation) in their regular Bitcoin nodes via exploit of the Bitcoin script flexibility using a “envelope” OP_FALSE OP_IF OP_PUSH “ord” OP_PUSH 1 OP_PUSH OP_PUSH 0 OP_PUSH OP_ENDIF, without previous social consensus and utilizing the ability of mining-nodes to collude with this pursuing their high time preference benefits. Again this attempt, from a de facto script exploit, do not represent and is not a NET (for ALL network participants) benefit.

Retropex commented at 9:11 am on August 13, 2023: none

NACK.

Inscriptions bring absolutely nothing good for the network and for users.

katesalazar commented at 9:54 am on August 13, 2023: contributor

Inscriptions bring absolutely nothing good for the network and for users.

I don’t think rejecting the ordinals BIP can deter ordinal inscribers. Antispam measures in nodes might do. At least they can increase the cost of inscribing. This discussion should instead circle around which is the best way to standardize ordering of the finite currency units. Then standardize whichever makes sense the most. The useful critique here is ordering these finite currency units using different criteria.

On Sun, Aug 13, 2023 at 11:12 AM Léo Haf @.***> wrote:

NACK.

Inscriptions bring absolutely nothing good for the network and for users.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1408#issuecomment-1676291377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMRS4W6JME4Z4SIX2VAC7YDXVCK6PANCNFSM6AAAAAAUCBXU4U . You are receiving this because you commented.Message ID: @.***>

ChrisMartl commented at 10:29 am on August 13, 2023: none

Inscriptions bring absolutely nothing good for the network and for users. I don’t think rejecting the ordinals BIP can deter ordinal inscribers. Antispam measures in nodes might do. At least they can increase the cost of inscribing. This discussion should instead circle around which is the best way to standardize ordering of the finite currency units. Then standardize whichever makes sense the most. The useful critique here is ordering these finite currency units using different criteria. …

Regarding ordering; i.e. trying to make a “Bitcoin Official FIFO Sat Ordering, clearly breaks a social consensus among Bitcoin participants about the optional fungibility of UXTOs.

This topic was already addressed; see: #1408 (comment)

RicYashiroLee commented at 12:28 pm on August 13, 2023: none

It is not because it is possible for burglars to go in a house, that we then turn off all anti-burglar measures in place. On the contrary! The goal is to make adding arbitrary data (=out of Bitcoin’s supposedly TINY SCOPE) the MORE CUMBERSOME possible, therefore NEVER EVER relax that. Bitcoin is NOT an all purpose DB, and the main reason why it has any value, otherwise becomes worst than an altcoin.

casey commented at 10:15 pm on August 13, 2023: none

This discussion should instead circle around which is the best way to standardize ordering of the finite currency units. Then standardize whichever makes sense the most. The useful critique here is ordering these finite currency units using different criteria.

Since the ordering described in this BIP is already in use, it should be documented for interoperability, and alternative orderings are outside of the scope of this BIP. Feel free to propose an alternative ordering in a new BIP!

ChrisMartl commented at 12:07 pm on August 14, 2023: none

Bitcoin Core and the whole Bitcoin participants, including specially the regular Bitcoin nodes operators, should not let document and thus standardize implementations rolled out in a “de facto modus operandi script exploit” breaking clearly the Bitcoin system philosophy; i.e. no one (no even C. Rodarmor) has the legitimation or the power to change the Bitcoin System behavior without a proper social consensus among the whole Bitcoin participants. Such a kind of attempt will clearly have a big impact on the fundamental value proposition of Bitcoin; which is decentralization, including power decentralization for making changes of the Bitcoin system behavior.

nsvrn commented at 4:20 pm on August 14, 2023: none

NACK

May be this is good for the author to try on one of the numerous experimental altcoins specially built for stuff like this.

There are millions who rely on the Bitcoin protocol for it’s censorship resistance and financial txs. It is imminent to take that seriously and not be a proponent of a very small illegitimate use-case compared to that.

staccDOTsol commented at 10:44 pm on October 25, 2023: none

I want to paint a better picture here:

Imagine Bitcoin as an immutable and trustable layer of the internet. It is apparent to anyone Bitcoin is the ideal solution for keeping arbitrary data past the censors and those who would alter the truth after the fact (say, maybe, a generation or two after the fact i.e. ‘history is written by the victors’)

This is better detailed in a tweet I made when I backed up all of bitcoin stack exchange to the bitcoin testnet.

Why bother?

Now everyone who has been running or will sync a testnet node in the future has record of how exactly to run a given microeconomy for any size community in a world where the internet may have failed and people need to continue keeping records && maybe opting into making financial transactions.

https://twitter.com/STACCoverflow/status/1676308596320006151

ordinals may not be a “great” strain on the network, but they allow a standard for storage that other chains can’t even get close to claiming. I can’t even see given transactions on explorers of some other top 10 chains by market cap if they’re dropped, and who knows what mutability does to storage on all the smart chains.

Bitcoin is the answer here, and ordinals opened up the eyes of a lot of people on how to store arbitrary data. Ignore the shit jpegs and think of real humanitarian value.

RicYashiroLee commented at 11:13 pm on October 25, 2023: none

I want to paint a better picture here:

Imagine Bitcoin as an immutable and trustable layer of the internet. It is apparent to anyone Bitcoin is the ideal solution for keeping arbitrary data past the censors and those who would alter the truth after the fact (say, maybe, a generation or two after the fact i.e. ‘history is written by the victors’)

This is better detailed in a tweet I made when I backed up all of bitcoin stack exchange to the bitcoin testnet.

Why bother?

Now everyone who has been running or will sync a testnet node in the future has record of how exactly to run a given microeconomy for any size community in a world where the internet may have failed and people need to continue keeping records && maybe opting into making financial transactions.

https://twitter.com/STACCoverflow/status/1676308596320006151

ordinals may not be a “great” strain on the network, but they allow a standard for storage that other chains can’t even get close to claiming. I can’t even see given transactions on explorers of some other top 10 chains by market cap if they’re dropped, and who knows what mutability does to storage on all the smart chains.

Bitcoin is the answer here, and ordinals opened up the eyes of a lot of people on how to store arbitrary data. Ignore the shit jpegs and think of real humanitarian value.

Complete NACK The BIP mania has made it easier then ever to dump arbitrary data into the current 17.000 Bitcoin’s voluntary full nodes. The BIP/PR mania sponsored by most Core Devs who are by definition as service providers in Bitcoin in a situation of permanent conflict of interests, has been absolutely contrary to keeping Bitcoin’s scope tyranically (SN’s term) TINY. What is needed INSTEAD is to allow/code more options in full nodes CORE software for the 17.000 node runners to choose themselves which functionality and implicitly which arbitrary data dumps to (UN)SUPPORT in their full node. I bet you NONE will be supported by these voluntarily if they have a choice!!!! So, surely NOT to even exploit further the problems that were created by the BIP mania, but instead to allow full node runners to UNSUPPORT it by giving clients of bitcoin=node runners, options. Maybe who knows some full node runner with some mental issues will want to run a HUGE full node voluntarily to support arbitrary data such as illegal data, or nudes, NFT ‘art’ or documents which could be stored in a p2p network with a scope specifically appropriate for that, as BITCOIN IS NOT AN ALL PURPOSE DATABASE, not even for ‘humanitarian’ purposes. And BTW congrats for being so altruistic, Ordinals are all about altruism 🤡 BITCOIN IS BY DEFINITION, TO EXIST AND HAVE ANY VALUE based on its value proposition, something that MUST KEEP ITS SCOPE EXTREMELY NARROW. AGAINST THAT, ORDINALS are just one of the exploits, consequence of the CORE DEVS suffering from the altcoining mindset BIP/PR mania, resembling what happened with “crypto” ‘solutions’. Obviously ALL EXPLOITS, like ordinals, only MAKE THINGS WORSE.

sennhann29 approved

junderw commented at 2:16 am on October 26, 2023: contributor

@casey A lot of the resolved comments are not actually resolved. Some of them were pretty well thought out constructive comments. If you think they don’t apply or should not be considered, please leave a comment explaining the reason for resolving them.

For anyone curious, my stance has still not changed since my first comment, though I have had an opportunity to work with inscriptions a bit, and I have made some of my concerns with the protocol’s ambiguity known on other repositories.

casey commented at 2:19 am on October 26, 2023: none

@junderw There are a ton of comments, and many of them are totally reasonable, but I’d like feedback from the BIP editors to know which, if any, they believe require being addressed.

in bip-0000.mediawiki:7 in b9506fbcdd outdated

0@@ -0,0 +1,289 @@
1+<pre>
2+  BIP: ?
3+  Layer: Applications
4+  Title: Ordinal Numbers
5+  Author: Casey Rodarmor <casey@rodarmor.com>
6+  Comments-Summary: No comments yet.
7+  Comments-URI: https://github.com/casey/ord/discussions/126

katesalazar commented at 9:50 pm on October 30, 2023:

is this a broken link?

casey commented at 10:08 pm on October 30, 2023:

Yup, fixed, thank you!

in bip-0000.mediawiki:273 in b9506fbcdd outdated

268+* A Merkle path to the coinbase transaction that created the sat
269+* The coinbase transaction that created the sat
270+* And for every spend of that sat:
271+** The spend transaction
272+** 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
273+** 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.

katesalazar commented at 9:59 pm on October 30, 2023:

Mediawiki lists are horrible, and here also break the elegant text-wide width limit. Can this section be reworked in a more pretty prose maybe?

sennhann29 commented at 10:04 pm on October 30, 2023:

Mediawiki lists are horrible, and here also break the elegant text-wide width limit.

Can this section be reworked in a more pretty prose maybe?

casey commented at 10:10 pm on October 30, 2023:

I tried, and I think it just gets kind of wordy.

katesalazar changes_requested

katesalazar commented at 10:02 pm on October 30, 2023: contributor

besides my opinions on ordinals themselves or about having this BIP, noted a couple more things

Update comments-uri link bda5cc7c6f

DrJingLee commented at 3:06 am on December 6, 2023: none

Inscriptions are a globle movement and has 3B USD market created aside bitcoin. And this BIP is still pending. Dev should do something.

RicYashiroLee commented at 11:19 am on December 6, 2023: none

Inscriptions are a globle movement and has 3B USD market created aside bitcoin. And this BIP is still pending. Dev should do something.

Inscriptions are contrary to Bitcoin’s survival. Data dumping in Bitcoin is out of its tiny scope, which must be kept “tyranically” (SN’s term) tiny, and not an all purpose DB neither a ‘world computer’ altcoining misconception mess.

Retropex commented at 11:25 am on December 6, 2023: none

Inscriptions are a globle movement and has 3B USD market created aside bitcoin. And this BIP is still pending. Dev should do something.

If we had to rely on the marketcap to make changes, it would have been a long time since bitcoin would have become a shitcoin.

earonesty commented at 10:47 pm on December 7, 2023: none

NACK : bitcoin is already a permissionless network. while some l2 proposals have BIPs - most do not, this one is probably too controversial to justify one, especially since a bip is strictly unnecessary for the operation of ordinals.

eragmus commented at 3:23 pm on December 10, 2023: none

Inscriptions are a globle movement and has 3B USD market created aside bitcoin. And this BIP is still pending. Dev should do something.

Inscriptions are contrary to Bitcoin’s survival. Data dumping in Bitcoin is out of its tiny scope, which must be kept “tyranically” (SN’s term) tiny, and not an all purpose DB neither a ‘world computer’ altcoining misconception mess.

May I ask why @RicYashiroLee is abusing the emoji feature to “upvote” his own comments, and furthermore doing so with multiple emojis? @RicYashiroLee also abuses the system by adding more than 1 emoji response to others’ comments. @RicYashiroLee should not feel entitled to conduct such behavior.

Example screenshot attached.

RicYashiroLee commented at 4:02 pm on December 10, 2023: none

Inscriptions are a globle movement and has 3B USD market created aside bitcoin. And this BIP is still pending. Dev should do something.

Inscriptions are contrary to Bitcoin’s survival. Data dumping in Bitcoin is out of its tiny scope, which must be kept “tyranically” (SN’s term) tiny, and not an all purpose DB neither a ‘world computer’ altcoining misconception mess.

May I ask why @RicYashiroLee is abusing the emoji feature to “upvote” his own comments, and furthermore doing so with multiple emojis? @RicYashiroLee also abuses the system by adding more than 1 emoji response to others’ comments. @RicYashiroLee should not feel entitled to conduct such behavior.

Example screenshot attached.!

“Should” is wishful thinkers’ favorite word. Altcoiners in Bitcoin are so ‘sticky’ that they are even able to complaint of the same exact misbehavior they do. Inscriptions ARE ABUSING the Bitcoin current ‘system’(setup), and you are complaining (??) now on this exact topic that someone is, by expressing freely my own feelings as the github system allows (just like Bitcoin unfortunately allows inscriptions!!! 🤡) that I am the one ‘abusing’ my right to express my feelings the most possible about the importance of my own messages and the ones of others on this matter crucial to Bitcoin’s survival, which I am sure by your comments waste space here you not care at all about, since IMV you are not focusing on tackling the content of message itself which is what matters?! Furthermore, this system here, GitHub, is IMV already not the most inclusive for bitcoiners node runners, the only true decentralizers of Bitcoin, to express themselves about the BIP mania and how inscriptions and other serious matters must be dealt with. If one cannot express his feelings about a topic in emojis then Github can restrict them. The fact of the matter is that for a true bitcoiner the content of the message must be what matters, not feelings, emojis or who is the messenger.

eragmus commented at 4:08 pm on December 10, 2023: none

@RicYashiroLee Do not make excuses for your bad behavior. Do not throw ad hominem and baseless accusations, in response. Instead, correct your misbehavior. That is the sign of maturity.

RicYashiroLee commented at 4:16 pm on December 10, 2023: none

@RicYashiroLee Do not make excuses for your bad behavior. Do not throw ad hominem and baseless accusations, in response. Instead, correct your misbehavior. That is the sign of maturity.

What you are complaining about is, as per my responsible reply, contradictory to what you are trying to defend, insciptions in Bitcoin, allowed by the ‘system’. So instead be responsible yourself also responding throroughly to my answer, which you did not yet, because your coment is about the system/Github setup, and zero related to the content of this BIP, which is what matters. When altcoiners lose argumentation they typically try to exclude from the conversation those who do not agree with them. They are even able to accuse the other side, of the same things they do, anything goes. 🤡🤡🤡 Focus on content.

eragmus commented at 4:37 pm on December 10, 2023: none

@RicYashiroLee Yet more excuses, ad hominem, and baseless accusations. Anyway, the purpose was to inform others that you are manipulating the emoji system. Whether or not the perpetrator is mature enough to respond appropriately is obviously out of my control.

p.s. Express your anti-Inscriptions-related argument clearly, and I’ll respond to it.

RicYashiroLee commented at 4:51 pm on December 10, 2023: none

@RicYashiroLee Yet more excuses, ad hominem, and baseless accusations. Anyway, the purpose was to inform others that you are manipulating the emoji system. Whether or not the perpetrator is mature enough to respond appropriately is obviously out of my control.

p.s. Express your anti-Inscriptions-related argument clearly, and I’ll respond to it.

I already have enough commentary above against this BIP, you did not reply to any, so baseless excuses of yours🤡 not mine. I even explained without need how Github system allows you to express several feelings about your message and the ones of others which I noticed I can yse and so do you, otherwise they would not exist or you are calling the Github team stupid for setting them up that way? “Perpetrator” is probably a word you must be used to hear, not me, I did nothing the system does not allow. The same logic applies to inscriptions and ordinals. Some people prefer to spend their time calling names to each other, or even rightly worried bitcoiners to the ‘inscripters/ordinalers’. I would rather spend my precious life time, talking instead about how to make them more and more cumbersome on Bitcoin. Not less, as this proposal is about.

junderw commented at 9:06 pm on December 10, 2023: contributor

Stay on topic, please. This is not a place for ideologues to stand on soapboxes and talk about how much they love or hate something.

Your love or hate of something is irrelevant to the discussion, and taking shots at each other and general bickering (worse than my 2 sons (7yo and 11yo)) should be done elsewhere.

Thanks.

udiWertheimer commented at 4:48 am on December 25, 2023: none

ACK, good BIP.

Also, @casey, please add @jimmysong as a co-author. He invented ordinals in 2017.

ariard commented at 7:19 am on April 25, 2024: none

why this BIP has not a BIP number ?

i don’t see the diff w.r.t infamous BIP125 defining transaction fields to be interpreted by wallets.

DrJingLee commented at 8:45 am on April 25, 2024: none

Yeah we are waiting . Maybe new editors can review and comments on some way ahead . Seems things just stuck here for over one year and no conclusion reached.

Maybe editors are also watching , learning ,and thinking 😶😶

in bip-0000.mediawiki:9 in bda5cc7c6f outdated

0@@ -0,0 +1,289 @@
1+<pre>
2+  BIP: ?
3+  Layer: Applications
4+  Title: Ordinal Numbers
5+  Author: Casey Rodarmor <casey@rodarmor.com>
6+  Comments-Summary: No comments yet.
7+  Comments-URI: https://github.com/ordinals/ord/discussions/126
8+  Status: Draft
9+  Type: Informational

jonatack commented at 10:21 pm on April 30, 2024:

It’s not clear to me which BIP type this draft would correspond to WRT BIP2. An Informational BIP does not propose a new feature. Nor does this seem to fit the criteria for a Standards Track BIP or a Process BIP.

casey commented at 5:46 pm on May 1, 2024:

Taking a look at the three kinds of BIPS:

There are three kinds of BIP:

A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.

Ordinals does not affect most or all Bitcoin implementations, so it shoudn’t be a Standards Track BIP.

An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.

Ordinals is essentially an application-level technology, so I think it fits into “guidelines or information”, and doesn’t propose a new feature, so I think it should be a Informational BIP. For example, see BIP-32, Hierarchical Deterministic Wallets. Anyone is free to use HD wallets, or not, similar to ordinals, so I think Informational BIP fits best.

A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin’s codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.

Ordinals does not require consensus and users are free to ignore ordinals, so this shouldn’t be a Process BIP.

jonatack commented at 6:32 pm on May 1, 2024:

We’ve implemented a wallet and block explorer, with public instances on mainnet, signet, and testnet, and a wallet that uses sat control to ensure specific sats are transferred to specific outputs. Constructing such transactions is tricky, especially given the dust limit and doing proper fee estimation, but once you get the details right it works well, and the fact that such transactions are otherwise normal Bitcoin transactions means that existing bitcoin infrastructure can be leveraged.

defines a scheme for assigning serial numbers to sats

provide stable identifiers

Whereas BIP32 describes a design implemented in the Bitcoin reference client, these appear to clearly describe features, thus my own hesitation with respect to Informational. There has been discussion to update or improve BIP 2, and perhaps a clarification on BIP scope will be an aspect of that.

jonatack commented at 10:33 pm on April 30, 2024: member

My current understanding of the BIP editor role is to dispassionately apply the rules and process, leaving aside personal opinion with respect to the proposals.

According to BIP2:

We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community.

My initial read is that I’m unsure if this proposal fits the above (I could be wrong). As for “building consensus within the community,” it seems controversial.

casey commented at 5:50 pm on May 1, 2024: none

My current understanding of the BIP editor role is to dispassionately apply the rules and process, leaving aside personal opinion with respect to the proposals.

According to BIP2:

We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community.

My initial read is that I’m unsure if this proposal fits the above (I could be wrong). As for “building consensus within the community,” it seems controversial.

This does not mean that “consensus within the community” is required for a BIP to be accepted. If this were the case, it would be not be possible to write BIPs for potential soft forks, before they had achieved consensus.

And, the description of “Informational BIP” explicitly says that they do not require consensus:

Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.

bitcoin deleted a comment on May 1, 2024

jonatack commented at 6:51 pm on May 1, 2024: member

Let’s please keep comments focused on technical review of this proposal – thank you.

in bip-0000.mediawiki:209 in bda5cc7c6f outdated

204+entries in the UTXO set, and thus increase the size of the UTXO set, which all
205+full nodes are required to track.''
206+
207+The dust limit, which makes outputs with small values difficult to create,
208+should encourage users to create non-dust outputs, and to clean them up once
209+they no longer have use for the sats that they contain.

Retropex commented at 7:37 pm on May 1, 2024:

this paragraph should be removed because it is factually false.

Retropex changes_requested

Retropex commented at 7:38 pm on May 1, 2024: none

I am totally against the merge of this BIP, in the past other BIP could have be merged even if they were controversial. However, this BIP is an attack on Bitcoin because individual satoshi do not exist and is largely linked to “scamcoins”.

but if maintainers still want to merge this BIP I think the paragraph on UTXOs should be removed because it is factually false.

murchandamus commented at 7:00 pm on May 10, 2024: contributor

There has been some debate whether this document is in-scope or out-of-scope for this repository. I am therefore delaying my review of this PR until the scope of this repository has been discussed.

murchandamus added the label Process on May 10, 2024

ProofOfKeags commented at 7:23 pm on May 10, 2024: contributor

Yeah it seems this is a referendum on the scope of BIPs.

I do want to note here, though, that having a BIP that clearly defines the process by which these types of overlay protocol schemes operate actually reduces scam potential.

Whether or not something you spend money on has value to you is a matter of subjective opinion, however, having documentation that clearly specifies the nuts and bolts of these types of protocols helps avoid situations where people disagree on how these overlay protocols behave. It allows people to verify the authenticity of these things they are attempting to acquire.

Whether or not the BIPs repository specifically is the right place to house such documents is definitely something worth discussing, however, if it is decided that the BIP repository is NOT the right place for such documents, it doesn’t alleviate the need for having some place for these sorts of canonical documents.

katesalazar commented at 7:28 pm on May 10, 2024: contributor

this BIP is an attack on Bitcoin because individual satoshi do not exist and is largely linked to “scamcoins”. @Retropex wrong, individual sats exist because txs are public by design and the blocks contain the txs in serialized form by design.

Ordering sats is not a choice, the choice is which way’s the simplest one to ordering them sats.

DrJingLee commented at 0:44 am on May 11, 2024: none

There has been some debate whether this document is in-scope or out-of-scope for this repository. I am therefore delaying my review of this PR until the scope of this repository has been discussed.

Thanks to make it clear. We need to do some kind of literature review of “scope” related of this repository. The point is whether this initiative is in-scope or out-of-scope of the repository .

Psifour commented at 0:52 am on May 11, 2024: none

BIP 39, which is not implemented in core, is tagged as Standards Track, 32 is tagged as Informational. It seems to me that this is simply an editorial field in it’s current form as it lacks sufficiently strict rules to adequately catagorize all relevant proposals.

As such, it seems unreasonable that we are now using flaws in the clarity of BIP 2 to continue withholding a BIP number for what is literally just an informational BIP.

DrJingLee commented at 0:56 am on May 11, 2024: none

BIP 39, which is not implemented in core, is tagged as Standards Track, 32 is tagged as Informational. It seems to me that this is simply an editorial field in it’s current form as it lacks sufficiently strict rules to adequately catagorize all relevant proposals.

As such, it seems unreasonable that we are now using flaws in the clarity of BIP 2 to continue withholding a BIP number for what is literally just an informational BIP.

Where can I find some definition of scope or maybe a BIP of “definition of scope " is also need 😀😀

junderw commented at 1:06 am on May 11, 2024: contributor

BIP 39, which is not implemented in core, is tagged as Standards Track, 32 is tagged as Informational. It seems to me that this is simply an editorial field in it’s current form as it lacks sufficiently strict rules to adequately catagorize all relevant proposals.

As such, it seems unreasonable that we are now using flaws in the clarity of BIP 2 to continue withholding a BIP number for what is literally just an informational BIP.

BIP39 is discouraged for use despite being widely used and is an example of why we need to be more careful with merging BIPs.

“We made horrible mistakes before so lets make another similarly horrible mistake now” is not the proper logic to run with here.

DrJingLee commented at 1:20 am on May 11, 2024: none

BIP 39, which is not implemented in core, is tagged as Standards Track, 32 is tagged as Informational. It seems to me that this is simply an editorial field in it’s current form as it lacks sufficiently strict rules to adequately catagorize all relevant proposals.

As such, it seems unreasonable that we are now using flaws in the clarity of BIP 2 to continue withholding a BIP number for what is literally just an informational BIP.

BIP39 is discouraged for use despite being widely used and is an example of why we need to be more careful with merging BIPs.

“We made horrible mistakes before so lets make another similarly horrible mistake now” is not the proper logic to run with here.

The opposite will be additude : “Once bitten, twice shy” It is not a proper logic either.

apoelstra commented at 2:00 pm on May 11, 2024: contributor

I am not a big fan of BIP39, but let’s remember that it was merged in 2013. It was years before the problems with it became apparent and probably many of them required widespread usage to notice. (Today many of them would be readily apparent, but we have a lot more experience now.)

If its issues were readily apparent at the time I would expect its many implementors to have requested changes.

So there isn’t a clear lesson to be taken from that IMHO.

casey commented at 7:06 am on May 12, 2024: none

There has been some debate whether this document is in-scope or out-of-scope for this repository. I am therefore delaying my review of this PR until the scope of this repository has been discussed. @murchandamus

Making the criteria for what is in-scope for a BIP less ambiguous would definitely be an improvement over the current situation.

However, I believe that ordinals would be in-scope for a BIP given any reasonable criteria. As mentioned in the ordinals BIP, ordinals can be used as public identifiers that can receive bitcoin payments, where the underlying private keys can be swapped, to allow for private key rotation in case of compromise or a change in the underlying custody setup. Alice tells Bob the ordinal number of a sat that she controls, and Bob can send bitcoin to the address holding that sat. Alice can then transfer that sat to a new address, indicating that going forward, she wishes to be paid at that new address. Alice can swap address types, private keys, or any other aspect of her custody setup and need communicate no new information to Bob to continue receiving payments from him. This makes ordinals squarely in-scope for a BIP, given the vast number of other BIPS concerning addresses, wallets, and payment methods, which would surely not be made out-of-scope for a BIP under any reasonable criteria. The fact that it has other applications, like collectable sats and inscriptions, is not a tenable rationale for making ordinals itself out-of-scope for a BIP.

DrJingLee commented at 8:00 am on May 12, 2024: none

There has been some debate whether this document is in-scope or out-of-scope for this repository. I am therefore delaying my review of this PR until the scope of this repository has been discussed.

“If a law can be falsified but has never been falsified, then we consider it to be valid.”

In the past long time discussion of this topic,there is no evidence that Ordinals theory is out-of-scope of the BIP range.

I may suggest that editors should review all the discussion in the past long period and find if there is any solid evidence/fact that ordinals theory is NOT in-scope of the BIP range.If NOT, then I think editors should consider assuming Ordinals are in-scope of the BIP range for not finding any out-of-scope evidence .

sharphill2022 commented at 11:37 am on May 12, 2024: none

Ordinal theory, as a theory of satoshi numbering, is a very appropriate result to be proposed as a BIP for discussion. I hope that eventually ordinal theory can be accepted by the BTC main network. However, before accepting the ordinal theory, I think it is necessary to seriously discuss whether there are any areas in the ordinal theory that need fine-tuning. For example, some of the current principles of the ordinal theory conflict with the principles of BTC. These conflicting areas require necessary adjustments. For example, ordinal theory believes that satoshis will be destroyed, and there are many ordinal numbers that do not have satoshis behind them, which means that the numbers are not continuous, but intermittent. I think these are areas worth fine-tuning. For specific discussion, please refer to this issue.

https://github.com/ordinals/ord/issues/3690#issuecomment-2083950493

sharphill2022 commented at 1:35 am on May 17, 2024: none

Where the ordinal theory needs fine-tuning:

The Ordinals protocol allows for the destruction of sats. In fact, in the ordinals ordinal theory system, 2,895,502,904 sats have already been destroyed. This result can be verified by querying the Ordinals website (https://ordinals.com/status).
The Ordinals protocol assigns ordinals to sats based on theory, resulting in many ordinals that do not have corresponding actual sats. For example, at block height 840,000, which is the fourth halving, the first sat of that block, called “epic,” has the ordinal 1,968,750,000,000,000. This may lead to the misconception that 19,687,500 BTC have already been issued. However, in reality, before reaching this height, there were less than 19,687,497.2 BTC in circulation due to several reward blocks not being fully claimed. Therefore, in the ordinals ordinal theory, behind the ordinal 1,968,750,000,000,000 of the epic sat during the fourth halving, there are many ordinals without corresponding sats.

I suggest that ordinal theory be adjusted to the following rules:

The ordinal of the first sat is 0.
Numbering continues in the order of birth without any gaps.
Sat transfers follow the first-in, first-out principle.
In reward transactions, the rewarded sat is the first input, and other transaction fees are sequentially added after it.
The number of rewarded sats strictly matches the actual reward quantity.

Among them, 2 and 5 have some differences from the current ordinal theory.

5twelve approved

alpeshvas approved

twosatsmaxi approved

monkeydluffyto approved

ariard commented at 2:50 am on September 5, 2024: none

Do @casey needs to have sexual intercourse with a BIP repository maintainer (or financially bribe one) for this draft to get a number ?

…I’m only half-joking…There are already “Applications” BIP like BIP175, BIP197 or BIP199 which are only useful if both end-to-end wallet clients support them and there are not sustained hints those application-level protocol get today more fee traffic than ordinals, even less I doubt they have been sufficiently reviewed for the protocol to work as described.

in bip-0000.mediawiki:195 in bda5cc7c6f outdated

190+''Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as ordinals
191+received in a transaction may carry with them some public history.''
192+
193+As anyone can send anyone else any sats, any reasonable person will assume that
194+a new owner of a particular sat cannot be understood to be the old owner, or
195+have any particular relationship with the old owner.

jonatack commented at 8:13 pm on September 6, 2024:

Suggest s/old/previous/ in both instances.

casey commented at 10:33 pm on September 6, 2024:

Fixed, thank you!

in bip-0000.mediawiki:278 in bda5cc7c6f outdated

273+** 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.
274+
275+== Reference implementation ==
276+
277+This document and an implementation of an index that tracks the position of
278+sats in the main chain are maintained [https://github.com/casey/ord here].

jonatack commented at 8:16 pm on September 6, 2024:

Are there other implementations and is there a need for interoperability?

casey commented at 10:32 pm on September 6, 2024:

I know of one non-public re-implementation in Go[0] and an alternative Rust implementation[1]. I think there are others out there, but haven’t been paying a lot of attention recently. I’m sure there are a bunch of a-hoc scripts and tools though.

It’s also pretty common to manually construct ordinals-aware transactions, which must match this BIP, so that’s another place where interoperability is important.

[0] https://blog.ordinalhub.com/what-is-gord/ [1] https://github.com/hirosystems/ordhook

in bip-0000.mediawiki:255 in bda5cc7c6f outdated

250+
251+Indexes supporting fast queries related to ordinals are slow to build and
252+consume large amounts of space.
253+
254+As of January, 2023, an O(1) index that maps UTXOs to the ordinals that they
255+contain is 100 GiB. The same index including spent outputs is 10 TiB.

jonatack commented at 8:16 pm on September 6, 2024:

Perhaps update this to the current (September 2024) size.

casey commented at 10:35 pm on September 6, 2024:

Will do! I currently only have access to indices which also contain other things, so I’ll need to build a fresh index. I’ll update this tomorrow.

casey commented at 7:37 pm on September 7, 2024:

Updated! Due to database optimizations on our part, it’s actually smaller, 93 GiB.

in bip-0000.mediawiki:238 in bda5cc7c6f outdated

233+payments or savings, since this would associate that publicly visible data with
234+the users otherwise pseudonymous wallet outputs.
235+
236+=== Fungibility considerations ===
237+
238+Since any sat can be sent to any address at any time, sat that are transferred,

jonatack commented at 8:17 pm on September 6, 2024:

0Since any sat can be sent to any address at any time, sats that are transferred,

casey commented at 10:33 pm on September 6, 2024:

Fixed, thank you!

jonatack commented at 8:18 pm on September 6, 2024: member

Do @casey needs to have sexual intercourse with a BIP repository maintainer (or financially bribe one) for this draft to get a number ?

…I’m only half-joking…

Please don’t troll. Moreover, the suggestion that sex or bribes might be involved with a number assignment probably doesn’t increase the motivation to do.

in bip-0000.mediawiki:72 in bda5cc7c6f outdated

67+
68+=== Specification ===
69+
70+Sats are numbered and transferred with the following algorithm:
71+
72+<source lang="python">

jonatack commented at 8:22 pm on September 6, 2024:

No strong opinion, but perhaps either provide pseudocode or valid python.

 0#!/usr/bin/env python3
 1
 2
 3def subsidy(height):
 4    """Subsidy of block at given height."""
 5    return 50 * 100_000_000 >> height // 210_000
 6
 7
 8def first_ordinal(height):
 9    """First ordinal of subsidy of block at given height."""
10    start = 0
11    for height in range(height):
12        start += subsidy(height)
13        return start
14
15
16def assign_ordinals(block):
17    """Assign ordinals in given block."""
18    first = first_ordinal(block.height)
19    last = first + subsidy(block.height)
20    coinbase_ordinals = list(range(first, last))
21
22    for transaction in block.transactions[1:]:
23        ordinals = []
24        for input in transaction.inputs:
25            ordinals.extend(input.ordinals)
26
27            for output in transaction.outputs:
28                output.ordinals = ordinals[: output.value]
29                del ordinals[: output.value]
30
31                coinbase_ordinals.extend(ordinals)
32
33                for output in block.transaction[0].outputs:
34                    output.ordinals = coinbase_ordinals[: output.value]
35                    del coinbase_ordinals[: output.value]

casey commented at 10:24 pm on September 6, 2024:

I think the indentation is off in the suggested code. Is it just the doc comments that you’d suggest adding?

jonatack commented at 8:29 pm on September 6, 2024: member

@casey thoughts on #1408 (comment)?

ariard commented at 9:21 pm on September 6, 2024: none

Please don’t troll. Moreover, the suggestion that sex or bribes might be involved with a number assignment probably doesn’t increase the motivation to do.

It’s only a half troll… I remember taking luke-jr defense in 2021 when a lot of people were talking about doing a bypass of its janitorial role as a bip maintainer and that time asking publicly the github organization admins to appoint without consensus new maintainers to have a bip number assigned to the BIP proposal they favored.

I also think all the set of bips that were proposing increases of the block size (100, 101, 102, 103), whatever their level of technical seriousness where assigned a BIP, and all of them had more serious implications on the long-term technical and economical stability of the bitcoin peer-to-peer network, that this simple BIP had.

There are sound conversations to add on the long-term effects of colored coins protocol on the Bitcoin ecosystem, though in a world of pay-to-contract and vanity addresses, ordinals are on a par with as an idea.

So for an external observer, it’s unclear why the BIP is not assigned a number, after all it’s probable that all BIP maintainers have sharing communication channel to coordinate the assignment of number, otherwise it’s unclear how they avoid potential collisions in assignment due to working in an asynchronous digital work environment.

ariard commented at 9:28 pm on September 6, 2024: none

I don’t think that comment is technically sound.

About (1) at the consensus-level, there is no sat destruction unless the private keys is definitively loss (and it’s hard to prove a private key loss if there has been a boat accident) and about (2) one can make the same argument about lightning milli-sats, which have no meaning at the consensus-level, yet are interpreted by lightning nodes since 2018. The keys backing a block reward claim can have been shuffled in a discreet fashion by using shamir secret sharing, or other crypto-systems not letting obvious mark on the blockchain.

casey commented at 10:28 pm on September 6, 2024: none

@casey thoughts on #1408 (comment)?

This comment is suggesting a change to the way that numbering handles cases in which sats can be destroyed. The main change, point 2, would be that when a miner underpays the block reward, causing new sats to be destroyed, this be reflected in the numbering of sats in subsequent blocks. This would require that, in order to know when a sat with a particular number was created, you look back at all previous blocks to see if any had been destroyed, and so would greatly complicate implementations, and turn what previously were O(1) calculations into O(N) calculations, where N is the number of blocks, without a clear benefit.

The author writes that point 5 is also a change, but I’m not sure what they mean by it.

In any case, ordinals is already widely deployed as is, so this BIP seeks to document it in its existing state.

Fix typo and improve style d1a5fda43e

Update current index size bcb21c5b3e

jonatack added the label New BIP on Sep 9, 2024

sharphill2022 commented at 4:37 am on September 23, 2024: none

I don’t agree with @casey ’s statement.

Ordinals have been widely recognized, but they are more used to inscribe and index data. Most people don’t care whether a satoshi’s current ordinal number is n or m. Those who care are more familiar with technical details and pay more attention to the security of BTC and the indestructible nature of satoshis themselves. Satoshis can be lost, but the introduction of a BIP should not lead to the destruction of existing satoshis. This is unacceptable both technically and emotionally.

Moreover, the Ordinals protocol also claims that Satoshi is indestructible, so why not unify the theory and implementation? Is there any reason to leave a gap that could destroy a Satoshi?

sharphill2022 commented at 4:47 am on September 23, 2024: none

In addition, computationally, there are countless ways to make indexing a satoshi O(1). We have implemented a go-code version of the indexer, where the satoshis are naturally sorted by birth order, with no gaps, and increment from 0. If needed, we can provide the source code for this indexer.

The indexer data can be browsed through this webpage. Open this webpage, click NFT, and you can see all NFTs minted through Ordinals protocol: https://app.sat20.org/#/explorer

New BIP: Ordinal Numbers #1408