ord
ord copied to clipboard
ordinals
Inscription numbers off by one, or the curious case of transaction `c1e0db6368a43...d9e4117151`
Block 788200 is including a curious transaction
Inputs:
2814d0a3c9e6dd5b88911a6280fc3899391f5c47072eb11593af2838160fad2f:0 : 0 sats
Outputs:
bc1q6zpf4gefu4ckuud3pjch563nm7x27u4r5j4ua7 : 0 sats
No satoshi at play in this transaction. Yet, ord validated the inscription (3492721) attached to the input https://ordinals.com/tx/c1e0db6368a43f5589352ed44aa1ff9af33410e4a9fd9be0f6ac42d9e4117151
which sounds like a bug.
Philosophically, the satoshi inscribed was transferred to the miner as a transaction fee, but was nevertheless inscribed by its previous owner.
Even if the miner own this UTXO, this is not how they should be inscribing it, per the protocol (they should be inscribing the coinbase transaction).
As a consequence, all the satoshis inscribed after inscription 3492720 are off by one.
If this is intended behavior, it sounds like a violation of the spec (implicitly or explicitly): one should not be able to inscribe a sat that one does not own.
If this is unintended behavior, then this bug likely impacts all Ordinal tools, explorers and marketplaces out there.
A curious transaction indeed! I'm told this was found by supertestnet, so nice find by them!
It shouldn't be possible to inscribe sats that you don't own, so this is a bug. However, fixing the bug by making ord ignore this inscription would change inscription numbers after the curious transaction. I'm honestly not sure what to do!
Yeah, apparently supertestnet initiated this transaction. I discovered this issue the hard way and led my own investigation, my re-implementation of the ordinal protocol was stuck on this transaction, blocking our explorer. Fixing this issue sounds like a sound approach, this bug is a violation of what crypto stands for. Not your keys, not your sats, and no exception.
... fixing the bug by making ord ignore this inscription would change inscription numbers after the curious transaction. I'm honestly not sure what to do!
Might be a good issue/time for a precedent of preferring correctness over stable inscription numbers. Similar to as with ordinal theory if there was a bug in a counting implementation one would very likely favor correctness. But yes, hard choice to make -- very subjective 😬
So if I do this 545 more times will a bunch of brc20 tokens suddenly belong to the wrong people?
So if I do this 545 more times will a bunch of brc20 tokens suddenly belong to the wrong people?
God I hope so!
I got one case where it doesn't show up in the explorers but the ord wallet treats it as regular ordinal. not sure if related, but I cannot tell what number it got.
Philosophically, the satoshi inscribed was transferred to the miner as a transaction fee, but was nevertheless inscribed by its previous owner.
One thing that bears mentioning is, no fee was paid either, at least, on-chain. This is a PHANTOM SAT
I released a tool for increasing the off-by-one error: https://github.com/supertestnet/breaker-of-jpegs
Please follow the installation and usage instructions and let me know if it works for you
Similar to as with ordinal theory if there was a bug in a counting implementation one would very likely favor correctness.
There was, and we did.
Issue #1841 caused hundreds of inscriptions to be tracked incorrectly. It was fixed by #1971 which fixes the tracked location of those inscriptions.
The fix requires the index.redb file to be recreated, but the release notes didn't mention that fact so most people are probably still working with incorrect inscription locations, so I don't see why this would be any different. The indexer was incorrectly recognizing inscriptions that it shouldn't, and it needs fixing.
I would prefer if the release notes mention that a fix was applied and what the impact was if it makes a significant difference.
it seems this affects "inscription numbers".. does it also affect satoshi ordinal tracking (satoshi numbers) - note these are different things and i hope its just the former
if its just "inscription numbers" then good, i think inscription numbers should have died a long time ago. if all of ordinal tracking is affected, then my rare sat bizniss is ded!!!
I think the only off-by-one here is that an inscription in the index and associated with the wrong sat, so if that inscription shouldn't have been indexed (because there is no sat in the first output), then the inscription numbers after this one are off-by-one.
AFAIU, there shouldn't be any impact to ordinal tracking, only to inscription numbers after this one.
Bro, you have increased the UTXO set with a (likely) unspendable output:
$ bitcoin-cli gettxout c1e0db6368a43f5589352ed44aa1ff9af33410e4a9fd9be0f6ac42d9e4117151 0
{
"bestblock": "00000000000000000003df2c062bba629e2881e8c96ce604fcedc56b0f197370",
"confirmations": 97,
"value": 0.00000000,
"scriptPubKey": {
"asm": "0 d0829aa329e5716e71b10cb17a6a33df8caf72a3",
"desc": "addr(bc1q6zpf4gefu4ckuud3pjch563nm7x27u4r5j4ua7)#hpavz6rt",
"hex": "0014d0829aa329e5716e71b10cb17a6a33df8caf72a3",
"address": "bc1q6zpf4gefu4ckuud3pjch563nm7x27u4r5j4ua7",
"type": "witness_v0_keyhash"
},
"coinbase": false
}
i attempted to summarize the situation here, lmk if anything is wrong! https://twitter.com/dannydiekroeger/status/1654259984375615490?s=20
I'm honestly not sure what to do!
First I think we should test all possible edge cases, to see how the indexer currently treats it. example1: what if the tx had a 2nd output? would the indexer treat the first sat of the 2nd output, as the inscribed sat? example2: what if this transaction was the last one in a block? would the crash the indexer? would the indexer ascribe it to the first sat in the coinbase? or would it index it to the first sat in the next block?
If nothing too weird happens after testing all possible cases. For example indexer doesn't crash, or if it doesn't ascribe to the next blocks sats. ect.
Then we can update the specs to the exact logic the indexer uses, and its fine to continue.
One is not really inscribing to a sat they don't own, as this type of inscription (if we end up counting it as one), can only be done if a miner wants to include it. (its nonstandard and default mempool policy nodes dont relay this). So a miner is choosing to inscribe to their own sats.
TLDR: we need to test all possible cases, and its potentially a nothing burger just would need update the spec to its exact logic.
The fix is as simple as this:
diff --git a/src/index/updater/inscription_updater.rs b/src/index/updater/inscription_updater.rs
index 1c18c7f..6c6c4a6 100644
--- a/src/index/updater/inscription_updater.rs
+++ b/src/index/updater/inscription_updater.rs
@@ -108,7 +108,7 @@ impl<'a, 'db, 'tx> InscriptionUpdater<'a, 'db, 'tx> {
}
}
- if inscriptions.iter().all(|flotsam| flotsam.offset != 0)
+ if input_value != 0 && inscriptions.iter().all(|flotsam| flotsam.offset != 0)
&& Inscription::from_transaction(tx).is_some()
{
inscriptions.push(Flotsam {
That is, only recognize inscriptions if there is at least 1 input sat, because then there will be a sat to inscribe on.
I tested doing this trick in the last tx of a block and the inscription's location was set to 00000000:-1 as expected. It didn't crash the indexer.
I'm honestly not sure what to do!
@casey what about these becoming the "official" Vanilla inscriptions? I'm sure you can come up with a much cooler name though 😆.
And in all seriousness, I believe this can be tied to deprioritizing inscription numbers. Is still early!
