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.
