Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Inscription Equality #16

Open
tyjvazum opened this issue May 26, 2023 · 16 comments
Open

Feature: Inscription Equality #16

tyjvazum opened this issue May 26, 2023 · 16 comments
Labels
enhancement New feature or request

Comments

@tyjvazum
Copy link
Owner

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

@tyjvazum tyjvazum added the enhancement New feature or request label May 26, 2023
@dannydeezy
Copy link

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
Copy link
Owner Author

tyjvazum commented May 26, 2023

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
Copy link

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
Copy link

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
Copy link
Owner Author

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
Copy link

0attack commented May 27, 2023

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
Copy link
Owner Author

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
Copy link

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

@dannydeezy
Copy link

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
Copy link
Owner Author

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
Copy link

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

@BatBushRacks
Copy link

@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
Copy link

jotapea commented Jun 4, 2023

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

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

@tyjvazum
Copy link
Owner Author

tyjvazum commented Jun 5, 2023

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
Copy link

jotapea commented Jun 5, 2023

@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
Copy link
Owner Author

tyjvazum commented Jun 5, 2023

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants