|
Dear Bitcoin Community,
I apologize I have been silent for such a long time. Current events and business pressures have kept me busy, as well as in an opaque cloud of uncertainty about Armory's future. I had looked forward to coming back to share with you good news and a fresh outlook, but unfortunately that's not the position that I am in. I could probably write a book about the depth and complexity of events of the past year, the lessons I've learned and the personalities I've dealth with. However, at this point it's all history, and I've always been more interested in planning the future than dwelling too much on the past.
Ultimately, Armory as a business was not managed well. We didn't raise money when we should have, and the Bitcoin space was not ready for the tech we produced (rather, the business economics didn't match up, yet). There hasn't been much public activity from us, because we were primarily focused on building a suite of enterprise security tools out of public view. These tools were impressive, but most of our target market was still in the exploratory phase and interested in proof-of-concepts, not actually holding $500M. Not yet. We couldn't make up for our missed opportunities to raise money to keep moving towards our vision.
Along the way, we accumulated a mess of legal and corporate complexity that has made it difficult to do anything constructive with Armory's intellectual property. These complexities make it risky for me to continue development, even if the money was there to pay me a salary. It has also made it difficult to be acquired by another company that shares my vision, that could provide funding to see its execution.
In the short-term, this is the end of the road for my involvement in Armory. My only real choice is to move on, and try to contribute my expertise elsewhere. After spending 80% of the last year primarily dealing with business operations, I welcome a return to the life of being a software guru, which is where my skill really lies. I also want to thank the other developers who were so loyal that they stuck around through missed payrolls way longer than any "regular employee" would. I'm proud that I was able to build and maintain such a loyal and devoted team to our mission.
In immediate future, Farhod (goatpig) has indicated that he will take over the reigns of the public side of the Armory project. He also has my utmost confidence and trust, and demonstrated a selfless passion for growing Armory for the sake of the Bitcoin community. Armory may be revived in the future, but in the short-term the rest of team has to move on without it.
I want to take this time to thank the community, which has been instrumental in getting us even this far. Even in its current state, the public version of Armory is a powerful, unique, and much needed piece of software which I think has made a significant impact on the Bitcoin ecosystem. And a large part of that is due to the testing, feedback, discussion and promotion provided by the community over the years. I hope to continue my involvement in some way and help the Bitcoin ecosystem grow in the future.
Alan Reiner
|
|
|
|
I tried deterministic signing a few weeks ago, and the transaction would not sign (some kind of error dialog suggesting a bad signature appears). Have any issues with that been dealt with?
There's a good chance the failure was due to the 1-in-256 bug mentioned in the changelog. (I never saw any problems but a couple of co-workers eventually did.) If you're still getting these kinds of errors, can you try without det signing? I saved the transaction at the time I tried it, and that same transaction worked afterwards without --detsign. But possibly the sig padding bug occurred literally that one time. Yes, this is most definitely related to the 1/256 bug. Sadly, the issue was not with the signature itself (it was, technically, correctly padded for DER/BIP66), it was our C++ code which expects exactly 32-byte BE integers. Half the time it is 33 bytes and it was properly truncated, but there was a 1-in-512 chance of an r- or s-value actually being 31 bytes (when the top 9 bits of the BE value are zero), and Armory wasn't adding zero-padding back to it make it 32 bytes. So our crypto engine was rejecting it for being the incorrect size (Armory aborts if any sig fails verifcation). Since every signature has an (r,s) pair, there was a 2-in-512 chance of failure for any given signature. So a tx with one input had 1-in-256 chance of failing, a 3-of-5 multisig spend with 85 inputs had approximately 50% chance of getting a rejected transaction. This was sporadic in the past, because we did not use deterministic signing. We'd occasionally get reports of a failed signature, but it would go away one of the next times they signed they samed the exact same tx -- because they got to re-roll the RNG on new rs-values. However, now with deterministic signing, if signing a transaction once fails, it will always fail. This made the problem more obvious and less likely to be related to quirks with custom builds, version mismatches, etc. |
|
|
|
A ton of reliability/robustness updates in version 0.93.2. Available in the secure downloader now, but the following links do work: Armory 0.93.2 for Windows XP, Vista, 7, 8+ (64-bit) Armory 0.93.2 for MacOSX 10.7+ (64bit) Armory 0.93.2 for Ubuntu 12.04+ (32bit) Armory 0.93.2 for Ubuntu 12.04+ (64bit) Armory 0.93.2 for RaspberryPi (armhf) Armory 0.93.2 Offline Bundle for Ubuntu 12.04 exact (32bit) Armory 0.93.2 Offline Bundle for Ubuntu 12.04 exact (64bit) Armory 0.93.2 Offline Bundle for RaspberryPi (armhf) Armory 0.93.2: Signed hashes of all installers Nothing should have materially changed, no database upgrades, etc. However, Ubuntu 12.04 support has been restored (the offline bundles for 0.93 and 0.93.1 both did not work with Ubuntu 12.04 due to using the full breadth of features available in C++11/gcc4.7.3). Also, I should mention that due to the new debian packaging process, it appears I can no longer use dpkg-sig to sign the .deb files. This step was redundant anyway, since all the final installers/tarballs are covered by the Bitcoin signature (for secure downloader) and signed sha256sum list. We will spend a bit of time looking to fix this, though I didn't feel it necessary to delay this release over it.
The bugfix notes: https://s3.amazonaws.com/bitcoinarmory-media/changelog.txtVERSION 0.93.2
Released June 7, 2015
- Fixed signing/broadcast failures on large transactions
Due to a signature padding issue, 1-in-256 signatures was failing
verification checks, leading Armory to abort the transaction. This
was most frequently observed in large transactions with 100+ sigs.
- Fixed issue with multiple outgoing transactions
Creating and broadcasting multiple transactions sequentially was
causing issues when zero-confirmation change had to be used for
subsequent transactions.
- Restored compatibility with Ubuntu 12.04 (GCC <4.7.3)
Introduction of C++11 advanced features into the BlockDataManager
in 0.93 made our Ubuntu builds incompatible with 12.04. With this
release, building on 12.04 still requires a bit of work, but our
downloadable .deb packages installs on 12.04 again. To build, see:
http://askubuntu.com/questions/113291/how-do-i-install-gcc-4-7
- Armory Daemon (armoryd) reliability fixes
A variety of reliability issues with armoryd were resolved,
primarily related to the new database and back-end introduced
in 0.93 (primarily getledger and getledgersimple).
- Multi-sig fee calculation fixed, warnings updated
Multi-signature transaction creation code was not
calculating and enforcing sane fees. Many users inadvertantly
tried to send transactions with no chance of success, and with
no useful information when it did fail.
- Uses floating fee estimation via RPC call in auto-bitcoind mode
When Armory is running Core in the background, it now uses
Core's floating fee estimation capability to recommend
acceptable fees to the user
- Deterministic Signing
Deterministic signing (RFC6979) was enabled by default in 0.93.1,
but the command-line arguments were not hooked up to be able to
disable it. You can now use --enable-detsign or --disable-detsign
to force the selection.
- Fix for lockbox change addresses
Lockbox transactions created with armoryd were sending change
back to the lockbox, but without P2SH. This is harmless, and
Armory is smart enough to handle it gracefully, but unintended.
|
|
|
|
|
This reminds me that we should probably remove all torrent-related code from Armory for 0.94. It is no longer needed with Core 0.10+ (headers first), and it was actually designed such that you could remove the torrent code directory and Armory would bypass trying to use it. We wanted to wait for sufficient people to have upgraded to Core 0.10 and Armory 0.93+, and I think that's likely to be the case now (we couldn't upgrade the Core links in the secure downloader, without inadvertantly leading to 0.92 users installing Core 0.10 which doesn't work).
|
|
|
|
Whole thing crashes when scanning tx's. CPU/Memory usage goes vertical-ish. Possibly the source of offence: (python:3377): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion `value >= min && value <= max' failed
Killed Logs are otherwise uneventful Did you pull the latest ffreeze? There was a problem with thread synchronization a couple days ago, and we all experienced the exact same issue. As of yesterday (when I posted this thread) that was fixed and no one else had the issue. Did you wipe the database? Is the version number 0.93.99.1? |
|
|
|
So, preliminarily 0.94 has stabilized, but it hasn't seen much testing outside "the lab." I would like to invite folks who can build, to checkout the ffreeze branch (feature-freeze) and try it out while we continue our internal testing. https://github.com/etotheipi/BitcoinArmory/tree/ffreeze++ In 0.94 the Armory home dir databases folder should now be less than 150 MB! This is what we refer to as "headless fullnode"
-- All database formats have changed. You must rebuild your databases! (and we don't have a clean way to help the user transition from the GUI).
Therefore, to use/test 0.94, please change your datadir, dbdir, or delete the databases folder in the Armory home directory. Though, you might want to just move the directory for the moment, in case you have to go back. Luckily, since the new version uses so much less space, it's not a big deal to create another directory for it! It's also is a heck of a lot faster to start up Armory the first time once Core is sync'd, since we're not building a 30+ GB database anymore. It's called "headless fullnode" because it's the same as previous "fullnode" version of Armory, but without maintaining it's own copy of the blockchain (of course, if you run supernode it will maintain your 2x-3x sized DB, but that's not the default Armory mode). Along with this, there's a ton of bug fixes and stability enhancements. We're looking forward to the database design finally settling down and stabilizing. PLEASE checkout the ffreeze branch and help test! Once we get a little bit more testing we'll do a semi-official testing release with a proper bug bounty! |
|
|
|
|
The short answer is that you need to create wallets in the Armory GUI first. Run regular Armory (ArmoryQt.py), use the interface to make a wallet, backups, perhaps make and keep only a watch-only copy for your armoryd.py server. When you start armoryd next, it will load whatever wallets you created in the GUI (they share the same home directory). If you are using for offline signing in some capacity, you should have the full wallet in the home directory of the offline computer, and a watch-only copy of it in the home directory of the online computer (I assume the armoryd server is on the online computer).
You will not be able to use wallets from other applications. Armory uses its own wallet format that is not compatible with other apps.
|
|
|
|
And that therefore, if I want to create two (or more) transactions from a watching-only wallet, such that both are spendable without conflicting with each other, then it's my responsibility to use coin control to ensure they spend from different addresses?
Yes. I do that sometimes. It works fine, if you are careful, but if you use the same input twice you cannot broadcast the second transaction (and do not get a clear error message). We took the easy way out on this topic (and didn't address it), because the alternatives are more complex under the hood and in the UI. If you allow Armory to arbitrarily lock inputs from being spent on subsequent transactions, you have to somehow represent to the user the state of the "locks" on your wallet. This includes some super-arbitrary amount (even though your tx is 1.3 BTC, you have 21.32 locked), and it also leaves open confusion when you end up not signing the transaction (changed your mind, made a mistake in the original and want to recreate it, etc) and now you have coins that are locked unnecessarily and you need to be able to reset the lock state. If it's not represented clearly, then you have new users who say "what's this Create Unsigned button do?" and they end up with locked coins and emails to us asking why fund are inaccessible. If there was at least a way to create a tx for X and then always lock exactly X, that would make it reasonable. But in most cases you have to lock some unexplainable amount more than your transaction is, and in some cases it's just not possible to do multiple offline tx (if you only have one input). At the end of the day, if you need to create multiple simultaneous offline transactions, you should be sophisticated enough use coin control and understand the limitations. On that note, we should have an input-level coin-control interface... soon...? Stay tuned. |
|
|
|
Just got a pop-up in Armory for 0.93.1... so are the issues fixed?
I was just about to post a message about this. We believe we've resolved a bulk of the issues. It's not perfect, but most of the issues were related to a database issue that has been resolved. Please try it and let us know. has the dependency fix for Ubuntu 12.04, 32 bit been implemented? I don't think so. A more permanent fix is about to enter the testing phase. Until then, a workaround is discussed here if you want to give it a try. It worked for me when I gave it a try a few days ago. it's actually the online version that is giving me the dependency error. It should work for both versions. EDIT: Derrrrrrrrp. Was conflating two issues. Sorry about that. Online 32-bit is still busted no matter which OS you use. What I posted should work for 32-bit offline and 64-bit online setups. ok, getting frustrated now. my online 0.92.3 online totally stopped working on 12.04, 32 bit. when are we going to get that dependency required i've been asking about? 12.04 and 32-bit are both broken (for different reasons) in 0.93+. You will have no choice but to use 0.92.3. We should have a testing version of 0.94 soon which will work on 32-bit (Linux and Windows), but 12.04 still won't work yet. Unfortunately, it's more than "a missing dependency". We're working on a solution, but it's requiring a reworking of the build and packaging system |
|
|
|
Our apologies. I should've updated the website to indicate that the 12.04 bundles are not going to work with 0.93 or 0.93.1. You need to use 0.92.3, which is fine because all the features you need you for offline mode are unchanged in 0.93. We're actively working on a fix for getting things to run on 12.04 again, but it will likely have to wait for the next major Armory version (we need it to work on 12.04 for our Gitian build process, anyway).
Etotheipi, Just to make sure I understand you correctly. For those of us running Ubuntu 14.04 LTS on a Cold Storage PC we need to install Armory Offline Bundle version 0.92.3. And just for further clarification, for those of us running Ubuntu 14.04 LTS on an ONLINE PC we need to install Bitcoin Core 10 and Armory 0.93.1 on the ONLINE PC. In short, it does not matter that my Armory versions between my ONLINE PC and my OFFLINE PC do not match since one is running Armory 0.93.1 and the other one is running Armory Offline Bundle version 0.92.3? I look forward to hearing back from you as to whether or not I am understanding all of this correctly. Thanks in advance. Yes, mixing versions online and offline is fine. As long as they both >0.92 (so they have the same offline/multi-sig message formats) |
|
|
|
|
Our apologies. I should've updated the website to indicate that the 12.04 bundles are not going to work with 0.93 or 0.93.1. You need to use 0.92.3, which is fine because all the features you need you for offline mode are unchanged in 0.93. We're actively working on a fix for getting things to run on 12.04 again, but it will likely have to wait for the next major Armory version (we need it to work on 12.04 for our Gitian build process, anyway).
|
|
|
|
Certainly did (see below). I just can't figure out why it was working and now it isn't.  Although the software should be okay using paths that have spaces in them, I would recommend moving/renaming the Bitcoin Core location to a path without spaces. Please try it and let us know if that resolves it. |
|
|
|
Just got a pop-up in Armory for 0.93.1... so are the issues fixed?
I was just about to post a message about this. We believe we've resolved a bulk of the issues. It's not perfect, but most of the issues were related to a database issue that has been resolved. Please try it and let us know. |
|
|
|
|
Show Posts
