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?
Topic: Armory 0.95 testing phase (Read 8539 times)
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?
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?
It happened two more times before I had a chance to get a hold of wireshark.
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.
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?
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.
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.
These were the last DB log entries:
OS: Windows 7 SP1 all updates.
Setup: Localhost default IP and port bitcoind, DB, and Qt.
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.
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?
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?
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.
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?
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.
Is it safe to connect ArmoryDB to a potentially untrusted bitcoind node? Or ArmoryQt to a potentially untrusted ArmoryDB server?
New testing builds are available at https://github.com/goatpig/BitcoinArmory/releases/tag/v0.94.99.1-testing. If you download the binaries, make sure that you verify them. The tag and the binaries are both signed with goatpig's offline signing key.
Green highlight is working for me. (Debian 8.6) Can't yet confirm whether send or receive work.
Wallet Properties view missing addresses is fixed since yesterday's commits also. All my wallets have their addresses displayed correctly, tested all the filters etc
Make sure that sending and receiving still work. Also, do you see the green highlight for addresses with balances? I don't.
Wallet Properties view missing addresses is fixed since yesterday's commits also. All my wallets have their addresses displayed correctly, tested all the filters etc
Yep, fixed. Only obvious bug in a quick perusal of the loaded GUI is the same Wallet Properties missing addresses issue (small number of total addresses used are displayed, and total addresses generated has, therefore, the same problem. Generating more isn't the issue, and shouldn't be anyway. Coin Control displays all addresses correctly, and balance displays are unaffected anywhere).
Do you mind hoping on the IRC channel to talk about that? (#bitcoin-armory on freenode)
Yep, fixed. Only obvious bug in a quick perusal of the loaded GUI is the same Wallet Properties missing addresses issue (small number of total addresses used are displayed, and total addresses generated has, therefore, the same problem. Generating more isn't the issue, and shouldn't be anyway. Coin Control displays all addresses correctly, and balance displays are unaffected anywhere).
Carlton Banks: your error should be fixed in testing, please pull and lmk.
Jump to: