Should inscription numbers be unstable?

[casey]

Inscription numbers are numbers assigned to inscriptions in the order in which they are created, starting at zero for the genesis inscription.

When inscription numbers were originally added to ord, the Ordinals wallet and explorer that powers ordinals.com, they were intended to be stable and never change.

However, now that we have more experience with the protocol, that seems less tenable and has undesirable consequences, as maintaining stable inscription numbers is a challenge in the face of changes to the inscription protocol.

Consider a simple case, an update that allows multiple inscriptions to be created in a single transaction.

The inscription numbers assigned by an implementation that recognizes multiple inscriptions in a single transaction would differ from those assigned by an implementation that does not.

The former implementation would see T1, creating two new inscriptions, and T2, creating a single new inscription, and assign inscription numbers N, N+1, and N+2, the latter implementation would assign inscription number N to the first and only inscription it recognized in T1, and N+1 to the inscription in T2.

There are many such updates that we would like to make or have made which would introduce discrepancies like these, including:

• Multiple inscriptions per transaction
• Inscriptions in reveal inputs other than the first
• Inscriptions with new even fields
• Multiple inscriptions on the same sat

We've been able to make these changes and keep inscription numbers stable using what I've now come to think of as a regrettable hack: cursed inscriptions. Whenever ord indexes an inscription which would not be recognized by an earlier version, it assigns a negative inscription number. This keeps old inscription numbers stable, while still recognizing new inscriptions.

Cursed inscriptions and negative inscriptions numbers have a number of downsides:

• An inscription number now does not tell you anything about the order in which the inscription was made.
• The logic required to keep track of which inscriptions are cursed is a source of bugs and complexity.
• "Blessing" cursed inscription types, i.e., collectively deciding that after a certain block height, certain cursed inscription types will no longer be assigned negative numbers, and be assigned positive numbers instead, requires coordination.
• Cursed inscription numbers are permanently unstable, so a substantial number of inscription numbers are already unstable, even under the status quo.

In light of the above, I propose that we make inscription numbers permanently unstable, and bless all cursed inscriptions, both retroactively and on an ongoing basis. Cursed inscription numbers would be folded into the main sequence, and, going forward, inscription numbers should not be used in URLs, which is already the case for ord, and inscription numbers would be de-emphasized on /inscription pages.

This would substantially simplify the ord codebase, make it easier to produce an implementation that assigns the same sequence numbers, and make future protocol changes easier.

Also, keep in mind that inscription numbers would change, but wouldn't entirely go away. New inscription numbers would be close to old inscriptions numbers, perhaps only differing by %1 or so.

What do you think?

[cbspears]

In light of the above, I propose that we make inscription numbers permanently unstable, and bless all cursed inscriptions, both retroactively and on an ongoing basis. Cursed inscription numbers would be folded into the main sequence, and, going forward, inscription numbers should not be used in URLs, which is already the case for ord, and inscription numbers would be de-emphasized on /inscription pages.

Strong ACK. Have been pushing to de-emphasize Inscription #s for a very long time.

Let me know where you think the best place to discuss this but I would consider "Cursed" P2SWH Inscriptions similar to #2139 as perhaps relevant to this discussion as well.

UPDATE
I really like the direction @huuep is going in this comment here. I would direct everyone there: #2458 (comment)

[BennyTheDev]

Could this be done with a grace period such that trackers can update and re-index everything before this gets into effect?
Else than that I believe we can bury numbers then once and for all. People don't even know what inscription ids are anymore and use numbers instead.

[cbspears]

I think it would make sense to set an "activation block height" once a resolution has been achieved.

[BennyTheDev]

yeah, like originally planned with cursed ones.
But there is a serious implication if previously invalid inscriptions make it into the ord index after such an activation block. it would basically harm all metaprotocols indefinitely. "Causality" should be maintained at all costs.

[wgomez23]

Depending on the metaprotocol, this could be a nightmare to clean up post update.

[BennyTheDev]

and ongoing. as I understood this can potentially happen with every wallet update after.

[BennyTheDev]

Psifour confirmed causality will be maintained after the update and there will also be a prolonged test-run before it gets out.

[jokie88]

I strongly support. the viability and maintainability of the protocol is the most important thing.

however i think the communication of the exact impacts should be very clearly illustrated so people understand what will change.

it’s pretty reasonable to us technical folk but as a non technical person it sounds very scary and unpredictable. maybe my sub 10k will suddenly become over 1m!?!? will this upend my carefully curated collection and make them worthless?! the reality is much tamer but “inscription numbers are fluid” makes the imagination go wild. so illustrating the change will be key imo.

