ord
ord copied to clipboard
Support of inscription reveal through P2wsh
I see a few instances of recent transactions including what appears to be a valid inscription, not being accepted by ord
.
de7401dcef9c694b7326051263b8d5342dada9fdb0eb732e04022e324f6d9b36i0 being one of them.
Some more context.
Leonidas pointed this one out There were 3 weird inscriptions made last night that none of the other indexers count but that Hiro does. This is resulting in all inscription numbers after '10366012' being off in Hiro's Ordinals API. '10366013' which is de7401dcef9c694b7326051263b8d5342dada9fdb0eb732e04022e324f6d9b36i0 is not a valid inscription and along with the other two invalid inscriptions it should be removed and the numbers recalculated after 10366012. Also to prevent future weird inscriptions like this from being included BobBodily on twitter can share how he did them.
Mentioned twitter thread? https://twitter.com/BobBodily/status/1664304114782838786
Thanks @314159265359879 for helping me connecting the dots.
I think Hiro will unfortunately have to disable P2wsh inscription indexing until it is officially supported by ord
- in a backward compatible fashion.
This is one of the other inscriptions mentioned by Leonidas:
59dedca28c59e01aa394d002bf13ae2f0dd627353b27825264367aa87c444eaci0 https://ordinals.hiro.so/inscription/59dedca28c59e01aa394d002bf13ae2f0dd627353b27825264367aa87c444eaci0
They are checking with Bob for other... (edit) third one: 2ce4807dcd415026c4f199d92471345ec875baf82d47b4afc27422f95bcecf4di0
Thanks @314159265359879 ! We'll remove these entries from our current db and repair the sequence hopefully tomorrow.
We are in the process of building a new index with hord
, taking into account cursed inscriptions. I just added the P2wsh
curse, so we that we can retrieve these inscriptions in the negative inscription number sequence.
Sorry to break some indexers. I just really want support for P2WSH in ordinals indexers. I have a dev working on a PR to support them in Ord right now. Then we can see at what block height it makes sense to remove the P2WSH "curse".
@bodily11 ha ha np, it's a cool idea and we're happy to support. Our hord
deployment is working on producing a new index, if you could just give me a 3 to 4 days before sending your next batch of p2wsh
cursed inscription, that'd be very helpful 😅
@bodily11 can share if there are any more that got indexed but for now I believe it is:
de7401dcef9c694b7326051263b8d5342dada9fdb0eb732e04022e324f6d9b36i0
2ce4807dcd415026c4f199d92471345ec875baf82d47b4afc27422f95bcecf4di0
59dedca28c59e01aa394d002bf13ae2f0dd627353b27825264367aa87c444eaci0
ef3e77de7efa210ad1abf75bbed83a492ccb1bc772015ce655da1b1bffdb4c41i0
Sorry to break some indexers. I just really want support for P2WSH in ordinals indexers. I have a dev working on a PR to support them in Ord right now. Then we can see at what block height it makes sense to remove the P2WSH "curse".
@bodily11, I'm excited to see the PR. I'd be happy to support it in arb too.
What's the benefit of supporting inscriptions in P2WSH?
@casey see the PR and my response on the importance of supporting P2WSH here: https://github.com/ordinals/ord/pull/2192#issuecomment-1688659068
I don't want to be dismissive, but I need to start with the background that I don't believe that ICP is decentralized or useful. So, given that the only benefit of P2WSH is to enable interoperability with ICP, and given that this increases the complexity of the implementation on an ongoing basis, I'm not inclined to support this. If ICP wants the ability to inscribe, then ICP should look into supporting Schnorr signatures.
I don't think the only benefit of P2WSH inscriptions is to enable interoperability with ICP. There could be other cases where Taproot isn't implemented yet where it could be useful (though I don't have any to share right now).
And there are discussions right now within the ICP community on how we might implement threshold Schnorr, although protocol changes can take some time, so was hoping for better news from you here.
One additional note, while I agree ICP has some aspects of centralization (lots of work on progressive decentralization right now), I think you might be surprised at how decentralized and useful it actually is. Storage, compute, and hosting all packaged together with an incredible developer experience. Full stack DAOs (FE/BE, assets, business logic all on chain). Smart contracts with threshold signing that can make and receive http requests. A Bitcoin light node running entirely on chain on ICP.
There is a lot to love about ICP if you care about a decentralized world computer.
I don't want to be dismissive, but I need to start with the background that I don't believe that ICP is decentralized or useful. So, given that the only benefit of P2WSH is to enable interoperability with ICP, and given that this increases the complexity of the implementation on an ongoing basis, I'm not inclined to support this. If ICP wants the ability to inscribe, then ICP should look into supporting Schnorr signatures.
The Uses of IC include but are not limited to: https://mora.app/planet/av5oo-hqaaa-aaaan-qdcza-cai/03DWQYZB7NK3321AK7HQ9MTNNK The Control and Implement of decentralized Full Stack code is the core( for example NNS, SNS, CodeBase...) If public voting for a week, but in the end, the project team still deploys the malicious version of the code, even if it's not malicious, it's still making a mockery of everyone. You could say that half the world is made up of code now. If decentralized entities do not include control over code execution, then how would people, including governments, dare to let the blockchain industry apply deeply? Is the act of closing issues decentralized? @casey
Linear cost of infinite scalability. As blockchain becomes more and more closely integrated with real life, more and more people participate, and the demand grows larger and larger. The infrastructure cannot support infinite scalability, or if it is too expensive to expand, it is unacceptable.
AI on blockchainLlama2.c LLM running in a canister! ......