Clean up your database folder or use another --dbdir.

Yes


Yes. This is why I instructed you to start the DB manually.

Run the DB manually.

Only for legacy Tx. You will need 0.95.1/2 to sign SW tx and 0.96 for to sign with the new wallets.

The same pathing command line arguments that work on the client work on the DB. You can see the full list of DB cli arg here:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L812

and these are the default paths:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L704

The DB will append /database to you datadir if no dbdir is specified.

If you have issues letting the client automate the DB spawning, I suggest you start the DB manually with the arguments you want and see how it operates. You will need to run ArmoryDB.exe in the command prompt.


Plenty of reason to split the server from the client. One is remote capability, another is multiple clients to one server, another is process isolation (after all, the client does everything wallets, the db does everything blockchain, and they dont intersect in these duties), another is to enable Armory to operate as a web stack element (one server in the backend, any number of clients over HTTP).

--------------------------

Ima digress here, TL;DR: it's awesome.

DB/client separation makes sense in the long term. 2 features needed in Armory are supernode and blocks over P2P. Blocks over P2P is a versatility and stability feature, supernode is a power user/professional feature. They both require aspects of the client/server separation.

Another benefit is splitting the code base, which will come in the future.

Overall this feature is inscribed in my vision for Armory. I want Armory to cater to high end users and professionals. Client/server separation is a must have in this case. Maybe this example will make my case better than a list of requirements:

When the likes of Microsoft and Dell add Bitcoin payment support, they're not integrating with Bitcoin, they are simply interfacing with a payment processor like Coinbase or BitPay.

It makes me die a little inside every time an IT giant approaches the Bitcoin space like your local florist integrates with Paypal. I would like there to be an industry standard, robust and full featured open source solution targeted at their needs, a kind of no brainer go to stack, and this is where I am trying to take Armory.

As for individual users, I fancy them all enthusiasts, and I believe their needs largely intersect with professional use cases. To give you another example, the reality towards with 0.95 is working, is that in the future you could have a server at home that runs your own Core and ArmoryDB instances, and with a JavaScript template, get your Armory GUI straight to your mobile phone, and offline sign with a Trezor on the spot, all the while fully verifying the blockchain with code you run and no privacy leak.

Imagine your friends and family are interested in Bitcoin. You could provide them with the full bitcoin experience with no privacy leak nor the need to rely on a 3rd party service. With supernode, you could even offer them a blockchain explorer service, again with no risk of privacy leaks.

Imagine in the future you are running a node to support your Lightning hub. You won't need a second node just to run Armory, point the DB to your existing one.

Imagine you want to setup a multisig scheme and split keys among several devices, some of which are online. You would be able to bounce the transaction stub between online devices, finalize and broadcast from any of these, all running against the same remote server. And then there's all the use cases I can't think of yet.

Put another way, it's the future! Flying cars and self drying clothes. Now, drink the koolaid!

Update Armory first.

There is no relationship between spending and the code throwing that error. I've never seen that one to begin with, and the code in question has been out for over a year and a half.

Try to spend from another wallet and see if you get the issue. Otherwise, create the same transaction as offline instead, maybe that will get you through.

You other solutions are:

1) debug the issue yourself
2) send me a watching only copy of your wallet.
3) try 0.95

I would suggest you do a Help -> Rebuild & Rescan.

1) I forgot guardian.exe on the Windows package, my bad. You can still run Armory if you turn off auto bitcoind management and run BitcoinQt yourself. I'll fix the release sometimes this week.

2)


Ugh, don't post unsigned 100Kb executables online, that's a poor idea. Guardian.exe is the same accross all versions, ever since it was introduced. If you can't wait for a fix, grab the file from older packages.

3)


DB is failing to detect older versions and still reads ahead, which results in this error. I'll fix that along with guardian. The end result is the same, you need to provide the DB with another a fresh dbdir or wipe your existing one.


This is not accurate. 0.95 is compatible with SegWit chains that Core 0.13 enabled on the testnet and 0.13.1 will eventually enable on the mainnet. The requirement is for Armory to be updated to 0.95 to run against a SegWit chain. 0.95 can run against any older version of the blockchain.


It will be 0.95.1. No point disturbing the versioning pattern. The slow startup I believe is related to starting bitcoind first. The client waits on bitcoind to get ready before processing any further. Test this assumption by turning off auto bitcoind, starting BitcoinQt yourself, then starting Armory. The DB should spawn right away.

This issue will go away in the next subrelease (0.95.2 now), once I'll have all the bitcoind management moved to the DB.


There is no "normally" per se yet. 0.95 just introduced the DB as its own binary. It used to run within the client's virtual address space as a shared library before.

I've left the DB command line dialog visible in Windows on purpose, as I explained in the release post. This is to make debugging easier and make users aware of the architectural shift. I'll hide it in 0.95.2

Your client is set to auto manage bitcoind, and apparently it's failing there, so it never got as far as starting the db.

Do you remember funding your wallet after Aug 23rd 2016?

Did you sign offline? Do you have a digital copy of your previous wallet somewhere?

What about this?


How many addresses do you have computed? Did you have other wallets? If you have several wallets, have you tagged them all as yours?

Has been there since Armory has had a db. You don't need to specify the dbdir if you are just appending /databases to the datadir, it does that on its own to begin with.


Db isn't starting at all then. I suggest you run ArmoryDB.exe on its own in the command prompt with the same cli args. You'll get a terminal output that will help you figure out what's wrong.

This is the 0.95 logs. I guess you nuked the previous log files while reinstalling?

These logs show you are up to date with the network.

You say you had some 0.9 BTC before and now only see 0.17. In your transaction ledger, do you see transactions that suggest at some point you had 0.9 and  0.72 were spent, or does it suggest you only ever had as much as 0.17?

If the later is the case, refer to achow's advice.

use pastebin.

I don't quite believe you had Armory 0.92 sync'ed with the current network. That's an age old implementation with poor scaling. It was already failing for a majority of users around block #300k, so my take is that you were not up to date with the network, so your balance was not correct to begin with.

Can we see some logs?

What OS and compiler are you using?

It's ready now, start ArmoryQt.

Point it to another DB folder (--dbdir) or empty the default one. You can see the default db paths here:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L704
https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L724

run ArmoryDB manually with your command line args, see what it has to say.