I assume you mean, setup with a bitcoin-accepting third-party who can donate the equivalent amount of cash, in order to expand the list to accept any donation targets, not just those accepting BTC...?

It's an option, but I like your comment about rewarding those who already accept BTC.  Also, we'd probably pay a fee to whatever third-party, which makes it even less attractive.

Humble Bundle is a good one, but I say that only because I'm personally a fan of Humble Bundle.  They were early entrants into the Bitcoin scene, and ATI has donated to them before.  Not sure if they should be part of the promotion though -- we'd like to support charities that have wide appeal and Humble Bundle only connects with a portion of the Bitcoin space (i.e. only the bitcoiners who play games).  I'm still happy to entertain them depending on how many options we have and how much in donations we ultimately decide to match.

In anticipation for the 0.92 release with multi-sig and simulfunding, we would like to offer up to 10 BTC worth of donation matching as a demonstration (and advertising) of the utility of Armory's new simulfunding features.  However, we cannot do this without a list of bitcoin-accepting charities or entities that are apolitical (i.e. making donations to something like wikileaks would be considered controversial, and out of the question).  We need ideas for who we can provide donations to.  Open-source projects are an excellent target since we are an open-source company ourself!

The process will probably look like this:

• Armory Technologies, Inc (ATI) will create 20 promissory notes of 0.5 BTC each, four to each of the 5 donation targets
• ATI will post all 20 prom notes (and descriptions) in a public location for people to browse
• Anyone who is willing to donation 0.5 BTC (knowing that it will be matched), will use the multisig menu to "merge promissory notes".  They will import our note, and then add their own for sending 0.5 BTC from one of their wallets.
• The user will sign the resulting 1 BTC transaction and will send it to us. (knowing it's not valid unless we also donate our 0.5 BTC)
• ATI will confirm that our 0.5 BTC is being sent with someone else's 0.5 BTC (or multiple people, if they coordinate).
• ATI will sign and broadcast the simulfund tx.  The donation target will receive 1.0 BTC

If all promissory notes are matched, it will be a combined donation of 20 BTC across some number of charities or projects.  I'd like to collect a list of potential donation targets, and then narrow it down to 5-10.  Don't want to have too many and dilute the effort.  Here's some ideas:

• Bitcoin Foundation
• Electronic Frontier Foundation
• Let's Talk Bitcoin webcast (Adam Levine, et al)
• XKCD Web Comic  (not exactly a charity, but who doesn't love his work? http://xkcd.com/538/)
• Cryptocat
• Freenet
• LibreOffice
• Linux Mint (this is my primary OS, so I'm a bit biased towards them!)
• The Tor project

Whoops, I was trying to update the diagrams and accidentally replied instead of editing.  Sorry for the spam.... but enjoy the pics!

Last testing version before 0.92 release (0.91.99.9-beta)
Still 0.03 BTC per bug!

---

As before, use the secure downloader to grab the latest testing version.  Armory will check the digital signatures for you!  Only use the links below if you do not yet have a trusted version of 0.91+ available.

---

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

Offline Bundles:
  Armory 0.91.99.9-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.9-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.9-beta Offline Bundle for Raspbian (armhf)

Signed Hashes:
  Armory 0.91.99.9-beta: Signed hashes of all installers

---

Thanks to all our testers, especially helgabutters!   It took us a while to get through all his bug reports, but I think we knocked them off all of the non-OSX bug reports.  Although we may not have fixed all the OSX bugs, doug_armory was able to integrate some Qt4 patches into the OSX build system that should resolve a ton of stability issues.  No promises, but he insists that he experienced a notable improvement!  Please let us know.

Not only that, but doug_armory and CircusPeanut have got a ton of new unit tests and functional tests integrated, which should dramatically improve robustness of everything going on under the hood.  We're still working on some automated GUI tests, but they're not ready yet.  Hopefully soon.

Finally, we made some significant improvements to armoryd.py.  It's still not quite stable, and we don't plan for it to be for the 0.92 release, but it's getting closer.  If you are interested in armoryd, please try it out and feel free to report bugs here for bounties.   We have made no claims of it being stable, so there's probably quite a few bounties to be collected.  We're happy to pay them out to speed up our development.

The 0.03 bounty is still active for 0.91.99.9, both GUI and now armoryd.  

Yes, in order to accommodate multisig transactions, the whole format changed.  There should've been a popup that explained that to you when you click on "Offline Transactions" on the latest dev version.  The old format was insufficient for handling multi-sig spends as well as simulfunding transactions.  There is no clean way to convert them.  We have always tried to maintain backwards compatibility, but it was just not possible this time.

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

Unfortunately, we removed BIP 10 because it was not used by anyone else, and the new format completely encapsulated everything we needed for both regular offline and multisig.  Hence, if you upgrade your online computer to 0.92+ you'll have to do the same for the offline computer.  It's the first time in 2-3 years that we've broken compatibility with older offline systems, but we felt we didn't have a choice.  Everything is far simpler for us this way.

As for the binary formats:  most of what's moving between systems is binary data.  And all systems have the standard set of get/put VAR_INT, VAR_STR, etc, the same as serializing and unserializing other Bitcoin objects.   We had pondered protobuf, but we ran into some issues getting it working cross-platform.  Maybe in the future we will.

As I mentioned above: we've done 5-way simulfunding and 7-of-7 lockbox spends with the new format, and have no issues.  Our barrier to release is stabilizin the GUI -- we see no reason we will have to further modify those formats.  Also, a lot of things in that new format are forward-thinking, like space for payment protocol or other web-of-trust mechanisms (authMethod & authData), and wallet-defined strings to help lite-wallets find their own addresses (wltLocators).   Those can be left blank right now (as Armory does).  The rest of it is just raw scripts, raw public keys, raw transactions, some metadata & labels, etc.  The only thing that might be unusual is the way we compute lockbox IDs, but it's not complex.

I do admit it may have to be updated in the future -- usually something this complex you can't get everything right the first time.  But at least for now, this works for 100% of Armory's simulfunding and lockbox activities, securely works with offlien devices, and even has a bit of foresight built-in to handle lite wallets and authentication of addresses.  I expect this will be sufficient for a very long time, maybe even until the community determines how they want to standardize this, and then we'll upgrade (as well everyone else)

Smartphone <--> Smartphone, too.  The nice thing about the audio solution is that there's no reason it wouldn't work, you just need the right cables.  And of course an Android version of the audio xfer

If you're going for simple, I would still use HMAC, as it is very simple to implement on top of any hash function in only a couple lines of code.  HMAC is a primitive that should be in every developer's toolbox, and it is intended to be used create hashes based on secrets without leaking any information about the secret and also resistant to things like length-extension attacks (may not be so important here, just pointing out that it has nice properties).  So if you're looking for dead simple, I would use:

   k = HMAC_SHA256(privKey, msg)

Which is really just

   k = sha256( (privKey XOR 0x5c5c5c5c...) | sha256( (privKey XOR 0x36363636...) | msg))

I believe that gmaxwell can describe a couple super-longshot concerns about it that RFC 6979 would cover.  But those things should not be considered practical/feasible attacks on the system, but simply that RFC 6979 is more sound and robust.   

Yes, we've done 5-way simulfunding and 7-of-7 multi-sig spending with this format and we plan to move forward with our release in its current form.  We expect that in the future, a variety of multi-sig services will standardize these formats to allow interoperability, but many such services are scrambling to get anything functional and standardizing would inhibit the design process.  So far, we see no reason that we will have to change the format at all, until that standardization occurs -- in which case everyone will be changing.  (much like how Armory and Electrum had their own deterministic wallet algorithms, then BIP32 was standardized and now everyone is moving torwards that).


Why do you need the last line?  Wouldn't you end up with some of the binary chars being converted to ASCII/unicode characters?   My apologies for being naive about python3 ... I'm not actually that familiar with it, beyond the fact that if I were to rewrite Armory from scratch, I'd use python3 from the start. 

Guys, I apologize for not being responsive here.  I'm up to my eyeballs in a variety of other things.   After 0.92, I will have some time to discuss this further, though I would then encourage you to switch to the new format we are using which handles offline transactions and multi-sig alike (you don't have to use the multi-sig stuff, it's simply a lot cleaner and more flexible).

Until then, everything that you need should be in serializeAscii() method:  https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/Transaction.py#L1246

From a glance, I'm not sure that you should be using .decode('utf-8') when doing the serializations.  This is binary data, not unicode.  Construct all pieces as raw binary and convert to hex.  There shouldn't be any utf-8 calls in it.

In the next release, we switch to UnsignedTransaction, which handles more general transaction types and securely signing with offline-multi-sig devices.  But it will become the new standard for Armory offline transactions and multi-sig.   And serialization is simpler:  create one giant binary string and convert it all to base64. 

Awesome!  Those are very encouraging results.  I am busily working on the Armory 0.92 release, but after that I will have some time to see if I can reproduce your results locally.   If so, I think you deserve a bounty!    I encourage anyone else subscribed to this thread to collaborate with roman.z and see if you can get his solution working and verify that it works.  I pay out once I can use the solution to move a 2MB file between two laptops reliably, as long as the performance is somewhat close to what you just described.

Overachiever's goal:  can you find the right cables to move data back and forth between a smartphone or tablet?  How difficult would it be to demonstrate that you get sufficient performance?  I like the idea of taking a tx on your phone to the safe-deposit box, plugging in a 2-way cable between the phone and computer, and letting them do their thing.  Or two smartphones -- one online one offline.  Granted, android dev is a little out of scope for this bounty, but if we can at least propose a feasible path to getting there and expect that its performance will be acceptable, I think this solution will be 110% complete!



 

 Actually, I've already got an encrypted GPG thread with helgabutters over email.  Please send the payment address there. 

And yes, thanks again!  You get the bug bounty overachievers award!

Generating the keys is half the battle.  And a critical half of the battle.  I believe the other half is using a deterministic signing algorithm RFC 6979.  In Armory we have been talking about doing it, because it's actually much simpler to implement than it would seem from reading the document, and it would totally eliminate the need to call the PRNG after the keys have been created.  And as gmaxwell said, doing so adds the ability to audit the signing device -- when you use the same private key and message to sign, you should get a deterministic signature that can be verified against another trusted device doing the same calculation.  This would certainly increase confidence in devices like the Trezor for which the pre-installed firmware would be difficult to audit otherwise.

Of course, there's still some shenanigans available for malicious manufacturers/handlers of the devices, but I think this would go a long way towards improving the situation.  We had actually planned to do RFC 6979 for the next release of Armory but it fell between the cracks of all the other activities.  And if we do, we'd have a way to toggle whether you prefer to use the PRNG or the deterministic signing (with deterministic signing being default).

Also, although I'd like to take credit for the card shuffling idea, it was actually maaku who originally mentioned it to me.  225 bits is overkill, and I'd have a tough time believe that you could end up below 128 bits of entropy after a two wash-riffle-riffle sequences, no matter how "bad" you are at it.  That doesn't mean you should lessen your shuffling efforts -- I see no reason not to do 5 such sequences and remove 100% of doubt, since it only adds 2 minutes to the key generation sequence that should be required only a couple times per year.

Tell you what, we will remove that warning in the next testing release.  It was really intended more for the early states of the multi-sig stuff, but that has been sufficiently ironed out, and we're nearing release.  That warning was going to go away anyway. 

OTOH, you can always safely downgrade or upgrade Armory.  The only catch here is if you setup an offline computer with the same version -- for the first time in two years, the offline transaction message format has changed, so this version is no longer backwards compatible with an offline computer running an older system.  With regards to offline computers, as long as both systems are running pre-0.90 or 0.92+, you'll be fine.  If you're not even using the offline feature, then this doesn't matter.

We should have another testing release this weekend.  You can safely upgrade then and be free of these issues

You're walking down the math-heavy path of elliptic curve calculations.   It is described dozens of times elsewhere throughout the forum.  Look up "Type 2 deterministic wallets" originally conceived by gmaxwell. The watch-only wallet is an exact copy of the regular wallet without any private key data.  If you are uncomfortable, you can manually inspect the binary file and confirm that the private key fields are all 0x00 bytes.  

I forgot to mention above that the private keys are computed the same way.  I should've had.


Yes, you can derive the same chain of public keys using only the root public key, as the private keys derived the same way from the root private key.  This is the basic math behind "Type 2 deterministic" wallets and the basis for HD Wallets/BIP32 which is in-process of being adopted by all major wallets.  Armory and Electrum both demonstrated the power of type2 det wallets and have used them for years.  Now everyone else will be, too (however, Armory's deterministic wallets use a different type2 algorithm that I created before BIP32 existed, but it still has all the same security and privacy properties)

The logic is in EncryptionUtils::ComputeChainedPrivateKey and EncryptionUtils::ComputeChainedPublicKey.

Simply put, publicKey(i+1) is computed from publicKey(i) using:

Armory has a backup tester specifically for this.  Technically, it does exactly what Armory would do when restoring a wallet from backup, but some people won't trust it unless they actually restore the wallet.  So either use the backup tester, or create the wallet you plan to use, create your single/fragmented backup and then wipe everything and restore it on a fresh version of Armory.  For the watch-only wallet, you can generate the first X addresses on the offline/full wallet, and then import the watch-only wallet to the online computer and verify it generates the same X addresses.  Technically, you only need 2 addresses since the equation is the same for generating subsequent addresses, but again people won't trust it unless they see it work a dozen times.  Compare 1,000 addresses if you have the patience to do so.

No, I haven't changed my mind about QR codes.  They're a non-starter, because the data transmission sizes are 1-2 orders of magnitude smaller than what is needed to handle standard transaction sizes.  Yes, it will handle 98% of transactions for some usage patterns, but only 5% of transactions for other wallet usage patterns.  It really needs to be 100% for all usage patterns.

OTOH, QR-video would work.  But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.

Do me a favor.  Try broadcasting again, and then as soon as it fails, look at the end of the Bitcoin debug.log.  In Windows it would be C:\Users\<username>\AppData\Roaming\Bitcoin\debug.log, in Linux it would be /home/<usrname>/.bitcoin/debug.log.  When Bitcoin core disconnects you, it always logs why -- usually you will see something like 'Inputs already spent" or "Invalid signature padding", etc.