[pleurerP]

"chronological ordering" >> "unstable"

[brandonmarshall-tm]

EDIT: Now that I've had time to think about this more, I'm expanding on my original post:

I think a good compromise is to preserve the immutability of existing inscription numbers, while also depreciating new inscription numbers going forward.

So for context, we basically have a set of positive-numbered ordinals and a set of negative-numbered ordinals, and those negative numbered ordinals are cursed. These cursed ordinals are already fluid, meaning their inscription numbers are already expected to change in the future.

Basically we would set a block height for when Ord 1.0 gets activated. When that block height comes, the following would happen:

• All current positive-numbered (regular) inscriptions would now become negative inscriptions, and would become static. Inscription 0 remains inscription 0, Inscription 1 becomes Inscription -1, Inscription 203665 becomes -203665, etc.
  • No new negative-numbered inscriptions would ever be created, preserving them in time.
• All current negative-numbered (cursed) inscriptions are immediately blessed and become positive numbered. These are numbered based on block height and the time they were mined.
  • Those numbers obviously end up changing, but they were expected to be fluid anyway, so it's not a huge deal.

What I like about this solution is that:

• Metaprotocols like BRC-20 who have relied on static inscription numbers in the past will only have to make minor adjustments to their code to look at negative numbers instead of positive numbers. Since we're just flipping the integer to negative, there should be no impact to BRC-20 balances. The metaprotocols will then have enough time to index the new positive numbers going forward, after the specific block height that activated Ord 1.0 has been reached.
• Early adopters of Ordinals (pre-1.0) would be graced with these exclusive negative-numbered inscriptions that are preserved in history, of which no more will be created.

Some additional considerations:

• BRC-20 indexers will need to account for this duality. Inscriptions prior to 1.0 follow this negative-numbered set of rules, and inscriptions after the block height of 1.0 activation have to follow this positive set of rules. They could alternatively take a snapshot and expand on things from there post-activation.
• People holding early cursed ordinals that were hoping to eventually be blessed in with existing inscriptions won't really get the opportunity to do that. But I don't think there was a ton of precedent set there anyway, so I think this is a small price to pay for a more sustainable system going forward. And they will still have early positive-numbered inscriptions!

Original post:
I look at inscription #'s as a sign of how "early" an inscription might have been made, but rarely focus on the number itself. As long as my early inscriptions remain early, I'm fine with it. Modifying the code to simplify accounting for all these edge cases seems like a more ideal long-term option.

I do wonder how indexers will adjust to this change, but indexers already sometimes differ in inscription #, so it might be a non-issue.

[BennyTheDev]

well, I think that's easy to solve with 3rd party indexing. I didn't test that yet but the numbers should be equivalent to the transaction index of each block. so if that turns out to be true, then the ord wallet could completely remove those numbers and leave numbering to 3rd party indexers.

[Anarkoic]

Strong disagree.

This would be what many would consider to be a rugging.

The community can agree on a block number from which cursed ordinals would be given regular numbers. Just like the community theoretically agrees on the overall protocol.

Code and protocols get messy as they age. That's reality.

Purity is for virgins.

[vibeymonk]

The inscription number doesn't "define" the inscription, The inscription ID is the important part + it's time stamped. Making this change helps managing the protocol easier, marketplaces have filters for "seniority" if that's the concern.

[gmart7t2]

Are inscription ids stable? The part after the i is like a mini inscription number within a tx and potentially suffers from the same issue when the rules are changed

[BitTogether]

To the peerson who was skipped for numbering it feels like a rugging to not honor their inscription.

[RagnarLifthrasir]

Strongly agree.
Tech > vanity

[bitgod21]

What about culture > tech?

[DanM3rcurius]

culture is tech. welcome to cypherpunk.

[brianorwhatever]

Yes strongly support this idea. Cursed inscriptions were always a bad idea for many reasons. If there is an off-chain vanity # assigned to every inscription it should be strictly derived from on-chain ordering.

[pleurerP]

Can we accomplish this without a hard fork?

i.e. is it feasible to accept the ordering as-is through a certain block and begin the more easily programmable numbering afterward?

[hans-crypto]

Great idea! 🙂

I have concerns because...

• From a human perspective, people want a readable, short number. The TXIDiN is really a bit too long.
• From a technical point of view, we need a method to easily sort inscriptions to determine which one came first.

