Bitcoin Forum
July 21, 2024, 04:53:26 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Bitcoin / Armory / The End of the Road for Armory on: February 03, 2016, 07:12:10 PM
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
2  Bitcoin / Armory / Armory 0.93.3 with BIP62 compliance on: October 29, 2015, 04:53:17 PM
Armory 0.93.3 with BIP62 Released

Download links below, but as always, please use the secure downloader within Armory under "Help"-->"Update Software" or on the Announcements tab on the main screen.

Implemented low S-value signatures to work with Core 0.11+:
Armory now implements all components of BIP62 compliance in its signing code. Also includes a correction path to fix non-compliant signatures when broadcasting transactions signed by older versions of Armory. Thus, offline systems do not need to be updated, as long as the online system is.

Critical Bug Fix: "bitcoin:" URI handling of Multisig/P2SH addresses:
The code that handles clicking on a "bitcoin:" link outside Armory was improperly handling Multisig/P2SH addresses, and would prefill a valid but incorrect address.

Transaction confirmation fix:
The number of confirmations was not being calculated properly for fee estimation in some contexts.

No more support for Mac/OSX:
Due to the high resource consumption of maintaining the Mac builds and lack of continued support from the Qt team for Qt4/PyQt4, we have no choice but to pull OSX support until we can upgrade Armory to Python3 and Qt5.

(OSX support re-added)

  Armory 0.93.3 for Windows XP, Vista, 7, 8+ (64-bit)

  Armory 0.93.3 for MacOSX 10.7+ (64bit)
  Armory 0.93.3 for Ubuntu 12.04+ (32bit)
  Armory 0.93.3 for Ubuntu 12.04+ (64bit)

  Armory 0.93.3 for RaspberryPi  (armhf)
  Armory 0.93.3 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.93.3 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.93.3 Offline Bundle for RaspberryPi  (armhf)
  Armory 0.93.3: Signed hashes of all installers

3  Bitcoin / Armory / [Bugfix Release] Armory v0.93.2 on: June 08, 2015, 01:54:24 AM
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:

VERSION 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:

   - 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.

4  Bitcoin / Armory / Starting preliminary 0.94 testing - "Headless fullnode" on: May 13, 2015, 10:54:19 PM
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.

++ 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!

5  Bitcoin / Armory / [ANN] Armory 0.93.1 Official Release on: February 21, 2015, 04:56:03 PM
Armory 0.93.1 is Now Available!

Download links below
Signed tag "v0.93" in
Upgrade with Secure Downloader in existing Armory is preferred (Help->Update Software)

The website has not been updated.  Sorry!  We changed the website a couple months ago and forgot that we don't have the scripts worked out for it yet.  Our updates only hit the secure downloader, not the website!  Will have a manual update to the website soon.  (as a workaround, you can always get the version from the website and use the secure downloader to immediately upgrade)

I'm pleased to announce the final release of Armory v0.93.  This release is especially relevant to the D&TD forum, as it implements a database mode we call "supernode" which does arbitrary blockchain lookups/slicing (instant importing & sweeping of any arbitrary address/script/wallet).  Along with it comes a more-robust Armory daemon ( which can be used remotely via JSON-RPC or modified in-place with your code to power your web service, exchange, etc.  Using along with the --supernode flag gives you a full-featured Bitcoin management platform on which to build your service with no external dependencies (such as for arbitrary balance lookup).  Your service can now integrate hot wallets, cold wallets, watch-only wallets, message signing, unsigned tx creation, and all multi-signature lockbox features.

