Was stupid, should be fixed now.

Fixed the typos, will bundle a more consistent fix tomorrow

Yes

Both 0.93 and 0.94 could be patched to ignore SW tx (like any non SW compliant client should, it's a soft fork after all). However I don't think anyone wants to go down that path. 0.95 will properly scan SW tx at the very least.


Ahh, this thing again.

First, the DB is hardcoded to listen to localhost:9050. You can't make it listen to another IP (ill add custom ports at some point). If you want to enable the DB to serve remote clients, you need to set a http daemon to connect to it over the FCGI protocol (same as how stuff like PHP interface with a web stack) and manage the network parameters around the daemon, not the ArmoryDB per se.

The issue you are seeing seems to be common to Linux. I ran into it when I first started implementing around the FCGI library. It appears localhost is bound both in IPv4 or IPv6, and the fcgi lib uses listen in an old enough way that it doesn't try to distinguish between the two.

At first I took that for a quirk of my debian install (it's quite aged), researched the issue and fixed it fairly quickly (something to do with /etc/hosts file maybe? can't remember).

If you are hitting this error too, it seems this setup is more of a default than a stand alone case. I will setup a fresh VM, check against that, and most likely fix the FCGI lib directly.

upgrade to 0.94.1, armory db is down to 150mb

Most likely chocking on arg parsing. Will look into it.

Every body please start the DB on its own, see what it has to say for itself. The binary is called ArmoryDB, resides in the root project folder (where ArmoryQt.py is) and takes essentially the same set of command line arguments as the client.

Say, to start the DB in testnet with the default folder paths, just do

It's that time again. Calling on testers to build the dev branch for the time being. You can see the current change set here:

https://github.com/goatpig/BitcoinArmory/blob/dev/changelog.txt

This covers the core of the update, i.e. litenode. Some GUI stuff is broken, mainly the address book, the wallet filter drop down list, progress bars and the some data in the wallet properties dialog.

Also unit tests are out whack and there a few pull requests I'm going over at the moment, notably one for SegWit scanning support submitted by achow101 (many thanks =D).

There are still a few convenience features I haven't implemented yet, albeit they should be done quickly, notably:
- a change to guardian to prevent ungraceful bitcoind shutdowns. This should fix a lot of corruption issues.
- a dust-be-gone feature for coin control.
- a fee per byte feature in spend dialogs with tx size projections.

Once the current the outstanding issues (and anything you guys find in the process) are fixed, we'll move to testing binaries.

Stuff that won't be in the scope of this release and when to expect them:
- New wallets: That's for 0.96, with full SegWit support (create and spend from SW transactions).
- HW wallets support: Most likely a point release for 0.96.
- Fee estimates: Expect a point release on top of 0.95 (.1~2)
- Blocks over P2P. 0.97 most likely
- DB to Client encryption and auth. Again, probably 0.97
- Code modularization: most of it for 0.96
- Supernode: 0.98

This is rather massive change to the code base with big overhauls under the hood. Expect a decent amount of bugs. It will make implementing and testing the new features a lot faster and safer as a return.

Happy testing =)

P.S. I'll be away on the 25-26th. Will go over bug reports starting Wednesday

You are using 0.93, please upgrade to 0.94

You can copy the /blocks folder across system. Not sure the you can move the chainstate folder from one file system to another (say from NTFS to Ext). At any rate, copy the whole bitcoin folder and start BitcoinQt. You will know right away if the chainstate is usable.

What errors are you getting on *nix systems? I'd like to see some log files. Are you running all these OS against the same hardware or is your Windows machine significantly faster than the other two (more ram?)

You should register addresses/wallets before you hit goOnline, that's how it is supposed to work. You are using the lazy way, which is: init db -> feed it addresses to monitor.

0.95 has a work around for that. Either use the correct init sequence or wait for 0.95.

Yes

It's off on the block height. Make sure you are pointing Armory to the right block data folder. Also, log files.

Your setup is using the default datadir for Core. Otherwise, you can start BitcoinQt with the -datadir command line argument to specify that folder.

One more thing: If you want to let Armory run for long periods of time, you should really consider turning off auto bitcoind management, otherwise Armory will always kill bitcoind if it closes ungracefully. If you manage BitcoinQt yourself, you will at least avoid Core DB corruptions when Armory fails.

Start BitcoinQt manually, see what it has to say for itself. Otherwise, I need to see log files.

Looks like it's a bug in LMDB. I have a tentative fix for 0.95

It means the DB failed to extent its map size, i.e. the disk is full.

I would suggest to upgrade to 0.94

any one letter per line