How about this approach: the new "inscription number" is a combination of two keys. The first key represents the block number, while the second indicates the position of that inscription within the block. By adopting this schema, we could initiate an index of inscriptions at any given time, even without prior knowledge.

We could consider two similar yet distinct approaches:

a) Block number + number of the transaction in the block — this will always remain constant, but there will be gaps.
b) Block number + number of the inscription in the block — this will be unstable.

[rxxndy]

Better to make a change for things moving forward once the new tech exists than change things from the past.

Also, what will this do to BRC20?

[BennyTheDev]

the problem is that retroactively added inscriptions may have been inscribed in earlier blocks. if after this change, inscriptions from earlier blocks are being added to the ord index, it could harm any metaprotocol negatively.

Therefore I strongly suggest to not include any inscription from earlier blocks if they didn't qualify within their block already.

[rxxndy]

then it is best to do nothing at all

[BennyTheDev]

why? I think the ord wallet can keep a list of rejected ones per block and just doesn't include them in subsequent updates if they would have been included otherwise.

[coinyeezy]

Doing nothing is a viable option here. I don't see the return on this investment of multiple months worth of time + energy spent on the topic. I reccomend punting on this and circling back in 18 months. You might be surprised, the market can solve alot of problems organically without central planning or government intervention.

• CEO

[onchainguy-btc]

Does adding these features make the protocol so much better that it's worth disrupting a system that has been accepted and appreciated? I know they're just examples but still I don't think so.

• Multiple inscriptions per transaction
• Inscriptions in reveal inputs other than the first
• Inscriptions with new even fields
• Multiple inscriptions on the same sat

[DanM3rcurius]

yes they do and yes it is. It makes the protocol scale better and make inscriptions less expensive. Many applications are waiting on this.

[Lafourkad]

Ugg

[mavrogkata]

Is there a way to keep the sub100k inscription number?
I believe a lot of collectors (including myself) Will feel like "ruged"

[stet]

My opinion from April stands.

I wanted you and the core team to not be burdened by this back then.
I respect the effort to try something to appease people, but I support your current perspective 100% to streamline Ord as much as possible as the protocol approaches finality.

[Anarkoic]

Each of these examples:

Multiple inscriptions per transaction
Inscriptions in reveal inputs other than the first
Inscriptions with new even fields
Multiple inscriptions on the same sat

can be added to non-cursed interpretation list after block # x, and treated as cursed before.

yes there is historical cruft in the code, but backward compatibility and rare numbers are an important part of digital artifacts and more human parseable than rare sats. Code with mass adoption always builds up cruft. Look at Windows.

Re-writing numbers would seem a bad pattern when we look at high-tech history over the last 4 decades, as detailed in this book:
https://www.amazon.com/Search-Stupidity-High-Tech-Marketing-Disasters-ebook/dp/B09X6FQ9HS/

[jokie88]

do you have an excerpt or a particular story from that book that is relevant? I think it could be informative for the convo if you do.

[0xFlicker]

From the sentiment here and on twitter I can tell that I am in the minority of not caring one bit about inscription numbering since when I work with ordinals it is almost exclusively by inscription id, which is the immutable part.

I would be entirely OK with getting rid of inscription numbers entirely from the reference implementation as they are just a vanity metric that anyone can track as they plz (or not).

[BennyTheDev]

the problem goes far beyond numbering (which I agree on to that part)

[cvasqxz]

My humble proposal:

1. remove the whole idea of a cursed inscription to avoid future drama
2. make the index based on "1 envelope = 1 inscription" to accept multiple inscriptions on one TX
3. make a concrete definition of every key concept on this project
4. don't discuss/implement things based on monetary incentives (rarity, volume, etc)
5. let us propose stuff in a clear way

[zhiying8710]

1. remove the whole idea of a cursed inscription to avoid future drama
strongly agree, i totaly igonre all cursed inscriptions in my project

[rafaelcr]

I'd like to chime in about how this change could affect (or not) meta protocols, specifically BRC-20:

Inscription numbers

Numbers today are really a proxy to block_height + tx_index, given that they are assigned to inscriptions in the order at which the transactions were mined in a block. As such, because BRC-20 indexers also process operations in the same order there's a belief that indexing would be broken if they are removed.

If numbers cease to exist, however, BRC-20 can remain unaffected as indexers could simply switch to processing operations using a tx_index ordering instead of an inscription number ordering. This is a relatively trivial change that indexers could actually do today, because it would yield the exact same results.

Blessing cursed inscriptions

