Quote from: pvz on January 26, 2013, 09:37:10 PM

Quote from: etotheipi on January 24, 2013, 05:35:39 AM

Yeah, I definitely want to have the add/remove/create/rescanwallet functions. Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.

Is it a option to do the rescan in a (parallel) external process? If this process returns the input, to the under laying database or memory, it takes a time span to obtain the data but the armoryd processes can keep running?
Or a temporary armoryd for the rescan of the specific new wallet. Gathered additional info (addresses and transactions for this wallet) put into the database/memory and the temporary armoryd exits.
I'm very n00b with this kind of processes, but I do hope this kind of solution is possible.
I still prefer a stable and 24/7 daemon. The add/rescan process is necessary, can take some time, but should not stall any daemon/JSON processes.

Quote from: etotheipi on January 24, 2013, 05:35:39 AM

Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).

Unfortunately, 24/7 is a stretch at the minute: I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event! I'm going to have to dig into this again.

On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata. Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away. I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.

I cannot understand exactly what you are trying to say, but it seem to me this is a big and crucial decision for the way Armory functions within the bitcoin (software) environment.
I do remember your primary reason to stick with the original bitcoin client are the network functions. If you maintain your own blockdata, can you still use the networkfunctions?
Scanning the blockdata to be able to add a wallet (concerning historical data) is a lot different than to add data to the (own) blockdata yourself (concerning new data).

On the other hand, maybe the way the original bitcoin client adds data is not difficult at all?

The second part that you quoted of me answered your first part -- having it scan completely in the background without stalling the BDM is what I will do. It will require a bit of work, because right now "scanning" involves updating the BDM as it is scanning, which is why it must go offline to avoid race conditions. But I can execute the scan in a ghost thread, then extract just the collected data and inject it into TheBDM when it's done. The injection would take a fraction of a second, so it would hardly be noticeable.

The downside is that I need to implement more interface options, such is "isScanning", "queuedAddresses", etc. It's doable and necessary -- it's just not trivial.

I know how important 24/7 stability is. And I'm almost there -- I currently, already, run Armory for 5+ days at a time, in both Windows and Linux. The last couple issues are tough to track because of how infrequent they are, but I am fairly certain they have to do with timing issues related to clashing with Bitcoin-Qt in the blkfiles. If I simply got everything from Bitcoin-Qt via sockets and managed my own blockchain files, those would go away, by definition, but I think I will be fixing them, as-is, right now.

Btw, I only use Bitcoin-Qt as a regular peer -- no JSON-RPC -- but it is a trusted peer (critical!). It is essentially a filter/gateway between Armory and the rest of the network, endowing Armory users with the network security of Bitcoin-Qt/bitcoind, filtering out invalid tx and blocks, etc. Armory still organizes the headers, calculates the longest chain, invalidates orphans, etc. But it relies on bitcoind/-qt for the nitty-gritty verification activities, and DoS protection, etc.