Thanks for the quick reply, goatpig. I might as well go all the way and upgrade both. What's an M-of-N feature BTW? I haven't seen that term/acronym on the website.
One of the new backup feature: constructs a wallet backup made of N fragments, which can be a mix of paper and digital backups. Requires M (M<=N) fragments to recompose the wallet. Currently M spans from 2 to 8 and N from 2 to 12. |
|
|
|
I've had 0.88.1-beta on my online machine (W7 x64) and an even much earlier version offline (W7 x86). The pair has been very stable but I feel the need to get with the times and upgrade to the current 0.90-beta version. Should I also upgrade the offline Armory to 0.90-beta just to be consistent if nothing else? Furthermore, do I need to uninstall the older versions first before upgrading or just install and upgrade over them?
Just run the installer when Armory isn't running. You'll eventually get to a point where the new features available will justify the need to upgrade your offline Armory version (let's say you want to use M-of-N for your back ups). You shouldn't run into a compatibility issue, using an ancient version of Armory to sign plain transactions emitted with 0.90. |
|
|
|
|
It's possible you ran into a nē computation issue rather than actual corruption. If it happens next time, give it 30 minutes and see if it completes.
As for the scanning, how many wallets do you use at the same time and do you use imported private keys? These could be the cause of the multiple transaction scans.
|
|
|
|
Thank you for your reply.
I believe I understand the current wallet, more or less. My workflow is acceptable, I can wait for some time for BIP32 support.
Will BIP32 be among the next features after the current big changes (memory and "internals"), or is it further down the list? Is it winter/spring, or "probably 2014"?
Yes, I am asking way too long into the future: Any guess if Armory/BIP32 will have several "wallets" from one seed?
Thanks a lot!
Ente
Frankly I'm not sure where BIP32 is on todo list currently. What I know is that we won't be delving into that until the new wallet file format is out. Any guess if Armory/BIP32 will have several "wallets" from one seed? If you mean creating unrelated children seeds from a common root key, as BIP32 specifies, what I can tell you is we don't have a reason to deviate from BIP32 specification for now. As for possible "Armory flavored" features we may add on top of BIP32 wallets, can't tell just yet. |
|
|
|
Kerogore, Is Armory crashing every time you type in your password? We have a known wallet corruption problem, but it's easy to fix if you have a backup. If not we, can also perform a recovery of the wallet file, which is usually successful. See the following page for more info ("Armory crashes every time I type in my password"): https://bitcoinarmory.com/download/troubleshooting/I installed 90.-beta version and encrypted wallet, after that was not able send any bitcoin armory client crash, I unencrypted wallet and try it again, 90.-beta crash again, i re-installed version 89.14-beta was able send bitcoin, I encrypted wallet again and after thad armory crash (89.14-beta) when I try send bitcoin, I unencrypted wallet and now was able send it again, I dont know what to do now. Can wallet by corrupted to the point then i will not able recovery private key or print copy of offline wallet ? Was Armory crashing (as in closes on its own) or hanging (stopped responding but didn't close itself)? If you can access your wallet I strongly suggest you create a paper backup for now. You can then write down your experience (with as much details as possible) to contact@bitcoinarmory.com |
|
|
|
|
Armory doesn't support BIP32 yet. With that in mind I can answer a few of your questions based on the current version of Armory wallets:
1) For now there's coin control to keep your change addresses in check. Besides that point, can't really talk about something we haven't implemented yet ^_^;;
2) Armory private and public keys are derived from their previous iteration. Private key X is derived from private key X-1 and is used to build private key X+1. This is done through modulo operations and injecting extra entropy, so you cannot go from address X to address X-1, or X-n for that matter. No amount of leaked private keys can reveal an Armory root key.
Same goes with public keys. However, any private key can reveal all private keys beyond it: Since X gives X+1, then X can give X+n.
3) The chain code (root public key) isn't encrypted. I think Alan mentioned something about implementing a separate password to encrypt the public key and address comments in the wallet files. You'd have to confirm with him.
4) Assuming we implement that, 3) should answer it.
|
|
|
|
I had been eagerly awaiting the new version, thinking that it wouldn't bog down my computer like the old one did, but it still seems to be doing that. Granted, I only have 5 GB of RAM, which is why I essentially stopped using Armory for a while, but in theory that wasn't supposed to be an issue any more.
Is this just something that happens the first time it's loaded in a while, or is even a computer with 5 GB of RAM too slow to properly use Armory? I waited until it finished building databases, but since I'm going to sleep soon and didn't want to wait another hour, I didn't wait to see how it'd behave after it finishes scanning transaction history.
The first time that new version starts (0.89+), it has to build its database. This is a heavy process. Once it is past that point, restarting Armory should take less than a minute + whatever time it'll take BitcoinQt to sync with the network (at this point the time it take to scan the new blocks is obsolete). |
|
|
|
|
Logs do not contain informations about your private keys.
|
|
|
|
I created a new wallet on my offline computer and printed a 5 of 6 backup. I then deleted the wallet and restored from the printed backups. There where no problems and the addresses that I created were the same as before. Are you saying that I have missed something and that I should not rely on that paper wallet for my small-country-sized-savings?
Let me put it to you from our perspective. Recently we are getting a wave a new users who download Armory, shove their coins into it and then figure out they don't know how to use it, then spam us with emails like "help me please". As with any new feature relating to wallets, please be sure to test it extensively, get familiar with the feature and acquire a solid understanding of how to use it before resorting to hold your funds with it. While the testing phase on the M-of-N backups is satisfactory, even knowing that it'll be part of the next release, do not forget that the current builds are, as the name says, for testing purpose. I hope this clarifies the point. |
|
|
|
Yes, but the quoted statement from etotheipi suggested the possibility that the fragmented-backup format might yet change between testing version and release version. That ambiguity hasn't been removed by a clear statement, although it seems unlikely that the format is going to change given how close we are to release of a new non-testing version.
I think he was making reference to the new paper backup format, exporting only the root key instead of root key + chaincode. M of N backups were not available to public at the time of that post, if memory serves right. Regardless, the current M of N backups are only available as part of test builds, you're better off waiting for a release build before shoving the GDP of Zimbabwe into one of those babies =P. You're welcome to abuse them with cheap change or testnet coins, however. |
|
|
|
I'm just not 100% confident that the backups will be the same as the final version. I know it creates a frustrating dynamic, because I need people to help test the backups, but I have to tell them not to rely on them yet.
When will you decide this? I would love to use the m-of-n paper backup. Have you decided this now? M-of-N backups are available in the current testing release |
|
|
|
Are the instances of DB corruptions on Windows caused by the same problems occuring on the OSX builds?
About which Windows corruptions are you talking about? Dia Not sure under which criterion this corruption falls. About a week ago I try to start Bitcoin-Qt to no avail. Had to delete the DB folder to get Qt to start, which resulted in a full redownload and verification of the blockchain. |
|
|
|
|
Are the instances of DB corruptions on Windows caused by the same problems occuring on the OSX builds?
|
|
|
|
Affecting Armory in OSX you mean? We run on a in house port of LevelDB in Windows built with MSVS whereas Bitcoin-Qt is built using MinGW and Boost (if memory servers me right). I've personnally ran in the LevelDB corruption with BitcoinQt, but I haven't seen any Amory bug claims that would pertain to this issue. If the issue is trully fsync, then there is a simple fix for it. Although it seems the suspicion has shifted to atomics. |
|
|
|
parser.add_option("--settings", dest="settingsPath",default='DEFAULT', type="str", help="load Armory with a specific settings file")
parser.add_option("--datadir", dest="datadir", default='DEFAULT', type="str", help="Change the directory that Armory calls home")
parser.add_option("--satoshi-datadir", dest="satoshiHome", default='DEFAULT', type='str', help="The Bitcoin-Qt/bitcoind home directory")
parser.add_option("--satoshi-port", dest="satoshiPort", default='DEFAULT', type="str", help="For Bitcoin-Qt instances operating on a non-standard port")
parser.add_option("--dbdir", dest="leveldbDir", default='DEFAULT', type='str', help="Location to store blocks database (defaults to --datadir)")
parser.add_option("--rpcport", dest="rpcport", default='DEFAULT', type="str", help="RPC port for running armoryd.py")
parser.add_option("--testnet", dest="testnet", default=False, action="store_true", help="Use the testnet protocol")
parser.add_option("--offline", dest="offline", default=False, action="store_true", help="Force Armory to run in offline mode")
parser.add_option("--nettimeout", dest="nettimeout", default=2, type="int", help="Timeout for detecting internet connection at startup")
parser.add_option("--interport", dest="interport", default=-1, type="int", help="Port for inter-process communication between Armory instances")
parser.add_option("--debug", dest="doDebug", default=False, action="store_true", help="Increase amount of debugging output")
parser.add_option("--nologging", dest="logDisable", default=False, action="store_true", help="Disable all logging")
parser.add_option("--netlog", dest="netlog", default=False, action="store_true", help="Log networking messages sent and received by Armory")
parser.add_option("--logfile", dest="logFile", default='DEFAULT', type='str', help="Specify a non-default location to send logging information")
parser.add_option("--mtdebug", dest="mtdebug", default=False, action="store_true", help="Log multi-threaded call sequences")
parser.add_option("--skip-online-check", dest="forceOnline", default=False, action="store_true", help="Go into online mode, even if internet connection isn't detected")
parser.add_option("--skip-version-check", dest="skipVerCheck", default=False, action="store_true", help="Do not contact bitcoinarmory.com to check for new versions")
parser.add_option("--keypool", dest="keypool", default=100, type="int", help="Default number of addresses to lookahead in Armory wallets")
parser.add_option("--rebuild", dest="rebuild", default=False, action="store_true", help="Rebuild blockchain database and rescan")
parser.add_option("--rescan", dest="rescan", default=False, action="store_true", help="Rescan existing blockchain DB")
parser.add_option("--maxfiles", dest="maxOpenFiles",default=0, type="int", help="Set maximum allowed open files for LevelDB databases")
List of Armory switches, as seen in the source. I am currently working on unicode support in Windows and the 'dir' arguments work just fine. |
|
|
|
You must not be doing the symlinks correctly. It's probably best to avoid that, just use the satoshidir and datadir switches.
Definitely this. Try with the command line arguments (make a shortcut if you have to) and let us know. |
|
|
|
That may be a bug in the new coin control module.
This is what I was dreading  Could the Armory developers confirm this either way? Thanks for your replies guys  We're gonna have to try and reproduce this situation on our side. Submit a ticket to support@bitcoinarmory.com |
|
|
|
Ok, so now I'm kinda concerned with Armory as it appears to have transferred my BTC to another address. I have a watching only wallet on an offline computer which holds the address where the BTC are delivered. I sent some BTC using the offline computer to sign the transaction but back on the online computer I have two extra addresses marked as 'change received' after I made the transaction. The problem is that the majority of my remaining funds has been moved from the original BTC address into the 'changed received' account. Where the hell are the private keys for these two extra addresses?  I have no private keys for these two extra accounts as I have not created them - armory has taken this upon itself. How the hell am I going to get the money back where it should be in the original BTC address. What the hell is going on here Armory wallets are deterministic. The private keys are derived from a unique root. Keep clicking receive coins on your offline computer, it'll keep generating new addresses until it eventually hits the ones you have marked as "change address" on the online watch only counterpart of the wallet |
|
|
|
I recently upgraded from the 0.88 stable to version 0.89.99.14-beta on Windows 7 64-bit.
Looks like the new version created the '%userdir%\AppData\Roaming\Armory\databases\leveldb_blkdata' directory, which now is larger than the original blockchain dir. What's the point in using double the HD space?
So it doesn't have to hold the full blockchain in the ram. This is a "full implementation", intended for full nodes. This path was opted to reduce overhaul time and limit the code base to debug. There are plans for a lighter version of the DB now that this new code is solid. |
|
|
|
|
Show Posts
