-
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
Internal Server Error for ordinal inscriptions that were spent as miner fees #1841
Comments
Observed this as well. The issue is that in Attached is a complete list of the 126 |
Two of these satoshis were mine before I accidentally spent them as miner fee. Now they give an "Internal server error" |
@casey now thinks ALL of them may have been spent as fees. Will follow that route later. |
@casey seems to be right. This is inscriptions being sent to the coinbase. We do not decode this correctly. Encoding is this in
|
Cool, so you no longer suspect this is a redb bug? |
@cberner Yep, no redb issue. |
Just commenting here so I can follow along and know when this has been fixed so I can reindex. :) |
It is worth noting that lots of inscriptions have been spent as fees and tracked successfully. All of the following, for example:
That is a full list of the sub 2k inscriptions that have been spent as fees as of the time of writing. #379 is spent as fees on its first hop, on purpose. |
In case it's not clear the issue is that when an inscription is spent as fees only the part that is actually fee contributes to the offset in the coinbase. The code was ignoring the size of the outputs of the tx that spends the inscription as fees, so the locations of all inscriptions that have ever been spent as fees are wrong. |
Casey's initial take was he wanted to set the location like we do on purpose, but what's missing is a small piece of logic when decoding inscriptions to catch this. I haven't looked into this deeply yet, if anyone has a proposal for a sound way to fix this issue that could save some time. |
Are you sure? The code as it stands is setting the incorrect offset into the coinbase. I can't see any reason he would do that on purpose. My PR fixes it.
Can you explain what is unsound about allocating the input sats to the outputs before allocating them to the fees? That's what my PR does. |
I'll try to explain the problem with the simplest mainnet example I could find. Take a look at inscription 48ad1f64a9e8332b48f88948b681a886028257bbc6c91dfbe3ac130d6552ea4fi0 Here's its reveal tx: https://mempool.space/tx/48ad1f64a9e8332b48f88948b681a886028257bbc6c91dfbe3ac130d6552ea4f It gets sent here: https://mempool.space/tx/1cd1332d5c6d7793e46ec2feccd071ae72a3a83869eccc5dc212df06ba8a1211#vin=0 Then it gets spent as a fee, here: https://mempool.space/tx/039339db679633db7e6b61f488bb33f75dd5e71a56f119e93874b44d59fd52d5#vin=1 The tx that spends it as a fee has one input of 500000 sats before the inscription in the inputs, and only has 493703 sats in the outputs so the inscription becomes part of the fee. The output is 6297 sats smaller than the input that comes before the inscription, so the inscription is at offset 6297 in the fee from this tx. To calculate the offset of the inscription in the coinbase of the block we need to sum:
That gives an offset in the coinbase of 625000000 + 300984 + 6297 = 625307281 However. What ord does is sums:
That gives an offset in the coinbase of 625000000 + 300984 + 500000 = 625800984 That is exactly 625800984 - 625307281 = 493703 sats too high, which is because ord didn't subtract the output values from the input values to get the offset into the fee. The fix is to subtract the output values from the offset. Please point out any errors in this reasoning, or any other cause for thinking my fix is incorrect. |
Here's a without-sats index created using the fixed code, up to block 782500 if that helps. |
Thanks, @gmart7t2 - this sounds very clear. Agree that your approach sounds right. Will take a look at the PR tomorrow. Thanks! |
Here's an exhaustive list of what I have scraped over mainnet (so far), a list of tuples of inscription number and inscription ID. Hope it helps.
|
That's almost exactly the same as my list except it's missing #41259 and #55588. Also that is just a list of the inscriptions whose locations are so wrong they are off the end of the block reward. There are another 946 inscriptions that are still viewable on the explorer but which have their location shown incorrectly. I won't list them here, but for example: Inscription #504856, |
https://github.com/casey/ord/blob/master/src/index/updater/inscription_updater.rs there is a bug in code line 181. flotsam.offset is absolute offset in transaction. but the offset we need should be offset in fee. So this code line may should change to old code: new code: I will submit a pull request to fix this later |
Is this issue related to the bug that @casey wrote about in https://github.com/casey/ord/issues/1455#issuecomment-1435049264 or is that a different bug? |
No. That is about a different bug: #1455 is about ord failing to detect the creation of some old inscriptions This issue is about ord failing to accurately track the location of existing inscriptions when they are sent as fees |
Thanks for the insight, maybe you could provide some info in https://github.com/casey/ord/issues/1455 since @casey prioritized it to be fixed but there doesn't seem to be any details or an inscription list ❤️ |
All I know is what @casey tweeted: "There was a bug that hid some inscriptions around 500-600". I don't know if the bug was ever reported anywhere or ever fixed. If I had to guess I would say the bug was in the code that created those inscriptions rather than in the indexing code. But I don't have to guess. So I won't. |
And here's a with-sats index created using the fixed code, up to block 782500 too. |
Some of the URLs on
/inscription
endpoint are throwingInternal server error
, even though the inscriptions are visible on the/tx
endpointFor example:
or
The text was updated successfully, but these errors were encountered: