Topic: [Bugfix Release] Armory v0.93.2 (Read 1186 times)

Deterministic signing appears to work, although I'm not skilled enough to look directly at the signature to confirm this. I didn't actually broadcast the transaction, so maybe it's possible the network could still reject it, but it at least works to Armory's specification.

Of course, there can be no random occurrences of signature bugs when you've removed the random element.

I'll try it out later, having problems getting dpkg to install the package (getting errors relating to the removal scripts, but it's most likely my setup that's causing that, 93.1 was similarly problematic to install)

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.  

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.

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

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


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