So far I'm still missing bounty addresses from a few people:
   george51
   brangdon
   ncs0ne
   TheAwer

Since you guys have been quite patient, I'll just send out what I've got so far.   I'll send out the rest when/if they send me their addresses!

@qnxt

I did fix the copyright year on our development branch.  The "secure downloader" auto-detect was more than a simple fix, so I also deferred that to the next version.  In fact, I'm going to totally rework that dialog, because I really don't like the way it organizes the downloads.  I think I'll make the version number selectable and then show all available downloads for that version.  Then this bug doesn't really mean much...

Regardless, thanks for pushing it.  Anyone else, if you think I overlooked something you found, let me know!  Sending out 6 of the 10 bounty payments in a few minutes.

I'm not sure what you're asking with the last question.  If you are signing with bitcoind (can it do offline signing?) then you can just broadcast it with any network-connected app once you get it back online.  Armory's default is to pass in this decorated-unsigned-tx, and return the same decorated-signed-tx to the online computer.  That Armory instance will "prepareFinalTx().serialize()" which converts the decorated-tx to a byte string appropriate to be sent over the wire.

Btw, we do have many users leveraging armoryd as their backend, it just requires a bit of work to fill in the gaps.  One of the nice things about armoryd.py is that it's pretty easy to adapt it to whatever you need to do:  there's a clear place to put code everytime a new tx comes in, everytime a new wallet-relevant tx comes in, and every new block.  You don't have to operate through RPC, you can just program your hooks directly in.

Armory unsigned transactions are different.  It's because they store all the extra data needed for the offline computer to verify the transaction without the blockchain.  It can be a lot of data, but required to maximize security. 

On the other hand, you might be able to go the other way, but you'd have to build some helper functions to convert a raw unsigned transaction from bitcoind, to collect all the blockchain data that is needed for Armory to verify the tx before signing.  Armory assumes all transactions will always be signed by a dumb device with no blockchain -- there is no alternative form.

This is not standardized in any way.  Maybe one day it will be.

At the moment, "getledger" and "getledgersimple" are the biggest divergences of them, though we attempted to implement "listtransactions" the same way Bitcoin Core does.  I really don't like what Core does with "listtransactions":  it provides multiple outputs with overlapping entries, which require a bit of extra logic to adapt to your application.

On the other hand "getledger" provides you exactly what you would see on the Armory GUI ledger -- it's a mutually-exclusive list of entries, each one corresponding to a single transaction, and theoretically all the values produced from it can be summed to give you your balance. 

We will also soon have an interface for:

- Multiple wallets (context switching)
- Create unsigned transaction (to take to offline computer)
- Sign unsigned transaction (to run from offline computer)

If you'd like to recommend more stuff you'd like to see, post in the following thread:
https://bitcointalk.org/index.php?topic=588227.0

Ye ask and ye shall receive:  I just pushed the signed tag.  I already had it the tag signed I just forgot to push it to the repo.

We will eventually start doing source tarballs, but we have had a problem where it's bundling up the git repo itself, so the source tarballs are like 100 MB.  Once we figure out how to get dpkg-build to stop doing that, we will add the tarballs to our regular release cycle.

Sorry about that -- we had to release a few tweaks to 0.91.1 to fix a wallet-recovery tool bug and some unicode path issues.  I put it out as a testing release so it would be available and ready for people to download if needed, but wouldn't spam people with more notifications (of course, I forgot it's going to notify everyone with testing notifications on!).  I'll try to give more of a heads up about it, next time.

Basically, unless you have path issues or wallet recovery tool issues, there's no real reason to upgrade to 0.91.2.

Sorry for the delay everyone.  Finally found a spare minutes to go through this thread and collect the list of bounties.  Here's what I got:


Keep in mind I'm only providing bounties for first-reported instances of bugs.  There were a lot of repeats in there.  In one case, I think I gave someone a bounty for a repeated bug, but only because we claimed to have fixed it and it wasn't fixed.  

Please PM me with your payout address, and a statement about whether you're okay to receive it as part of a single all-bounty-payout transaction.  I will honor requests for separate transactions, if necessary.

If you updated from 0.90 to 0.91+, you most likely have to rebuild your databases.

Unfortunately, if you can't even get it to open, you'll have to manually delete the databases.  On OSX it is under the following directory by default:

~/Library/Application Support/Armory/databases

You can navigate to the Armory directory and delete the databases directory (which holds a lot of data).  Next time you start Armory, it will rebuild and rescan, which might take a couple hours, but it should be smooth after that.

If the offline computer is already upgraded to 0.91+, then you can use the secure downloader to grab the package and "Save with offline-verifiable signature".  Then take that to the offline computer and use "Help"->"Verify Signed Package".  That will check the offline Bitcoin signature and let you save the installer (only after the signature is verified). 

This is specifically so you don't have to trust your online computer, and you don't have to deal with GPG.  The Bitcoin signing key used here is handled at the same security level as the offline GPG key.

Sorry guys, I've been out of town at the MIT Bitcoin Expo this past weekend and haven't even been looking at this thread.

I just want to mention that the "real" solution here is something I've talked about for a while, but no one else in the community seems to be taking it seriously, even though it's perfectly compatible with BIP 32.  You provide your BIP32 branch root public key (but not chaincode!), perhaps putting it on your business card.  So your business card contains the public key portion of M/i/j, then when you compute address M/i/j/k for someone to pay you, you do all the hashing and crypto, and save off the multiplier just before it is applied to M/i/j.  You send the recipient the receiving address and the multiplier.  They can apply the multiplier to the public key on your business card and see that it matches the address given, proving that it's actually part of your wallet.  Note that this is perfectly private because the chaincode is not the same as the multiplier, and cannot be computed from the multiplier.  It simply allows you to optionally prove that an address is related to your root public key without leaking any privacy or security information.

