AssumeUtxo mocks the nTx value of headers after the last background block and before the snapshot header with nTx=1. This means that the getblockheader and getchaintxstats RPCs return the wrong nTx or txcount fields for those blocks.
Not sure if anything should be done about this?
The RPCs should probably be fixed to never return fake values.
It is pretty easy to tell when the nTx value is fake. You can just call IsValid(), and if it returns true, the nTx value is real, and if it returns false, the value is fake.
It is less straightforward to determine when the nChainTx is fake, but we could introduce a helper function to do that which could be used by these RPCs and also be useful for #29299. If nChainTx is greater than 0, and nSequenceId is not 0 or BLOCK_ASSUMED_VALID is not set or the block is the snapshot block, then nChainTx value is real. Otherwise the nChainTx is probably fake. This check could falsely indicate that real nChainTx values were fake in the interval between blocks being downloaded and fully validated, but this should not be a big deal.
In the long run it would be better to just not set fake values. According to a comment in PopulateAndValidateSnapshot these values are only faked so that GuessVerificationProgress works better. I don’t know if this is true, but if it is true, it seems like GuessVerificationProgress could just report progress based on block heights instead of transaction counts below the snapshot height, and we could get rid of the fake values, leaving nTx and nChainTx set to 0 when unknown and nonzero when known.
I don’t know if this is true, but if it is true, it seems like
GuessVerificationProgresscould just report progress based on block heights instead of transaction counts
If we can do that, we should get rid of nChainTx altogether. I think that its only other use is for HaveNumChainTxs which doesn’t use its value but checks whether it is 0. That would also save some memory and eliminate problems like #29258.
However, just using block heights would be very inaccurate because the first ~300k blocks are almost empty.
Maybe we could plot the nChainTx for each block, use non-linear regression to fit some mathematical function (e.g. some polynomial, possibly piecewise) to approximate it, and then use that and get rid of nChainTx?
If we can do that, we should get rid of nChainTx altogether.
Oh, I don’t think we should use block heights instead of real nChainTx values, because as you say using block heights would be very inaccurate. I’m just suggesting we could use block heights instead of fake nChainTx values, and we would not be worse off because currently the fake nChainTx values are set to block heights. Also probably it probably be good to estimate the number of transactions in BLOCK_ASSUMED_VALID blocks by interpolating between nChainTx in the snapshot block, and nChainTx in the last validated block, instead of assuming each block before the snapshot has 1 transaction.
It is pretty easy to tell when the
nTxvalue is fake. You can just callIsValid(), and if it returns true, thenTxvalue is real, and if it returns false, the value is fake.
I don’t think this is true. For example, it is possible that a block was downloaded and the nTx value was set, but the block later turned out to be invalid. Thus IsValid() will return false, but the nTx value is real.
I don’t think this is true. For example, it is possible that a block was downloaded and the
nTxvalue was set, but the block later turned out to be invalid. ThusIsValid()will return false, but thenTxvalue is real.
Good point. Maybe the practical consequences would not be too bad if it just causes nTx to be omitted from rpc results when in some cases it shouldn’t be. But this seems like another reason to want get rid of the fake assumeutxo nTx and nChainTx values, so we can simply treat 0 values as invalid, and nonzero values as valid.
EDIT: It also seems like BLOCK_VALID_TRANSACTIONS level is not removed if a block is marked invalid (a BLOCK_FAILED_VALID flag is added instead). So code could check level is >= BLOCK_VALID_TRANSACTIONS directly to see if nTx is valid.