Unfortunately, we permanently broke support for 10.04. I really tried not to do that, but some of the new stuff we made (including the universal builder that makes things much simpler to deploy on other Linux systems), requires a version of libc that is newer than 10.04. The benefit here was that now we have a single deb package that works on all Ubuntu newer than 12.04 -- we used to have to have lots of different packages and individually verify which OSes it worked on.
For myself, I just keep an old version 0.91.2 on my online computer, and use that when I need to sign something with my offline computer. It's certainly inconvenient, but at least the databases don't have to be rebuilt to switch, so it doesn't take that long. I plan to eventually upgrade/switch my offline computer. It may be inconvenient, but you can be sure that I myself and inconvenienced too! Yet I still went through with it because of the simplicity and robustness added by making the associated change.
Thank you for your kind reply. Are the 0.92.1 offline bundles working on 12.04.4 or are they working only on 12.04.3 as per previous versions of such bundles? We didn't get around to upgrading the offline bundles. I think you still need to use 12.04.3. |
|
|
|
Just re-released 0.92 as 0.92.1.
Do I understand correctly that upgrading from 0.91 would require upgrading the offline wallets too? If that is the case, please put a warning on the website, upgrading the offline Armory may be significant work depending on the setup. I for one plan to wait till the dust has settled. I know that no new changes are expected in the communication protocol, but there will probably be many bug fixes. Yes, moving past 0.91.2 will require both offline and online computers to be upgraded to 0.92.1. This is true whether or not you plan to use multisig. My offline system is based on Ubuntu 10.04, as this was the recommended set up just a few months ago. I see only offline bundles of 0.92.1 for 12.04, are you planning to make offline bundles also for 10.04? Last but not least: do the offline bundles for 12.04 work on 12.04.4 or only on 12.04.3 as the previous ones? Unfortunately, we permanently broke support for 10.04. I really tried not to do that, but some of the new stuff we made (including the universal builder that makes things much simpler to deploy on other Linux systems), requires a version of libc that is newer than 10.04. The benefit here was that now we have a single deb package that works on all Ubuntu newer than 12.04 -- we used to have to have lots of different packages and individually verify which OSes it worked on. For myself, I just keep an old version 0.91.2 on my online computer, and use that when I need to sign something with my offline computer. It's certainly inconvenient, but at least the databases don't have to be rebuilt to switch, so it doesn't take that long. I plan to eventually upgrade/switch my offline computer. It may be inconvenient, but you can be sure that I myself and inconvenienced too! Yet I still went through with it because of the simplicity and robustness added by making the associated change. |
|
|
|
Just re-released 0.92 as 0.92.1. We tested the OSX build this time, and also found a bug in the private key sweeping just after we releasing 0.92. Both should be resolved! (there was nothing unsafe about 0.92, just We don't have an automatic process to update the website, but my release scripts spit out these pretty formatted forum links. As always, we recommend you use the secure downloader within Armory. Use the links below if you are still running a version older than 0.91. Armory 0.92.1 Installers: Armory 0.92.1 for Windows XP, Vista, 7, 8+ (32- and 64-bit) Armory 0.92.1 for MacOSX 10.7+ (64bit) Armory 0.92.1 for Ubuntu 12.04+ (32bit) Armory 0.92.1 for Ubuntu 12.04+ (64bit) Armory 0.92.1 for RaspberryPi (armhf)Armory 0.92.1 Offline Bundles: Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (32bit) Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (64bit) Armory 0.92.1 Offline Bundle for RaspberryPi (armhf)GPG Verification Data: Armory 0.92.1: Signed hashes of all installers @chrisrico: it's a bit late to ask what went wrong with the RPi build, but whatever it was, I'll make sure it makes it into the next release. If it's a dependency issue, I might need some help figuring it out. If it's a script execution bug, should be easy to fix it. |
|
|
|
We support the goal/mission of the Foundation, even if there is controversy around the actual execution and transparency to achieve that goal. We try hard to remain totally apolitical and are simply offering to match donations if others support them. Most importantly, we really wanted to support the Core developers, and bitcoin.org insists that donations for Core development go to the Bitcoin Foundation. I discussed with some folks on the bitcoin-dev IRC channel (including Wladimir) about other ways to contribute to Core development, but agreed that the BF is still the best way, even if it is indirect. If people don't want to support the BF, then do not match the donations. Even if there is a lot to dislike about them, they are still paying some core dev salaries, maintaining the website, lobbying for Bitcoin, and serve as [one] public face of Bitcoin. They also put on a really good conference in Amsterdam that we saw as extremely positive for Bitcoin. If no one supports them anymore, then no one will offer to match. But if a lot of people who support us also support the BF, then we will support them, too. |
|
|
|
What would cause Armory to fail to recognize that new blocks have arrived?
In this case, bitcoind is running on a separate machine, with NFS used to share the blockchain directory and socat used to tunnel Armory's connection requests to 127.0.0.1:8333 to the appropriate interface.
Indexing the blockchain works just fine, sending transactions works just fine, and Armory does notice incoming unconfirmed transactions.
However the block count in the lower-right corner never increment, requiring a restart in order to notice that new blocks have arrived.
It sounds like it's finding the block files fine on startup, but sees them staying the same size after that.. Armory reads new blocks by observing the last block file changing size or the creation of a new blk file. Perhaps NFS is not allowing up to date access to that info. |
|
|
|
I don't know much about that device or company behind it, but I will say that a true HWRNG is overkill if you are creating a couple wallets and don't mind doing dice or cards yourself. Why? Because you need like 100 bytes of entropy per year to create a few wallets. Most HWRNGs produce X kB per sec (the quantum RNGs produce 10 MB/s). I'm sure this device is good, but the random numbers Armory uses for the online computer are not only cryptographically secure, we throw in a bunch of other entropy from mouse clicks, system files, etc, to ensure even better entropy. If grandma was going to use Armory, we'd say just use the built-in RNG -- we use it and we trust it. If you're going to do some custom thing, use dice or cards. If you need to create millions of independent private keys, the HWRNG is probably the best choice. |
|
|
|
F*ck, after restart and started Armory again i see now sign transaction dialog. I don't understand this beta version... It's very buggy. Some dialogs work same: click -> nothing -> click -> ok -> click -> nothing -> click -> nothing -> click -> OK -> click -> OK It remains me a mining  Please send us your log file. Do so within the app (Help->Submit Bug Report). It will automatically include the log file when you do. When you click a button and it doesn't do anything, it's usually a very simple bug that we can fix but only if we see the log file. |
|
|
|
Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?
One at a time, although I can imagine a scenario where armoryd could be used to rapidly sign transactions. Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?
No. Classic double spend scenario. One of the transactions would be rejected. It wouldn't matter since the other version went through. Creating new transactions to sign before signing and broadcasting earlier ones is likely to lead to the later ones trying to spend the same coins and being invalidated. Per lockbox, you can only have one outstanding transaction at a time and know that it will be valid when you sign it. If we had coin control for lockboxes, it would be possible to do a few sequentially. A transaction specifies what coins are being spent and where they are going. Multiple copies of the same transaction are spending the same coins, thus if you try to broadcast a second copy (regardless of whether it's the same signatures or different), it will be rejected as a double-spend. |
|
|
|
Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.
That is in fact a collapsed column that I only found out about recently. If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows. That's interesting, and curiously enabling that and clicking to view / unview removes the blue hue on the title bar, but the small sliver remains. In any event, it's not a big deal. Would you, dear devs, say that 0.91.99.11 is RC worthy for 0.92? i.e. is it safe enough to replace the previous version I have running on my main machine? We had actually planned to turn 0.91.99.11 into 0.92 today, but we have some non-code-related things to do before we officially release it. Unless any critical bugs are found, we will simply be releasing 0.91.99.11 + polishing as 0.92 early next week. Therefore, I believe the only difference between .11 and the official release is the ugly version number that will be displayed on the main screen |
|
|
|
Alright, got it going. Did it just like you suggested. Thank you!
Glad to see it worked. Still kind of curious why it failed. Perhaps the .py file was in the right place, but you ran it from a different directory? Such as "python OfflineBundle/Install.py" (instead of cd'ing to the directory and running it there). I wrote the install script assuming it was executing from the same directory the script is in. Easy enough to modify the script to fix that though... If you want a desktop icon, simply create /home/<user>/Desktop/armory.desktop: [Desktop Entry]
Type=Application
Name=Armory
GenericName=Bitcoin Wallet
Comment=Advanced Bitcoin Wallet Management
Icon=/usr/share/armory/img/armory_icon_32x32.png
Exec=/usr/bin/python /usr/lib/armory/ArmoryQt.py
Terminal=False |
|
|
|
Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.
Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored. Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used). I hope my question here isn't too ignorant. Ultimately, the list of the public keys is all that matters. If know what public keys were used, you can recreate the lockbox. If you just know what wallets were used, you'll eventually figure it out, though it might take a script to do. Nonetheless you'll get your coins back. But this should be mostly irrelevant we assume that not all your devices are losing it or getting destroyed, or you might have bigger problems. As long as one of them still has the definition, you just export-import. Or backup the multisigs.txt file to save yourself some time. We just haven't made an option for it because we didn't feel it was necessary (though we'll have some automatic backup features with the new wallets, for saving address/tx labels and lockbox definitions) |
|
|
|
Hi, I can't seem to run "Install_DblClick_RunInTerminal.py" on raspbian from armory_0.91.2-rc1_rpi_bundle.tar.gz downloaded through armory secure downloader. python Install_DblClick_RunInTerminal.py
No installer found! Trying to to install an updated offline armory wallet so I don't have to have an additional armory install on my main pc just to sign a tx from an earlier armory version on the pi. Any ideas? Or just go the cross compiling route? I haven't tested this in a while, but I'm not sure why you'd get that error unless you moved the .py file outside of the unpacked directory. It only displays that error if there are no files in the unpack directory that start with "armory_". When I unpack it, I see about 30 deb files and "armory_0.91.2-rc1_raspbian-armhf.tar.gz". Do you see something different? P.S. - that .tar.gz file has everything you need. That install script basically only executes 3 commands: sudo dpkg -i *.deb
sudo tar -zxf armory_0.91.2-rc1_raspbian-armhf.tar.gz -C /
<another command to write the desktop file> Technically, you can run the first two yourself, and then manually start it from the terminal. |
|
|
|
Just an update on version 0.92: it's pretty much ready. But we are trying to get some non-code-related stuff together so that we can ensure a smooth rollout and be prepared for the influx of media attention and new users. Including the donation-matching activity I mentioned on this thread a week or two ago. One of the things I've been working on is a new page devoted to explaining the new multi-signature lockboxes. A lot of explanation. With pretty pictures! Feel free to check it out and provide feedback: https://bitcoinarmory.com/using-lockboxes I think this kind of documentation was long overdue, and I'll probably work on doing some of the more-basic feature documentation of Armory next. It's surprisingly pleasant to create using the combination of the program "shutter" in Linux and a Wordpress plugin that allows you paste images from the clipboard. Also, we are not planning for armoryd to be a stable feature in the 0.92 release but we plan to get it stable shortly afterwards. Delaying the release will not slow that down, but instead means that we may get a bit more in by release day. Perhaps that doesn't matter though, since most armoryd users will probably just checkout the repo instead of running from a given release. |
|
|
|
Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?
Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet. It bundles in that extra entropy with the Crypto++ RNG. That extra entropy alone should be well in excess of 256 bits. One question please: data are collected in moment only when i press button "Create" or before? I don't see any messages like "To move mouse, to press some keys" and don't understand where start and end time for real world entropy? It's collected in the background as you go through the create-wallet process. Only 32-bytes of entropy is needed, and the whole process collects far more than that, so there's no need to explicitly request the user do stuff. Though, from a marketing perspective, it's probably better to make the user aware that it's happening. |
|
|
|
|
This is not possible, by definition. The Base58 string is the hash of the raw public key, and all hash functions are designed to be impossible [infeasible] to reverse. This is why they are commonly referred to as "trap-door functions."
If you are going to create a lockbox, you will need to get the full public key from the wallet. If you have an address string, it has already been hashed, but the wallet always maintains the full public key. You can right-click on an address in your wallet properties, or simply use the address book within the "Create Lockbox" window to fetch the public key from one of your loaded wallets.
|
|
|
|
fbueller: What happens if your server is hacked and those public keys are modified with keys that belong to him? The server side script will be generating MultiSig addresses with 2 of 3 public keys belonging to the hacker.
So far, people seem oblivious to this particular attack vector being investigated by antonimasso. You can have the most hardcore security setup in the world, with an offline laptop buried 100 meters under Fort Knox, but none of it matters if the money destined to be stored there never makes it because an attacker swapped your deposit address. There are three primary issues at hand: - How to get money into secure storage
- How to keep money secure once it's there
- How to securely authorize movement of money
The second one is where people are mostly focused. The first and third are the ones that are subject to address manipulation, and provide a channel for an attacker to completely sidestep your cold storage. The attacker can't get the money that's already in the secure storage, but he try to divert new money on its way there, or divert money leaving the secure storage all by manipulating network traffic or compromising devices that distribute addresses. The payment protocol defends against man-in-the-middle attacks, but it still doesn't defend against your own server with the watch-only wallet getting hacked. With the payment protocol, each address needs to be signed by an X509 cert on the same server distributing the addresses. If an attacker gets control of that, he also can sign his own addresses to make them look legit. The technique I proposed allows one to provide a "fingerprint" of your offline wallet with every address, so that the other parties can verify your addresses if even your own address-distribution system is compromised. Unfortunately, the infrastructure is not there to support it, but I hope we can eventually develop such a system. |
|
|
|
Could this be done in Javascript? I want to generate all private keys client side. I want my users to control their private keys and their bitcoins.
Thanks
What I posted is mostly theoretical, unless you're going to have the users run your software, or you team up with wallet developers and standardize what I described above. The users still maintain full control of their own private keys, but it gives them the ability (and yourself) to provide an extra piece of metadata with your addresses that proves the address is controlled by you. More specifically, you publicly link a root public key to your identity, and then you can provide unique addresses to users for whatever purpose (in this case, for multi-sig signing authority) and the users will be able to verify that unique address actually belongs to you without them knowing any other addresses in your wallet. We are helping some organizations get setup with Armory as their backbone, and had planned to demo this in localized environments, mainly to ensure that users within an organization can recognize the addresses of other users/branches of their organization. We hope that we can make it a supported standard someday, as it has phenomenal security and privacy properties, and perfectly compatible with BIP 32. But at the moment, it will have to be developed and deployed in isolated environments until it catches on. |
|
|
|
|
About bug 2: this is intentional. You can only 100% disable it using --skip-announce-check from the command-line when starting Armory. We wanted to make it possible to fully disable it, but not too easy either. The reasoning is that in the case of a major network event (such as a hardfork), it is critical for us to be able to communicate with users (always offline-signed, of course!), to let them know how to deal with it. A hard-fork can leave open a period of non-consensus that a resourceful attacker could exploit to reverse a transaction.
This is communicated to you through the settings window, further down where you select the notification levels. Only critical security notifications will be retrieved from the server at the highest level, but you can fully disable it with the command-line option.
|
|
|
|
Thanks for all your comments. I guess there is no way to make this script hacker proof. I'll have to secure my linux server and hopefully catch in time the attacker.
There is a software solution, but it requires extra infrastructure and complexity to make it work. The gist of it is that you will always provide addresses from a BIP32/HD Wallet chain. You setup all parties to know the root public key of that chain and the software will recognize it (but not the chaincode!). Then when the multisig script is received by the users' software, it can come with the multiplier that can be applied to the root public key. If the included key that supposedly belongs to you match pre-verified root public key (EC-multiply) multiplier, then the user knows that the public key is truly owned by you. Due to the difficulty of the discrete logarithm problem, and attacker has no way to produce a valid multiplier that, when applied to the already-verified root public key, produces his malicious address. And without the multiplier, the software will prevent users from trusting that key. This is something we had hoped to build (slowly) into Armory -- a way to create localized webs of trust so that you can pre-verify a root public key, and then the party can optionally choose to reveal a multiplier that proves a given address is part of his wallet. This would be strictly optional, and none of the information reveals any other keys that party controls. |
|
|
|
|
Show Posts
