bips
bips copied to clipboard
bitcoin
New BIP: Ordinal Numbers
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!
@luke-jr I think this qualifies for a BIP assignment.
Edit: I spoke in haste. Will return with feedback.
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.
ACK
Added 2 suggestions:
Fix typo
Syntax highlighting for code
Nice, fixed! Thank you 👍
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?
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.
@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
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.
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
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.
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: https://github.com/bitcoin/bips/pull/1408#issuecomment-1430575707
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.
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)
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!
Anyone may have opinions and share their thoughts. This does not impact the merging of this BIP
@Semisol See https://github.com/bitcoin/bips/pull/1104 as an example how opinions of editor(s) can delay merging of PRs
See https://github.com/bitcoin/bips/pull/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.
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.
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.
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.
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.
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.
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.
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.
@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.
NACK
This should be managed in a separate repo for the Ordinal Project similar to BOLTs. This could be OIP-001.
@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?
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.
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 😅
@Semisol That's a requirement for moving a BIP to Final status, not for BIP assignment.