"when there is no utxo ... in the data"

But the data that inkan is trying to handle *does* have "utxo." There are two competing artifacts that each is cryptographically valid by itself:

1. A revocation declaration R signed by pubkey X saying "X revokes signing authority from Y"
2. A nostr event E signed by pubkey Y

The "unspent transaction output" is the output of the the delegation transaction that occurred earlier, i.e.:

utxo = the delegation of signing authority from X to Y

Now the revocation transaction R invalidates that delegation, i.e. it consumes / burns the utxo.

At the same time, the transaction consisting of the signing by Y of event E tries to draw on that utxo, i.e. it tries to draw on the delegation relationship to cause E to be attributed to X.

So both the revocation and the signing of the nostr event are trying to "spend" the same utxo, one by burning it and the other by drawing on it.

But this type of utxo can only be "drawn on" when it hasn't yet been "burned." So we need to know in which order these transactions occurred.

Classic double-spend.