Assertion failed: (false), function forced_return, — macOS when syncing from genesis / multiple watch-only addresses

[seanPhill]

On a wallet (running the current master — the second commit to master on 20260809) where I added several watch-only addresses (for testing) and then did a full blockchain sync, after having previously done a resync when adding a single watch-only address, it succeeded, BUT had crashed some hours after having begun the resync.

% ./veil-qt 
Assertion failed: (false), function forced_return, file /home/runner/work/veil/veil/source/depends/x86_64-apple-darwin18/share/../include/boost/variant/detail/forced_return.hpp, line 45.
zsh: abort      ./veil-qt

I started up the wallet again, and it started and then automatically shutdown safely.

I started it a second time, and everything was fine, and the watch-only addresses were up to date.

---

My only concern is that I have some mislabelled transactions, but that involves addresses that I had originally mislabelled and then corrected. Clicking on the transaction shows the correct address, not matching the incorrect label. Most, if not all other listed transactions are correctly labelled.

I will soon test the watch-only address deletion process.

The wallet is working reliably under normal conditions and the crash may have had nothing to do with the wallet itself, as it may have been power fluctuations or something else. However, I am running from a surge protected UPS, but the chain data is on a fast external USB SSD directly connected to an M4 Mac Mini.

[seanPhill]

There are some existing issues with the GUI transactions list, particularly that when resyncing to gather historical transactions the dates are incorrectly set to when they were detected instead of when they actually took place!
Sometimes this can look suspicious, such as when you see large transactions on a budget address on a date when no budget transaction should have taken place. Then when clicking through the transaction you see it was a correct transaction from years ago. Also, as per #988 a transaction can be wrongly described as basecoin mined, for example, when it's a budget multisig address receiving a Superblock, possibly when mined by another watch-only address. ¯\(ツ)/¯ This is fairly niche stuff (edge cases), of course, and possibly contributed to the thought that a label was wrongly attributed in the GUI transactions list, because maybe two of the watch addresses were involved with the same transaction.

I've written up the GUI transactions list issue in #1074

[seanPhill]

Users experiencing a crash like this should simply restart, and if it then shuts down without crash, just open it up again and then it should be fine.