Bug in inscription number assignment - bvm.network jpegs are messing with the inscription numbers

[lgalabru]

Checking the data, there might a regression in ord.
Zooming on 824535, the last transaction in this block is 972765a3769073c8f4159a13588af2d9027715935279c95444c33efc48fcacdd, so it should have the highest inscription number of the block. Instead, it's getting the inscription number 53391473, and instead, this transaction
4a6c1853f75272076d349f88aec50c54057c51d899850da1852e1b1efbf6b6f7
is getting a highest number 53391474.

@casey @raphjaph any hint?

[lgalabru]

https://ordinals.hiro.so/inscription/972765a3769073c8f4159a13588af2d9027715935279c95444c33efc48fcacddi0 is correctly (?) is reporting 53391474

[samedcildir]

Second transaction is sending the inscription as fee to miner (since its output value is 0). Ordinal theory creates implicit inputs for fees to the coinbase transaction. A quote from Ordinals BIP:

For the purposes of the assignment algorithm, the coinbase transaction is considered to have an implicit input equal in size to the subsidy, followed by an input for every fee-paying transaction in the block, in the order that those transactions appear in the block.

Also, coinbase transaction is calculated at the end of the block. So according to sat movement rules, the inscriptions that are sent as fee on creation should be numbered the last.

[lgalabru]

For the purposes of the assignment algorithm, the coinbase transaction is considered to have an implicit input equal in size to the subsidy, followed by an input for every fee-paying transaction in the block, in the order that those transactions appear in the block.

So according to sat movement rules, the inscriptions that are sent as fee on creation should be numbered the last.

Your comment is not a logic follow-up on the spec you are quoting.

in the order that those transactions appear in the block

This is the important part, and per the spec that you're quoting, the numbering here is flawed.
This issue is a bug in the patch that was supposed to fix this bug #2062.

Introducing unbound transactions was kind of making sense in the context of #2062, because a sat was inscribed without being owned by its inscriber.
In this case, things are looking perfectly fine, satoshis are provided in an input, the first one is being inscribed, respecting the protocol, and is being spent in fees.

Generally speaking it would be great if we could stop considering the bugs present in ord as incredible unique features multiplying the values of inscriptions (read: curses, charms, etc), or try to read between the lines of the specification to see what we want to see.

Instead, let's stick to the specification, fix the bugs, and re-compute the inscription number sequence per the specification.
The "Jubilee" has been quite painful and it would not have been a thing if bugs (read: cursed, charms, etc) had been addressed one after the other.

[samedcildir]

in the order that those transactions appear in the block

This only applies to the fee inputs, first fee is added to coinbase as second input, second fee is added as third etc. but all of these inputs come after all other transactions in the block. So actually, the code works correctly according to BIP specs.

Normally I would agree about fixing the bugs and also issue 2062 was definitely a bug and it has been fixed almost immediately. But in this case in my opinion the code works perfectly fine according to Ordinals BIP, so either Ordinals BIP has a bug, or everything is running correctly.

Also, this is not specific to 0.14.0, ord is handing fees like this since the beginning (you can check the code for version 0.5.0 which was waaay before issue 2062 and it also handles fee inscriptions the exact same way), and there are a few other cases of this that happened before.

[lgalabru]

@samedcildir I think you are twisting the spec to see the outcome that you're desiring, ie what the code is doing today. Admitting the presence of a bug at this scale is not an easy thing, but let's try again.
Let's consider the following block:

Tx0 - Coinbase
- virtual input 0 (subsidy) 
- virtual input 1 (fee)

Tx1
- Sat 0 from Input #0 being inscribed, Going to Output #0

Tx2
- Sat 0 from Input #0 being inscribed, Spent in fees

Tx3
- Sat 0 Input #0, spending Output #0, is being re-inscribed, is Spent in fees  

The transactions and more precisely the inputs are responsible for inscribing the satoshis, not their destination.
This problem is not different from transaction chaining, so if you really believe that this is not a bug / side effect of an inadequate design, why is not also implemented for transaction chaining?
Let's say you're chaining some transactions in the same block (case of Tx1 + Tx3), the inscriptions should get their inscription number in the order of transaction, so Tx0 (can not inscribe by nature), Tx1, Tx2, Tx3.
If we are following the logic that you're trying to sell in a consistent fashion, then we would end up with Tx0, Tx2, Tx1, Tx3 - which does not make sense.

My frustration is coming from the fact that I created and I am maintaining an alternative indexer (powering https://ordinals.hiro.so) and simulating these bugs is 1) quite challenging and 2) dishonest from a protocol point of view.
By stipulating that this behavior is working per the specs seems quite a stretch, otherwise transaction chaining should follow the same pattern.

[lgalabru]

@samedcildir Also, the spec that you are quoting is not the inscription number assignment, it's the ordinals number assignment, which are 2 different things.

https://github.com/casey/ord/blob/master/bip.mediawiki#design

[casey]

Thanks for the bug report! We're checking this out.

[casey]

I just finished indexing with #3031, which numbers fee-spent inscriptions correctly. However, it would lead to around seven million inscriptions being renumbered, so I think we've just got to live with this. Unfortunate, since it's definitely a bug, but so it goes!

[lgalabru]

Thank you for taking the time to look into this @casey!
I understand that re-indexing is annoying, Hiro's indexer went through this a bunch of times already. If this bug is not fixed in ord, we will have to re-create this bug in our indexer (along with folks running gord, and so on). Re-indexing on Hiro's end will impact more end users simply because most of the web wallets out there are using our APIs, and there are more users using web wallets than users running ord - I don't have any numbers, but intuitively I would say multiple orders of magnitude.

If this bug is indeed becoming part of the spec, a definitive guide in the documentation on how inscription numbers are being attributed would be very appreciated.
Thanks!

[casey]

Yah, it definitely sucks that we can't fix this. We'll definitely document this, I have a PR open that adds a test for the current behavior, #3032, and I'll add documentation in the same PR.

[cbspears]

Thank you for taking the time to look into this @casey! I understand that re-indexing is annoying, Hiro's indexer went through this a bunch of times already. If this bug is not fixed in ord, we will have to re-create this bug in our indexer (along with folks running gord, and so on). Re-indexing on Hiro's end will impact more end users simply because most of the web wallets out there are using our APIs, and there are more users using web wallets than users running ord - I don't have any numbers, but intuitively I would say multiple orders of magnitude.

ty for the reference -- we are not spending the developer resources to try to maintain gord numbering parity with ord for the time being or until it appears ord reaches a relatively stable, documented state.