ahhh, that's it. I wonder how that might change if the assumevalid milestone is ditched for the pure p2p-based algorithm that went into 24.0? i've not yet looked at any of it, but as things are, for sure this is a pitfall/footgun for Armory users migrating databases to different machines (users will often be shorter on disk space than planned during these types of task, and if the data requirements stopped growing then either Bitcoin died or if we're lucky, some ZKP scheme ate the blockchain finally)
I'm considering a scheme for blocks over P2P that could work with pruned nodes too. It's meant to work with full nodes but it "could" be used with pruned nodes too. The idea is to create a sort of reverse bloom filter of all addresses in the chain and hint block scanning from these hits. Would probably reduce the average wallet scan to ~1k blocks instead of some 800k. You'd be able to build this filter map from your own block data but you could also download it from somewhere else, and unlike block files, the data wouldn't vary. This was an idea originally emitted by Olaoluwa Osuntokun from Lightning Labs to build some sort UTXO map side data per block (a wet dream for lightning devs). It applies quite well to addresses.
In this mode, ArmoryDB could grab the few blocks it needs to scan over P2P, and a node could be bootstrapped by downloading the filter map. It could also scan any address relatively quickly, and work against any Core node. The drawbacks are that it would require more disk space (up to 5% of the chain I assume), and it would leak privacy to the Core node you're getting the blocks from (assuming you're lazy and didn't download the chain/are using a pruned node).
It doesn't fix the issue in Core however. Core tracks blocks by offset as well, mess with its blocks file and it will ask to re-verify the whole thing.
Quote
that sounds pretty neat, so you could lose the watch-only copy somehow, and still have wallet metadata backup coverage in the offline wallet. But it wouldn't work on my current system
You could also sustain that data some other way. The point is that it would be available to export and import.
Quote
just signing the encrypted data as part of the protocol seems like a ready solution?
To sign the data means you're carrying a private key. This is a fair assumption for signing a tx in a multisig setup, but not for sharing meta data across time for a simple online WO + offline signer.
Quote
and why would it matter, once someone else encrypts data using a public key of yours, what could they possibly do with that?
You can't assume if you generated the data or not in this setup, the only valid assumption is that you and whoever wrote the message know of its content. Encryption without authentication isn't useful all that often. This scheme needs some identification layer as well to work.
Quote
maybe even next release it will play video using the GPU over IOMMU
VFIO passthrough works pretty well with kvm over qemu, but CPU performance is pretty muted I find. For the most part, cache and RAM timings are quite eroded, I remember messing a lot with cgroups to recoupe some performance. It kinda turned me off the whole thing.
), but it was certainly not 0xFFFF (which is 4 bytes anyway, no?) regardless, the (scrubbed_but_valid_hexdata) bytes 1-4 were not 0xFFFF either
this effort was a part of getting my basic working machine ready to switch permanently, so hopefully I'll start trying out 0.97 again 