I cant change default transaction fee 0.0005(this is reap off when I send 0.01) I try set lower then 0.0005 but armory don't let me do it its bolox....
Some transactions must have a fee, and that is determined by the network, not Armory. Armory simply determines whether the network will require a fee, and then tells you you must include it. Many transactions, especially those over 1 BTC, can usually be sent for 0.0 fee. Small transactions, using coins that were recently received, almost always requite a fee of 0.0005. The network does this to prevent people for sending out millions of tiny transactions for free, or moving coins billions of times between two of their own wallets and clogging the network. |
|
|
|
Doesn't BIP 32 allow for the creating of hierarchies of arbitrary depth?
Yes, you create wallet "trees". Standard users will have a single wallet file that is backed up by the seed once. Creating new "wallets" will still be covered by the old seed . You can see a graphic of it here. Since Armory is multi-wallet, though, I will be expanding it to accommodate multiple wallet files when I get the new wallets implemented (for Expert users, probably Advanced, too). When such a user makes a new wallet, they'll have the choice of whether to generate one already protected by their existing backup, or generate a new wallet file. I still need to work out how to deal with the multiple layers, such that you might have a wallet "chain" 2 levels deep, for which you want to import just the public/watching-only part of that chain. Or the full chain. I have interface details to work out on that front. (like, company creates master wallet, and gives each employee their own subwallet/chain. It could be a full chain or watching-only chain. The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing. |
|
|
|
And as Anon136 said -- it's probably best not to keep all your backups in one place. In the future, Armory will have split backups that make this a little safer. Until then, protect them very carefully. Anyone who gets a paper backup gets your wallet.
Question: there's no relation between the seeds of different wallets, through, correct? If someone gets the paper backup for one wallet, is the other wallet still safe? Correct. BIP 32 will change that, though it depends what part of a BIP 32 you are backing up. The new Armory wallet files based on BIP 32 will contain multiple "wallets", each of which is derived from that master seed. But you'll be able to create multiple wallet files, with different seeds, and back them up separately. |
|
|
|
The deb files are GPG-signed directly. Once you have the GPG keys imported and have the dpkg-sig package installed, simply do "dpkg-sig --verify armory*.deb".
Perfect. Thanks for that tip. I see it now at the bottom of the page, but it might be helpful to link to that from around the deb file download link. I'm very impressed with Armory -- finally tried it after 1+ years of hearing about it. You've done a great job. One question: does Armory 0.87 beta implement BIP 32 for its deterministic wallet? No one should've implemented BIP 32 yet (well, released it). It's not final. And now there's murmurings of it possibly changing/being tweaked. I have code that implements the current implementation of BIP 32, and I can tell you how to access it via code ... but it's not ready yet. |
|
|
|
|
In such cases, it's probably best to just write the data down by hand. Pen and paper is fine.
Only the four lines of text are important. The QR code is just there for convenience (it contains those four lines). Arguably, many people feel safer doing this, anyway, to limit the number of devices that have seen your unencrypted root key.
|
|
|
|
Anyone who gets a paper backup gets your wallet.
(but it could be encrypted so still useless if they don't know the passphrase right? Paper backups are never encrypted. You can use them to recover your wallet if your forget your passphrase. Digital backups are just copies of your wallet, and thus encrypted if your wallet is. |
|
|
|
How long does it normally take to process the blockchain on startup? With my (admittedly rather ancient) Athlon x2-64 laptop, it can take upwards of half an hour every.freakin.time I start Armory to scan through the chain, and during that time my CPU usage is pegged on one core.
Is there any way I can reduce this? Maybe put the blockchain files on a ramdrive or something fancy like that? Are there plans to reduce this time somehow, or is this really a bug on my end somewhere?
Not a bug. Just an ancient design under the hood, derived when the blockchain was like 300 MB. Not 6 GB. Don't worry, though, I'll be working on fixing it in the next couple weeks. I've just been heavily distracted by other things. But the time has come to finally do it. On non-ancient computers, it should take like 3-10 minutes. Not short, but bearable knowing a fix is coming. If you are low on RAM, I think it has to start swapping, and load time increases by an order of magnitude. |
|
|
|
I printed out 2 paper backups. Should I put ALL my coins that I am saving on this with essentially 3 backups?
Should I do more backups? Is it possible to backup to a usb stick as well?
(when I rescue a wallet and it has all that data... is the passphrase involved at all? is the passphrase somehow stored in the data as well? What if the passphrase is lost? Just curious.
Paper backups are forever!. Protects you from your hard-drive dying, and forgetting your passphrase. Digital backups are literal copies of your wallet file, which is encrypted if your wallet is encrypted. Obviously doesn't protect you if you forget your passphrase. If necessary, you can always write the passphrase on the DVD or USB key that you saved it on. Don't put all your coins in until you're comfortable. Put a little bit in. Try it out. Get used to the process of sending. It is hopefully guided well. Once you do a few such transactions, then you'll decide for yourself whether to put all of them in there. And as Anon136 said -- it's probably best not to keep all your backups in one place. In the future, Armory will have split backups that make this a little safer. Until then, protect them very carefully. Anyone who gets a paper backup gets your wallet. |
|
|
|
|
I actually have no experience with blockchain.info. They read Armory wallets?
|
|
|
|
Great software, however I just upgraded to version .87 beta on ubuntu 12.04 and bitcoin-qt .8.1 and now when Armory start and
scan the block chain it runs for awhile and then crashes. I usually fix things myself, but I need to send some bitcoins for payment.
So could you give me a idea of what may be wrong.
Does it crash after it finishes scanning? Or during? There's been some issues with upgrading to Bitcoin-Qt 0.8 plus ... it has new blockchain files. Armory 0.87+ should handle it, but sometimes it doesn't play nice. Most often when I hear of Armory crashing during scanning, it's because the blk files became corrupt. Which is unfortunate, since it requires redownloading everything... Can you send me a log file? You can export it while it's scanning. Email or PM. Also, you might try the newest version of Armory, but you have to build from source -- it's quite simple though: 1. $ sudo apt-get install git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted python-psutil
2. $ git clone git://github.com/etotheipi/BitcoinArmory.git
3. $ cd BitcoinArmory
3a. $ git checkout managesatoshi #(extra step to access 0.87.9)
4. $ make
5. $ python ArmoryQt.py Not only might it fix your problem (or make it worse!), but the log file contains a LOT more useful information for me. So if that fails, let me know (you'll have to either let it run bitcoind for you, or open the settings and select that you want to run it yourself). |
|
|
|
Every time you request coins or send coins, Armory creates a new address from the initial seed. After a lot of use, I imagine that Armory could get really filled with thousands of bitcoin addresses, many of which would have been used once and discarded.
Question: When you restore your wallet from a paper backup, I assume Armory has to go through all the same steps it used to generate the addresses before, and check them one by one to see if they have anything. Is there a limit to the number of addresses it scans through? E.g., if I used over 100,000 transactions (hypothetically), with all my remaining coins being in adress #100,001, and restore Armory from a paper backup, is there a chance that Armory will use the seed to generate and check only the first 100,000 addresses, and miss my coins in the 100,001 address entirely?
It checks 100 at a time, checking the next 100 if the key pool has less than 90 empty addresses. You can change this keypool size from the command line, i.e. --keypool=1000 I meant to make it a geometric distribution, (check 100, then 200, then 400, then 800, etc), to avoid taking forever to scan an enormous wallet. Instead, you can switch to "Expert" usermode and a new button will appear in the wallet properties, that lets you generate as many addresses as you want. The intention was, rather than try to do something fancy, the user probably has some idea of how many addresses they used, and if they used so many that they need this, they can find it in the expert usermode.  |
|
|
|
No, the best I've got is a tutorial for after the system is setup. I'm actually working on a kind of "Best Practices" guide. FDE is part of it. If you don't have FDE, the thing to do is use FAT32 partitions so that you can effectively shred files. Interesting comment. I was always under the impression that NTFS did data journalling, which of course makes secure deletion problematic (particularly given a very large default journal size). But all the references I can find now suggest NTFS only does metadata journalling, at least by default. Did this change at some point, do you know? Or is there some other reason why secure deletion isn't possible under NTFS that I'm missing? Also, if you have the RAM for it, you might want to consider not having a swap partition/pagefile. For simplicity, users can use the alternate Ubuntu install CD, which has an option for encrypted LVM, and includes encrypting swap. It encrypts everything but the /boot partition. As for NTFS journaling, I actually have no idea. I don't want to gamble on it. But I do know that FAT32 will have the desired behavior. |
|
|
|
It's a good observation. I made the same observation myself, when I actually applied it. The problem is, there's only so much I can do with a command line script. This was intended to be a stop-gap measure until I get the new wallets integrated. I will come up with a way to avoid writing them to disk.
What I will probably do in the future, with all backup types, is have them print/save encrypted, and you are given a 15-character encryption key to write down and keep with it. It could be disabled, but it would offer a way to print/save the data without worrying about the device onto which the backup goes.
Thanks for the feedback.
Actually, what I'll probably do - on further thought - is simply run the script with the current directory being in a ramfs filesystem :-) But I don't know if things are quite as straightforward for Windows users - and it would be good to make it hard for people to shoot themselves in the foot. Incidentally, do you document any guidelines for setting up an offline system? If you don't already I'd suggest you should recommend FDE as a mitigation for private keys getting written to swap - particularly on Windows which AIUI doesn't have a fully reliable mechanism for locking pages in RAM. roy No, the best I've got is a tutorial for after the system is setup. I'm actually working on a kind of "Best Practices" guide. FDE is part of it. If you don't have FDE, the thing to do is use FAT32 partitions so that you can effectively shred files. |
|
|
|
Your software is the best and safest by far without any real competition. You are the main expert. When Bitcoin becomes sufficiently mainstream you will be approached for: 1) Creating customizations (either open source or proprietary) 2) Performing other services (such as coaching and setting up the software) 3) You will likely be offered rather lucrative contracts by business wishing to enter this market (the equivalent of a buy out if Armory was proprietary) Of course I hope you will not take option 3 and will have time to keep working on Armory (out of my own interest)  . But if you monetize on this it is truly deserved as this is a magnificent piece of work. Thanks! +10000000 Thank you for your incredible work, Alan Thanks so much guys. I really appreciate the encouragement. It's awesome to see so many people so excited about my work. I am working on some ideas to generate some revenue, and I think I can do so without harming the user experience (hopefully enhance it!). I'll discuss that more later. Just know that I'm planning to keep Armory 100% free. Or at least 98% of it -- I might try to develop some kind super-advanced features, or maybe a corporate add-on that could be sold. But for everyone else, I want there to be no reason not to use Armory. Instead, find ways to leverage a wide userbase. And if Armory makes an impact in the Bitcoin world, it will help me out by fattening my offline wallet  (both in donations and price).
Finally figured out the code signing problem. Check out this bling!  |
|
|
|
Excellent work. I've just started using Armory and I will certainly be setting up n-of-m soon.
My one criticism is that frag_wallet.py seems to insist on saving all the fragments in the current directory, immediately and without explicit prompting - which is the moral equivalent of writing the private keys to disk. Yes, with appropriate care (full disk encryption, secure erase, etc) this can be mitigated - but it's providing a gun for people to shoot themselves in the foot.
If I'm going to go to all this trouble in the first place then I'd much rather save each fragment directly onto its own individual USB stick (which I'd store alongside the corresponding hand-transcribed paper copy of its contents). My FDE is there to protect me from mistakes, such as unencrypted keys getting written to swap, etc. But my aim is never to deliberately write keys to hard disk in the first place.
If the unfrag_wallet.py script was similarly modified, then I could still do a test unfrag from my stack of USB sticks, with the unencrypted keys unlikely to ever hit disk.
I'm sure I can easily modify the python scripts to do that when I get round to setting up n-of-m backups, but just my 2 bitcents.
roy
It's a good observation. I made the same observation myself, when I actually applied it. The problem is, there's only so much I can do with a command line script. This was intended to be a stop-gap measure until I get the new wallets integrated. I will come up with a way to avoid writing them to disk. What I will probably do in the future, with all backup types, is have them print/save encrypted, and you are given a 15-character encryption key to write down and keep with it. It could be disabled, but it would offer a way to print/save the data without worrying about the device onto which the backup goes. Thanks for the feedback. |
|
|
|
Are these available anywhere for the latest releases? I see the windows and osx md5 hashes, and the hashes for building from source, but nothing for the deb files.
Thanks!
The deb files are GPG-signed directly. Once you have the GPG keys imported and have the dpkg-sig package installed, simply do "dpkg-sig --verify armory*.deb". |
|
|
|
Forgive me, I am new to Armory.
I have bitcoin-qt running and Armory is still saying "disconnected".
I have restarted both and bitcoin-qt is updated with a green check, but Armory is still disconnected.
Any ideas?
The dashboard should tell you why it's disconnected. Are you using 0.87.2? Can you try the latest testing version and send me a log file if it still doesn't work? |
|
|
|
I've had the latest testing version running on Windows 7 x64 for the past day or so. The settings worked fine for non-default data directories. I like the progress bar for scanning the blockchain too.
Yay, good news! To everyone else: also post if you've had a good experience, not just when it's a bad experience. All I hear is the bad experiences and I feel like nothing works. It sounds like there's lots of circumstances where this works, but not all. Hopefully, I can deduce when it doesn't work, based on the mix of good and bad reports. |
|
|
|
It's complicated by the fact that with 1 trial, there is a 0% chance that the house will take within 1.89 to 1.91 percent.
The chance is not 0%, but it is very small, perhaps <<0.001%. Markov chains are more useful when there's a relationship between the states of the system. In this case, it would be more like "losing 3 in a row changes your chances of winning the next one". Since we don't have that, you can use regular IID statistics.
It seems to me that SD could be modelled as a markov chain since the game is stochastic and has a markov property; that is, the outcome of trial B is not dependent on the outcome of trial A (I'm not sure if that's what you meant?). Although the probability of consecutive lessthan1 "successes" is very remote, it is still possible and a probability is associated with it. Given infinite number of trials, its bound to happen and there is no "losing 3 in a row changes your chance of winning the next one" for the markov model because the game has a markov property (or maybe it doesn't?). Maybe I'm misunderstanding the application of markov models, so please correct any errors I've made. There's nothing stopping you from using Markov chains to model this problem and get a correct answer. But it would be like using calculus to compute the area of a square. It works, but there's simpler ways to do it. |
|
|
|
Whelp. Installed and now it won't load. Crashes immediately.
Problem Event Name: APPCRASH
Application Name: Armory.exe
Application Version: 0.0.0.0
Application Timestamp: 4918017b
Fault Module Name: MSVCR90.dll
Fault Module Version: 9.0.30729.4940
Fault Module Timestamp: 4ca2e32e
Exception Code: c0000005
Exception Offset: 000000000001eb58
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 95d1
Additional Information 2: 95d1766db898ef8ee32e62bf8315c3fc
Additional Information 3: eb9a
Additional Information 4: eb9a4ba802ad3af552861bced4313be9
GAH! Can you try repairing the installation? Or completely remove c:\program files (x86)\Armory ? Then reinstall it? I assume you're in Win7-64? |
|
|
|
|
Show Posts
