Software.

Thanks for the help, it's really appreciated. Can I ask how you are testing this? I can't reproduce any of these bugs so I can't progress in fixing them without your log files currently. If I could experience them first hand,  the fixing would be a lot faster.

Is the error deterministic? Does it happen with latest commit?

Edit: Actually I expect the error to be deterministic. Armory was closed while it was on a fork. It's trying to get back on the main chain at start but since the block update code didn't handle things properly in the previous run it won't recover from this. The new code should prevent the bad state from happening in the first place.

Let's see logs, also try the latest commit in bugfix.

Glad to hear

I'm not sure what you mean by portable. Portable binaries usually implies they do not depend on registry/hive settings to run, nor do they have to install other packages on your machine. This is true for Armory in Windows. You can copy paste the install dir to any compatible machine and Armory will run. On Linux, you can copy the installed lib folder to another machine, and as long as you have the proper Python packages and libstd, it will run too. Granted, on Linux you should just build your own binaries if you want to operate this way. I don't know about OSX, I don't use it.

If you mean something else when you say portable, you should present that.


If you want to use Armory on partitions that aren't always available to your system or move the entire Core + DB around, you should be manually running BitcoinQt instead of using auto managed bitcoind. That's a default setting, easy to use, press one button and let it do its thing option made available to our users. You can't expect to customize your setup and get a good experience with the default behavior, that's contradictory.

You can disable both torrent download and auto manage bitcoind from the File -> Settings menu. In your case, failing to connect the drive in as you start Armory would result in Armory simply being offline, and no bootstrap would be downloaded.


While the new DB is resilient to this kind of abuse (LevelDB is terribly weak on that front), this is outright bad practice. If you're going to run any process against files on removable media, you should respect the remove procedure provided by your OS, which will clearly warn you the media is in use and shouldn't be removed at the moment. Blaming that on us is uncalled for. If you run your car into a wall, are you going to blame the manufacturer because it doesn't run anymore?

You can't expect to use a custom setup and have it convenient at the same time. Also, convenience and security are on the opposite end of a same line. You can place the cursor wherever you see fit, but don't think you can get an extremely secure system that works at the flick of a button. That's called web wallets, and it isn't secure at all.


Works in 0.93 afaik


I fixed some major bugs pertaining to bitcoind failures a few days ago, and some more are in the works. Why were these fixed only now? Because we were not aware of them until this moment in time. Why? Because users like you didn't report they were having issues, and we don't experience these on our dev environments.

This is FOSS. You don't pay us and we don't throw user satisfaction surveys are you either. If you want stuff to get better, you have to present us with the issues and help us isolate the bugs. That's the nature of things. Don't expect to get treated any better elsewhere if your approach is to silently endure bugs until you can't take them anymore.

That one is hitting the block update code. These have unit tests dedicated for headers first behavior, but I guess you just found a corner case. Time to reinforce them.

Did restarting fix the DB?

1) Windows 8 "Mobile" only runs "apps", not programs, i.e. only stuff built with MSVS for Windows works on that version. We build on MSVS for Windows desktop, which comes with the fully fleshed std libraries. You don't get half of that on the mobile dev suite, and it would be a nightmare to build Armory with it. If this is the version of Windows you have installed on that tablet, we can't do anything for you.

2) No x86 for 0.93, you have to use 0.92.3, which will do just fine for offline signing.

Does it try to redownload 100~150 blocks if you shut it down and restart it right away? It may show 1-2 blocks on consecutive restarts but I think that has to do with some corner case handling of the RPC packets Core returns to Armory. Also keep an eye on your top block just to be safe.


When you say BDM mode you mean auto bitcoind? That would be SDM mode (satoshi data manager). BDM is the block data manager, i.e. the C++ backend.


Ah, obviously. Since I don't shut down the P2P socket before asking bitcoind to stop it can end up thinking bitoind terminated unexpectedly. If only that would have triggered on my machine... T_T. I hate not experiencing the bugs first hand.

That went faster than expected. Try out bugfix, let's see if that covers your issue.

Gimme your ticket #, I'll look at it.

I fixed the block catch up issue yesterday. You can pull bugfix if you want to try that. Ima push a change in a few hours to cover for this issue too. Maybe you want to wait till then to try out both changes.

Does the comment reappear on the next start?

Yes please.

I'm aware of that but non Mac users read these threads too so I use platform agnostic statements whenever possible.


Core behaves differently when it verifies blocks through milestones hashes as opposed to checking each transaction sig. The usual behavior is checking the sigs, which is slow and doesn't trigger empty block data. Milestone hash checking is a lot more aggressive with disk writes and will resort to the headers first approach as much as possible. Also, you don't want to be heavily reading and writing the same data concurrently.


Too much has changed in this release so I don't expect most documentation to be up to date yet. Headers first changed some significant things under the hood for us and we might be more and more motivated to resort to blocks over P2P.

As for letting BitcoinQt run its course before starting Armory, it wasn't a requirement up until Core 0.10, but rather a good practice. Better let the first finish before moving on to the second.

Some changes are Python only and can get away with not rebuilding, but it's a general guideline to make clean & make every time to you pull, regardless of the changes.

Something can and will be done in the next version. It won't make it instant but it should prevent it from redownloading the last few blocks over and over.

Next version will take it easier on the RAM front. For now I'm more interested in stability.

sflicht:

You either let Armory manage bitcoind for you, or you start BitcoinQt manually and let it sync fully before you start Armory. Instead, you are starting BitcoinQt and letting Armory run on top of a blocks folder that Core is still indexing through milestones hashes, which guarantees you'll run into missing block data. Let BitcoinQt do its thing then start Armory.

For now try the new build with the fresh fixes, but your logs did not indicate anything that would lead me to believe these fixes will cover your issue. At any rate, try and it report here.