Feature: Inscription Equality

[tyjvazum]

All inscriptions should be treated as valid inscriptions and be transferable. This is the choice most in line with the culture and ethos of Bitcoin. Tag-based protocol upgrades are not impacted at all, since a mechanism like activation height would need to be adopted to reliably perform such upgrades anyway.

Related work: https://github.com/casey/ord/issues/2045, https://github.com/casey/ord/pull/2109, https://github.com/casey/ord/discussions/2113

[dannydeezy]

one consideration is to be weary of future upgrades that may use even tags to assign the inscription to a different sat offset of the outputs

[tyjvazum]

Yes, I saw that claim already. Not to be dismissive in any way whatsoever, but it's unrelated to the discussion from a technical perspective. A mechanism like activation height should be used to do those upgrades, and it's also trivial to solve it in a stronger way, for example, with a JSON string being the data that's attached to the tag.

If someone raises legitimate concerns, I'll consider them, but I think treating all inscriptions as valid is the best choice. Users will be able to choose what they want for themselves out of all available options. That's what decentralization is all about 🙂

[drahlraigon]

Yes, I saw that claim already. Not to be dismissive in any way whatsoever, but it's unrelated to the discussion from a technical perspective. A mechanism like activation height should be used to do those upgrades, and it's also trivial to solve it in a stronger way, for example, with a JSON string being the data that's attached to the tag.

If someone raises legitimate concerns, I'll consider them, but I think treating all inscriptions as valid is the best choice. Users will be able to choose what they want for themselves out of all available options. That's what decentralization is all about 🙂

All for decentralisation and equality!

[dannydeezy]

Yes, I saw that claim already. Not to be dismissive in any way whatsoever, but it's unrelated to the discussion from a technical perspective. A mechanism like activation height should be used to do those upgrades, and it's also trivial to solve it in a stronger way, for example, with a JSON string being the data that's attached to the tag.

If someone raises legitimate concerns, I'll consider them, but I think treating all inscriptions as valid is the best choice. Users will be able to choose what they want for themselves out of all available options. That's what decentralization is all about 🙂

isn't the one issue with relying solely on block height is that older clients who don't upgrade may be incorrectly tracking the location of an inscription?

but by having unrecognized even tags default to unbound, then at least older clients will not be tracking location for these inscriptions at all, so they wont provide conflicting info about where the inscription is.

i think my suggestion here might be a nice compromise: https://github.com/casey/ord/pull/2109#issuecomment-1564786869

[tyjvazum]

isn't the one issue with relying solely on block height is that older clients who don't upgrade may be incorrectly tracking the location of an inscription?

but by having unrecognized even tags default to unbound, then at least older clients will not be tracking location for these inscriptions at all, so they wont provide conflicting info about where the inscription is.

i think my suggestion here might be a nice compromise: casey/ord#2109 (comment)

Yes, that's the issue, although I'm against doing breaking upgrades in general. It's equivalent to a hard fork in Bitcoin. I think things should be done in ways that preserve compatibility, similar to the concept of a soft fork, by using odd tags or other means.

Your suggestion is to treat some subset of the even tags like odd tags, but it's questionable as to what the optimal choice of which even tags to do that for is. Ideally, it would cover all of the existing unrecognized inscriptions. Have you done any analysis on this for your choice of division by 4?

I think it's a very reasonable compromise, assuming it covers all currently unrecognized inscriptions and all client implementations support it, otherwise, I consider making the unrecognized inscriptions transferable as more important.

[0attack]

couldn't some broadcast, maybe using inscriptions, be used so older clients get alerted when/if an upgrade that breaks stuff is done? more work to code but should fix the problem with older clients incorrectly tracking things they don't know...

[tyjvazum]

couldn't some broadcast, maybe using inscriptions, be used so older clients get alerted when/if an upgrade that breaks stuff is done? more work to code but should fix the problem with older clients incorrectly tracking things they don't know...

That's an interesting idea. It'd be some work to implement, but it shouldn't be too difficult. I recall reading that there was something similar in Bitcoin Core during the early days, if my memory serves me right.

