2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2789 - ***WARNING: Duplicate wallet detected, 2i9jR2jWX
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2799 - Second wallet is more useful than the first one...
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2800 - Wallet 1 (skipped): /Users/James/Library/Application Support/Armory/armory_2i9jR2jWX__02.wallet
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2801 - Wallet 2 (loaded): /Users/James/Library/Application Support/Armory/armory_2i9jR2jWX_.wallet
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2789 - ***WARNING: Duplicate wallet detected, 2i9jR2jWX
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2799 - Second wallet is more useful than the first one...
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2800 - Wallet 1 (skipped): /Users/James/Library/Application Support/Armory/armory_2i9jR2jWX_encrypt.wallet
2016-10-08 19:10 (WARNING) -- ArmoryQt.py:2801 - Wallet 2 (loaded): /Users/James/Library/Application Support/Armory/armory_2i9jR2jWX_.wallet
2016-10-08 19:10 (INFO) -- ArmoryQt.py:2822 - Number of wallets read in: 1
Clearly there are 3 copies of that wallet file in your datadir, and Armory is prioritizing one of them. |
|
|
|
So, if I intend to use manual IP:port I'm going to have to forward ArmoryDB traffic through a FastCGI webserver?
The FCGI layer ip:port are hardcoded. You would have to set them to your desired value in your own builds if you want to stick to that interface. |
|
|
|
Yes, ADB is running and fine. If I remove the --armorydb-ip and --armorydb-port commands it connects just fine(ADB is running on the local machine so Qt's default connect settings work) but when I try to specify IP:port, even the local default ones, it throws an error and puts that in the log.
DB API is built around the FCGI lib. This is a webstack layer meant for http daemons to tunnel data to child processes (think PHP behind a httpd instance). Of course it is unrealistic to expect the average user to run a http daemon along side Armory just to use it locally, nor is it acceptable to automatically run one for them. Instead this is split down in 2 operation modes: when the client is using the default IP and port, it will try to speak to the DB using the FCGI protocol. When the IP and/or port is set manually, it expect the DB to sit behind an http daemon and will swap to pure HTTP. |
|
|
|
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. |
|
|
|
|
All back to normal, unsticking this
|
|
|
|
http://pastebin.com/itk6PMzA-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Got a message from Google today indicating someone tried to log into my 2 Google accounts using the respective correct passwords.
Google blocked them. The offender used my IP both times, indicating this is either a false positive, or some malware on my machine.
I'm recycling passwords amd going my machine for now. Do not trust my unsigned messages on the forums until I post otherwise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWUYCVAAoJEIxSEXZJIliacuUP/1VOH9Jwi7CAIGZfWWuw08nz
HkM/kJSS77t8kXnf4Iu9Aui22cZVITlHeXrwgTn3F6+owms3Vd554ipvZg3Jsw2Y
tELoVV76kWaLLpPZ9ohH9VTFJyi9FcClBKAVFXHeA0cEdk6kUrbhoXzHS97hvTaN
Rq83Vk2Hg0XFL7IkY4GKDTMwzrfL6oTeLjyBax9K2jq+7BdVzcMn3YB54Pns24Ha
3a0oFRUWOHtTM4cJARLusJBSmasrk1OVdr01+s7lzOLKqTS2r06lLC6I/vXUEqkU
66D0JcUOujzGXJZ2vxR4lFS//telAnhY+EoZR64lUvKKiA1gUoVl6qrAnRPEkGWZ
i2XkHYuwZ9TM47dygt5trGyHdqtajz4HKizCE+iH3D/2iIkmirJu4rv8WIARg5WI
F4PRAqPi+sMAlwvHWcH73DWq0WO2lYyaxHbSLvVSa0+0j0XkaVx+Gv0dm9KzBpO9
BD6z2jN1K4M+HUnbjbkXJOM846wNqT9lV7/RdB57GcucPo8tXo4aJ9T/oVlBY671
D8cf8Wia/BxzyHUhdpSnAhr90AZ7VNxJkHfyLu92GKMJtI9pVXsgnY0ZxEwwXFyY
yOQ0Os41VPAsRDC/ZWfRyriV9tk9tfY9ZoBnd2nL/IF0Nr0kYrv3bt+W4y4/4Kq0
KI4nH2vn5Yn3nqRRmKwo
=3m6a
-----END PGP SIGNATURE-----
It's all in the pastebin. Bottom line, don't trust stuff I post until the next signed message. This is most likely a false positive but I'd rather err on the safe side. Will post new testing builds after this is resolved.
|
|
|
|
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) |
|
|
|
|
You are running your node in testnet and Armory in mainnet, not gonna work. If you want to spend your coins, you need to synchronize your node against the mainnet.
If you just want to test things around, run Armory with the --testnet argument against your current node.
|
|
|
|
|
Carlton Banks: your error should be fixed in testing, please pull and lmk.
|
|
|
|
2016-09-27 18:18 (INFO) -- ArmoryUtils.pyc:1212 - Available HDD (ARM) : 0 GB
2016-09-27 18:18 (INFO) -- ArmoryUtils.pyc:1213 - Available HDD (BTC) : 0 GB
Full hdd, you need to move the blockchain data elsewhere. |
|
|
|
Here's a something from ArmoryLog.txt referring to a registerWallet function: 016-09-27 23:25 (INFO) -- ArmoryQt.py:2307 - Setting netmode: 1
2016-09-27 23:25 (ERROR) -- Traceback (most recent call last):
File "./ArmoryQt.py", line 6637, in method_signal
method()
File "./ArmoryQt.py", line 6689, in completeBlockchainProcessingInitialization
self.setupBDV()
File "./ArmoryQt.py", line 6655, in setupBDV
self.walletMap[wltId].registerWallet()
File "/home/user/BitcoinArmory/armoryengine/PyBtcWallet.py", line 284, in registerWallet
self.cppWallet = TheBDM.registerWallet(prefixedKeys, self.uniqueIDB58, isNew)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 116, in inner
return func(*newArgs, **kwargs)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 246, in registerWallet
return self.bdv().registerWallet(uniqueIDB58, prefixedKeys, isNew)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1417, in registerWallet
def registerWallet(self, *args): return _CppBlockUtils.BlockDataViewer_registerWallet(self, *args)
RuntimeError: data is too large for fcgi packet
apparently the one wallet is so large it created a serialized packet over the per packet 64kB limit. Will fix it at some point. |
|
|
|
|
Means I botched the auto path on Debian where it looks for the DB in /usr/lib instead of /usr/bin... ugh!
PS: apparently I botched the Windows installer too, will come out with a new build sometimes today or tomorrow.
|
|
|
|
|
Moved 0.95 to the testing branch, dev is now for 0.96 development, and won't be stable for a while.
|
|
|
|
Time has come once again, calling on testers for the final testing phase of 0.95 You can get the release and signed hashes here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.94.99.testingA new addition to this release, the git tag is signed as well with my offline key. You can see the list of changes here: https://github.com/goatpig/BitcoinArmory/blob/testing/changelog.txtCode is staged in the testing branch. Notable points: No OSX builds yet, sometimes next week most likely. DB format is different from 0.94, you will have to use a fresh folder. I'm getting late reports that zero confirmation tx don't always display in the ledger, this needs eyes on. Also the fee per byte and coin control needs tested thoroughly. Enjoy, and thanks for your effort. |
|
|
|
|
Empty your db folder, try again.
|
|
|
|
Alright, I will try that instead but I noticed on your website ( https://www.bitcoinarmory.com/using-armory-python/ ) you have: "Note that, unless you have built the Armory databases with the –supernode option, Armory will automatically initiate a rescan if there are any addresses in the wallet not there in previous loads" does this still hold? That's information that holds true for 0.93, the latest version ATI supports. This project is a fork of ATI's work, and 0.94 then 0.95 come with nuances to that old statement. Notably in your case, 0.95 will not rescan. 0.95 keeps constant record of any addresses you show it, as opposed to previous versions that only keep up to date with addresses they are loaded with. This change is due to the database being it's own binary starting 0.95, which means it isn't necessarily loaded with any wallet data at init. In order to prevent constant rescanning from detached db inits, the db address list is now append only. In your case it simply means it fixes your issue 100% |
|
|
|
@unamis76 running bitcoin core GUI works just fine and syncs completely. I think armory expects defaults when running bitcoinCore manually.?
You have to set paths using command line arguments. What OS do you use? |
|
|
|
Hi Goatpig
As promised I familiarized myself with the architecture, and I am just wondering if there is a way then to speed up the
time it takes to do a fresh scan?
Currently it takes close to an hour.
Thank you for your help.
0.95 will fix your issue 100%. You should help testing with that. |
|
|
|
|
Delete the content of your databases folder in the Armory datadir and try again.
|
|
|
|
Let me see armorycpp.log from the 0.94 computer. Also, delete the Core db and the Armory db on the 0.94 machine. Copy the blockchain over from the 0.93 machine and sync off of that. I now checked the box again and let Armory manage bitcoinCore. I began to build the database again but I can't see any changes happening in the database dir... It's building the db or sync core? You have some path issues I'm guessing |
|
|
|
|
Show Posts
