Armory 0.95 testing phase

[Searinox]

Is it safe to connect ArmoryDB to a potentially untrusted bitcoind node? Or ArmoryQt to a potentially untrusted ArmoryDB server?

[1715184947]

1715184947

[1715184947]

1715184947

[1715184947]

1715184947

[achow101]

Is it safe to connect ArmoryDB to a potentially untrusted bitcoind node?

ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself.

Or ArmoryQt to a potentially untrusted ArmoryDB server?

AFAICT, your Bitcoin would still be safe, but not your privacy.

[Searinox]

ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself.

Aha... question. Does it need access ONLY to the disk where an up to date blockchain exists, or ALSO the bitcoind.exe running instance(remote could still be achieved by pointing the btc folder to a mapped network drive, and forwarding localhost:port to the remote machine).

Alternatively, does Armory 0.95 work with a pruned bitcoind node?

AFAICT, your Bitcoin would still be safe, but not your privacy.

When you say this, you mean the Qt would poll ADB for info about a specific address, and that gives away what wallet a certain IP address has, right?

[goatpig]

ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself.

Aha... question. Does it need access ONLY to the disk where an up to date blockchain exists, or ALSO the bitcoind.exe running instance(remote could still be achieved by pointing the btc folder to a mapped network drive, and forwarding localhost:port to the remote machine).

The DB reads block data from the path you feed it. It needs a socket to a node (any node) that runs the same network as the chain data on disk (same magic word) to get signals (new blocks, new zc) and broadcast its own tx. The DB gets mempool tx from the node directly (over p2p), however the new block invs over the p2p socket are only used as signals to trigger on disk data checks atm (blocks over p2p is the last stage of that transformation, that's somewhere on the list of todos).

So you could run a remote node + blockchain data which you symlink. You will have to build your own DB though, it is hardcoded to only look for nodes on localhost atm.

When you say this, you mean the Qt would poll ADB for info about a specific address, and that gives away what wallet a certain IP address has, right?

Upon connection, the client creates a BlockDataViewer instance with the DB, and feeds it all its wallet data (i.e. all addresses in all your wallets). DB calls back client with when necessary (no polling really occurs).

An untrusted DB would get to know all your current addresses, and it could serve you bogus data which can be boiled down to DoS and withholding info. It cannot get you to sign anything however. This model is meant to have you connect to trusted DBs. The next step is to encrypt the socket and add authentication. Most likely going the BIP151 way for this.

[Searinox]

ArmoryQt latest build laments about being unable to start the DB if started while the DB is offline, but if ADB is running it handles it closing or restarting just fine. Can AQT be made to not complain if it doesn't find DB running immediately and just wait?

[achow101]

ArmoryQt latest build laments about being unable to start the DB if started while the DB is offline, but if ADB is running it handles it closing or restarting just fine. Can AQT be made to not complain if it doesn't find DB running immediately and just wait?

If it can't find the DB it will spawn the DB by itself unless the socket it is occupied by something.

What error do you get?

[Searinox]

It is a warning, I don't have it up anymore, I will repro it. Also. After running for ~2 days and me doing nothing with it, computer idle, today I came from work to find armoryDB crashed.

Armory: latest beta published on the forum, unmanaged bitcoind node.

Code:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	ArmoryDB.exe
  Application Version:	0.0.0.0
  Application Timestamp:	57f1a01f
  Fault Module Name:	ArmoryDB.exe
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	57f1a01f
  Exception Code:	40000015
  Exception Offset:	00000000000f9a8a
  OS Version:	6.1.7601.2.1.0.256.1
  Locale ID:	1033
  Additional Information 1:	9071
  Additional Information 2:	90719623e2e1d09ab95d0bbb808a8813
  Additional Information 3:	f515
  Additional Information 4:	f515d384d99c042243c8e1208441aaea

These were the last DB log entries:

Code:

-INFO  - 1476169262: (..\BlockchainScanner.cpp:650) scanned from height #433862 to #433862
-ERROR - 1476169283: (..\BitcoinP2P.cpp:862) caught unkown exception in processDataStackThread
-INFO  - 1476169283: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-ERROR - 1476169283: (..\SocketObject.cpp:262) poll() error in readFromSocketThread: 10038
-ERROR - 1476169283: (..\BitcoinP2P.cpp:851) caught SocketError exception in processDataStackThread: poll() error in readFromSocketThread: 10038
-ERROR - 1476169283: (..\SocketObject.cpp:125) poll() error in writeToSocket: 10038
-INFO  - 1476202821: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO  - 1476202821: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node

OS: Windows 7 SP1 all updates.
Setup: Localhost default IP and port bitcoind, DB, and Qt.

[achow101]

It looks like it received a bad message and just crashed. These crashes are usually hard to reproduce and thus we can't really debug them to fix.

[Searinox]

Earlier today ArmoryDB and Qt were using 20% CPU each in idle. They were hogging the system but Qt's interface at least looked responsive. After restarting Qt the issue disappeared(only restarted Qt, DB went back to normal by itself when I did that). The logs had absolutely nothing in them unusual, just the usual block activity and scan and nothing eyecatching during that time. Is there any way I can debug these?

[goatpig]

Earlier today ArmoryDB and Qt were using 20% CPU each in idle. They were hogging the system but Qt's interface at least looked responsive. After restarting Qt the issue disappeared(only restarted Qt, DB went back to normal by itself when I did that). The logs had absolutely nothing in them unusual, just the usual block activity and scan and nothing eyecatching during that time. Is there any way I can debug these?

Wireshark the data over the local socket, most likely the client is spamming the long poll callback request to the server.

[Searinox]

It happened two more times before I had a chance to get a hold of wireshark.

[dansmith]

Alternatively, does Armory 0.95 work with a pruned bitcoind node?

Came here to ask the same thing.
Being a developer myself, are there a lot of changes that have to be implemented in order to make it word with a pruned node?

[achow101]

Alternatively, does Armory 0.95 work with a pruned bitcoind node?

Came here to ask the same thing.
Being a developer myself, are there a lot of changes that have to be implemented in order to make it word with a pruned node?

Yes. Lots. Armory currently relies on reading the raw block data from Bitcoin Core and building its own databases that way. That would have to be replaced with an entirely P2P solution which would also probably lead to some optimization issues every time the database needed to be rebuilt.