Short answer:Armory gives you excellent protection against malware on your computer, if you use an offline computer for that purpose only. It is also a highly convenient way to have a secure wallet and still be able to access the bitcoins. Armory gives you excellent protection against accidentally losing your bitcoins due to forgotten passwords, hardware failure, fire in the house, etc, but only if you use the paper backup option. In particular, I recommend the N-of-M paper backup. For example a 2-of-3, where you print three paper backups and place them in three different, reasonably secure places. Any two of them are sufficient to recover the funds, but one alone cannot do it, so a thief getting hold of one of them will not help him. Offline wallet setup: * A computer with significant disk space, connected to the internet, running Armory. This computer only has a watch-only version of the wallet. It can generate unsigned transactions, but cannot sign them for the bitcoin network. * An offline computer, even an old or tiny one will do, with no internet access. It is running Armory in offline mode (needs very few resources). This computer holds the real wallet. It cannot generate transactions because it does not have access to the blockchain, so it does not know which bitcoins you own. But it can sign transactions generated by the online computer. Long answer:https://bitcoinarmory.com/about/using-our-wallet/
|
|
|
|
1) Regarding the N of M approach that you mention, is the easiest way just to have say five sheets, each with a fifth of the code sequence/keys that shows up on the paper backup or is there a better way.
The newest Armory has an N of M paper backup. If you make a 3 of 5 backup, then you print five sheets of paper, each with a code on it. You can restore the wallet from any three of these. If a thief gets two of them, he has no information at all about the wallet. If you lose one or two of them (fire?), then you can still recover your funds, as long as you have three pieces left. It is using Shamir Secret Sharing, http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing2) Also, any recommendations/resources for creating bomb-proof, yet easy to remember pass phrases.
Any passphrase that is easy to remember will be insecure. Any passphrase that is secure will be forgotten  Seriously, you could use a sentence that is partly nonsense but still meaningful to you. Or a sentence that is meaningful to you, but only use the first three letters of each word. |
|
|
|
BTW arent you afraid of HDD fails? Cold storage should be made on some durable device.
By durable, do you mean besides digital and paper backup. My impression was that those are sufficient for recovering from HDD failure. Those are sufficient indeed. You also need the offline computer if you actually want to access your stored bitcoins. So your setup is sound and perfectly normal: - Online computer with newest Armory, and a watch-only wallet.
- Offline computer with some old version of Armory (was new when installed, but that was long ago!), and the full wallet.
- Digital (probably encrypted) backup on one or more USB sticks, CDs etc, stored safely. If properly encrypted, even storing on Dropbox is an option.
- Paper backup (not encrypted) in a safe e.g. in the bank; or better yet: An N-of-M paper backup stored multiple reasonably safe places.
|
|
|
|
I just had this issue, I went to Help -> Rebuild and rescan databases, so far its working. Ill update once it's complete
Edit: Crashed again, ignore my previous advice
It may be due to a bad block in the Bitcoin-Qt/bitcoind database - the reference client seems to handle that better than Armory. It should of course not place malformed blocks in its database, but it often does, and then ignores it. But Armory may barf at them. Try deleting the blocks of the original client. If you don't want to wait ages downloading it again, google for torrents containing a recent snapshot of the blockchain, it is far faster to download. If you do use a snapshot, you first need to start bitcoin-qt/bitcoind with a specific command line option (Google again, I cannot remember it), and let it rebuild its own database. After this is done, you can delete the huge file you got with torrent, and then start Armory. Delete the torrent before starting Armory, that way you never have three copies of the blockchain on the disk simultaneously, two is bad enough |
|
|
|
Ultimately, this doesn't mean anything -- BC.i is not "bitcoin"... they are just run a service that lets you browse the network easily, but their window seems to be a bit foggy. It seems that everyone else has a better view of the network than they do.
I have a BC.i wallet. Unfortunately, it is not at all uncommon for them to lose contact with the rest of the network. |
|
|
|
suggestion: on emailing a wallet backup, have a possiblity of GPG encryption.
+1 |
|
|
|
|
How can anybody see to which country BTC are being sold? This makes no sense. At the most, they can trace the activity on various exchanges, you might as well argue that this is panic SELLING on the chinese exchanges. Every time 1 BTC is bought, 1 BTC is sold (except for 25 BTC every 10 min, of course).
|
|
|
|
Oh, and just curious, did you run Alan's build or roll your own? If the latter, try Alan's. I believe it was built under 10.8. If you're still seeing stability issues, let me know.
I used Alan's, I think it is more useful to test his builds than my own - there could be things that only works when compiled on your own machine. |
|
|
|
Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.
Hi, I am running OS X version 10.9.1. It looks like a stability thing - now I cannot reproduce the lock-up, but in stead I can reach the OS X print dialog sometimes, sometimes I get a crash along the way. When I reach the Print dialog it is hit or miss whether it is responsive or not. I get random crashes without anything appearing in the log file (I monitor it with 'tail -f'). We have previously had some test builds with this instability, I think it is related to a bug in Qt, probably building on OS X 10.8 is a workaround. There seems to be something horribly wrong with Qt on OS X 10.9. :-( |
|
|
|
|
I cannot speak for the developers, but my guess is that they have to be psychic to help you. You need to give them some information to work on, otherwise they have no chance to guess what is going wrong.
What version of Armory are you running? What operating system? What computer (how much RAM)?
Also, you probably need to dig out the log file and copy-paste the error messages from the end of that file here. I am sorry, but I don't know where it is stored if you use Windows. If you use a Mac it is in Library/Application Support/Armory
|
|
|
|
And I just wanted to test one more feature. Bang! I wanted to try making a 2-of-2 paper backup of a wallet I rarely use (no funds in it). When I presses Print all Fragments, a popup warned me that an error had occurred and that printing would be aborted. And Armory then opened a blank window, and froze. I had to force-quit it. The log: 2014-02-22 07:47 (ERROR) -- qtdialogs.py:6234 - Problem with private key and/or chaincode. Aborting.
Traceback (most recent call last):
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6231, in __init__
raise KeyDataError
KeyDataError
2014-02-22 07:48 (ERROR) -- qtdialogs.py:6234 - Problem with private key and/or chaincode. Aborting.
Traceback (most recent call last):
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6231, in __init__
raise KeyDataError
KeyDataError
2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
self.cleanup()
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'
2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
self.cleanup()
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'
2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
self.cleanup()
File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'
2014-02-22 07:49 (INFO) -- ArmoryQt.py:5255 - Resetting BlockDataMgr, freeing memory
I tried again with the same wallet. Same result. Then with another wallet, and it worked fine. Except that the old Print-dialog-not-working-on-Mac problem is back: The system print popup is unresponsive. |
|
|
|
Trying the new Mac build. First impression: It is faster and smoother than previous versions. And the fonts stay the same size all the time The wallet consistency check is also very reassuring. I did a single offline transaction just to test. I noticed two issues, none of them are new, and none are serious: 1) Comments written in the transaction are lost. Perhaps they are lost along with the transfer of the transaction to an older Armory on the offline machine. 2) One CPU is running full speed while Armory has some windows open. For example after saving the unsigned offline transaction, I can press Done or Continue. While this window is open, one CPU is loaded 100%. |
|
|
|
Have you received the coins? I've done the same mistake.
It is not a mistake! The receiving wallet is not involved in receiving the coins, that occurs on the block chain. The following scenario is perfectly all right. 1) Create an armory wallet. 2) Back up your wallet on paper 3) Create a lot of receive addresses, and request a payment from an exchange. 4) Turn off your computer. 5) Accidentally drop the computer from your seventh floor window. 6) The exchange transfers money to your receive address (so obviously it was not Gox ). 7) You go trekking in the Himalayas for six months. 8 ) Buy a new computer 9) Restore your armory wallet from backup in step 2. 10) Your money is there. It is stored in the block chain not in the wallet, the wallet just has the codes to release the bitcoins again. |
|
|
|
|
I thought locktime transactions were non-standard, and therefore extremely hard to get into the blockchain, because locktime is used to delay when a transaction can at the most early be confirmed, and chaining an unconfirmed tx after such a tx which is prevented from confirming makes it too easy to cheat with 0-confirmation purchases. If this is all locktime does, then once the tx is in the blockchain it should be irrelevant that it was once locked.
Perhaps Armory should ignore (or color in a strange color) any unconfirmed TX with a locktime, but treat it as any other tx once confirmed.
|
|
|
|
|
You have to run the last command in the directory where the .deb file is located. You do not have to repeat the first three steps again.
|
|
|
|
Could a minimum fee not be implemented, one that would make sending 1 satoshi currently futile?
It is. Most of these 1 satoshi transactions will never confirm, and will go away after a week os so. But some do, as some miners include transactions even without a fee. That is how it will necessarily be in a distributed system. |
|
|
|
Misunderstandings and neglect create more confusion in this world than trickery and malice. At any rate, the last two are certainly much less frequent.
—Johann Wolfgang von Goethe In particular in the case of MtGox, who have repeatedly demonstrated technical incompetence. EDIT: Grey's Law: "Any sufficiently advanced incompetence is indistinguishable from malice" |
|
|
|
I understand this would only be an issue if your spend transactions are close to each other (i.e. 20 minutes or so, a block or two) but still, seems like something that needs to be solved.
Not necessarily. Your wallet *might* actually get confused by the transaction that you issued having a "wrong" tx-id once it gets into the blockchain. It should not be, since even without transaction malleability you could have made a transaction using the same inputs on another computer (with a copy of the wallet), so the wallet software should (and probably does) recognize this altered transaction once it makes it into the block chain, then discard the original transaction and update the balances. I would expect that all wallets do this correctly, but my question was really if we are sure that Armory does this correctly (MtGox's wallet apparently does not). One reason for suspect that Armory might *not* do this correctly is that there has been a bug in recent versions of Armory where a transaction vanishes once it is confirmed. A rescan fixes it. But it could potentially be a corner case triggered by the altered transactions we are now seeing in the wild. |
|
|
|
Can Armory fall victim to the problem with spending 0-confirmation change coins due to transaction malleability? It is apparently a problem i Bitcoin-Qt see http://www.reddit.com/r/Bitcoin/comments/1xj3rq/gavin_andresen_and_jeff_garzik_mt_gox_is_wrong/cfc9elc It is the problem that has not just caused MtGox to fail, but Bitstamp has also had to suspend withdrawals due to this. The problem is simple: You send some bitcoins and receive some change. An evil relayer modifies your transaction and relays quickly. The modified transaction still spend the same inputs and generates the same outputs, but it has a different transaction ID. You and the nodes you are connected to see the original TX id, and so does some miners. But some see the TX id of the changed transaction. Now if you wait until the transaction is confirmed, nothing bad happens - either your original tx confirms or Armory presumably sees a confirmed transaction doing exactly the same thing as you original one, and discards the original as a double spend. But if you have already spend the change from the first transaction in a second transaction, then if the modified first transaction confirms, then the second transaction is invalid since it is based on the output from an invalid transaction (the TX id is apparently used to identify the inputs). My point is: Will Armory end up being totally confused by this (inconsistent database or something), or is this a non-issue (a part from the risk of issuing invalid transactions?). I workaround would be that Armory disallows 0-confirmation inputs even in the case when it has just created them itself. That would of cause have a negative usage impact as well. Hmmm.... |
|
|
|
|
It is far more likely to be incompetence than malice. After all, they probably have more to lose than to gain by crashing the bitcoin price. And the problem they suffer appears to be a likely problem to run into if you are not careful. MtGox does not exactly have a history of technical competence!
|
|
|
|
|
Show Posts
