ord
ord copied to clipboard
ordinals
Wallet re-inscribing sats
There was a report of a few inscriptions being made that weren't appearing on ordinals.com, or in the local index. This appears to be due to the fact that ord wallet inscribe was re-inscribing already inscribed UTXOs.
The wallet already has code to avoid inscribing already-inscribed UTXOs, so this indicates that there is a possible desync between the wallet and the index, e.g. the wallet knows about UTXOs that have inscriptions and haven't been indexed.
We don't know how this might be happening, but a good fix would be to proactively check before any wallet command that requires knowledge of inscriptions that all unspent UTXOs in the wallet are outputs of transactions that have been indexed.
We can check that UTXOs have been indexed by making sure they appear in the OUTPOINT_TO_VALUE table which, has an entry for every unspent output. We can put this check in get_unspent_outputs. This should be tested by creating an index, syncing it to a certain height, and then created inscriptions after that height. This check should be on the path of ord wallet send and ord wallet inscribe, but possibly also on the path of ord wallet inscriptions and ord wallet outputs, since if these don't show inscriptions it'll get confusing.
https://ordinals.com/inscription/b21ee1e6b643444c0c88943e175a007d689590e604991cf72c7f29cb472a304di0
uploaded an avif file which won't render
https://ordinals.com/inscription/b21ee1e6b643444c0c88943e175a007d689590e604991cf72c7f29cb472a304di0
uploaded an
aviffile which won't render
This is a separate issue, the inscriptions referred to in OP aren't being recognized by the index at all, i.e. when you go to https://ordinals.com/inscription/ID it shows an error. AVIFs are just a currently unsupported content type.
You can also always see the inscription when you click on content. https://ordinals.com/content/b21ee1e6b643444c0c88943e175a007d689590e604991cf72c7f29cb472a304di0
These are the six txids that dont show for me after getting mined - all of them are .png files. I am syncing up a local sat index to see if they show for me, but on ordinals.com, they dont appear
617b02026b7d56c85a41c07ebfd67a1186f0888fd07c59428f11b1b9cdf6a84c
156a787e50ef1b912830ca1f495fbb2032a159d477844aa84dd63f777bb4db33
3646828db8e2656ce7fe5e468a6cd34b71409ea286b499270e21b1b8e1a16608
de1c1bacf4311067ab547a658afe47dbaf361423e62695bff4d5eac2a4124c9e
414f69e1ce439fdf58dcd2edddcf06eaf26090b9f60a2ac3920d38a555e25cdd
f7ac52da8c1640239bf909d4058c06716457efd6744b15bb3ad44b966396f2a5
@hbeckeri Awesome, thanks for following up! We think we've figured out what's going on. The inscriptions were made on sats that already had inscriptions, and the protocol currently only supports a single inscription per sat. (Inscriptions after the first are just ignored.) The wallet shouldn't select UTXOs with inscriptions when making new inscriptions.
So something went wrong in this case, and the wallet selected an already inscribed UTXO when making the new inscription.
This should never happen, even if you're spamming ord wallet inscribe like crazy, so it's definitely a bug in ord, some kind of desync between the index and the wallet.
@casey Would a work around be to send all the sats to a new address each time i want to make an inscription?
getting errors when trying to send to a new address https://github.com/casey/ord/issues/1435
@hbeckeri I can't recommend that as a workaround, because we haven't figured out what the underlying issue is.
@hbeckeri Was just thinking about it, and I think the way to deal with it, and I'm not 100% sure of this, is to wait for inscriptions to appear in ord wallet inscriptions before making another. My working theory is that the wallet is making new inscriptions before seeing old ones, which causes sats to be reinscribed, so waiting for them to appear in ord wallet inscriptions will probably help.
@casey my wallet is showing an empty array , no items, for ord wallet inscriptions. I think this is because i havent indexed the whole chain yet. Perhaps this is the root of the problem
@hbeckeri Hmm, weird. That's really good to know. The wallet is supposed to wait until the index finishes before continuing, so it sounds like we're getting closer to the root issue. Is bitcoind also not fully synced by any chance?
@casey bitcoind is fully synced - i did control + c when ord::index::updater started syncing from block 1, and then it went and started letting me mint. Im now going to wait for a full sync overnight before inscribing more
Okay, got it. Still not sure what's going one, but one potential workaround is to make sure the index has seen every UTXO in the wallet before allowing inscribing.
Re-opening, since #1459 just makes ord throw an error, it doesn't identify or fix the underlying issue.
I'm going to go ahead and close this. We only have one report, and it's a very user visible error. Also we don't know if the client was modified, and if so, that could be the root issue.
@hbeckeri Awesome, thanks for following up! We think we've figured out what's going on. The inscriptions were made on sats that already had inscriptions, and the protocol currently only supports a single inscription per sat. (Inscriptions after the first are just ignored.) The wallet shouldn't select UTXOs with inscriptions when making new inscriptions.
So something went wrong in this case, and the wallet selected an already inscribed UTXO when making the new inscription.
Sorry to talk on a closed issue, but this seems like an interesting case to support?
For example, if I wanted to daisy chain inscriptions or burn-to-create. Not sure what the social consensus would be on what one calls inscriptions being done on an already inscribed sat, but it feels like having some power user support for this could be good?
If yes I can create an issue.
Yes, feel free to open an issue or GitHub Discussion and outline this idea!
Have just listened to @casey on Rug Radio Twitter Space and it sounds like this is what is being thought of for a good provenance solution. If there isn't already an issue that is tracking this then I will create one, but sounds like its already in the works?