ordinally

> Confirmed reinscription with logging code from https://github.com/veryordinally/ord/tree/issue-2202 > > ``` > Jun 20 21:56:25 ordinals-dev ord[1249]: [2023-06-20T19:56:25Z INFO ord::index:: > updater::inscription_updater] unbound inscription 207322afdcca902cb36aeb674214dc > 5f80f9593f12c1de57830ad33adae46a0ai0 on offset 546...

Results from indexing: `207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0` is a reinscription of sat 655649449543261 (previously inscribed with https://ordinals.com/inscription/cdb4a37b187e6342483756eee63e15e324295f0342eda5efa3feb48534e95815i0

> So if every re-inscribed inscription is unbounded and cursed .Every re-inscribe will cause a re-index right ? > > Don't know if my understanding is correct > > And...

Indexing comparison file at http://ordinals.tel:8181/inscription_number_to_id-0.6.3-rc.tsv.gz

Interesting. Dug a little into how concurrency is being handled by Tokio and by the Rust standard library's thread::sleep function. When you use thread::sleep, you're pausing the entire operating system...

Haven't been able to reproduce this yet.

This will be addressed in https://github.com/ordinals/ord/issues/2256

> I don't really like the `/-/` path prefix, because it may be a pain to have duplicate routes everywhere. Also more importantly how would that work in practice? You...

> @raphjaph @veryordinally first off thank you for being open source devs... irregardless of no open discussion... any update on #2109... why is it being straight up disregarded? We're working...

Converting to draft until we resolve the performance issues.