Headers first, which are handled across multiple threads. Each valid header (where the PoW checks out) is queued to be written by whatever thread checked it, so blocks often end up out of order on disk past the last height milestone (process is single threaded up until then), which was around 420k? Core discontinued that milestone ever since, AFAIK.
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)
LMDB is a plain <key, value> store, unlike SQL databases it doesn't have a concept of tables and records, so it's preferable to split the keys via some prefix scheme. Therefor all keys end up with an extra prefix byte at the I/O layer.
ah, that's pretty simple, good to know
but it was certainly not 0xFFFF (which is 4 bytes anyway, no?)
2 hexits per byte. Each hexit encodes a 16 bit value: 0-9, A-F (I use hexit cause I've seen that once a long time ago and found the naming elegant, I don't think anybody else does =D)
better a snappy name than some of this overwrought computer science terminology imo. I always liked "nibble" (which is half a byte IIRC)
and yes, 0xFF is obviously 8 bits, I blame old age
Comments live in the wallet. Address comments are keyed by address, tx comments are keyed by tx hash. Tx comments are resolved at each ArmoryQt load, by checking for tx hashes in the ledger. As long as your DB works, the wallet will find its comments.
phew, thank satoshi for that (well, i suppose that was Alan's work, etotheipi is up amongst the bitcoin deities these days)
I've added a feature to export/import meta data in the new wallet format. It carries out address chain length and comments among other things. Thinking of adding a checkbox in the "Send" dialog to carry the structure along an unsigned tx blob to backup the meta data in the offline wallet. This would persist all that stuff in a saner fashion, though none of that data will be covered by paper backups.
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, as I have it set up so that the user partition is a non-persistent LVM snapshot, the OS ditches the snapshot upon closing the VM.
Alan was thinking of a system to share meta data. It was to be an online store where you key your data by some hash that is only known to you. The idea here was to synchronize multiple signers over multisig (something like passing the unsigned tx around between a phone and a PC). Maybe something like that could work to persist wallet meta data, by encrypting it to some private key in the wallet. However there's an issue of authenticity: anyone can encrypt data to your private key. The scheme would need some more thinking to keep the data private. Something to mull over.
just signing the encrypted data as part of the protocol seems like a ready solution? and why would it matter, once someone else encrypts data using a public key of yours, what could they possibly do with that? they can prove the data encrypts to that value, but it's common knowledge that this is how keypair cryptography works for decades. what am I missing?
The whole Qubes thing still eludes me tbh. I don't know how you put up with it. VFIO over kvm is all I can stomach in terms of virtualization, though I've got some chops with docker now and I plan to make ArmoryDB fully dockerizable at some point.
right, docker is the quick and easy way (using native kernel cleverness from cgroups or namespaces), although there's some kind of closed source wrinkle to it all that escapes me, maybe that's outmoded though.
Qubes was always like pulling teeth, but it's made for one thing only: overly cautious security. and so it fits Bitcoin usage well (especially for old timers like me with a stash to defend). using Qubes for anything else is not fun, although it's improved over the years (maybe even next release it will play video using the GPU over IOMMU, in just 1 VM across the whole OS!! atm playing video induces the CPU fan to push so hard that the computer levitates a little)