NOTE: If you already use Armory, always get the latest version from the "Secure Downloader"  (Help->Update Software).  The links below are only for those who do not yet have a trusted version of Armory (or running a version so old it doesn't have the secure downloader).  If you use the download links below, please check the GPG signatures of the last link and confirm hashes!

  Armory 0.93.1 for Windows XP, Vista, 7, 8+ (64-bit)
  Armory 0.93.1 for MacOSX 10.7+ (64bit)
  Armory 0.93.1 for Ubuntu 12.04+ (32bit)
  Armory 0.93.1 for Ubuntu 12.04+ (64bit)
  Armory 0.93.1 for RaspberryPi  (armhf)

  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.93.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.93.1: Signed hashes of all installers



Released Feb 21, 2015

   - Compatible with Bitcoin Core 0.10 and "headers-first"
        The most recent version of Bitcoin Core includes a parallel network
        synchronization feature called "headers-first" which is incompatible
        with previous versions of Armory.  This version is required to use
        Bitcoin Core 0.10 and newer.  Torrent-based bootstrapping will
        be removed in the next version of Armory.

   - New Scalable Blockchain Engine
        This version of Armory will look very similar to previous versions,
        but actually has a completely new, scalable database engine (using
        LMDB instead of LevelDB).  The engine can now handle wallets with
        millions of addresses and transactions!

   - Rebuild Required (but much faster!)
        The new database engine requires rebuilding and rescanning.  You
        will be prompted as soon as you start up 0.93 the first time.  
        However, due to the new blockchain engine, this process is
        considerably faster than before.  Generally less than 45 min!
        NOTE: This is NOT redownloading the blockchain. It is only
        rebuilding the local databases that Armory creates for itself.
   - Improved Threading and Reliability
        With the new backend comes overhauled inter-thread messaging.  This
        resolves a whole class of reliability issues that Armory has had in
        the past, especially with large wallets and transaction histories.  

   - Address and Wallet Importing in Background
        Importing wallets and addresses now induces background scans which
        do not disable the interface (previously forced you into offline
        mode for the duration of the scan).  
   - Supernode Mode
        Use the "--supernode" flag before creating the databases to create
        a supernode database that enables instant address & wallet import.
        This is an enabling feature for high-volume, consumer facing apps
        and services to be built on Armory, such as exchanges and block-
        explorers.  NOTE: Running with --supernode will result in an Armory
        database approximately double the size of the blockchain!  
   - Improved
        The daemon version of armory,, has been fully updated and
        tested with the new database engine.  Also includes a new "webshop"
        sample application that demonstrates basic usage of to
        collect & verify payments, generate unsigned transactions, etc.

   - RFC6979 Deteministic Signing (via CLI args)
        Armory now has a deterministic signing mode based on RFC6979.  
        The code passes all test vectors, but disabled by default pending
        more rigorous review.  It can be enabled using the --detsign
        command-line flag.

Thanks to everyone on the Armory team for their hard work in developing, tweaking, testing, and more testing of the code in this release.  And especially goatpig, who was instrumental in upgrading the database engine and responding extremely quickly (and effectively) to the variety of issues you would expect to pop up when overhauling such a large part of the code base.   He's even got more tricks up his sleeve, for 0.93.1.  Stay tuned!
6  Bitcoin / Armory / Armory 0.93 testing release! (with 0.05 BTC bug bounty) on: January 09, 2015, 10:29:37 PM
Armory 0.93 Testing Release  (
Bug Bounty Started:  0.05 BTC per bug!

REMEMBER:  Download links are at the bottom but you can get the new version through the secure downloader.  Armory will check the signatures for you!

NOTE:  If you upgrade Core to 0.10 you must use this new version of Armory.  Armory 0.92.3 and older does not work with headers-first!

Hi all,

Finally, we have a solid testing release for 0.93.  This version has taken us quite a long time because it represents a substantial reworking of the blockchain engine as well as the inter-thread communication.  Much of Armory looks the same as it did in previous versions, but now it's 100% scalable, handling wallets that even have a 1,000,000+ addresses and transactions in their history.  It also does things in the background such as address and wallet imports, which no longer force you offline.  Because of the new threading engine, there's a whole class of stability problems that don't exist anymore (specifically BDM timeout errors that cascaded into unusability and required restarting Armory;  usually with larger wallets).  

Special thanks to goatpig and njaard who have spent many months the new blockchain engine!

Especially important for our more-hardcore users, we now have a "supernode" mode, that doubles Armory's DB size, but indexes all scripts on the blockchain.  If you delete your databases and start Armory with "--supernode", you'll build a DB that does instant importing of addresses and wallets.  It could be used to build a block explorer or an Electrum-style server for feeding lite-nodes (for everyone who's asked about lite-Armory, completion of supernode was a critical milestone that needed to be crossed to even think about it).

KEEP IN MIND:  This new version uses a new DB engine (LMDB instead of LevelDB).  This means that the 0.93 databases are incompatible with any already-built databases.  And it won't delete them automatically -- you must do it manually if you don't want both versions.  This was done to accommodate users that have to jump back to 0.92 if the latest version doesn't work for them.  We recommend simply using a new datadir for testing.

REMEMBER:  You can always get the new version through the secure downloader.  Armory will check the signatures for you!  Download links are provided here as a convenience for those testing in non-secure environments.

NOTE2:  I have no expectations of the OSX build working.  If it does, it would be a blessing.  We've had to stir some things up, and didn't have time to solidify before this testing release.  It'll come soon!

  Armory for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory for MacOSX 10.7+ (64bit)
  Armory for Ubuntu 12.04+ (32bit)
  Armory for Ubuntu 12.04+ (64bit)
  Armory for RaspberryPi  (armhf)

  Armory Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory Offline Bundle for RaspberryPi  (armhf)

  Armory Signed hashes of all installers

Semi-official changelog:

Released Jan 9, 2015

   - New Scalable Blockchain Engine
        This version of Armory will look very similar to previous versions,
        but actually has a completely new, scalable database engine (using
        LMDB instead of LevelDB).  The engine can now handle wallets with
        millions of addresses and transactions!

   - Compatible with Bitcoin Core 0.10 and "headers-first"
        The most recent version of Bitcoin Core includes a parallel network
        synchronization feature called "headers-first" which is incompatible
        with previous versions of Armory.  This version is required to use
        with Bitcoin Core 0.10 and newer.  Torrent-based bootstrapping will
        be removed in the next version of Armory.

   - Improved Threading and Reliability
        With the new backend comes overhauled inter-thread messaging.  This
        resolves a ton of stubborn stability issues that Armory has had in
        the past, especially with large wallets and transaction histories.  

   - Address and Wallet Importing in Background
        Importing wallets and addresses now induces background scans which
        do not disable the interface (previously forced you into offline
        mode for the duration of the scan).  
   - Supernode Mode
        Use the "--supernode" flag before creating the databases to create
        a supernode database that enables instant address & wallet import.
        This is an enabling feature for high-volume, consumer facing apps
        and services to be built on Armory, such as exchanges and block-
        explorers.  NOTE: Running with --supernode will result in an Armory
        database approximately double the size of the blockchain!  
   - Improved
        The daemon version of armory,, has been fully updated and
        tested with the new database engine.  Also includes a new "webshop"
        sample application that demonstrates basic usage of to
        collect & verify payments, generate unsigned transactions, etc.

7  Bitcoin / Development & Technical Discussion / M-of-N passwords to generate wallet encryption key on: June 11, 2014, 09:32:11 PM
Today I was thinking about the idea that you could implement a software-based multi-factor encryption key for a wallet.  What comes to mind is Shamir's Secret Sharing, but in reverse.  I'll explain what that means after I explain basic SSS.

Modify wallet encryption, which normally requires the user to enter a password, and then key stretches it into a symmetric encryption key (such as AES256) and uses that to encrypt the wallet private keys.  What I would like is:  during wallet setup, you can have 3 passwords entered, and any 2 of them would be sufficient for the system to compute the AES256 encryption key.   Of course, it would be nice to implement any M-of-N.

The idea is that 3 employees of an [wing of] an organization would be responsible for managing either a single-sig wallet, or a single key of a multi-sig wallet.  In order to gain access to the offline key to sign transactions, the wallet will need to be decrypted, but the decryption key can't be calculated from any single employee's password.  

Shamir's Secret Sharing is a mechanism by which a secret piece of data is interpretted as the highest order coefficeint of a polynomial, and then points of that polynomial are distributed and stored separately.  For instance, you store the secret as the slope of a line, and then you write down three points of the line on separate pieces of paper.  If you have any two pieces of paper, you have two points on the line and can compute the slope--which recovers the secret.  This would be 2-of-3.  You can do this with any M and N, using N points on an (M-1)th order polynomial.

While this concept is easy to visualize like we did in high school, you can't use floating point numbers because of precision issues.  Instead, you do all operations on finite fields, which are really just modulo-arithmatic, cyclic groups.  You simply define all operations to be on integers between 1 and some large prime N, define division to be   a/b = a * bN-1, and then you can implement all the algebra identically.  I won't go into the details here, but this is how SSS is implemented in crypto systems.  However, usually the prime N is chosen ahead of time, and known by the device, so it knows which finite field to use to combine the points.  

Rephrased goal:  
Shamir's Secret Sharing is a process for converting a secret into M-of-N shares to be distributed.  What I want is a process for converting N shares (user passwords) into an M-of-N secret.  It's the inverse of the problem being solved by SSS.

Half-way there
If this was 2-of-2,  3-of-3, or M-of-M, stock SSS would work.  Say for 3-of-3:  the system collects all three passwords when the wallet is created, computes the highest-order coeffiicent of the parabola created by the hash of all three passwords (perhaps using the first four bytes of the hash as the X-value, and the remaining as the Y-value), then uses that as the encryption key for the wallet.  When all passwords are entered, the system can compute this value, decrypt the wallet, then destroy it.  This works, though there are simpler ways to combine mulitple passwords.   But how do you do arbitrary M-of-N?  

But this doesn't work for M-of-N where M is not equal to N.  For 2-of-3:  you would like to compute a slope that could be computed from any two of the three points, but the three points are not co-linear in a pre-defined finite field.   One way would be to collect all the passwords first, and then figure out a set of finite field parameters for which all three points are colinear (for simple prime-based finite fields, try to find a prime N such that they are colinear).  Store the FF parameters in the wallet, and the wallet will use that data when two passwords are entered.    But this feels like a hack.

Unfortunately, my googling skills are failing me -- as I keep running into a bunch of unrelated things.   I feel like this must be a solved problem, and I just need to find the right documentation of it.

The best alternative is to simply not let users create passwords, but create a secure encryption key, then use SSS and put the shares onto smartcards.  In the institutional security world, this is at least how backups are made when using HSMs (and how Armory does fragmented backups of its wallets).  In this case, we're simply trying to expand on the user-password concept to be executed on consumer PCs.  At the moment, HSMs don't exist in the BTC world, and while they may, it would still be cool to have a solution for this problem here.

Another alternative, for small M and N is to simply store all N-choose-M multi-encrypted forms of the encryption key.  For instance, for 2-of-3, the encryption key will be randomly generated by the system, and then it will be stored 3 times in the wallet, each one encrypted with a different 2 keys.  Decrypting would simply be matter of trying to decrypt all three keys and picking the one that works (if any).  But this is an even bigger hack, and it doesn't scale very well (though modern computers could handle most use-cases pretty easily if there was no additional key stretching).

I recognize we're still talking about a single piece of consumer hardware that could be compromised by malware, or someone with DMA could swipe the key from RAM once all passwords are entered, etc.  The goal is to provide a mechanism whereby multiple people are required to access the system, and together they monitor all interactions with the system and verify that no one is tampering/manipulating it.  Is it failproof?  No.  But it still prevents one person who temporarily gains access from pulling the key off the disk, even if they have one password.  If proper access control is exercised, this might provide another tool for implementing segregation of duties, in-place-of or in-addition-to multi-sig transactions.  

In the future, this might be moot, since orgs will move to HSMs which are all tamper-proof, destroy the private keys if you try to open, implement similar M-of-N access control, etc.  But for consumer hardware, I think this could be pretty strong.

8  Bitcoin / Development & Technical Discussion / [ANN] Armory Multi-Sig with Simulfunding [BOUNTY 0.03 per bug] on: May 13, 2014, 05:35:30 AM
    Armory Multi-Signature "Lockboxes" with Simulfunding
    Testing Bounty - 0.03 BTC per bug (up to 1.5 BTC)  

    Installers for version 0.92 (pre-release
      Armory for Windows XP, Vista, 7, 8+ 32- and 64-bit
      Armory for MacOSX 10.7+ 64bit
      Armory for Ubuntu 12.04+ 32bit
      Armory for Ubuntu 12.04+ 64bit
      Armory for RaspberryPi (armhf)

    Offline Bundles:
      Armory Offline Bundle for Ubuntu 12.04 32bit
      Armory Offline Bundle for Ubuntu 12.04 64bit
      Armory Offline Bundle for RaspbianPi (armhf)

    Signed Hashes:
      Armory Signed hashes of all installers

    Check out our Lockbox tutorials:

    EDIT:  Thanks to SimonBelmond for sending us a link to this intro Armory multi-sig intro video:
    EDIT2:  We actually redesigned the interface/dashboard, so his video doesn't show what the latest version looks like, though the process is the same

    I am pleased to announce that Armory has finally completed the design and initial testing of "multi-signature lockboxes" in Armory.  This is the first truly generic, fully-decentralized multi-signature interface available for any cryptocurrency.  Armory is innovating multi-sig the same way it innovated offline wallets -- taking a concept that is inherently complex, and making it about as simple as it can be.  It is still an advanced tool, but makes available features that haven't existed before!

    Not only that, but the interface works seamlessly with hot or cold wallets, alike!   To understand how powerful this is, consider that you could independently setup 7 different laptops in five vaults around the world, and a signature is required from physically visiting each one, in order to move any of the money.   Yet you can receive money to it and track its balances safely from an online computer (just like a watching-only wallet, it only has public keys).    Or you can setup a 2-of-2 with hot Armory wallets and simply improve your security for the funds held by you and your spouse.  Or somewhere in between.  Really, the flexibility is astounding, and this solution is the "manual transmission" version that requires no third-party services.  It could be executed by any number of anonymous parties using nothing but email or pastebin.  

    The interface enables the following operations (and all work as expected with offline/watch-only wallets):

    • Create Lockbox:
      • Participants:  Provide Public Keys
      • Organizer: Collect Keys, Define Lockbox, Distribute
      • Participants: Import LOCKBOX definition
    • Deposit into lockbox (regular):  
      • Use regular send-BTC interface
    • Deposit (simulfunding, for certain contract types):
      • Participants: Create Promissory Notes
      • Organizer:  Merge Notes to Create Simulfunding Tx
      • Participants: Review and Sign Simulfunding Tx
    • Spend:  
      • Organizer: Create Proposed Spend
      • Participants: Review and Sign
      • Organizer: Collect Signatures & Broadcast
    This process uses no centralized servers or third-party services!  Instead, it provides you with chunks of ASCII-armored text which can be circulated to participants via email (inline) and/or saved to USB key to be taken to offline computers to retrieve signatures.  In the future, Armory Technologies, Inc, will be providing servers to facilitate the data exchanges and simplify the process, though we wanted to make sure that a [usable!] truly decentralized solution was available at all times  [Plus, all automated solutions will just build off the manual solution]

    • This does not use BIP32 determinstic key chains!  A lockbox is like a single multi-sig address.  If you do not spend the full amount, change is sent back to the same lockbox.  With regular addresses, this is a privacy concern.  With lockboxes, the privacy issues are mostly unavoidable:  the vast majority of transactions on the network still single-sig, thus a multi-sig change address would be obvious even if a new multisig address was created to receive the change.  By the time this matters, Armory will have the BIP-32 linked wallet stuff in place.
    • All message formats changed, including those used for regular offline transactions (which are a special case of multisig: 1-of-1).  If you upgrade your online system that creates offline transactions, you would have to update your offline computer to be able to read and sign these new transaction messages.

    Other notes:
    The best way to do testing is to run a couple instances of Armory at the same time.  All Armory instances on the same computer can share a single Bitcoin-Core instance, but must have separate --datadir=  settings.  Additionally, you will have to set a random --interport to avoid Armory detecting the already-open instance and aborting.  For instance, I do testing with 3 Armory instances, I run them as follows:

    python --debug --testnet --datadir=~/.armorytest1 --interport=9913
    python --debug --testnet --datadir=~/.armorytest2 --interport=9914
    python --debug --testnet --datadir=~/.armorytest3 --interport=9915
    The datadir paths must exist before running the above!  If you corrupt your databases by accidentally running on the same datadir with different interports, use the --rebuild option to fix it.  It only takes a few minute on testnet.

    And now for the pretty pictures:

    Collect public keys from participants to create a lockbox:

    Manage multiple lockboxes:

    Collect signatures from all devices/parties:

    Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders

    Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.

    As you can see, the final transaction has three different input wallets, and change back to those wallets as well.  
    9  Bitcoin / Press / [2014-04-07] Bloomberg TV: Alan Meckler (MediaBistro) and Alan Reiner (Armory) on: April 08, 2014, 10:22:27 PM
    Got the joy of being invited to speak on Bloomberg TV after giving my talk on best security practices.

    April 7 (Bloomberg) –- Mediabistro Chairman Alan Meckler and Armory Technologies CEO Alan Reiner discuss the world’s biggest Bitcoin conference. They speak with Trish Regan on Bloomberg Television’s “Street Smart.” (Source: Bloomberg)

    FYI:  The host (Trish) was obviously quite skeptical about Bitcoin.  That clip was preceeded by an description of recent Bitcoin woes, that included the "plummeting value" and that Bitcoin had been "banned in China and Russia."  Glad we got to offer a little counterbalance.
    10  Bitcoin / Armory / [TEASER] Multi-Sig Lockboxes! (Now with Simulfunding!) on: April 07, 2014, 12:20:24 AM
    Introducing Multi-key Lockboxes by Armory Technologies, Inc.

    Armory Technologies, Inc. has come a long way since we incorporated 9 months ago.  We now have 5 full-time developers, and for the first time since I started Armory I was able to take my hands off the steering wheel, and focus on innovating, instead of just bug fixes and testing.  This gave me the opportunity to do something I've been wanting to do for a very long time... Multi-signature transactions!.  

    I've been busy getting a form of multi-sig implemented before the conference this week (Apr 7-8), but without the new wallet format, yet.  This isn't a waste of time, because this kind of interface should be available for one-time escrow situations where you won't need a full wallet, anyway.  And in the short-term, it can used for low-volume, secure savings (when it's ready in a few weeks).

    In the end, it turned out to be more than just a demo: it's actually quite usable!   See screenshots below.  If you can compile from github, you can play with it on the "multihacker" "devel" branch.  More details below.

    Keep in mind the multi-key lockbox interface is an advanced tool.  All manual data exchange, multiple steps, multiple wallets, etc.  But just like offline transactions, I think we've taken something that is inherently quite complex, and made it about as simple as it can be without centralization.  We will be providing a server-assisted mode in the future which will make this far easier, but it will always be usable without a 3rd party service.

    UPDATE: lockboxes are now being updated on the "devel" branch

    Multi-key lockboxes:

    WARNING: This is not ready for real money!  I have powered through the design process to get it demo-ready for the conference under time constraints.  Over the next couple weeks, we will be fixing all of it's limitations, reduce bugs, add simulfunding, and test it!  Until then, only use this with testnet!

    A "lockbox" is created from a list of public keys (and some meta-data), and then anyone can put money into the lockbox.  To spend from the lockbox, one party initiates a transaction, and then circulates it to collect signatures.  Whoever adds the last signature can then broadcast it.

    All data exchanged looks like the following example lockbox (go ahead and import it, see what happens):

    Some great things about the current state of "Multi-key lockboxes":
    • No central points of failure.  Private keys never exposed to any other device, and only used at time of signing much like offline transactions.  Armory lets you collect all public keys from all devices/parties, and creates a multi-signature address to deposit money in the lockbox.  
    • Totally online/offline agnostic!  All circulated transaction data is treated as "offline" transactions, and thus includes data needed for secure offline review and signing!  You can mix any kinds of wallets you want, even do a 5-of-5 spread out between cold laptops kept in bank vaults in 5 different countries! (please don't do this yet, but it technically will be possible soon)
    • Uses ASCII (base64) text blocks for easy exchange inline via email.   Armory used to use BIP 10, but that had some serious limitations.  A new format was created that accommodates all the quirks and security issues of exchanging data and offline signing (especially lots of complexities if P2SH is involved).
    • Change is handled automatically:  It's handled by sending the change back to the exact same lockbox, which all remains transparent to the user, as always.  This is certainly "address reuse", but until we have multi-sig/linked wallets, we have no other choice unless you require the user to spend all or nothing.
    • Completely decentralized:  We will add a server-assisted mode in the future, but we wanted to guarantee that it's theoretically usable if no servers exist.

    Some current limitations of what's there:
    • Plain multi-sig only -- limited to 3-of-3 on mainnet:  P2SH is theoretically supported, and I have designed all the data formats, and blockchain code to be able to accomodate P2SH.  But none of it has been tested, and requires a bit more complexity under the hood to make it work.  However, supporting P2SH will be required to go above 3-of-3 on mainnet, so it will be done. Eventually
    • No simulfunding yet:  Certain types of contracts require both/all parties to send coins to the lockbox simultaneously (in the same transaction).  Again, I have designed the data formats to accommodate simulfunding, and even created a "Promissory Note" structure that can be exchanged like LOCKBOX and TXSIGCOLLECT blocks, but it's not complete yet.  Until then, these lockboxes are best suited when either (1) All devices are your own [you can't scam yourself], (2) All other parties are trusted, such as family members, (3)  Only one person is funding the lockbox.
    • Expert tool!  All manual exchange of data: These are building blocks of multi-signature transactions.  Once we have all the mechanics in place, Armory will start hosting servers that will facilitate the exchange of this data (privately, of course!).  Until then, all data must be exchanged via email or shared folders.
    • No signature merging yet:  Right now you must literally circulate the transaction to all parties, in any order.  Each party must sign it before passing it to the next party.  In the future, you will be able to send all parties the proposed transaction, they can each sign it and send it back, and the organizer can merge and broadcast
    • All devices must be upgraded:  None of the data exchange formats are compatible with older versions

    Using Lockboxes
    You must be in Expert usermode on Testnet to use lockboxes!
    • (1) One party/device is elected to make and organize the lockbox.  All other parties send them their public keys and contact info, etc (there's a new right-click menu in the wallet address table, to copy the hex public key).  If you are setting up a lockbox between multiple devices, you can simply use the addressbook buttons to pull the keys from watching-only wallets.
    • (2) When the organizer is done creating the lockbox, and decorating it with contact info, lockbox description, etc, he will be given a "=====LOCKBOX" block of data to send to all the other parties.
    • (3) Each other party will go into the lockbox manager and import the lockbox.  They will then be able to see its balance and transaction history only within the lockbox manage (from the the multisig menu)  There are no notifications.
    • (4) Any party may send money to the lockbox by selecting it in the manager and clicking "Deposit Funds".  Or you can copy the ID into the regular "Send Bitcoins" window (from a regular wallet) in the following format "Lockbox[ID:z87Qnm42]".
    • (5) To spend funds, one party is elected to create the spending transaction.  They click "Spend Funds" from the lockbox manager, which will open a regular dialog, but will only show UTXOs and balance of the selected lockbox.
    • (6) Armory will open a "Signature Collector" window.   At any time, you can export the tx with all available signatures, to an ASCII block and email it inline to other participants, or put it on USB key or shared folder to get it to the other devices that need to sign
    • (7) Once a sufficient number of signatures are present, the "Broadcast" button will appear.  Simply broadcast it and wait!

    Final note:  No compiled versions will be available for a while.  If you can compile from the github repo, you are welcome to play with it and provide feedback, but we don't even want to give any hint that it might be usable for real money.  Check back in a couple weeks for updates!

    Simulfunding is Implemented!

    The simulfunding options menu.  Create notes, merge into a single tx, then sign and broadcast:

    Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders (right now no labels are passed through, so you only see how many participants there are and how much they are contributing, but not who is who...)

    Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.

    As you can see, the final transaction has three different input wallets, and change back to those wallets as well.  
    11  Bitcoin / Development & Technical Discussion / [BOUNTY 0.03/bug] Help test next major release of Armory! (0.91.1) on: March 31, 2014, 12:09:22 AM
    Find bugs in Armory 0.91.1, get 0.03 BTC!

    This thread used to be for the 0.91 release, but I'm going to piggyback on it for for 0.91.1 because it's basically the same release, but with some minor tweaks.  Nothing substantial should've changed, except for the bug reporting and wallet-corruption handling.  This was born out of a couple reports of wallet corruption that were not being handled well by Armory in 0.91, and we had to not only improve it but add a way for users to submit their wallet recovery logs for review.  

    Given that this will be pretty boring, I've upped the bounty to 0.03 BTC (~$15) per bug.  I will pay out all bounties for the original 0.91 testing and this round at the same time.  I expect this round won't be very long, and the same rules apply -- you must be the first to post it, and it must be something that isn't totally trivial.  But we're not going to be stingy about it -- we need testers more than we need to save $15 on this bounty!

    This release might require explicit digging for bugs.  There might a few pieces of low-hanging fruit, but beyond that you're going to have explicitly test some of the less-commonly-used functionality (importing, sweeping, rebuilding, making & restoring backups, etc).  

      Armory 0.91.1-rc3 for Windows XP, Vista, 7, 8+ 32- and 64-bit
      Armory 0.91.1-rc3 for Ubuntu 12.04+ 32bit
      Armory 0.91.1-rc3 for Ubuntu 12.04+ 64bit
      Armory 0.91.1-rc3 for Raspbian armhf
      Armory 0.91.1-rc3 for MacOSX 10.7+ 64bit

      Armory 0.91.1-rc3 Offline Bundle for Ubuntu 12.04 32bit
      Armory 0.91.1-rc3 Offline Bundle for Ubuntu 12.04 64bit
      Armory 0.91.1-rc3 Offline Bundle for Raspbian (armhf)

      Armory 0.91.1-rc3:  Signed hashes of all installers

    Note:  The RPi regular build works just fine (as far as I can tell).  However the RPi offline bundle is still a work in progress.  No guarantees it works for as advertised!


    We finally have a stable version of what is soon to become Armory 0.91-beta.  We just put out a testing release (link below) and want to encourage people to help test by offering coins for your time. We are aware of a few quirks with the latest version, but nothing serious, all just usability/convenience/interface issues.  We will pay out for the obvious ones, as long as you're the first!

    See post above for details on the new version.  Here's a few highlights:
    -- Major fix for 99%-scanning crashing bug, and general performance improvements
    -- Solid OSX support including 10.9.1 and 10.9.2 (we think!)
    -- Torrent download for initial network sync (only in auto-bitcoind mode)
    -- New announcement system and secure downloader
    -- Binaries for RaspberryPi (armhf)!

    All bounty payout decisions are final!  We're not going to be stingy about bounties, but we do have to be reasonable.  We have done this in the past and no one complained.  Let's keep it up!

    12  Bitcoin / Development & Technical Discussion / Pay-to-Revoke using the Bitcoin Network on: March 21, 2014, 07:21:19 PM

    Design an authentication system that uses the blockchain as a revocation "list" (for say, software signing keys).  By doing this, you can add extra conditions for a revocation to be considered valid, such as requiring a large payment to the person or company that controls the original key.  The payment is "free" for the authorized individuals, but not anyone else.


    You are an individual or organization with some kind of signing key or certificate that is used for Important Things (such as signing Armory installers).  You'd like a way to permanently revoke the key/cert if it is compromised or lost, to prevent users from trusting it anymore.  And you'd like the revocation to be timestamped so that users can still trust messages signed before that time.

    Since you are also protecting yourself from simply losing the key/cert, just like in GPG, you may pre-sign a revocation cert, and keep it in a secure place until it is needed one day.  The problem with revocation is that it relies on permanency -- you can't unrevoke a key.  It is revoked one time and permanently updated in all key servers, etc.  So it would be great if you were the only one who had that power.

    But you can't keep it too secure, because it needs to be available quickly in case it's needed -- for instance, you find evidence that the signing key was compromised, and want to revoke it before the attacker can sign and distribute malicious versions of your software.  If it's kept in a safe deposit box, and it's Saturday, you may have to wait two days to revoke.  Also, if you are the only person trusted to control the private key, and you die, it would be good for someone else to be able to revoke it for you.

    So you also may want to back it up, and/or distribute it to semi-trusted individuals to make sure it's available if needed.  But you don't want those individuals to have access to the signing key itself, and would like to be protected if they don't secure the revocation cert properly.

    An attacker that gets access to the revocation cert can do a lot of damage to you or your organization, even if they don't personally benefit (blackmail?).  Or maybe they can find a way to exploit the power vacuum while the key is revoked and not yet replaced (perhaps they know how to poison the key re-distribution process).  As always, most solutions are a balancing act of security and convenience.

    My Solution: (assume the signing key is controlled by a company)

    Use the Bitcoin network as the revocation "server", but add a large payment to a company address as a condition of revocation.  The software that relies on verifying signatures from this key, will track of the latest blocks on the network, looking for the revocation trigger.  Perhaps, they are hardcoded with the revocation cert message, and simply watch for OP_RETURN strings that contain a valid signature  (and of course you get natural timestamping from this tx being mined).

    So make the revocation condition 2-fold:
    (1) Requires a signature from the key being revoked in an OP_RETURN string
    (2) The tx with the OP_RETURN must include a payment of 2,000 BTC to company address X

    (X is probably a 3-of-5 address controlled by the 5 directors of the company, etc)

    This is cool, because if the company itself decides to issue the revocation, it doesn't cost them anything because they are simply sending 2,000 BTC to themselves.  They don't actually lose any money.  But if someone else wants to maliciously revoke it without company permission, they're going to have to cough up 2,000 BTC to a company address, and won't get it back.  Even if the company doesn't have that much BTC on hand, they can simply borrow it, send it to themselves, then return it (the existence  of the 2,000 BTC tx is the trigger, doesn't matter where the money goes after that).   Perhaps the value chosen is the perceived cost to the company of a malicious revocation -- an attacker has to pay them the cost of fixing the problem, if he's going to revoke maliciously.

    While we don't like people dumping data into the blockchain, revocation happens exactly 0 or 1 time, ever.  Very few people/orgs would use this technique, and even fewer would need to actually ever revoke.  I'm fine with this, personally, in terms of blockchain bloat.

    Revoke & Replace: (Huh)

    In general there is no safe way to include revoke&replace in the same operation, since it would make the revocation certificate exactly as sensitive as the private key itself.  However, if you employ pay-to-revoke, you've made it extremely expensive for anyone but the company to exercise that option.  In some contexts, this still wouldn't be considered safe as an attacker may be able to profit more than 2,000 BTC by being able to quickly replace the signing keys.

    OTOH, if you're going to do key revocation & replacement at the same time, you could also add a third and fourth condition, where the new key will not be considered active until after 30 days, and can be canceled by an even bigger payment to the same address! Then the company has 30 days to detect the attack, and send themselves >2,000 BTC to cancel the revocation -- and they get to keep the attacker's money!
    13  Bitcoin / Armory / Please Help Test Armory 0.91-beta! on: March 19, 2014, 10:43:50 PM
    Please Help Test Armory 0.91-beta!

    This new version has a ton of new stability and performance improvements.  Including a fix for most users that had crashes at 99% scanning!

    GPG signature of hashes at the bottom

    Armory for Ubuntu/Debian 64-bit*

    Armory for Ubuntu/Debian 32-bit*

    Armory for Windows (including XP!)

    Armory for MacOSX

    Armory for Raspberry Pi (raspbian; armhf)

    *Apparently we have broken Python2.6 support with this release, and so cannot make a version (yet) that is compatible with older versions of Ubuntu like 10.04.  We are working on that...

    New stuff in

    • Major fix for crashing at 99% scanning!  We finally isolated the cause for most reports of crashing at 99%.  If you've previously had wallets with this problem, please download and try!
    • Torrent downloading for initial blockchain sync.  Armory Technologies is now running a private swarm of seedboxes to make sure there's enough capacity for everyone (it's the "Armory CDN" - content distribution network)
    • New announcement system, that includes a secure downloader for Bitcoin Core and Armory, as well as offline bundles with ATI signatures that can be verified on the offline computer. This will also be used in the event that there are critical security alerts, either by the core Bitcoin devs, or Armory team.
    • Extra entropy from keyboard, mouse and filesystem, are now used when creating new wallets (this is done invisibly, but a log message tells you how much is collected).
    • Use --nospendzeroconfchange to not allow spending of any unconfirmed TxOuts (Armory already deprioritizes ZC change, but it's off-limits with this flag)
    • Full P2SH support in send-BTC dialog, address book, tx info, etc
    • WinXP support
    • Proper unicode path handling (new wallets will support unicode in 0.92-beta)
    • No more choking on bad blocks written by Bitcoin-Qt/bitcoind
    • Major improvements to OSX compatibility!  (hopefully)
    • Fixed fonts in OSX
    • Bug reporting window -- Use "Help"-->"Submit Bug Report"
    • Progress bars for long-running operations
    • Factory reset window -- including "Delete Bitcoin-Qt databases and re-download"
    • Raspberry Pi offline bundle (process ironed out, will create test bundles soon!)
    • Minimize-on-open (in settings)
    • Wallets->"Recover Damaged Wallet"
    • Wallet creation wizard
    • Faster rescanning and rebuilding
    • Better logic to prevent unnecessary rescans
    • Better zero-conf tx handling
    • Fee calculation fixes
    • fixes and upgrades
    • Multithreading improvements
    • Code refactoring

    A few points to emphasize:
    • Dramatically reduced rescanning and rebuilding.  Armory is much smarter about when it really needs to rescan.  It's not perfect, but it should be solid now  (will have a more robust fix in 0.92)
    • The new announcement system uses an offline Bitcoin private key that is protected at the same level as our offline GPG key.  We plan to start releasing new versions signed with both.  The benefit of the Bitcoin key, is that Armory can verify the signatures, without the user having to have GPG or find our offline GPG key.  The expected public key is hardcoded into Armory.  For now, use --test-announce which uses a different key, protected to the same extent as my email GPG key, which allows for easy testing.  (btw, the offline Bitcoin key is hardcoded in previous versions, it just wasn't used, yet)
    • Torrent downloading uses a swarm of seedboxes provided by Armory Technologies.  Using Bitcoin Core 0.9.0, I can get online from a new system in about 6-8 hours (that includes download, bootstrapping, DB building and scanning).  If for whatever you wish to not use built-in Armory torrent'ing, you can use --disable-torrent, or even remove the entire BitTornado directory.  We have verified that Armory works with all torrent code removed.
    • Slowness and UI freezes should be mostly gone.  It turns out that large wallets were choking on the number of zero-confirmation transactions on the network, combined with an inefficiency in Armory's handling of them.  It should be dramatically improved. If Armory previously worked well for you, but then got slower over time, this should fix it for you (at least, after the first invocation of Help->Clear All Unconfirmed)
    • Please try the bug reporting window! (only if you have actual problems, of course!).  It will collect your system specs and log files and send them directly to our customer support tracking system.  Help->Submit Bug Report

    Recently identified:
    • Wallets that receive large numbers of small transactions, usually from pooled mining, certain types of gambling services, and advertising payments, will not work with Armory.  They freeze at 99% scanning.  This has been a problem for a while, but we only recently isolated the cause, since no one on our team uses a wallet like this.  We are not aware of a quick workaround for 0.91, but will have something in 0.91.1.  If you must get at your coins, you can export the private keys from Armory into another application, or export the key list, remove the wallet, then create a new one and sweep the private keys into it. Solution found! It's part of!
    • The organization of the secure downloader is sub-optimal.  In a future version, we will make it easier to find what you're looking for, though the downloads there are valid and signed by our lower-security Bitcoin key.  (we are working on getting a signature from the offline key ... it's not convenient Smiley)

    If you get this testing version, this should be the last time you need to use GPG to verify Armory installers!

    Here's the Bitcoin keys we will use for signing announcements and downloads from the secure downloader -- they are hardcoded in the Armory source:

    1NWvhByxfTXPYNT4zMBmEY3VL8QJQtQoei (offline key)
    1PpAJyNoocJt38Vcf4AfPffaxo76D4AAEe (online testing key)

    Until you get the new version, here is a GPG-signed copy of the
    Hash: SHA256

    a89fb24c98d88e991b96d309d2890c285e0012fd4eac6ec3e9b31c3f0e5eb4f9  armory_0.90.99.7-testing_32bit.deb
    761e4aaf285b28c530a34f522d487ada88733607e297ec7bd61ab7f163738dac  armory_0.90.99.7-testing_64bit.deb
    1bbac95eb56046b86cf63b96c0957da6a4dbee9bbf1ca2836a70d517b4534b65  armory_0.90.99.7-testing_osx.tar.gz
    076368590875b4ff2faf1446a4aa1aec4fd94abe0790caf0f323ba703fc5f836  armory_0.90.99.7-testing_raspbian.tar.gz
    c797a9e08e8d845bb085dd45d86d2d82b9911db735e276ff9e7cc85ce4c7ba87  armory_0.90.99.7-testing_winAll.exe

    Version: GnuPG v1.4.10 (GNU/Linux)

    -----END PGP SIGNATURE-----

    Version 0.91 automatically identifies messages that match the key and explicitly tell you it's signed by "Armory Technologies, Inc".  It's only if you're using an older version that you have manually verify the address.  Here's what it looks like in 0.91:

    We will have OSX and Linux versions posted soon.  Some recent changes we made broke our build/release system -- it seems to work for local compiling, but building distributable packages is broken and hopefully fixed later today.
    14  Bitcoin / Armory / Verifying Armory installers in Windows on: November 22, 2013, 09:07:23 PM
    Okay, I'd like to beef up the instructions for verifying downloads in Windows.  It will take a bit of work, but it can be done!

    I'm going to post my instructions here, and I'd like others to try it and tell me what I got wrong, or what needs to be improved.   After about 20 replies, I expect we'll have something that can reliably check your installer on windows, even if it requires a bunch of steps and installing some stuff.

    Here goes:

    • Download and install GPG for Windows:  Get gpg4win here.  It allows you to check GPG signatures in Windows.
    • Download a sha256sum utility:  For computing the SHA256 hashes of files.  I trust Kanguru for stuff like this.  Someone else please recommend more well-known tools (I can't believe this kind of thing isn't built into Windows anywhere.... is it?)
    • Download our offline-signing GPG key:
    • Download installer and hash file: Go to our download page and grab the installer for Windows, and the "GPG-signed SHA256 hashes of all installers" for the same version

    At this point you should have the following in your downloads directory:
    • gpg4win installer
    • Our GPG key (0x98832223)
    • sha256sum.exe
    • armory_<version>_win32.exe (or similar .msi)
    • armory_<version>_sha256sum.txt.asc

    Run the gpg4win installer, and import the GPG key (I'm not sure how complicated this is...let me know).  After that, do the following:

    • Verify the hash of the installer against the signed hashes:  Open a windows terminal and "cd" to your downloads directory.  execute sha256sum.exe armory_0.90-beta_win32.exe (or whatever the installer name is).  Open the .txt.asc file in a text editor and confirm that the output on the terminal matches the line for the same filename.
    • Verify the signature on the signed hashes file:   I don't know if gpg4win gives you good windows explorer utils.  I presume you can simply right-click on a file and check it's signature..

    I'll update this posting when I get feedback, and then once it's stable I'll post it on the website.
    15  Bitcoin / Armory / Running Armory on Testnet on: November 20, 2013, 09:00:00 PM
    If you want to run Armory on testnet, you'll have to disable auto-bitcoind and run Bitcoin-Qt or bitcoind in testnet mode manually.  And especially confusing is the fact that Armory and Bitcoin-Qt/bitcoind use inconsistent command line arguments.  For instance, you use "-testnet" flag with Bitcoin-Qt/bitcoind and "--testnet" flag for Armory (yes, one slash for bitcoin, two slashes for Armory).  To be more explicit:

    • Armory.exe --testnet
    • Go to settings, unselect "Let Armory run Bitcoin software in the background"
    • Close Armory
    • bitcoind.exe -testnet
    • Wait for it to synchronize
    • Armory.exe -testnet

    Due to some quirks in the path resolution, if you want to use a custom directory for Armory and Bitcoin, the --datadir and --satoshi-datadir arguments are inconsistent.  For instance, if you moved both your bitcoin home dir and your armory home dir to F:\Bitcoin and F:\Armory, respectively, do the following:

    bitcoind.exe -testnet -datadir=F:\Bitcoin
    Armory.exe  --testnet --datadir=F:\Armory\testnet3 --satoshi-datadir=F:\Bitcoin

    The problem is that Bitcoin-Qt expects the base bitcoin home directory, even for testnet, and will add the "testnet3" for you.  If you specify F:\Bitcoin\testnet3, it will run in F:\Bitcoin\testnet3\testnet3.  But I did not realize this when I setup the code for processing arguments, and Armory requires explicitly specifying the full path. 
    16  Bitcoin / Armory / [WARNING] Malicious Armory Website Clone Found on: November 19, 2013, 06:14:06 PM
    Please only download Armory Bitcoin Wallet from

    We have identified a clone website which provides malicious download links for our software.   All software and communications by Armory Technologies, Inc, will happen via the domain  There are no other domains under which we operate!   We use the following [offline] GPG key to sign all software releases, and sign all employees' GPG keys:
    Armory "Offline Signing Key": 0x98832223

    (please do not use this key for encrypting email to us -- only for authenticating software and employees!)

    Armory is a tool for advanced users, holding serious quantities of money -- please make sure you download the correct version and verify hashes & signatures before installing it!    There are instructions at the bottom of our downloads page that describe how to verify the signatures in Linux.  Windows is a bit harder, but possible if you install gpg4win and verify the SHA256 hashes file.  

    P.S. - I am not posting the link to the malicious site here, because it's unnecessary and I'd prefer people only be exposed to the good domain.  If you have a reason for it (such as doing a security investigation), please contact me.

    This is a repost from the main Bitcoin Discussion thread.  Please reply there.
    17  Economy / Scam Accusations / [WARNING] Malicious Armory Website Clone Found on: November 19, 2013, 05:32:59 PM
    Please only download Armory Bitcoin Wallet from

    We have identified a clone website which provides malicious download links for our software.   All software and communications by Armory Technologies, Inc, will happen via the domain  There are no other domains under which we operate!   We use the following [offline] GPG key to sign all software releases, and sign all employees' GPG keys:
    Armory "Offline Signing Key": 0x98832223

    (please do not use this key for encrypting email to us -- only for authenticating software and employees!)

    Armory is a tool for advanced users, holding serious quantities of money -- please make sure you download the correct version and verify hashes & signatures before installing it!    There are instructions at the bottom of our downloads page that describe how to verify the signatures in Linux.  Windows is a bit harder, but possible if you install gpg4win and verify the SHA256 hashes file

    P.S. - I am not posting the link to the malicious site here, because it's unnecessary and I'd prefer people only be exposed to the good domain.  If you have a reason for it (such as doing a security investigation), please contact me.
    18  Bitcoin / Project Development / [BOUNTY] Help test next major release of Armory! [0.04 BTC/bug] on: November 15, 2013, 02:37:53 AM
    Make some money helping test the new version of Armory (0.89.99-testing)!

    Download Windows (32- and 64-bit)
    Download Ubuntu/Debian 32-bit
    Download Ubuntu/Debian 64-bit
    Download Mac/OSX (not very usable in 10.9)

    For anyone who's been waiting for the new version of Armory, we're almost there!  But we desperately need more testing.   I tested this bug-bounty idea about a year ago, and it seemed to work pretty well.  Besides bugs, Armory got a ton of polishing, too.  So let's try this again!  If you want to claim a full 0.04 BTC (about $17 USD at the time of writing):

    • (1) You must be the first to post the buggy behavior.  If there's an error in the log file, you must copy that error here.
    • (2) The bug must be reproducible by me and impact the usability or security in a non-negligible way (things like grammatical error or sub-optimal design choices are welcome, but won't be rewarded with BTC)
    • (3) Certain categories of bugs, along with already-known issues are not rewarded (the list is at the end of this post)
    • (4) I get the final word in who receives a bounty and how much.  Double-bounties and partial-bounties are possible
    • (5) I will cap the payouts to 1 BTC total.  If this is productive, I'll happily increase the limit.  
    • (6) You are expected to know how to run and use Armory already.  It's an advanced tool with a bit of a learning curve.  This space is not for teaching you how to use it.  (there's an Armory sub-forum for that).
    • (7) Not responsible for lost Bitcoins (though I've never seen even a hint of a problem that would lead to loss of coins).  To use it on testnet, you may have to run Bitcoin-Qt yourself and unselect the first checkbox in the Armory settings window.  Remember that Armory uses "--testnet", Bitcoin-Qt/bitcoind uses "-testnet"

    This offer ends at 11:59pm EST, Nov 23, 2013!

    The following is a list of new features in Armory.  Yeah, there's a lot!  Please test all aspects of the application, though you might be more likely to find bugs in these new features:

    • RAM usage and startup time reduction: RAM reduced to less than 300MB, and startup time typically under 60 seconds after initial DB build!
    • Persistent database: Armory now maintains its own blockchain database for fast startup.  Make sure you have space to duplicate the blockchain (will be reduced in a subsequent version; this way was easier for now).
    • Full MacOSX support: thanks to picobit for the builder, though the Apple+PyQt bugs prevent full usability in 10.9.  Only accepting bug reports in OSX 10.8.
    • New Backup Center:  Better organization and description of backup options.  Includes unencrypted digital backups, now.
    • Fragmented Backups:  Shamir's Secret Sharing (M-of-N secret splitting); balance your physical security and redundancy.  Create up to 5-of-6 backups in Standard & Advanced modes.  Up to 8-of-12 in Expert mode.  Fragments are also deterministic for a given M value.  For example, if you make a 3-of-5 backup, you can later make a 3-of-7 and the first 5 will be the same as the 3-of-5
    • SecurePrint: Paper backups optionally encrypted with code on screen to prevent private key exposure to printer and other network devices.  SecurePrint code should be identical across all backup types for a given wallet
    • Half-sized paper backups:  The chaincode is now derived from the private key, meaning only two lines of data for wallets created with the new version of Armory.  Yet, all backup features work with older wallet without a hitch -- they'll all show four lines (if you don't believe me, prove me wrong and collect your 0.04 BTC!)
    • Paper backup tester: test any kind of paper backup before you bury it in your backyard.  Includes subset testing of fragmented backups.
    • Message Sign & Verify: Finally Bitcoin-Qt-compatible signing and verification.  Will have a new ASCII-armored version like PGP signing, soon
    • Fixed broadcasting non-std signatures:  Older versions of Armory produced signatures that have non-standard padding.  If an older version is used on your offline system, you can't broadcast those signed transactions with 0.88.1 online.  This version will fix the padding and broadcast successfully
    • Improve *nix Makefile:  Improved Makefile that should work out of the box on most Linux distros once the proper depedencies are installed.  See the osx_picobit directory for compiling on OSX.

    As a reminder, here's some pre-existing features that would benefit from testing:

    • Importing & sweeping of private keys.  Single and multi.
    • Creating deterministic wallets with customizable unlock time/RAM.
    • Restoring paper and digital backups without restarting the app
    • Coin control (in Expert usermode)
    • Customizable change addresses
    • "bitcoin:" URI-handling (with known deficiency on some Linux distros)
    • "File" -> "Export Transaction History"
    • OFFLINE WALLETS (no offline bundle for this version yet)


    whault:  1 x bounty (key calculator not removed)
    duxZero:  1 x bounty (tool tips and squashed buttons)
    jyyst:  1 x bounty (unicode issues)
    simonL: 1 x bounty (corrupt wallet file confusion)
    Cyberdyne:  1 x bounty (lingering sys tray icon)
    idoB:  1 x bounty (links, grammar and backup fields)
    cp1:  2 x bounty (confusing --datadir DNE behavior)
    devthedev:  1 x bounty (bad autoscrolling of dashboard)

    flipperfish:  1x for the "Send Bitcoins" first five entries bug (I knew about that one... long story)
    PRab:  1x for the lots of little issues:  (4 time pwd asking, focus issues, let user choose backup)
    greBit:  1x for shutdown hanging (I think this is fixed now, isn't it?)
    Zomdifros: 1x for... I don't know what that error is... sending issues... definitely a bug!
    elbandi:  1x for UAC issues (will be fixed in 0.91)
    tc23emp:  1x for maxConnections error (I've been looking for the src of that bug!  Thanks!)

    19  Bitcoin / Armory / On bitflips and Armory security on: November 07, 2013, 10:22:48 PM
    I have received a lot of questions about RAM errors potentially causing users to lose coins.  gmaxwell has made some statements about this in the past, and I want to give people an opportunity to find a hole in my logic.   Admittedly, I haven't spent a ton of time thinking about this, and I'm probably overlooking something.

    My Statement:

    Offline transactions:  Armory offline transactions are not vulnerable to bitflips, if you verify addresses and values on both the online and offline computer.
    Online transactions (hot wallets):  There is a remarkably narrow window in which a bit-flip could result in loss of coins.  This could be mitigated with a secondary verification window after signing is complete.

    Neither of these conditions hold true if you are assuming the possibility of multiple, perfectly-inconvenient bitflips.  DRAM errors are so rare, that squaring that error and assuming that the two errors are perfectly correlated in the worst way possible -- is effectively impossible.

    My justification:

    Offline transactions:  I can't enumerate all the possible times and places a bitflip could happen.  But here's a few:

    • Online computer creating the transaction, value or address: you catch it when you check the addresses and values on the offline computer (check every character!)
    • Offline computer before signing:  you catch it when you verify the address and value on the online computer before broadcasting.  
    • Either computer, after signing:  signature breaks, tx is invalid.

    Online transactions (hot wallets):  
    For this situation, a bitflip after confirming the outputs as correct, but before the system actually creates the signature, is the black swan event.   But it could be caught if there was a second verification window that displayed the final, signed transaction before it actually broadcasts.  At least in Armory, it is always re-parsing the raw transactions and displaying information from that parse.  So, a check of every character of the output address both before and after signing would catch this.

    The only other time I can think that this would be a real issue, is a bit flip in the address as it is sent to you by the other party.  Perhaps their system bitflips the hash160 value pulled out of the wallet, before they even give you the address.  That would be undetectible.  But if you are moving life-changing quantities, of money, I'd always recommend calling and verifying every character of the address, anyway.  That would catch bitflips after the transfer of the address (and technically the checksum should catch that, too).

    Lessons learned: When executing an offline transaction, always check every character of the recipient addresses and values, both on the offline computer before signing, and on the online computer before broadcasting.

    What am I missing?  

    P.S. - We could also just recommend that all systems handling large BTC volumes use ECC RAM.  But I'm not convinced it's necessary for an online-offline setup if you do the appropriate checks.
    20  Bitcoin / Press / 2013-09-30 PaymentsSource - A Rocket Scientist Takes On Bitcoin Security on: September 30, 2013, 04:02:30 PM

    Quote from: PaymentsSource
    Alan Reiner, 30, thought he wouldn't find any career more interesting than missile defense simulations, but the self-described nerd left physics recently to work full-time on an ultra-secure Bitcoin wallet, Armory.

    Bitcoin, a decentralized virtual currency, "has a lot more benefit to humanity than missile defense does," Reiner says. "There's a richness [in Bitcoin] that hasn't been tapped yet. You know that rumor that you only use 10% of your brain, that's kind of how Bitcoin is; there's so much more it can do."
    Pages: [1] 2 3 4 5 6 »
    Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!