Feel free to open the wallet file in a hex editor and walk through it using the wallet file map. Watching-only wallets should have all zeros in the private key fields. Not the easiest thing to do for a random user, but only a few users need to do it to expose any bugs/backdoors. If you want to review the code, it's in a function called forkOnlineWallet(). You can see it overwrites the private key fields with empty strings before the writeFreshWalletFile() call. I hope that calms some nerves  |
|
|
|
Small request, or maybe it has already been implemented somehow. Can Armory users get the option to switch into mBTC please?
Not yet. But we'll be adding it to 0.91-beta. That version is mostly bug-fixes, usability upgrades, polishing, etc. Things like sending to P2SH, unicode fixes, alternate units, will all be implemented then. |
|
|
|
I'm not yet using Armory because I'm waiting for two things: compressed keys, and works on XP. hehehehe.
But this is what I had in mind: compile a list of safe places. To me, these are the following:
1. My house.
2. My parent's house.
3. My in-laws house.
4. Sister's house.
5. Brother's house.
6. Main Office (work).
7. Another office 1. (also work.)
8. Another office 2. (also work.)
9. In the Cloud.
I think that's more than enough, the only problem is all of them are located in the same region and country, except the last one. Those other offices are in different cities, more than a few kilometers away from each other.
So, let's pretend I have 9 locations. N = 9. The debate in my mind now is, how many do I want needed, or M = ? 3? 4? 7 might be too much (and doesn't protect from careless siblings accidentally destroying my little paper backup with them.)
The advantage I have is all the offices have safes or vaults and armed guards and both parent's and in-laws also have a safe or will have one. That, and most of the banks in my area do not offer deposit box services.
Also, when you are using a high N-value, you can use "privileged" and "unprivileged" holders. For instance, you might consider your safe-deposit boxes privileged and give them 2 fragments each. Consider each low-security or low-reliabilty location "unprivileged" and only put one in each. Certainly the cloud would only get one. |
|
|
|
I had some fun with 0.9 lateley. The backup center is just mindblowingly awesome. All the safety questions are addressed. e.g. I was wondering if testing of backup is safe. Just then it tells me that no keys will be written to disk. Great stuff.
I noticed one little flaw though. Might have been mentioned before. Wehn printing a 1/1 (normal) paper backup the last block of of the chain key on each line does not stay within the given frame. two letters were just on top of the line. Does not happen with fragmented backups though. Let me know if you need a screenshot.
Thanks! I have battled with the text sizes and fonts on those backups, but Qt just does not want to obey me. I think I'm missing something, and maybe it's somethign we should investigate for 0.91-beta... apparently your desktop DPI and default font affects it even though I explicitly tell Qt the exact size and font to use. And on Mac it doesn't even use fixed-width font! I'll make a note for the next version to do a bit more investigation of that (as well as spend some time on the Mac build, which got lost in the conference preparations) |
|
|
|
I don't know if this was posted or not, but i have a problem. I'm using Armory with the "--datadir=" command and it keeps crashing at 99% scanning transaction history with every version that i try. Using the default directory works, but what should i do to work with the "--datadir=" option?
Solved. Deleted the "databases" folder and now works like a charm. This may have been the last major bug I never found before releasing -ERROR - 1384746267: (..\StoredBlockObj.cpp:1063) Cannot get tx copy, because don't have full StoredTx! It's in my plans to fix that for 0.91-beta. I got a couple people to pass me their databases that have this error so I can debug it. Will tend to it after I get back from the conference (in addition to fixing all the broken optimizations in the LevelDB code which causes it to scan so slowly!) |
|
|
|
This is not what i was aski g about but cool to know.
I more or less made my own in the past by hand.
Thanks
I know that you were asking about encrypted paper backups, and this is my standard response to that topic. Most people want physical security of their backups when they make that request, so I have provided a mechanism for improving physical security (through fragmenting). I have no plans to implement user-input encryption strings into the backup system. Fragmented backups are what I implemented instead, and I encourage you explore whether they meet you needs, since they do for most users. |
|
|
|
Hi!
Just installed the new version (0.90) but it keeps getting stuck at the "building databases" part with "15 seconds" left.
I tried "rebuild and rescan databases" in the help menu and it builds up to 99% again but keeps getting stuck with "15 seconds" left. I left it on for a full day but it never budged, then it started giving a crapload of "bitcoin-qt disconnected" errors.
I'm using windows 8 64-bit with 32GB of ram and a 256GB SSD.
Send a log file to support at bitcoinarmory com |
|
|
|
Be absolutely sure you don't install Armory in a different folder than the previous installation. This might lead to a complete loss of all your (non-backed up) wallets.
Uh...it shouldn't. If this happens for some reason, let me know. But the install folder has nothing to do with your Armory home folder which is where your wallets and settings are kept. The only way to change or affect that folder is to change the "--datadir=" flag when running Armory, and that will simply change it... it won't delete anything. |
|
|
|
|
Actually the error would be in the first half of the file (long story). You posted the C++ log which is the underlying engine. The regular log file (the first half of that file has all the GUI related errors. The message format looks different when it switches.
|
|
|
|
Just wanted to to simulate the way etotheipi posted. I need a paper backup which lasts decades.
Only little more than half a year later etotheipi's instructions are almost useless (if I assume i printed this forum thread). The chaincode is history and so is the function ComputeChainedPrivateKey.
I'm very concerned that my paper backup is useless in the long term and nobody can then reconstruct the private keys from it.
Edit: Useless, if I printed a "Root Key only"-Paper Backup and this thread.
Armory wallets still use a root key and chaincode, it's just that the new wallets simply hash the root key to get the chaincode, meaning they don't need to be backed up anymore (it turned out to be unnecessary to randomly select the chaincode). Again, the code for this is dead simple, and will easily persist for decades on the internet, github, googlecode, amazon S3, and random users' download folders, as long as Bitcoins still have value. Anything that would somehow lead to this information becoming inaccessible would probably be accompanied by bigger problems that destroy bitcoin anyway (like nuclear war, collapse of the entire internet, etc). It's just not going to happen. |
|
|
|
|
Use the fragmented backups in the new version (0.90-beta). They were created to provide users with the ability to balance physical security and redundancy without the high-risk of permanent coin-loss associated with brainwallets (which is what you have if your backup requires information only contained in your brain to be useful).
Instead of a single backup (fragment 1) with a password in your head (fragment 2), simply make a 2-of-2 backup and store them separately. Or make 2-of-3 to add some redundancy so loss of one fragment doesn't destroy the entire wallet.
For M-of-N, M is the "security level": how many separate pieces/places/systems an attacker needs to compromise to take the wallet. N is the redundancy (well, N-M)... how many pieces can get destroyed/lost and the backup is still useful. Calibrate as needed -- you can go up to 5-of-6 in the standard interface, 8-of-12 if you switch to expert mode. You can get creative, like creating 4-of-8, and "priveleged holders" can have two fragments, and less-secure holders can have 1 fragment. For instance, each of two safe-deposit boxes might hold two fragments, but you and each of three family members might just keep one each in your house laying around. Etc.
|
|
|
|
|
Indeed, we are using cloudflare. Although it looks like all cloudflare sites are being blocked in China, so we are discussing internally if there's another way to handle this.
Haven't heard much about what happened with the forums, anyone got a link?
|
|
|
|
|
Yup. Just close any open instances and install the new version. It will remove the old version but won't touch any of the existing wallets or settings.
There's a note about it on our About->FAQ page on the website bitcoinarmory.com.
|
|
|
|
|
I just updated the list on the first post. I think that covers everything. I have basically ignored any OSX issues since that was completely hosed. Hopefully we'll get an OSX build going, after the conference.
If you are on the list, please PM me with payment address and specify if you are okay with me sending one transaction with multiple outputs to everyone receiving a bounty.
BTW: a lot of these bugs will actually be fixed in 0.91-beta. I didn't perceive most of them to be showstoppers for 0.90. It was the showstopping bugs that I was looking for that would make for an embarrassing release...
Thanks everyone for helping out! If you continue bug-hunting in 0.90, and find new bugs, feel free to post here and I'll honor the bounty up to the limit I originally specified.
|
|
|
|
|
My apologies guys. I've been swamped with the new release, and preparing for the conference next week. I'll spend some time today going through and tallying up how many people get bounties. If you believe you get a bounty, please PM me your address and let me know if you are okay with a single outgoing payment with all recipients at once. I prefer to reduce blockchain bloat, but I'm also okay with it if privacy is important to you.
|
|
|
|
What's the difference between creating entire transactions offline/online? The chain code could be input manually into the offline computer, along with a number determining the indexes of the deterministic addresses to be created, the online Armory will simply check if the transaction is valid and no private key will ever get onto the online computer.
I'm not sure I understand your question. The online computer already never touches the private key data. It is created on the offline computer and stays on the offline computer. Only the root public key is transferred to the online computer. Even all the data moving back and forth between the two systems is totally security-insensitive -- no private key data ever touches the USB key, only signed transactions that will end up in the blockchain anyway. When people talk about "paper wallets", I believe they're talking about something similar to what you are describing: the private keys are not held on the offline computer, but instead re-typed every time the offline computer is booted. Also, when Armory upgrades to BIP 32, it will be possible to compute private key X directly. But the current deterministic algorithm in Armory uses a real chain: i.e. private key X depends on private key X-1. Therefore, if you need address 132, you have to compute the first 131. Instead, I don't even pass indices between the systems. Armory just precomputes the first 100-1000 addresses and identifies what it is capable of signing in the supplied transaction. |
|
|
|
Thanks for the support even though I should have figured this out by myself. There was also some other odd behaviour: one transaction lagged with the confirmations for a few hours, but eventually started to show the same number of confirmations as the client on my other computer (without any rescanning being needed). Also the "Send!" button just doing nothing is very confusing since it's not at all obvious that it's caused by a previous transaction not being recognised by Armory. This only applied to the wallet that had the unrecognised transaction btw.
Actually, if a button appears to do nothing, then it's actually an error being thrown under the hood and then aborting the requested operation. There's almost definitely an error sitting in your log file. Do you mind exporting your log file and sending it to support at bitcoinarmory dot com? You can find it in the "File" menu on the main window. Or you can just look in your log file and post/email the seemingly relevant error messages. I think I have observed Armory occasionally falling behind the network, but I'm not sure yet what causes it. It definitely resolves itself on a restart, but there is no indication other than the mouseover text of the number of blocks (i.e. "Last block received 8.5 hours ago!"). It's a non-critical bug we'll have to track down eventually. |
|
|
|
Conclusion: It would be great to be able to send new transactions, even though the transaction right before was not yet processed by Armory.
As alluded to in the quote above: it's not easy to rebroadcast. Armory and Bitcoin-Qt both require their memory pools to be flushed, which requires restarting both of them. And in Armory's case, also removing the memory pool file, but that is now handled by "Help"->"Clear all Unconfirmed" |
|
|
|
Hey, I have a section about this in our new troubleshooting page: https://bitcoinarmory.com/download/troubleshooting/I sent a transaction, but it is “stuck” with 0 confirmations
This problem can happen when there is a temporary disconnection from the network right as you attempt to broadcast your transaction. It can also happen seemingly randomly with low-value transactions. Unfortunately, because of the way Armory and the core Bitcoin software works, it’s not easy for Armory to correct this situation on its own. But it is not too hard to deal with it manually.
If you let Armory manage the core Bitcoin software for you (or you do not know what this means): Go to “Help”->”Clear All Unconfirmed”. Then restart Armory. Send/broadcast your transaction again.
If you manage Bitcoin-Qt/bitcoind manually: Go to “Help”->”Clear All Unconfirmed”. Then restart both Armory and Bitcoin-Qt/bitcoind. Send/broadcast your transaction again.
If this does not help, it’s possible that the network is simply processing your transaction with very low priority. This can happen to transactions that are small in value (BTC), large in size (kilobytes), and do not have fees attached. You can avoid this by including a 0.0001 BTC fee on all your transactions by default. If this is the problem, you will be able to right-click on the transaction in your history and select “View on Blockchain.info”. If the website shows you an “Unconfirmed!” transaction, you will just have to wait. |
|
|
|
(copied from the Armory discussion thread) 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/ |
|
|
|
|
Show Posts
