Armory 0.95 is out

[goatpig]

No changes since the last testing release (0.94.99.1). I've decided to sticky the latest stable release thread from now. Enjoy

Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.0

Changelog:

https://github.com/goatpig/BitcoinArmory/blob/v0.95.0/changelog.txt

- Forgot to bump the version and add the date in the changelog, will do for 0.95.1
- On windows, the automated DB will spawn a command line dialog. This wasn't the intention originally, but it goes a long way conveying the change in architecture. I've decided to leave it as is until 0.95.1.

*************************************

Botched auto bitcoind management on Windows,
you'll have to turn it off until I get a fix out.

**************************************

[1714036592]

1714036592

[1714036592]

1714036592

[Carlton Banks]

@users of Qubes OS:

0.95 is currently not working with Whonix, investigating a fix to that right now.


Debian 8 template is running 0.95 ok. Those that add parameters to their /usr/share/applications/armory.desktop file may need to invoke python directly (i.e. "Exec=python /usr/lib/armory/ArmoryQt.py <arguments>" instead of running the /usr/bin/armory script file. Don't forget to run /usr/lib/qubes/qubes-trigger-sync-app-menus after editing your .desktop files.

[m.fridge]

Hi,

thanks for finalizing the new release! I am keen to check it out

I get the following compilation error in Swig:

Code:

CppBlockUtils_wrap.cxx:3991:77: error: ‘type_name’ is not a member of ‘swig::traits<long long unsigned int>’

Regards,
Michael

[goatpig]

Hi,

thanks for finalizing the new release! I am keen to check it out

I get the following compilation error in Swig:

Code:

CppBlockUtils_wrap.cxx:3991:77: error: ‘type_name’ is not a member of ‘swig::traits<long long unsigned int>’

Regards,
Michael

What OS and compiler are you using?

[visdude]

Armory 0.95 is not working for me. Due to some changes in 0.95 (e.g. Client and Database split), I assume that my arg in my ArmoryQt shortcut target which is set to point to alternate database directories for both Bitcoin Core and Armory is no longer valid (it was working just fine with 0.94.1). What do I have to do to get 0.95 working without changing my current alternate Bitcoin Core and Armory database locations/directories.

This is my current Armory shortcut target arg that worked quite well with 0.94.1:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="D:\Bitcoin" --datadir="D:\Armory"

Also, on the btcarmory site under "Notable Changes", it says:

"Client no longer requires a local Bitcoin node to operate as P2P has moved to ArmoryDB"

...while under "Full changelog/Added", it also states:

"ArmoryDB requires the presence of a bitcoin node on localhost:8333 and access to raw blockchain data like before".

I'm confused. Do I still or do I not have to manually fire up and sync Bitcoin core 0.13.1 before running Armory 0.95 as I did before with Armory 0.94.1? I'm running W7 x64 BTW.

Sorry for my cluelessness as I am very coding-illiterate.

[achow101]

Armory 0.95 is not working for me. Due to some changes in 0.95 (e.g. Client and Database split), I assume that my arg in my ArmoryQt shortcut target which is set to point to alternate database directories for both Bitcoin Core and Armory is no longer valid (it was working just fine with 0.94.1). What do I have to do to get 0.95 working without changing my current alternate Bitcoin Core and Armory database locations/directories.

This is my current Armory shortcut target arg that worked quite well with 0.94.1:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="D:\Bitcoin" --datadir="D:\Armory"

That should be fine. What is probably broken is the fact that goatpig forgot to include guardian.exe which is what spawns the bitcoind when Armory is set to auto manage it.

Also, on the btcarmory site under "Notable Changes", it says:

"Client no longer requires a local Bitcoin node to operate as P2P has moved to ArmoryDB"

...while under "Full changelog/Added", it also states:

"ArmoryDB requires the presence of a bitcoin node on localhost:8333 and access to raw blockchain data like before".

I'm confused. Do I still or do I not have to manually fire up and sync Bitcoin core 0.13.1 before running Armory 0.95 as I did before with Armory 0.94.1? I'm running W7 x64 BTW.

Sorry for my cluelessness as I am very coding-illiterate.

There are two parts, the DB (ArmoryDB) and the client (ArmoryQt). ArmoryDB requires a local Bitcoind. ArmoryQt can connect to any instance of ArmoryDB, both remote and local. That does not require a local bitcoind. ArmoryQt will automatically spawn an instance of ArmoryDB of it does not detect one locally and a remote one is not specified. Thus, if you are just running ArmoryQt without doing anything to ArmoryDB, then you will still need to run Bitcoin Core locally.

tl;dr yes you still need Bitcoin Core locally.

[visdude]

Armory 0.95 is not working for me. Due to some changes in 0.95 (e.g. Client and Database split), I assume that my arg in my ArmoryQt shortcut target which is set to point to alternate database directories for both Bitcoin Core and Armory is no longer valid (it was working just fine with 0.94.1). What do I have to do to get 0.95 working without changing my current alternate Bitcoin Core and Armory database locations/directories.

This is my current Armory shortcut target arg that worked quite well with 0.94.1:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="D:\Bitcoin" --datadir="D:\Armory"

That should be fine. What is probably broken is the fact that goatpig forgot to include guardian.exe which is what spawns the bitcoind when Armory is set to auto manage it.

Also, on the btcarmory site under "Notable Changes", it says:

"Client no longer requires a local Bitcoin node to operate as P2P has moved to ArmoryDB"

...while under "Full changelog/Added", it also states:

"ArmoryDB requires the presence of a bitcoin node on localhost:8333 and access to raw blockchain data like before".

I'm confused. Do I still or do I not have to manually fire up and sync Bitcoin core 0.13.1 before running Armory 0.95 as I did before with Armory 0.94.1? I'm running W7 x64 BTW.

Sorry for my cluelessness as I am very coding-illiterate.

There are two parts, the DB (ArmoryDB) and the client (ArmoryQt). ArmoryDB requires a local Bitcoind. ArmoryQt can connect to any instance of ArmoryDB, both remote and local. That does not require a local bitcoind. ArmoryQt will automatically spawn an instance of ArmoryDB of it does not detect one locally and a remote one is not specified. Thus, if you are just running ArmoryQt without doing anything to ArmoryDB, then you will still need to run Bitcoin Core locally.

tl;dr yes you still need Bitcoin Core locally.

Thank you for the timely reply and explanation. It's helping me understand a bit more though it is still a challenge for me to comprehend the intricacies of coding. I'm just a plain ol' user.

When I run ArmoryQt with the shortcut arg (specifying Bitcoin and Armory alternative/non-standard database directory paths) after starting and syncing Bitcoin Core 0.13.1 (not managed by ArmoryQt), the client opens with the ArmoryDB CLI dialog and does nothing else after the third line:



...and of course, ArmoryQt consequently gets stuck at this point without any progress...and offline:



Though I don't think it's related to my particular issue, I'm curious as to why there is a "slash" (/) instead of a "backslash" (\) between "Roaming" and "Armory" on the first line of the CLI dialog (directory path).

From what I can surmise, perhaps the ArmoryQt shortcut arg (directory locations) is not being passed on when it automatically spawns an instance of ArmoryDB, thereby not finding the specified database directories. It's most likely a far-fetched assumption on my part but if it is so, can you suggest a workaround?

Just out of curiosity, was there a reason/purpose of the binary split since it was working just fine up to 0.94.1?

[achow101]

Thank you for the timely reply and explanation. It's helping me understand a bit more though it is still a challenge for me to comprehend the intricacies of coding. I'm just a plain ol' user.

When I run ArmoryQt with the shortcut arg (specifying Bitcoin and Armory alternative/non-standard database directory paths) after starting and syncing Bitcoin Core 0.13.1 (not managed by ArmoryQt), the client opens with the ArmoryDB CLI dialog and does nothing else after the third line:

...and of course, ArmoryQt consequently gets stuck at this point without any progress...and offline:

Can you post the log files?

Though I don't think it's related to my particular issue, I'm curious as to why there is a "slash" (/) instead of a "backslash" (\) between "Roaming" and "Armory" on the first line of the CLI dialog (directory path).

That shouldn't matter. The backslash and forward slash are treated the same.

From what I can surmise, perhaps the ArmoryQt shortcut arg (directory locations) is not being passed on when it automatically spawns an instance of ArmoryDB, thereby not finding the specified database directories. It's most likely a far-fetched assumption on my part but if it is so, can you suggest a workaround?

I doubt it.

Just out of curiosity, was there a reason/purpose of the binary split since it was working just fine up to 0.94.1?

The main reason is to make the litenode feature work. Litenode is where you run the client remotely and have it connect to an ArmoryDB instance on another machine. I think the idea is to shift Armory towards an Electrum-like architecture where you have clients and servers.

[goatpig]

From what I can surmise, perhaps the ArmoryQt shortcut arg (directory locations) is not being passed on when it automatically spawns an instance of ArmoryDB, thereby not finding the specified database directories. It's most likely a far-fetched assumption on my part but if it is so, can you suggest a workaround?

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.

Just out of curiosity, was there a reason/purpose of the binary split since it was working just fine up to 0.94.1?

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!

[visdude]

Thank you for the timely reply and explanation. It's helping me understand a bit more though it is still a challenge for me to comprehend the intricacies of coding. I'm just a plain ol' user.

When I run ArmoryQt with the shortcut arg (specifying Bitcoin and Armory alternative/non-standard database directory paths) after starting and syncing Bitcoin Core 0.13.1 (not managed by ArmoryQt), the client opens with the ArmoryDB CLI dialog and does nothing else after the third line:

...and of course, ArmoryQt consequently gets stuck at this point without any progress...and offline:

Can you post the log files?

Here they are (wallet/user info obscured with x's).

From armorycpplog:

Log file opened at 1477695827: D:\ArmoryData\Armory\armorycpplog.txt
-ERROR - 1477695831: (..\SwigClient.cpp:61) unexpected type


From armorylog:

2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1128 - C++ block utilities loaded successfully
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1238 -
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1239 -
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1240 -
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1241 - ************************************************************
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1242 - Invoked: C:\Program Files (x86)\Armory\ArmoryQt.exe --satoshi-datadir=D:\BitcoinData\Bitcoin --datadir=D:\ArmoryData\Armory
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1243 - ************************************************************
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1244 - Loading Armory Engine:
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1245 -    Armory Version        : 0.95
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1246 -    Armory Build:         : 374672b751
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1247 -    PyBtcWallet  Version  : 1.35
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1248 - Detected Operating system: Windows
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1249 -    OS Variant            : 7-6.1.7601-SP1-Multiprocessor Free
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1250 -    User home-directory   : C:\Users\xxxxxxxx\AppData\Roaming
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1251 -    Satoshi BTC directory : D:\BitcoinData\Bitcoin
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1252 -    Armory home dir       : D:\ArmoryData\Armory
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1253 - Detected System Specs    :
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1254 -    Total Available RAM   : 15.94 GB
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1255 -    CPU ID string         : Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1256 -    Number of CPU cores   : 4 cores
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1257 -    System is 64-bit      : True
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1258 -    Preferred Encoding    : cp1252
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1259 -    Machine Arch          : amd64
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1260 -    Available HDD (ARM)   : 108 GB
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1261 -    Available HDD (BTC)   : 108 GB
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1262 -
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1263 - Network Name: Main Network
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1264 - Satoshi Port: 8333
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1265 - Do wlt check: True
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1266 - Named options/arguments to armoryengine.py:
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     thread_count    : -1
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     rescan          : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     ignoreAllZC     : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     rescanBalance   : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     disableModules  : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     port            : None
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     interport       : 8223
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     skipStatsReport : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     forceWalletCheck: False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     regtest         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     rebuild         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     nettimeout      : 2
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     datadir         : D:\ArmoryData\Armory
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     clearMempool    : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     offline         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     coverageOutputDir: None
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     armoryDBDir     : DEFAULT
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     armorydb_port   : 9001
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     satoshiPort     : DEFAULT
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     useTorSettings  : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     netlog          : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     keypool         : 100
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     coverageInclude : None
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     forceOnline     : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     skipAnnounceCheck: False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     redownload      : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     armorydb_ip     : 127.0.0.1
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     multisigFile    : DEFAULT
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     ram_usage       : -1
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     testAnnounceCode: False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     mtdebug         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     logDisable      : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     settingsPath    : D:\ArmoryData\Armory\ArmorySettings.txt
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     db_type         : DB_FULL
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     doDebug         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     enableDetSign   : True
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     disableConfPermis: False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     testnet         : False
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     rpcport         : DEFAULT
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     satoshiHome     : D:\BitcoinData\Bitcoin
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     satoshiRpcport  : DEFAULT
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     logFile         : D:\ArmoryData\Armory\ArmoryQt.exe.log.txt
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1268 -     verbosity       : None
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1269 - Other arguments:
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1272 - ************************************************************
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:1675 - C++ block utilities loaded successfully
2016-10-28 16:03 (INFO) -- BDM.pyc:367 - Using the asynchronous/multi-threaded BlockDataManager.
2016-10-28 16:03 (INFO) -- BDM.pyc:368 - Blockchain operations will happen in the background. 
2016-10-28 16:03 (INFO) -- BDM.pyc:369 - Devs: check TheBDM.getState() before asking for data.
2016-10-28 16:03 (INFO) -- BDM.pyc:370 - Registering addresses during rescans will queue them for
2016-10-28 16:03 (INFO) -- BDM.pyc:371 - inclusion after the current scan is completed.
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:3588 - Using settings file: D:\ArmoryData\Armory\ArmorySettings.txt
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2485 - loadWalletsAndSettings
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2539 - Loading wallets...
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2598 - Number of wallets read in: 3
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2603 -    Wallet (xxxxxxxxx):   "xxxxxxxx (Watch)                     "   (No Encryption)
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2603 -    Wallet (xxxxxxxxx):   "xxxxxxxx (Watch)                   "   (No Encryption)
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2603 -    Wallet (xxxxxxxxx):   "xxxxxxxx (Watch)                    "   (No Encryption)
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2608 - Loading Multisig Lockboxes
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2153 - Setting up networking...
2016-10-28 16:03 (INFO) -- ArmoryQt.py:1412 - setupUriRegistration
2016-10-28 16:03 (INFO) -- ArmoryQt.py:1480 - Armory already registered for current user.  Done!
2016-10-28 16:03 (INFO) -- ArmoryQt.py:546 - Usermode: Expert
2016-10-28 16:03 (INFO) -- ArmoryQt.py:1708 - Changing usermode:
2016-10-28 16:03 (INFO) -- ArmoryQt.py:1709 -    From: Expert
2016-10-28 16:03 (INFO) -- ArmoryQt.py:1717 -      To: Expert
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2217 - startBitcoindIfNecessary
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2257 - setSatoshiPaths
2016-10-28 16:03 (INFO) -- SDM.pyc:382 - Reading bitcoin.conf file
2016-10-28 16:03 (INFO) -- SDM.pyc:395 - Setting permissions on bitcoin.conf
2016-10-28 16:03 (INFO) -- SDM.pyc:404 - Setting permissions on bitcoin.conf
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:642 - Executing popen: [u'icacls', u'D:\\BitcoinData\\Bitcoin\\bitcoin.conf', u'/inheritance:r', u'/grant:r', u'xxxxxxxx:F']
2016-10-28 16:03 (INFO) -- SDM.pyc:410 - icacls returned:
2016-10-28 16:03 (INFO) -- SDM.pyc:755 - Creating proxy in SDM: host=127.0.0.1, port=8332
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2257 - setSatoshiPaths
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:642 - Executing popen: ['./ArmoryDB.exe', '--db-type="DB_FULL"', '--spawnId="BNvn2WehsxpeokfqjebEwukaYuXRdkgkyLHp9pSrgnS5"', u'--satoshi-datadir="D:\\BitcoinData\\Bitcoin\\blocks"', u'--dbdir="D:\\ArmoryData\\Armory\\databases"']
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2307 - Setting netmode: 1
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2307 - Setting netmode: 0
2016-10-28 16:03 (INFO) -- ArmoryQt.py:2289 - loadBlockchainIfNecessary
2016-10-28 16:03 (INFO) -- ArmoryQt.py:5645 - Dashboard switched to "Scanning" mode
2016-10-28 16:03 (INFO) -- ArmoryQt.py:5645 - Dashboard switched to "Scanning" mode
2016-10-28 16:03 (INFO) -- ArmoryUtils.pyc:3753 - Another Armory instance just tried to open.
2016-10-28 16:19 (INFO) -- ArmoryQt.py:6366 - BDM state is scanning -- force shutdown BDM
2016-10-28 16:19 (INFO) -- SDM.pyc:587 - Called stopBitcoind
2016-10-28 16:19 (INFO) -- SDM.pyc:593 - ...but bitcoind is not running, to be able to stop
2016-10-28 16:19 (INFO) -- ArmoryQt.py:6386 - Attempting to close the main window!

[visdude]

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!

Thanks for elaborating on your vision of Armory. Very cool stuff...especially the hardware wallet>mobile device app>private remote node/server scenario. Awesomeness indeed! Imbibing the koolaid.

[goatpig]

Run the DB manually.

[visdude]

Run the DB manually.

How do I do that? Running stuff in a CLI terminal gives me the heebie-jeebies...it horrifies me.

Better yet, can I just copy and paste the arg from the ArmoryQt shortcut (Core and Armory database paths) that worked before the upgrade into an ArmoryDB shortcut and run it this way?

BTW, did you get a chance to see the logs I posted above for achow101? Anything unusual in them that would indicate why it crashes on me?

[goatpig]

Better yet, can I just copy and paste the arg from the ArmoryQt shortcut (Core and Armory database paths) that worked before the upgrade into an ArmoryDB shortcut and run it this way?

Yes

BTW, did you get a chance to see the logs I posted above for achow101? Anything unusual in them that would indicate why it crashes on me?

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

[visdude]

Better yet, can I just copy and paste the arg from the ArmoryQt shortcut (Core and Armory database paths) that worked before the upgrade into an ArmoryDB shortcut and run it this way?

Yes

BTW, did you get a chance to see the logs I posted above for achow101? Anything unusual in them that would indicate why it crashes on me?

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

Crashed.



dblog:

Log file opened at 1477771772: D:\ArmoryData\Armory/dbLog.txt
-INFO  - 1477771772: (..\main.cpp:22) Running on 4 threads
-INFO  - 1477771772: (..\main.cpp:23) Ram usage level: 4
-INFO  - 1477771772: (..\BlockUtils.cpp:1325) blkfile dir: D:\BitcoinData\Bitcoin/blocks
-INFO  - 1477771772: (..\BlockUtils.cpp:1326) lmdb dir: D:\ArmoryData\Armory/databases
-INFO  - 1477771772: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 1477771773: (..\BlockUtils.cpp:1508) Executing: doInitialSyncOnLoad
-INFO  - 1477771773: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node
-INFO  - 1477771773: (..\DatabaseBuilder.cpp:162) Reading headers from db
-ERROR - 1477771773: (..\StoredBlockObj.cpp:538) buffer is too small: 0 bytes. expected: 106
-ERROR - 1477771773: (..\BDM_mainthread.cpp:255) BDM thread failed: buffer is too small: 0 bytes. expected: 106

[goatpig]

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

[goatpig]

Pushed the fixes for 0.95.1 in dev. People who've had issues, please build and try. Looking to release tomorrow or Monday.

[visdude]

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

1. You mean rebuild the Armory database from scratch?
2. --dbdir has the same effect as --datadir, right?

[visdude]

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

ArmoryDB insists on still creating "dblog.txt" file in the default "Armory" folder location (C:\Users\username\AppData\Roaming\Armory) in spite of the arg that specifies the alternate directory. It was crashing on me the way it did because it needs the presence of an Armory folder at the default location to be able to create dblog.txt in it. Otherwise, it refuses to proceed.

Perhaps it can be fixed in 0.95.1 if it's not too late so it will be consistent (along with the rest of the files) when opting to move the Armory database folder to a different location.

Thanks for the assistance.

[goatpig]

1. You mean rebuild the Armory database from scratch?
2. --dbdir has the same effect as --datadir, right?

1) Yes

2) No. The datadir is where your wallets, logs and setting files are, as well as where the /databases folder defaults to. --dbdir forces the the db folder to the path of your choosing.

ArmoryDB insists on still creating "dblog.txt" file in the default "Armory" folder location (C:\Users\username\AppData\Roaming\Armory) in spite of the arg that specifies the alternate directory. It was crashing on me the way it did because it needs the presence of an Armory folder at the default location to be able to create dblog.txt in it. Otherwise, it refuses to proceed.

Perhaps it can be fixed in 0.95.1 if it's not too late so it will be consistent (along with the rest of the files) when opting to move the Armory database folder to a different location.

Thanks for the assistance.

Log files do not go in the dbdir. If you want to use a custom datadir and a custom dbdir, use both command line arguments together. You do not need to provide the DB with the same datadir as the client, i.e. it doesn't need the wallets, settings and other log files to operate.

However, the db needs a valid datadir (it won't create it for you). There isn't much I can change here. The issue you were experiencing with the log file is simply the first failure in line when the db lacks a valid datadir. Side stepping that one will only bump you to the next failure.

If you do not want to point the DB to the same datadir as the client, you can start the db directly with --datadir="/newpath" and it will set the db by default to /newpath/databases. If you let the client spawn the DB for you, the client will always push its own datadir to the DB, in which case you may want to use a custom dbdir.