Apr 12, 2024

malleable64 does not imply the block is invalid, and we may not know that until we hit the validation or confirmation stages, which are after the block is stored. So we need a very efficient query to determine if a stored block is malleable64. So this is now implemented and tested in the store. I added a flag to the txs association, which is an independent table from blocks and txs. This allows a query to determine if the block requires validation and confirmation despite having been checkpointed, and also indicates that the block should not be marked as invalid if either of these stages fail (because a valid block with the same hash is presumed to exist). The query is extremely efficient as the data is already paged into RAM wherever it would be called. And it required no storage expansion as it was able to fit within an existing byte used for the block.txs.count field.