Quote from: Searinox on October 09, 2016, 03:56:35 PM

Quote from: achow101 on October 09, 2016, 02:23:23 PM

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.

Quote

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.