While i know the risks of using Beta software i just want to be sure of something. Having a paper backup makes me safe from any Armory/wallet problems/bugs/disasters right? Also please tell me how paper wallets work. If i make a paper backup of an encrypted wallet will it require the password when importing the backup or not? I can't go into technical details exactly about how the paper backup works (for time reasons). The gist of it is that the wallet derives all its private keys in a deterministic (and secure!) manner from a seed. That seed is what's on the paper backup: root key (and chaincode on wallets created with 0.88.1 and earlier). That seed can be used to generate trillions of addresses. You'll get the same trillion addresses the next time you restore from that seed. The seed is all that matters. So yes, you are totally protected from your coins being lost due to fire, HDD failure, and forgetting your password. You do not need your password to use your paper backup. That's by design: 95% of coin loss I've seen is due to forgetting your password and not having a paper backup. The "risk of losing coins" is that perhaps Armory computes an address incorrectly and you send money to the wrong address. Maybe one that can't be recovered by anyone. I've never seen such a bug in Armory in its two-year history, but other people have done this with other apps and custom scripts. |
|
|
|
I freshly installed Armory, created a new wallet while it was downloading the blocks, and haven't quit it since. It's still scanning.
Just to be clear, when Armory starts up is using auto-bitcoind, it does the following: (1) Starts bitcoind, requests its sync state (2) Waits for bitcoind to finished downloading the 15GB blockchain (3) Builds/updates the Armory databases from the 15GB of blk*.dat files produced by bitcoind (4) Checks the stored address histories in the DB and compares against wallet addresses (4a) If there are no addresses needing to be rescanned, it simply loads the histories (4b) If the histories are incomplete, or you had an unclean shutdown (histories were never written to DB) -- rescans the full Armory databases (5) Switches the interface to "online mode" and displays the tx history. If your bitcoin-qt/bitcoind is already synchronized, then step #2 is minimal effort. Otherwise it can take 4-48 hours depending on your connection (but you know that part). If you have not run Armory before, it will have to build the databases from scratch the first time in #3, which will take 30-120 minutes (on most systems). If the DB is already built, it only updates the latest blocks (like 10 sec). Step #4 either takes 5 sec (if already sync'd), or 10-30 minutes if it needs a full rescan. This step will get much faster on the next release. If you did not add any addresses, or you did but they were part of a new wallet, then it should only have to do step #4 once. After that, it will startup in like 30 sec. If you see alternative behavior, it's probably a bug. *The one exception to all of the above is the occasional DB corruption where it automatically detects and rebuilds. Yes, annoying. But I don't have any other way until I reduce the DB corruption events. |
|
|
|
I'm not sure if this counts as a bug, but when I loaded up armory, it had to download the last 3% of the blockchain, then go through building the database, but now its scanning the blockchain. The problem is, the only wallet has 0 addresses and was freshly created. So now I'm stuck waiting while it scans for nothing.
If there's zero addresses/wallets, it should skip the scan. If it's a newly created wallet, the addresses should be marked "new" and not induce a rescan. However, it will always rescan on an unclean shutdown. It's a long story. I'd rather that inconvenience occur than have corrupted balances/history and the confusion that follows. However, it's probably robust enough to not require a rescan on unclean shutdown, I just haven't tried yet. |
|
|
|
Anyway a lot of the heavy weights are in this thread. I would have thought that generating private keys manually might be termed a little extreme.
Depends on your definition of cost-to-benefit ratio: Cost: Spending 20 minutes, one time, to create entropy and convert it to a wallet Benefit: Avoiding 100% of all BS regarding computer-generated entropy sources & algorithms, until the end of time If you're holding a "lot" of money, some people would rather just remove all doubt. And the cost of doing so really isn't that high. |
|
|
|
Ok, so this isnt a bug, but a suggestion. The percentage complete when downLoading the blocks is really only helpful on the first download. When i boot up Armory and it says 99% 10 minutes remaining, that doesnt tell me much. Maybe the percentage could be percentage complete since the beginning of the download, or you could include how many blocks behind the client is.
Heh, ironic you mention that. Because not long ago I had it the way you just mentioned, and people were pissed off that it looked like the whole thing was starting over from scratch. Especially when they interrupted the initial DB build and restarted it. I changed it from what you just requested, due to popular demand  Admittedly, maybe I can change the behavior when you're mostly synchronized already, versus in the middle of the huge DB build operation... |
|
|
|
I have got still problem with no ascii, national characters(like ążźć) in label of address.
Ack, I was just about to add that to the list of off-limit topics. I'm well aware of Armory's unicode issues, and fixing that is in my plans for the next release after this one. Since it wasn't on the list, I'll give you the bounty for it. Your (?) tool tips require you to click, hold and drag the mouse off the tool tip to keep it displaying else as soon as you just click it disappears.
This behaves differently in each OS. I haven't yet figured out how to make this consistent and friendly. Still better than the mouse-over-hold-wait-display, which some users didn't figure out. Again, something else I meant to post as already-known, but I'm not going to be stingy about it. You tested the interface and found a usability issue. One bounty for you! Here's a bug I've found since the last stable version, I've tried this on 0.89.99.10-beta and 0.89.99.14-beta and I've done a couple rescans too. It seems for me the transactions tab does not populate until it receives a new block after it has finished loading. It pretty much seems to stay like and looks like it is broken until I left it running for a while and then suddenly all the transactions in the window appears, everything else seems to work fine though. This only seemed to happen the first time it was run so, it might be that everything is catching up the first time and it is taking a really long time to reorganise itself. It does report errors in the log though so here they are.
Okay, so I haven't heard of this bug in a long time. I thought it only happened when you have a corrupt wallet in your list. If you isolate it better, I got a bounty for you! What OS? Can you try making a copy of the ARMORY_HOME_DIR (if you have the space for it), then remove the wallets, and run Armory with " --datadir=/new/directory/path". Create a single new wallet, then restart and let it sync again. I need to know if it goes away. If so, then there's an issue with one of the wallets and I'll dig further. |
|
|
|
Is it BIP32 compliant?
Negative. That's a whole different overhaul, and it would be a total mess to do that overhaul at the same time as this one. After this release will be a bug-fix and polishing release (like fixing unicode issues, and re-optimizing the database engine). Then, I'll finish the new wallet format (which is like 75% done already), and that will come with support for BIP 32, compressed public keys, and all the hooks for adding multi-sig. |
|
|
|
OSX errors: frustrating I might not be able to claim 10.9 support yet. I think I have to limit it (and bug bounties) to 10.8.
The print issue predates Mavericks, I can replicate it on 10.8 in both the latest stable and the latest beta. I completely understand your reluctance to support 10.9, it's foreign territory especially as you're not a native developer. Oh, that's right... I do remember having to do some special stuff on OSX with the print dialog. But I seem to remember that it was fixed with the OSX-specific code... I guess not? |
|
|
|
|
@whault:
OSX errors: frustrating I might not be able to claim 10.9 support yet. I think I have to limit it (and bug bounties) to 10.8.
EC & Key Calculators: Ack! The Key calculator was meant to be gone, and I normally would've specified that it's off-limits for bug bounties. But I'll give you a bounty for it, because it is a bug that it's still there! I need to remove it.
I will update the top post to specify that both key calculator and EC calculator are off-limits for bug bounties, and key calc will be removed.
|
|
|
|
OSX 10.9, general feeling is that the app is not ready for prime-time. Almost constant crashes, for which I only know a couple of the triggers.
Can you please run from the terminal and confirm that the printed error messages look like this: modalSession has been exited prematurely - check for a reentrant call to endModalSession
From the terminal, you can just "cd /Applications; open Armory.app" |
|
|
|
Here's a list of things that are already known that do not qualify for a bounty: - Yes, Armory requires having the whole blockchain. Yes, it requires running Bitcoin-Qt in the background. Yes, sometimes it's difficult to point Armory to the correct bitcoind location. Yes, Armory now duplicates the blockchain data (will be reduced in the next version...this way was simpler for the overhaul). Most reports related to general setup will be unrewarded.
- Bugs in online mode must be reported after a full synchronization. I don't need help finding synchronization/setup bugs (I get plenty of emails). All bugs assume you are in either in offline mode or fully sync'd in online mode.
- I know the auto-install bitcoind buttons don't work
- The app initiates a rescan on unclean shutdown. Yeah, it's kinda slow on mainnet. Shutdown cleanly as much as possible
- Fee calculations. Max tx size. Min tx value. I know they're outdated. I will fix them soon.
- The new version is not very usable on OSX 10.9. I can only accept bugs for 10.8 and lower. If you run in 10.9, compare your error messages to this before reporting. These are actually Apple+PyQt bugs, not mine.
- In some Linux distros/environments, URI-handling is broken. I can tell you how to fix it if needed. Should work in Ubuntu+Unity, as well as all Windows verisons.
- WinXP support is hosed. Goatpig is trying to figure that one out...
- Occasionally the DB gets corrupted and automatically rebuilds. It takes a while. And may be inconsistent. Yeah, it sucks.
- Key Calculator and EC Calculator are both off-limits. Key calc was meant to be removed, and EC calc is both only for expert users and not very maintained (though it technically works if you have the screen space for it).
I will not be maintaining this list for every reported bug. You may have to read subsequent posts to find out what's been reported. Or just post your bug and I'll tell you if I fixed it yet.
Usage notes: This version maintains a full database between loads. If you find yourself with incorrect balances or corrupted DB errors, you can use the "Help" menu to reset the DB. A rescan typically takes about 10-20 min. A rebuild takes 30-90 minutes followed by the rescan. I'd like to think this will largely be unnecessary, but it's always useful to someone. Similarly, you can run with " --rescan" or "--rebuild" on the command line. Or if you're desperate (or on OSX where CLI options don't work), you can simply "touch ~/.armory/rebuild.txt" or "touch ~/.armory/rescan.txt". Also "touch ~/.armory/clearmempool.txt" will remove stuck transactions. |
|
|
|
Make some money helping test the new version of Armory (0.89.99-testing)!Download 0.89.99.14: Windows (32- and 64-bit)Download 0.89.99.14: Ubuntu/Debian 32-bitDownload 0.89.99.14: Ubuntu/Debian 64-bitDownload 0.89.99.14: Mac/OSX (not very usable in 10.9)
For anyone who's been waiting for the new version of Armory, we're almost there! But we desperately need more testing. I tested this bug-bounty idea about a year ago, and it seemed to work pretty well. Besides bugs, Armory got a ton of polishing, too. So let's try this again! If you want to claim a full 0.04 BTC (about $17 USD at the time of writing): - (1) You must be the first to post the buggy behavior. If there's an error in the log file, you must copy that error here.
- (2) The bug must be reproducible by me and impact the usability or security in a non-negligible way (things like grammatical error or sub-optimal design choices are welcome, but won't be rewarded with BTC)
- (3) Certain categories of bugs, along with already-known issues are not rewarded (the list is at the end of this post)
- (4) I get the final word in who receives a bounty and how much. Double-bounties and partial-bounties are possible
- (5) I will cap the payouts to 1 BTC total. If this is productive, I'll happily increase the limit.
- (6) You are expected to know how to run and use Armory already. It's an advanced tool with a bit of a learning curve. This space is not for teaching you how to use it. (there's an Armory sub-forum for that).
- (7) Not responsible for lost Bitcoins (though I've never seen even a hint of a problem that would lead to loss of coins). To use it on testnet, you may have to run Bitcoin-Qt yourself and unselect the first checkbox in the Armory settings window. Remember that Armory uses "--testnet", Bitcoin-Qt/bitcoind uses "-testnet"
This offer ends at 11:59pm EST, Nov 23, 2013!The following is a list of new features in Armory. Yeah, there's a lot! Please test all aspects of the application, though you might be more likely to find bugs in these new features: - RAM usage and startup time reduction: RAM reduced to less than 300MB, and startup time typically under 60 seconds after initial DB build!
- Persistent database: Armory now maintains its own blockchain database for fast startup. Make sure you have space to duplicate the blockchain (will be reduced in a subsequent version; this way was easier for now).
- Full MacOSX support: thanks to picobit for the builder, though the Apple+PyQt bugs prevent full usability in 10.9. Only accepting bug reports in OSX 10.8.
- New Backup Center: Better organization and description of backup options. Includes unencrypted digital backups, now.
- Fragmented Backups: Shamir's Secret Sharing (M-of-N secret splitting); balance your physical security and redundancy. Create up to 5-of-6 backups in Standard & Advanced modes. Up to 8-of-12 in Expert mode. Fragments are also deterministic for a given M value. For example, if you make a 3-of-5 backup, you can later make a 3-of-7 and the first 5 will be the same as the 3-of-5
- SecurePrint: Paper backups optionally encrypted with code on screen to prevent private key exposure to printer and other network devices. SecurePrint code should be identical across all backup types for a given wallet
- Half-sized paper backups: The chaincode is now derived from the private key, meaning only two lines of data for wallets created with the new version of Armory. Yet, all backup features work with older wallet without a hitch -- they'll all show four lines (if you don't believe me, prove me wrong and collect your 0.04 BTC!)
- Paper backup tester: test any kind of paper backup before you bury it in your backyard. Includes subset testing of fragmented backups.
- Message Sign & Verify: Finally Bitcoin-Qt-compatible signing and verification. Will have a new ASCII-armored version like PGP signing, soon
- Fixed broadcasting non-std signatures: Older versions of Armory produced signatures that have non-standard padding. If an older version is used on your offline system, you can't broadcast those signed transactions with 0.88.1 online. This version will fix the padding and broadcast successfully
- Improve *nix Makefile: Improved Makefile that should work out of the box on most Linux distros once the proper depedencies are installed. See the osx_picobit directory for compiling on OSX.
As a reminder, here's some pre-existing features that would benefit from testing: - Importing & sweeping of private keys. Single and multi.
- Creating deterministic wallets with customizable unlock time/RAM.
- Restoring paper and digital backups without restarting the app
- Coin control (in Expert usermode)
- Customizable change addresses
- "bitcoin:" URI-handling (with known deficiency on some Linux distros)
- "File" -> "Export Transaction History"
- OFFLINE WALLETS (no offline bundle for this version yet)
Claimed:whault: 1 x bounty (key calculator not removed) duxZero: 1 x bounty (tool tips and squashed buttons) jyyst: 1 x bounty (unicode issues) simonL: 1 x bounty (corrupt wallet file confusion) Cyberdyne: 1 x bounty (lingering sys tray icon) idoB: 1 x bounty (links, grammar and backup fields) cp1: 2 x bounty (confusing --datadir DNE behavior) devthedev: 1 x bounty (bad autoscrolling of dashboard) flipperfish: 1x for the "Send Bitcoins" first five entries bug (I knew about that one... long story) PRab: 1x for the lots of little issues: (4 time pwd asking, focus issues, let user choose backup) greBit: 1x for shutdown hanging (I think this is fixed now, isn't it?) Zomdifros: 1x for... I don't know what that error is... sending issues... definitely a bug! elbandi: 1x for UAC issues (will be fixed in 0.91) tc23emp: 1x for maxConnections error (I've been looking for the src of that bug! Thanks!)
|
|
|
|
Fix coming in 3... 2...
... 1! Top post links now link to the fixed .deb installers! |
|
|
|
Linux 64bit .deb do not start. Next error after manual start: sudo python /usr/lib/armory/ArmoryQt.py %u (ERROR) Traceback (most recent call last): File "/usr/lib/armory/ArmoryQt.py", line 42, in <module> from dialogs.toolsDialogs import MessageSigningVerificationDialog ImportError: No module named dialogs.toolsDialogs Argh, same problem as on OSX. I must've accidentally tested the new version in the development directory instead of through the installer. Fix coming in 3... 2... |
|
|
|
Communication with Qt is done through the RPC server, however (don't quote me on this) I think it is hardcoded to localhost. Assuming you get accross this hurdle (or that I'm wrong), you still need to give Armory the raw block chain files path. Through a network share, I assume.
Close! Armory actually doesn't use the RPC connection, it connects as a regular peer through localhost. Some people have problems with this because they assume it's RPC, and setup their bitcoin.conf to only accept connections from certain IPs, thinking that Armory will sidestep it through RPC. However, it only uses that connection for new blocks and transactions. It still relies on the BTC_HOME_DIR/blocks/blk*.dat files to read the past blockchain history. Now that Armory is maintaining its own database, I can transition off of using the blk*.dat files and only use the peer connection. But there may be some hurdles there: (1) Bitcoin-Qt/bitcoind cutting me off because I'm demanding too many resources and it blacklists me (2) Please dear god do not connect Armory to an untrusted node!. You will die a fiery death. Armory does absolutely no blockchain validation: it is designed to use that connection as its secure gateway. I want to eventually allow remote connections, but then also make it painfully obvious that there is a serious risk involved. You might even want to use some kind of SSL to make sure you remote connection is not intercepted. None of this matters though when it's forced to use localhost... |
|
|
|
Ack! The installer script didn't copy over all the files, whoops!
I'll work on that...
(updated the first post with the old 0.89.99.10 OSX app until I fix that)
Well that was easy. Just rebuilt 0.89.99.14-testing on OSX with the updated Makefile and re-posted it to the main thread. Please try it again! |
|
|
|
|
Ack! The installer script didn't copy over all the files, whoops!
I'll work on that...
(updated the first post with the old 0.89.99.10 OSX app until I fix that)
|
|
|
|
For those waiting for native message signing & verification ... it's here! Just posted 0.89.99.14-testing for all OS: https://bitcointalk.org/index.php?topic=299684.0That includes the fragmented backup tester as well as message signing compatible with Bitcoin-Qt (version 0). We hit a hiccup and don't have the version 1 signing & verification ready yet. It will be compatible only Armory-Armory, but we're hoping to demonstrate its superiority and then encourage others to use it (no formatting issues, only one block of text to copy & paste). This is very close now to being appropriate for a real release. At the very least, we'll post it on the website since it is now likely more usable than the previous version (for most prospective users). |
|
|
|
|
Show Posts
