Apr 18, 2024

Tracked down and fixed another bug in confirmation today. There is a case in the tail end of block download where duplicate blocks can become stored. This is allowed, but I'll be cleaning that up at some point. However the condition resulted in an unexpected confirmation failure due to tx_->block reverse navigation link (based on confirmation) not being present on the duplicated blocks. The first instances got confirmed, resulting in the second instances being the first found on natural key search and therefore not showing confirmed. This search is part of spend verification, where spends are associated from inputs to outputs via the input point tx hash. I resolved this by enumerating all instances stored against the hash (almost always one), which ensures the confirmation will be found if set.