 Show Posts
|
|
Pages: [1]
|
|
Seeing as 0.15.0 is out (ok, tagged) I was wondering if/when it would be safe to upgrade. Looking at the draft release notes, changes are extensive and go deep, so I wouldn't expect something as closely integrated as Armory to just work as-is, so I thought we might have a thread about it.
Note that this isn't meant to rush anybody, it's done when it's done! Usually I'd wait a good while anyway, but I'd like to show support for Core by upgrading ASAP.
|
|
|
|
I'm seeing it now on another wallet. Were you using P2PKH or P2SH addresses?
P2PKH. I didn't touch the address type defaults. |
|
|
|
I cannot reproduce this. Try to rescan your DB. Yep, that fixed it, thank you. Sorry for the noise. |
|
|
|
|
I'm new to Armory, so it's quite likely I'm mistaken, but the Wallet Properties of my OW (as seen from the online box) seem strange to me:
* It shows None in the category Addresses Used, even though there are multiple addresses that have received and sent -- doesn't get more used than that. The addresses in question are shown under Unused Addresses. They do have the correct Address Activity and balance in Address Information, and the total for Addresses Used is plausible.
* Tx Count is shown as 0 for any and all listed addresses, both in Wallet Properties and Address Information.
I could've sworn this used to work (in 0.96.1, at least).
|
|
|
|
|
How do you manage / keep track of your generated addresses in a hot + WO wallet setup?
Generating them on the cold side would be a bit safer, because assuming the hot side is compromised something could substitute the new address for one their own, causing you to give out the wrong address and thus lose any funds sent there.
However, the cold side does seem to keep track of some number of used addresses (how?), but naturally not the actual used addresses themselves. So you could copy & paste from its address pool, but if you're not careful you might end up reusing addresses.
Generate on the hot side, then visually check if they're on the cold side's unused list as well -- as cumbersome and error prone as that is?
A way to mark addressed used manually would help. I'd settle for the ability to comment on addresses (in wallet properties) that weren't officially "generated" by [Receive Bitcoins] yet. Maybe it's there and I just haven't found it yet ...
|
|
|
|
|
The Transaction info dialog [GUI, bottom panel, Transactions tab, context menu, View Details] shows "not in the blockchain yet" for all incoming transactions that arrived during the current session (even after 20+ confirmations). Confirmations and balance are all updated in real time, as expected. Restarting the GUI helps, then it gives me a block and tx #. Probably just the UI not updating.
(No anomalies for outgoing transactions, AFAICT.)
|
|
|
|
|
Ok, did some testing, fees be damned. Both wallets can send and receive BTC normally, so the priv keys are definitely there for both. I'm going to go with copies of ~/.armory for digital backups, so whether or not the GUI EDBs work and have the correct extension doesn't impact me, but I still think you should look at that, when you have the time, just to be safe.
|
|
|
|
The security column in the lobby's wallet list tells you if your wallet is WO or has private keys (Encrypted or Unencrypted). That's "Offline" for the watch-only wallet and "Encrypted" for the hot one, looks fine. [Encrypted digital backups] do not carry comments nor labels IIRC. Ok, so it's actually better to just copy the files in ~/.armory while it isn't running? Anything I'm missing? Show me armorylog.txt 2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1138 - C++ block utilities loaded successfully
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1255 -
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1256 -
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1257 -
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1258 - ************************************************************
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1259 - Invoked: E:\Armory\ArmoryQt.exe
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1260 - ************************************************************
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1261 - Loading Armory Engine:
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1262 - Armory Version : 0.96.1
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1263 - Armory Build: : b77932c8e3
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1264 - PyBtcWallet Version : 1.35
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1265 - Detected Operating system: Windows
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1266 - OS Variant : 7-6.1.7601-SP1-Multiprocessor Free
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1267 - User home-directory : D:\red\AppData\Roaming
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1268 - Satoshi BTC directory : D:\red\AppData\Roaming\Bitcoin\
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1269 - Armory home dir : D:\red\AppData\Roaming\Armory\
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1270 - Detected System Specs :
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1271 - Total Available RAM : 15.91 GB
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1272 - CPU ID string : Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1273 - Number of CPU cores : 4 cores
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1274 - System is 64-bit : True
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1275 - Preferred Encoding : cp1252
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1276 - Machine Arch : amd64
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1277 - Available HDD (ARM) : 140 GB
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1278 - Available HDD (BTC) : 0 GB
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1279 -
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1280 - Network Name: Main Network
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1281 - Satoshi Port: 8333
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1282 - Do wlt check: True
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1283 - Named options/arguments to armoryengine.py:
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - thread_count : -1
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - rescan : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - ignoreAllZC : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - rescanBalance : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - disableModules : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - port : None
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - interport : 8223
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - coverageOutputDir: None
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - forceWalletCheck: False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - regtest : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - rebuild : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - nettimeout : 2
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - datadir : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - clearMempool : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - offline : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - armoryDBDir : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - armorydb_port : 9001
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - satoshiPort : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - useTorSettings : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - netlog : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - keypool : 100
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - coverageInclude : None
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - forceOnline : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - redownload : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - rpcBindAddr : 127.0.0.1
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - armorydb_ip : 127.0.0.1
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - multisigFile : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - ram_usage : -1
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - mtdebug : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - logDisable : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - settingsPath : D:\red\AppData\Roaming\Armory\ArmorySettings.txt
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - language : en
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - db_type : DB_FULL
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - doDebug : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - enableDetSign : True
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - disableConfPermis: False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - testnet : False
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - rpcport : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - satoshiHome : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - satoshiRpcport : DEFAULT
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - logFile : D:\red\AppData\Roaming\Armory\ArmoryQt.exe.log.txt
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1285 - verbosity : None
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1286 - Other arguments:
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1289 - ************************************************************
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:1692 - C++ block utilities loaded successfully
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:3590 - Using settings file: D:\red\AppData\Roaming\Armory\ArmorySettings.txt
2017-08-04 10:56:15 (ERROR) -- ArmoryUtils.pyc:3747 - Unsupported language specified. Defaulting to English (en)
2017-08-04 10:56:15 (INFO) -- ArmoryUtils.pyc:3750 - Using Language: en
2017-08-04 10:56:15 (INFO) -- BDM.pyc:365 - Using the asynchronous/multi-threaded BlockDataManager.
2017-08-04 10:56:15 (INFO) -- BDM.pyc:366 - Blockchain operations will happen in the background.
2017-08-04 10:56:15 (INFO) -- BDM.pyc:367 - Devs: check TheBDM.getState() before asking for data.
2017-08-04 10:56:15 (INFO) -- BDM.pyc:368 - Registering addresses during rescans will queue them for
2017-08-04 10:56:15 (INFO) -- BDM.pyc:369 - inclusion after the current scan is completed.
2017-08-04 10:56:16 (INFO) -- ArmoryUtils.pyc:3590 - Using settings file: D:\red\AppData\Roaming\Armory\ArmorySettings.txt
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2050 - loadWalletsAndSettings
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2110 - Loading wallets...
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2175 - Number of wallets read in: 2
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2180 - Wallet (XXXXXXXXXX): "Online Wallet (*****) " (Encrypted)
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2180 - Wallet (YYYYYYYYYY): "Offline Wallet (*****) (W) " (No Encryption)
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:2185 - Loading Multisig Lockboxes
2017-08-04 10:56:16 (INFO) -- ArmoryQt.py:1752 - acquiring process mutex...
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1391 - setupUriRegistration
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1509 - URL-register action: AskUser
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:565 - Usermode: Expert
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1687 - Changing usermode:
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1688 - From: Expert
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1696 - To: Expert
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1825 - startBitcoindIfNecessary
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1895 - loadBlockchainIfNecessary
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-08-04 10:56:19 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-08-04 10:56:57 (INFO) -- ArmoryQt.py:1138 - Adding 27 keypress events to the entropy pool
2017-08-04 10:56:57 (INFO) -- ArmoryQt.py:1140 - Adding 5.5 kB bytes of filesystem data to the entropy pool
2017-08-04 10:56:57 (INFO) -- ArmoryQt.py:1142 - Adding 175.9 kB bytes from desktop screenshot to the entropy pool
2017-08-04 10:56:57 (INFO) -- PyBtcWallet.pyc:882 - ***Creating new deterministic wallet
2017-08-04 10:56:57 (INFO) -- PyBtcWallet.pyc:888 - (with encryption)
2017-08-04 10:56:57 (INFO) -- PyBtcWallet.pyc:890 - Target (time,RAM)=(0.250,33554432)
2017-08-04 10:56:58 (INFO) -- PyBtcWallet.pyc:957 - New wallet will be written to: D:\red\AppData\Roaming\Armory\armory_3fwvpcKR_.wallet
2017-08-04 10:57:02 (INFO) -- ArmoryQt.py:2842 - addWalletToApplication
2017-08-04 11:24:42 (INFO) -- ArmoryQt.py:4918 - New Block! : 478982
2017-08-04 11:24:42 (INFO) -- ArmoryQt.py:4926 - Current block number: 478982
That's launching armory and creating a new test wallet. And from ArmoryDB's POV: -INFO - 10:56:39: (BDM_Server.cpp:1074) registered bdv: 540932974008305bb3ee
-INFO - 10:57:23: (BDM_supportClasses.cpp:378) Starting address registration process
-WARN - 10:57:23: (BDM_supportClasses.cpp:224) Updating ssh last scanned
-INFO - 10:57:23: (BlockchainScanner.cpp:665) scanned from height #478981 to #478981
-INFO - 10:57:23: (BDM_supportClasses.cpp:497) Completed scan of wallet 3fwvpcKR
-INFO - 11:25:02: (BlockchainScanner.cpp:665) scanned from height #478982 to #478982
|
|
|
|
There's an option to delete the private keys in a wallet. I certainly didn't use that. To make doubly sure it's not PEBKAC, I just created a new testwallet and made an EDB when prompted -- still gives me a .rootpubkey file (though I've no idea if it's the file contents that are off or just the extension, of course). I couldn't have deleted anything by that point if I tried. (That's v0.96.1 official binaries on Windows, BTW). Regardless of my reply, you should just test the backups to make sure. At this point it could be one of three things: 1) The actual wallets don't have their priv keys. 2) The priv keys get stripped from the backup. 3) The backup gets assigned the wrong extension. Is there any way to test which it is, without moving small amounts of BTC back and forth? Can you reproduce it at all? Also, should the EDBs be bit-identical to their live wallets or is that just a red herring? P.S.: Small buglet: after creating a new wallet, ArmoryDB logs "(BDM_supportClasses.cpp:497) Completed scan of wallet XXXXXXXX" pretty soonish, but GUI shows "Scanning: 0%" in the balance column until restart. |
|
|
|
"Encrypted digital backup" is just a copy of your wallet file. Hmm, the "encrypted digital backup" is not bit-identical to the live wallet file in ~/.armory, at least, only the same size (tested on both installations). If I make multiple EDBs in succession those are bit-identical to each other. (?) If the file has no pub keys, you're gonna end up with a copy of a WO, hence the .rootpubkey thing. Now I'm really confused ...  Aside from the fact that "copy of WO" and ".rootpubkey" sounds more like it has no priv keys ... -- why/when would that be the case and is it normal for a new wallet? P.S.: The different extensions for Linux and Windows EDBs might just be cosmetic: The Linux file picker has .wallet as default extension for new backups but filters for "Root Pubkey Text Files" (so doesn't show old backups in the same folder), Windows has .rootpubkey for both. Could be a case of an extension not consistently changed. So I guess the question becomes, are my wallets and EDBs fine, even though they're not identical and "have no pub keys"? You can't, the ID computation is different. The extra you got is a left over. Ok, so delete all three, two will regenerate. Voight-Kampff test for timelords. Gotcha. |
|
|
|
|
Sorry in advance for being such a newb, alas, my Google-fu has failed me ...
datadir holds, among other things (correct me, if I'm wrong):
- one armory_XXXXXXXXX_.wallet file (main) and one armory_XXXXXXXXX_backup.wallet file (duplicate) per wallet, with XXXXXXXXX being the wallet ID; this is the legacy wallet format
- armory_YYYYYYYYY_wallet.lmdb file and armory_YYYYYYYYY_wallet.lmdb-lock files; this is the new LMDB-based walled format (incl. file-based lock)
1) encrypted digital backups result in one *.wallet file (on Linux) but one *.wallet.rootpubkey file (on Windows). Why the different suffixes? Is the content of these backups the same (rootpubkey sounds suspiciously like it might be missing the private key)?
2) Can the LMDB wallet be regenerated at will or should it be backed up as well? What kind of information does it (not) contain, compared to the legacy wallet, how sensitive is it privacy/security-wise?
3) How can I tell which legacy wallet corresponds to which LMDB one, seeing as the 9-char-IDs are all different? For whatever reason I have 3 sets of .lmdb* files for 2 active wallets (1 online, 1 offline, in case it matters) -- normal, or left-over stale data from a past wallet-creation experiment?
4) On Linux there's a file called "~/.wallet", even though datadir is default ~/.armory, that I did not, to my knowledge, create manually. Any idea how it could've gotten there? User error is most likely, but if there's a chance Armory writes wallets outside of its datadir, I'd like to know.
|
|
|
|
|
I certainly didn't mean to complain, sorry if it sounded that way. FWIW, I'm really happy with the direction Armory is going and the pace it's going there is incredible, especially for a one-man show.
|
|
|
|
|
I suppose the same rationale goes for the local copy of crypto++? I'm a bit weary of whole projects of source copied in verbatim in general -- it tends to either remain in the initial imported state forever or drain resources from the importing project (which has just one man, as it stands). Case in point, even Debian stable looks to have a newer version.
A couple of observations / buglets:
* build docs: add pkg-config and rsync, remove python-twisted as build-deps
The build process is a bit byzantine, why does it need rsync at all and why is there so much code being built during make install ...
* pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)?
* pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?
|
|
|
|
|
Thank you for --without-gui! That gets rid of all the QT and Python deps in one fell swoop.
And since you're already fiddling with the build system, how about --without-online to build just the GUI part, for offline systems? ^^ That'd probably also make it easier to keep supporting older systems for offline-only use.
Oh, and why do you maintain your own version of libfcgi? Is it just build fixes or is there more? Since libfcgi is pulled in as a submodule after the fact it presumably isn't covered by the main repos signature checks, so if it works I'd rather install libfcgi-dev and be done with it.
|
|
|
|
|
Thank you for the comprehensive answer!
Just wanted to report back and say that the setup seems to be running fine now.
FWIW, a bare Debian VM running just bitcoind in listen=0-mode and ArmoryDB uses (w/o buffers and cache) a tad over 1 GB RAM plus ~200 MB swap in normal operation, so 2 GB should be plenty. That's without touching any of the RAM tunables. For the initial build of Armory's DB I had it at 3 GB, no issues. Then again, I haven't actually done much with it yet, just let it run for a few days, to see if it was stable.
One thing I still don't get is FCGI. Setting up a web server/proxy, even a very lightweight one, seems to me a very heavy-handed solution to the problem of getting two pieces of software on different machines to talk to one another. That on its own doesn't even handle security, you'd need to set up SSL with self-signed certificates or something. For the time being I just tunnel the hardcoded port over ssh, works like a charm.
|
|
|
|
|
In a nutshell, I'd like to run as much as possible of the "Armory stack" in a Linux VM on a server, while keeping the GUI on a Windows desktop.
1) It looks like running bitcoind, ArmoryDB, a minimal web server and Tor in the VM, armory-qt on Windows should do the trick, correct?
2) What would the system requirements for such a VM be? I have lots of reliable storage, but RAM is at a premium.
3) How picky is this about versions -- do I have to keep the DB and GUI in lockstep or ...?
4) In this configuration, the VM would not hold any sensitive data, correct?
5) How'd I set up bitcoind, ArmoryDB and armory-qt if I didn't want incoming connections at all and outgoing ones via Tor only?
|
|
|
|
|