Hopefully a solution closer to the suggestion from @dannydeezy can be agreed on, but your proposal would solve the minor issue of older clients being confused (assuming that such a future breaking upgrade actually occurs) 👍

[BatBushRacks]

@tyjvazum @dannydeezy as I said in my other message ordinals/ord#2109 (comment) this is very important to me... how will this work?

[dannydeezy]

Your suggestion is to treat some subset of the even tags like odd tags, but it's questionable as to what the optimal choice of which even tags to do that for is. Ideally, it would cover all of the existing unrecognized inscriptions. Have you done any analysis on this for your choice of division by 4?

even tags won't be the same as odd tags, because even tags are cursed, whereas odd tags are not cursed.

dividing by 4 because that would keep half the tags bound and half unbound, since there is uncertainty about the future it keeps everything flexible

[tyjvazum]

even tags won't be the same as odd tags, because even tags are cursed, whereas odd tags are not cursed.

Right, they would be cursed, which is just considering them to have negative inscription numbers. I didn't mention that because I was talking about bound or unbound. I'm in favor of the concept of negative inscription numbers, although inscription numbers seem to have a lot of problems in general.

dividing by 4 because that would keep half the tags bound and half unbound, since there is uncertainty about the future it keeps everything flexible

Your proposal seems like a perfect initial step, has a lot of community support behind it based on the emoji reactions, and serves as a compromise that can be offered and hopefully respected. Contributions are very welcome if you'd like to help implement it. I think it's the way to go 👍

[BatBushRacks]

@tyjvazum @dannydeezy and anyone else helping on this... thank you so much... slept like a baby last night... what relief

[BatBushRacks]

@tyjvazum @dannydeezy I hope progress is happening on this... as seen in the comments the other devs are avoiding any discourse on the problem... chances they do right by the community seem very low... ordinals/ord#2109 ordinals/ord#2149 ordinals/ord#2151 ordinals/ord#2145 ordinals/ord#2045

[jotapea]

All inscriptions should be treated as valid inscriptions and be transferable.

Even the ones that have no sat to assign it to?

[tyjvazum]

All inscriptions should be treated as valid inscriptions and be transferable.

Even the ones that have no sat to assign it to?

@jotapea, no, I think that's clearly a bug. What I mean is all inscriptions that were made in a typical way using the ord protocol identifier. I don't think it's appropriate to needlessly 'teach users a lesson' and that seems to be the general view, judging by the emoji reactions on that comment.

---

@tyjvazum @dannydeezy I hope progress is happening on this... as seen in the comments the other devs are avoiding any discourse on the problem... chances they do right by the community seem very low... ordinals/ord#2109 ordinals/ord#2149 ordinals/ord#2151 ordinals/ord#2145 ordinals/ord#2045

@BatBushRacks, yes, I've been working on it following the concept from @dannydeezy and the idea from @0attack, but I've also been working on other arb features like arb-companion, which I just put up a first version of.

---

@veryordinally, I see you gave the comments from @dannydeezy a thumbs up, does that mean you're interested in ordinals/ord#2109 (comment)? I don't see any reason not to do that, assuming the relaxed even tags won't be used for any protocol upgrades that break backward compatibility, which should be easy to agree to. I'll implement a solution in arb either way, but it'd be great to arrive at a cooperative outcome if possible.

[jotapea]

@tyjvazum Cool. I just think we need to properly differentiate between transferable tracked sats (ordinals) vs the ord data envelope (inscription).

(But I can also understand not specifying the caveat if less than 0.0...1% of inscriptions have no possible sat... but this doesn't matter if it messes up the numbering! What a mess deciding to keep inscription numbers final has gotten us all into!)

[tyjvazum]

@tyjvazum Cool. I just think we need to properly differentiate between transferable tracked sats (ordinals) vs the ord data envelope (inscription).

(But I can also understand not specifying the caveat if less than 0.0...1% of inscriptions have no possible sat... but this doesn't matter if it messes up the numbering! What a mess deciding to keep inscription numbers final has gotten us all into!)

I totally agree and there's some related documentation work taking place here: ordocs/oip#4