What could affect BRC-20, though, is the blessing of cursed inscriptions. Today, there are a lot of BRC-20 operations that are completely ignored by indexers because they are done via cursed inscriptions. If they are suddenly blessed, indexers will definitely break and show incorrect (or different) balances to what they show today.

However, if this is the case, the BRC-20 spec can simply be amended to only count inscriptions in vout 0, tapscript, etc. as valid (i.e. count only those inscriptions that are considered blessed today). This would be another simple change to indexers that would not affect any of the token holders' balances.

[stet]

Exactly. I came here to ask what I was missing regarding claims of breaking "all metaprotocols". I asked in a space, and I just moments ago asked Benny of Trac. Then saw this come through. These fixes are quite trivial, and I do not think it is fair to have drama stirred up on X as if there would be some irreversible breakage. Inscription numbers are only expressed as a vanity on top of timestamped txs.

Thanks for posting.

[BennyTheDev]

Your response was overlapping with mine. So we can take this as confirmation moving forward, no inscriptions from earlier blocks may unexpectedly be included?

I am not relying on numbers anyway, I just want to make sure that at some point we don't have to re-index everything with every single ord wallet update. Thank you for clarification.

[edit] I talked with a couple of people that are also closely following the ord wallet project and they pretty clearly stated changes may occur on an ongoing basis. So unless I am not reading a clear statement about that from the devs, I have to stick with the last known information, which clearly says "ongoing" as stated by Casey above.

[BennyTheDev]

Question: are the proponents here aware that this will lead to ongoing causality breaks and grandfather-paradoxes?

I am usually very patient and really do not like to tell others what they should do, but I make an exception:

I am not concerned about the numbers per se but at some point you need to draw a line and finalize the protocol. From that moment on, no other edge-case will be allowed to get included in the index. No matter what a small group of people demands and shills for. And before the above idea is getting released, give the ecosystem at least 3 months of time to adapt (~50% of the time it took for the ecosystem to emerge).

To me, personally, it's shocking that people that deal with blockchain every day seriously consider something that is supposed to be continuously unstable and thus unreliable.

Thanks for reading, feel free to hate me now.

[Psifour]

The inscription number should not be used as a stable identifier. We reference inscriptions by one of the two reasonable methods instead. These two methods are:

