Using commit_tx.confirmations to determine the validity of etching runes can lead to inconsistent judgments on the validity of runes during node operations

[alexha123123]

When deploying a rune, it is required that the commit tx and reveal tx for the same rune are separated by at least 6 blocks. Currently, the code logic checks the confirmations of the commit_tx using block.commit_tx.confirmations. Let's consider the scenarios for two nodes:

Node A: This node is continuously running. When it reaches block X, it executes the etching rune commit tx. Then, in block X+1, it performs the reveal tx. Since the two transactions are not separated by 6 blocks, the etching rune in this case is considered invalid.

Node B: Starting from block number 0, this node backtracks the data. When it reaches block X, it discovers the etching rune commit tx. In block X+1, it finds the reveal tx. Due to the time spent on backtracking, by the time it retrieves commit_tx.confirmations, it has already exceeded 6 blocks. Therefore, the etching rune is considered valid and appears in the list of runes.

The code in question is as follows:

https://github.com/ordinals/ord/blob/master/src/index/updater/rune_updater.rs#L399

let mature = tx_info
    .confirmations
    .map(|confirmations| confirmations >= Runestone::COMMIT_INTERVAL.into())
    .unwrap_or_default();

The suggestion is to compare the block numbers of the commit_tx and the reveal tx and check the difference to determine their separation.

[Psifour]

You are correct, if the intent is to seperate two transactions by COMMIT_INTERVAL number of blocks, we can use the blockheight of tx_info and tx (subtract the second from the first) and compare that to the COMMIT_INTERVAL.

[raphjaph]

Fixed in #3507