New BIP: Ordinal Numbers #1408
New BIP: Ordinal Numbers #1408
Conversation
|
@luke-jr I think this qualifies for a BIP assignment. Edit: I spoke in haste. Will return with feedback. |
| The ordinal numbers of sats in transaction inputs are transferred to output | ||
| sats in first-in-first-out order, according to the size and order of the | ||
| transactions inputs and outputs. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
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.
|
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. |
|
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. |
|
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. |
|
I'm very open to style, license, and scope feedback, since I've never submitted a BIP here for review. |
Nice, fixed! Thank you 👍 |
bip-0000.mediawiki
Outdated
| Status: Draft | ||
| Type: Informational | ||
| Created: 2022-02-02 | ||
| License: PD |
There was a problem hiding this comment.
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)
bip-0000.mediawiki
Outdated
| for output in block.transaction[0].outputs: | ||
| output.ordinals = coinbase_ordinals[:output.value] | ||
| del coinbase_ordinals[:output.value] | ||
| </pre> |
bip-0000.mediawiki
Outdated
| @@ -69,7 +69,7 @@ mined, not how many actually were. | |||
|
|
|||
| Sats are numbered and transferred with the following algorithm: | |||
|
|
|||
| <pre> | |||
| ```python | |||
There was a problem hiding this comment.
| ```python | |
| <source lang="python"> |
|
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. |
|
Is this going to need a series of BIPs or is a single BIP number going to be sufficient @casey?
@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. |
BOLTs should stay separate. It has grown into something that would ideally have its own proposals.
|
|
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. |
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. |
| [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP-34] made | ||
| the creation of transactions with duplicate IDs impossible. | ||
|
|
||
| For the purposes of the assignment algorithm, the coinbase transaction is |
There was a problem hiding this comment.
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 ?
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. |
Anyone may have opinions and share their thoughts. This does not impact the merging of this BIP
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) |
|
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! |
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. |
|
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. |
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. |
@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:
@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. |
@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:
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. |
|
Concept ACK for BIP assignment. |
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. |
|
@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. |
|
@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. |
|
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. |
|
ACK, good BIP. Also, @casey, please add @jimmysong as a co-author. He invented ordinals in 2017. |
|
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. |
|
Yeah we are waiting . Maybe editors are also watching , learning ,and thinking 😶😶 |
There was a problem hiding this comment.
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.
| Comments-Summary: No comments yet. | ||
| Comments-URI: https://github.com/ordinals/ord/discussions/126 | ||
| Status: Draft | ||
| Type: Informational |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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:
|
|
Let's please keep comments focused on technical review of this proposal -- thank you. |
There was a problem hiding this comment.
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.
|
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
Process
|
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. |
@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, |
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 . |
|
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 😀😀 |
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 : |
|
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. |
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. |
"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 . |
|
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. |
|
Where the ordinal theory needs fine-tuning:
I suggest that ordinal theory be adjusted to the following rules:
Among them, 2 and 5 have some differences from the current ordinal theory. |
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!