• By Inscription ID. This ID is made up of transaction hash and an index. Since transaction hashes are unique (other than the two grandfathered exceptions in Bitcoin's history) we can know that these identifiers will not have collisions. Their inclusion of the txhash also means that they are self-referential pointers to where the data lives on-chain.
• By ordinal number (and optionally which inscription on that sat). This relies on the uniqueness guarantee of Ordinal Theory (again assuming that the two grandfathered exceptions are handled) to gain the same assurances about lack of collisions. Lookups of the data for these can be done by starting at the sats 'point of origin' and forward tracking (if not maintained in a full index).

As for the core of your concerns, this only leads to future challenges if we fail to define the standard of what an inscription is in the most permissive sense prior to those outliers being created. Casey has already made a very good move in this direction with #2461. By indexing anything resembling the most lenient possible interpretation of an envelope we can be certain that this includes all future variants of said envelope.

[stet]

I think in the not too distant future, envelope changes will stop and freeze.
The exception to this might be an eventual shift to using Witness Annex field to simplify the tx in future.
If so, this would be known way in advance and can be coordinated with the ecosystem of indexers etc.

The point of getting to Ord V1 is to solidify the envelope and have clear understanding of what are "blessed" inscriptions.
The phase of tweaking will be behind us, maybe with a few exceptions. Again, if communication is good, these rare occasions can be dealt with without pain.

The topic of inscription number has sort of bled into more broadly the envelope construct, which is the root of this.

[CryptoMikex]

"Unstable" is not really a state I'd like to see on the blockchain. It's not something You could rely on. but for people who are afraid about the numbers going to hell...
There is enough data on-chain to track the order of inscriptions. If the market wants it, market makers will deliver. I just think we should hold the existing order and propose a change after a given future block.

I bet it could be easily done on the consensus layer, so the protocol could get rid of the inscription numbers altogether.
The indexers could check if the inscription follows the previous standard & was inscribed before block "x". If yes - index it as a standard inscription. If the inscription is "cursed" & was inscribed before block "x" - index it as a negative, cursed inscription.
Then, each inscription after block "x" would be counted as a standard (so blessed) inscription.

But that could just be consensus. If we ever as a group decide to do that differently, we can work on the agreement.

[dannydeezy]

Ok hear me out...
What if we stuck with the negative number concept (original cursed plan)
Except instead of making them all "blessed" at a future block height, we instead make everything after that block height negative
So after that cutoff there will be no more new positive numbered inscriptions, and all new inscriptions will have larger negative numbers

Preserves integrity of existing inscription numbers
And gracefully introduces the concept that all new inscription numbers are unstable

[brandonmarshall-tm]

I literally posted this as a joke today, but there is an actual good idea buried in there 😂

[dannydeezy]

hahaha excellent

[Psifour]

Please stop joking, this is how we got cursed inscriptions the first time around. 💢

Kidding aside, I don't really like this idea as I think that the negative numbers were sub-optimal to begin with. Users without that precondition may come to a different conclusion though.

[BennyTheDev]

Here is a proposal in regards to exposing a "strict" label.

https://twitter.com/trac_btc/status/1704590325908488624

[Psifour]

This honestly deserves a bit more attention as the idea has potential, but needs a bit more to rise to the top. I'm not ready to comment on it in long-form, but a short revision would look something like We need to define every version of indexing that has existed, assign them enum values, and surface an array of versions that an inscription would have been valid in for each inscription. This doesn't need to be built directly into ord.

This is a very preliminary opinion, but may end up being representative of my final opinion on Trac's suggestion.

[rocktoshi]

What do you think?

#idea for numbers

Block Height

Perhaps ord could use block height + a sub-block identifier for each inscription.

For elegance, we could ignore all blocks prior to the genesis inscription and refer to the first block with an inscription as 0.

The genesis inscription would be referenced:

0-1 or 0-0

A later inscription, being the 3rd inscription in block 27, would be:

27-3

[sanjfomojis]

I definitely agree some sort of snapshot and then an elegant solution that relies purely on onchain data should be implemented going forward.

It's important we remove any areas that rely on off chain guidelines so we don't have this debate again in the future. No one can debate timestamps, so a numbering system based on chronological order inscribed seems important.

Would it be difficult to have both displayed on explorers? But the new numbering system used in the code base.

Eg. All the current numbers remain the same, and we can look at them as "Legacy Numbers" almost like relics.

"Relic: Implies that the technology or system is a remnant from the past, often with historical significance"

But the new system of numbering is what is the true number that verifiably shows what occurred according to the blockchain, which can never be disputed.

[Psifour]

Ordering should 100% be based on block height and index within that block. As for how users may wish for that to be exposed it could simply be that the numbering is ordered based on that on-chain ordering OR a whole new format could be derived like you have presented.

I personally feel names like '27-3' lack a certain narrative appeal and would honestly lean on someone like Erin to see if there is a way to structure this that makes good mathematical/organizational sense while also having strong narrative value.

[sanjfomojis]

I feel like there are strong cases for both sides of the argument, and @huuep proposal seems like a good compromise.

On one side, the change is definitely beneficial for the protocol long-term tech wise

But are the cultural impacts associated with changing history (or what a significant amount of people believed was the correct history) worth risking.

I definitely agree some sort of snapshot and then an elegant solution that relies purely on onchain data should be implemented going forward.

It's important we remove any areas that rely on off chain guidelines so we don't have this debate again in the future. No one can debate timestamps, so a numbering system based on chronological order inscribed seems important.

Would it be difficult to have both displayed on explorers? But the new numbering system used in the code base.

Eg. All the current numbers remain the same, and we can look at them as "Legacy Numbers" almost like relics.

"Relic: Implies that the technology or system is a remnant from the past, often with historical significance"

But the new system of numbering is what is the true number that verifiably shows what occurred according to the blockchain, which can never be disputed.

Last point is that I feel it's important to try and define as clearly as possible the true definition of "What is an inscription?" and try to identify as many edge cases we can now before implementing any changes.

Last thing we want is something like this coming up again in six months time.

[Psifour]

It is important to note, we do NOT want to use timestamps. Doing so will have undesirable outcomes. Block height and index of the transaction within that block is how we measure time in Bitcoin.

Specifically, while there are some rules to keep timestamps within a reasonable limit, they are very flexible and allow a fair bit of manipulation before you would run into consensus issues.

[cypherpork]

Renumbering = hard fork

Projects that existentially depend on the immutability of the inscription numbers will have no choice but to hard fork.

I know, I know. BRC-20 is the first to come to mind, which is not the best example to bring up to win friends and influence people, but.

They will hard-fork, and that will cause others to follow, inevitably weakening the ord protocol. It's a defining factor, IMHO - we should avoid renumbering.

Instead, let's embrace the "cursed" inscriptions by stabilizing their negative numbers and recognizing their seniority via alternate means (proposal underway).

[Psifour]

I thought this as well for a few minutes, but the more I thought about it the more I realized that even if we consider this a 'hard fork' it is only a negative if we believe that all online indexers should be expected to maintain parity on inscription numbers (and/or which inscriptions they index). If we drop that requirement than a 'forked' indexer is actually just an application-specific indexer, which many engineers would likely argue is optimal (I have even pushed for them to use an alternative envelope in the past).

If they don't fork, that is a win as it means we keep the majority of mindshare on the limited number of existing active indexing solutions.
If they do fork, that is a win as it means there is a greater chance of them addressing the underlying flaws in the current implementation of BRC-20.

Example: If an explorer was created that wished to focus only on visual art, it would be reasonable for them to drop non-visual formats from their index to better optimize content delivery. Optimizing to make that easier is a good goal, attempting to avoid that at the cost of tech debt is probably not.

[cypherpork]

@Psifour, I like the argument you brought up. IMHO, it is flawless from a systems engineering standpoint. Here's another way to put it: inscription's sequential numbers are not part of ord's specification. These numbers can be deduced from the Bitcoin chain if they need to be chronological. Or they could be random. The difference will have zero effect on the work of the ord protocol or any application built to the letter of the "ord proper." From that standpoint, whether there is renumbering or not does not matter. There will be no fork.

What worries me is hard forks that will start forming in people's heads.

ord wallet and ord explorer are currently considered a bitcoind of the ord world: the reference implementation. As we observed so far, users and devs believe in it; they are willing to forgive a lot of imperfections for the luxury of having such a standard.

If we renumber, a very sizeable group of users will have no choice but to abandon that luxury for the sake of survival of their projects. I am not finding an angle from which such events unfolding after renumbering would look good for the stability of the ord protocol.

[ACken2]

I have a quick question: Why can't we simply consider the 'ord' indexer as the reference implementation?

If the latest version of 'ord' indexer (at the time of a block) did not recognize certain edge case, then it would never be recognized - the 'ord' indexer itself acts as the reference which determines whether it is valid or not.

When there is a new update that supports some edge case that is previously not supported, these edge cases can be supported starting from certain activation block height.

Then we would not have this discussion about changing the history. What am I missing?

[stet]

indexers are inferior to the timechain.

[roadbuilder]

The initial cursed inscriptions totalled over 80,000 but this new set of curses added like 5, AND they screwed up the regular numbers as well (the un-cursed) at least those in 0.6.2 no longer match the regular numbers for 0.8.3 .. the first one I see this happening is
https://ordinals.com/inscription/207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0
On version 0.6.2 this was #12649108 .. now it is cursed at #-55791 (negative) .. there are 4 more like this... well wait, no now that same cursed # is even different, now it is -76292 (unstable)... I guess this is version 0.9.0 now.

They should have just left the protocol as it was, if people's got screwed up, so be it, because having to keep updating code for people that couldn't follow the spec or at least verify how most people were inscribing, is costing everyone time and money. At the end of the day, the protocol is just all made up non-sense anyway.. just pick some non-sense and stick to it, don't have us make a career out of it.

If you want to keep adding new features to the protocol, it is TOO LATE. That's called a FORK. Same thing with the horrible BRC-20 standard that everyone went with built on top of this.. it is garbage, he has a warning right on there, "don't use this for anything" .. but no... mess on top of mess on top of mess:

If you aren't going to have stable inscription numbers then there is no reason to use numbers at all; this goes beyond numbers though because if you keep including new types of inscriptions and they affect BRC-20s, this is a far worse problem... this is where the big money is right now.. with images it doesn't matter so much, an image will always be at the same inscription id.. but BRC-20 state engines will quickly diverge if they aren't considering the same inscriptions as valid.

[DanM3rcurius]

In my mind it's failry easy. Do I want vanity numbers for flexing or do I want a robust protocol that is aligned with cypherpunk values and can offer yet still unimaginable applications while scaling organically. Do I really want to trade: Multiple inscriptions per transaction, Inscriptions in reveal inputs other than the first, Inscriptions with new even fields, Multiple inscriptions on the same sat; for a vanity flex?
I don't.
This is not about money locked in BRC20. This is about the future of YOUR (data) sovereignity.

Destabilize#2StabilizeYOU