Stealth addresses are based on this idea, but don't require any interaction.  It lets the sender generate the multiplier for you using ECDH, and then encoding the DH information in an OP_RETURN output.  However, it comes at the expense of extra data in the blockchain, and the receiver must scan every transaction in the blockchain with expensive crypto ops to find transactions to his wallet.  This doesn't work with lite wallets, and the stealth address discussion has gone through many ideas of outsourcing that computation/search to trusted nodes with enough computing power.

Instead, using this rootkey+multiplier trick, you still have to provide a payment address to the sender, but they can prove to themselves that the address is yours as long as they have verified your root public key at any point in time.  This doesn't require any extra computation or embedded blockchain data like stealth addresses do.  It is a solid compromise between where we are and what stealth addresses attempt to accomplish.  

When I talked about "...and a whole lot more" in my foreshadowing of what the new wallet format will do, that is one of those things we will be supporting.  It would allow you to save BIP32 root public key information for various contacts in the wallet, and provide a new (optional) address encoding that proves your addresses are related.    In all cases, we are requiring the sender to verify the receiver's address under the assumption that maybe the receiver's own WO wallet has an error or is compromised.  

Until then, the best thing you can do is exchange watching-only wallets with parties you interact with frequently, and make sure that any payment addresses they send you appear in the WO wallet you have for them.  Armory already gives you a way to watch multiple wallets and mark who they belong to.  Out-of-band verification of payment addresses (such as phone call) would be recommended for exceptionally large transactions.



P.S. - This proposal does not have a compact extension into P2SH multisig, but it is still possible.  Your company would actually have, say, 5 public keys associated with the company address (because the company uses a 3-of-5).  The sender would receive 5 multipliers, apply the multipliers to verify each one, and then sort the resulting public keys and create the P2SH-multisig themselves.   There's no loss of privacy there, just a lot more data needing to be moved between parties to do the verification.

P.P.S - You would most likely include a much shorter hash on your business card, and then supply the root key(s), multiplier(s) and payment address all at once.  They would hash the root key(s) to make sure it matches your business card, then follow the process above.

He means 32-bit architecture vs 64-bit architecture.   

Armory communicates with Bitcoin-Qt with network messages that are independent of your architecture (the same way you can access the same websites on the internet with 32- and 64-bit machines).

Similarly, if you setup an offline wallet with Armory, the online and offline machines don't have to have the same architecture, OS or even same version of Armory!  As long as they can read text files!

We've tried to fix this and even when we think we fixed it or breaks for someone else.  This is why we added the warnings to verify the number of columns, and posters you if you don't test the backup.  We're thinking of even REQUIRING the backup test.

Notice it says not necessary   If all your hot wallets and watching-only wallets have been loaded on 0.91 or 0.91.1 before, and no notification popped up, no further action is required.  I would guess that 99%+ users will pass this check without issue.  And of those cases with consistency issues, the recovery tool can fix most of them.

Will post more information about this soon.   Working on getting an announcement page up and distributing notifications to older versions.

Yup totally fine.  Armory doesn't use the filenames.  It simply checks that the contents look like a wallet file.  On that note, any files you add to the Armory home dir will automatically be loaded by Armory, regardless of their filename. 

Yes, we just pushed the new version 0.91.1.  It's actually on the testing branch, haven't merged it into master yet.   But there is a signed tag for it:

https://github.com/etotheipi/BitcoinArmory/tree/v0.91.1

At a more technical level, most of our dialogs are spawned as a subclass of QDialog.  And I think our subclass is not doing the placement correctly.  But that means we can fix all of them at once, but I also don't want to risk messing with it for this release.  The next one...

The squished'ness might be similar -- we gotta find the right method to tell Qt that to give each of those widgets and absolute minimum size, without having to set them explicitly each time.  We'll see what we can do in 0.91.2.

My apologies, I actually somehow didn't get notified of your post until I noticed while posting RC3.

Some of them are more complex to fix than others.  Even after reviewing them, I have determined that they are worth fixing, but not stirring up things for this release.  As such, you will get your appropriate bounties, but it the actual fixes will go into the next version. 

The exceptions are Bug 3 which should've been fixed, and Bug #8 that we will look at before the final release.  Otherwise, I suspect all these bugs were in the 0.91 release as well, which this release is going to replace.  It's not that they shouldn't be fixed -- we appreciate the feedback and will fix them -- it's that I need to make sure I didn't break stuff in 0.91.1 that worked in 0.91.  All the other stuff can go int 0.91.2 or 0.92.

In general, we need some help with widgets, layouts, etc.  A few of your reports are more systemic issues with the way we use Qt that allows windows to be spawned smaller than necessary to show everything, or spawning them off the screen.  We'll get to those eventually.  P.S.  What is your screen resolution?

P.S. - The RPi offline bundle was created automatically as part of my new set of release scripts, but I haven't really tested it.  Don't expect it to work!  But it will later today or tomorrow when I do a final release.  The regular RPi package works, though.

Last one, I think!  


  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 I switched around the versioning, and the update system doesn't handle it anymore.  I'm now doing 0.91.1-rcX instead of 0.91.0.99 that I was doing before.  The update system only notifies when a higher version number is available, but these all appear to be the same version number.  So you can get the testing release from the secure downloader, you just won't be notified of it (even then, you'd have to have enabled it in your settings to get notified of testing releases).

At least the way it's described on the wiki, there's a 520-byte limit on any PUSHDATA operation... each sig is ~ 70 bytes (with DER encoding bytes) so no problem there.  But the last PUSHDATA pushes the multisig script onto the stack -- so the multisig script must be no bigger than 520 bytes.  it's indepdendent of the number of signatures -- there's a separate limit for the total script size.