-
Notifications
You must be signed in to change notification settings - Fork 61
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
feat: support cursed inscriptions #85
Conversation
Vercel deployment URL: https://ordinals-ghr0hog7v-blockstack.vercel.app 🚀 |
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.
In the deployed version, the inscriptions data are nested in a cursed_inscription_reveal
field (vs inscription_reveal
).
This is something we could change in future versions, but I think it was a good choice. cursed
inscriptions are a bit polarizing, and the ingestion rules are different: you should always wipe cursed inscriptions when ingesting blessed inscription is an idempotent operation.
By keeping the cursed_inscription_reveal
schema, developers have to "opt-in" (with an explicit code path) if they want to support cursed
inscription.
If we mix everything under inscription_reveal
, developers are receiving cursed
data by default, and have to "opt-out" by explicitly testing the inscription number if they don't want to support "cursed" inscriptions.
Note that there's also a new field available that you should probably keep: curse_type
, which will tell you why the inscription is cursed (even tag, batch, p2wsh as we speak).
@lgalabru a few questions
Does a
Can you expand a bit on this? When should I wipe cursed inscriptions?
Gotcha, should I return this data on cursed inscription responses too? |
Yep
We can leave this for a future iteration, we're resetting blessed and cursed inscriptions pretty regularly. At some point, we will be adding new curse types, and I think we will keep the blessed inscriptions (to avoid re-ingesting 10M inscriptions), and only reset the cursed inscriptions.
That'd be great for the explorer I think. |
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.
Looking great, thanks @rafaelcr!
## [0.3.0](v0.2.0...v0.3.0) (2023-06-08) ### Features * support cursed inscriptions ([#85](#85)) ([fb93474](fb93474))
🎉 This PR is included in version 0.3.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
## [0.3.0](hirosystems/ordinals-api@v0.2.0...v0.3.0) (2023-06-08) ### Features * support cursed inscriptions ([#85](hirosystems/ordinals-api#85)) ([fb93474](hirosystems/ordinals-api@fb93474))
prev_output
andprev_offset
in the locations table so we can calculate gaps/sats/:ordinal/inscriptions
endpoint to list all cursed inscriptions for a single satcursed_inscription_revealed
curse_type
on all endpoints