-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Refactor inscription parsing #2461
Conversation
I support this PR, however I do think this still requires a clear definition on what a "valid" ord envelope is. Because if it defined as |
I updated the the PR description to clarify that this still only recognizes envelopes in tapscripts. |
finally expressive open envelope! |
While this PR doesn't extend to alternate locations in transactions where the envelope can be stored, is it an indication that we intend to not allow those alternatives or simply a matter of the expedient solution first while still open to further refinements if developers are willing to commit to writing it up and getting the PR to you and Raph? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huge fan of this change! I am biased as it will allow us to rewind a lot of bad engineering we did with gord to maintain inscription number parity. The core of our logic is very similar to this optimized pipeline.
ACK
Are you think of envelopes in P2SH and P2WSH scripts? I'm personally not convinced that there's utility in recognizing envelopes in anything but tapscripts, in order to keep things simple. Storing envelopes in the signature annex is a desirable future extension, since that would allow inscribing with a single transaction, but that's a longer term change. |
While I personally share your views expressed on ICP as an unconvincing reason for recognizing P2WSH scripts, I do think there are probably reasons for utility in other parts of Bitcoin data, including P2WSH. A discussion should probably be had on whether an Inscription needs to have a utilitarian purpose to be recognized by ord, or if we simply allow as broad of a definition of a "valid envelope" as possible. I don't consider this topic super urgent (and it should have its own Discussion) as I think this PR and the sequence # PR should get through ASAP. But I do think the discussion on valid ord envelopes should happen because it could have important implications. |
We both are very aligned on annexes.. I really wanted to do this with our inscription tool, but couldn't get the sign off from Luxor (yet) to inject non-standard transactions to our pool. If we get that it will likely be a massive boon as I implemented inscription from scratch for us and skipping the commit would be better for financial and organizational reasons. As for alternative locations, I would say P2WSH is a pretty straight forward one (lower dust limit), but I could see opposition to it from both a protocol design AND Bitcoin ethos standpoint. A few novel ones exist as well, such as op_return with a minimal inscription envelope. I would agree with Charlie that NONE of these are worth holding this change up for, but would love to continue this as a discussion and/or even assist in implementation if we reach a point that we can agree on for them. |
Regarding inscription in the annex, if we do this, we should ideally come up with a different encoding, since using the script-based encoding in the annex doesn't make much sense, and is inefficient and overly complex compared to other possible encodings. We could either use a simple custom encoding which amounts to lists of byte strings, where each inscription is a list of bye strings, or something like CBOR. |
Is the 11-byte savings worth the added complexity of having a second indexing pipeline? Or do you more mean inclusion of some form of compression for the fields that currently rely on UTF-encoded plaintext? |
What happens if there is gibberish in the envelope that isn't clear about how to parse it? Do we still index it and maybe just display the unparsed data? |
Should the mime-type be optional when parsing too? Some executable files don't need a mime type and could get by with just a shebang. This is what I recommend in my "dapp" metaprotocol to inscribe dapp code. |
I think it's probably more than 11 bytes. But the idea of putting script in the annex is just sad. The alternate encoding could be something like CBOR, which is standard and widely implemented, but complicated. Or a simplified encoding of
I don't think so. I've been thinking of this recently, and I think compression of anything that |
Yah, it'll be indexed, but any gibberish is ignored.
The mime type is already optional, inscriptions can omit them. |
Sorry if this is not the right place to ask, but I'm trying to understand why unrecognized even fields are the only unbound inscriptions, while duplicate/incomplete fields are bound. Would appreciate any insights. |
like op_66? #2113 |
Makes sense 👍 #2109 (comment) provides some additional context as well. Curious to know if the recent discussion changes anything here, now that we might recognize/bind inscriptions with gibberish in the envelope. |
Even tags are intended to be used for fields which change how an inscription is first assigned to a sat, or how it subsequently transfers. For example, the proposed offset field #2383, specifies an offset to the sat the inscription is first assigned to. So, if you see an unrecognized even field, you can't make any assumptions about where the inscription is, so it's better to show it as unbound than at an erroneous location. |
@casey That makes sense. Thanks explaining 🙏 |
Just confirmed that this doesn't change any existing blessed inscriptions, and recognizes four additional cursed inscriptions. |
Any details of the four cursed? |
No blessed inscriptions have changed. I just checked out the four new cursed inscriptions, which are:
The first three have duplicate fields, the last has an incomplete field. (The envelope ends where the previous parser would be expecting a field value.) @Psifour Are there any other inscriptions you would expect the new envelope parser to find? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So much cleaner than before! Lesgo
This PR refactors inscription parsing by disentangling envelope recognition and inscription parsing.
Envelope recognition recognizes envelopes of the form
OP_FALSE OP_IF "ord" <data pushes> OP_ENDIF
in tapscripts. Inscription parsing converts envelopes into inscriptions.The goal is that all valid envelopes are recognized, and that all valid envelopes result in inscriptions. This can give us some confidence in the stability of inscription numbers, since previously, failures in the inscription parsing code would result in an inscription not being assigned an inscription number.
Changes in behavior: