So, one transaction:  one input of 10 BTC from 1 address,  and 40 outputs, each 0.25 BTC each to the exact same address?  That can be done manually in Armory, as you can just add 39 recipients and manually copy&paste the data between the fields.  It will put everything into the same transaction.   Clearly it's not preferable, but it's better than creating 40 different transactions.

I am working on an example script for other reasons, that will also serve your purpose, too:

Input:
  Wallet file
  List of addresses in that wallet (or just one addr)
  List of (recip, amt) pairs
Output:
  Signed Transaction

It will search the blockchain, construct the transaction, calculate the fee, add the appropriate change output and sign it.  It could send it too, if you want (I can add a confirmation message, along with a password prompt in case the wallet is encrypted).

I'll let you know when it's done -- it's part of my effort get developers a jumpstart on leveraging armoryengine since there is no JSON interface yet, and sounds like it would get me 5 BTC from you

Just be aware that the more outputs you use, the more the tx will cost.  Each input is about 150 bytes, and each output is about 35 bytes.  Above 3-4 kB, a tx can no longer be free.

There is one chain code and an infinite series of private keys.  If an attacker gets one private key and nothing else, that's all he gets.  If he gets PrivKey(i) and the chaincode, then he can calculate PrivKey[i+1], PrivKey[i+2], ..., but not any of the ones before it (i-1, i-2, ...)

A lot of you have been waiting for this feature, so please help test it!  Gimme feedback!

Version 0.60-alpha-RC1: Satoshi Wallet Migrate/Import!

Finally got a migration tool integrated, and it works with encrypted wallet.dat files!  Import from encrypted or unencrypted Satoshi wallets, with or without the address pool, including address labels, into an encrypted, unencrypted, or new Armory wallet.

A special thanks to Joric for providing me such excellent reference code to get the wallet-decryption working. I donated 5 BTC to Joric for his help!  Now, if all you want to do is pull your private keys out of your wallet.dat, you can use Armory to dump them into a new wallet, and then use "Backup Individual Keys" to create a text file you can print out. 




48 hours left in the crowdfunding!
It doesn't look like I'll make the $12k, but I will still be able to take a pretty significant chunk of unpaid leave.  If I make it to $6k, I will cut a full day off my job!   I wish I'd gotten RAM-reduction going by now, but instead I was listening to you and implementing features that I were in high demand (and not major overhauls of the application).  Plus, the RAM-reduction is half-done, and hopefully be implemented in the next couple weeks!

I'm working on a code example for you, that will allow you specify a list of addresses and a list of [recip, amount] pairs, and it will create a signed transaction with minimum acceptable  transaction fee.  As I look through the code, it's not trivial to make it happen, but it's not a lot of code, either -- you just have to string together the right set of calls.   If you have a more-specific request, I'll adapt to it.

I've been told many times that I should do some of that anonymity stuff.  I probably will eventually... 

(1) Armory does use custom C++ blockchain code under-the-hood:  but it's only for reading and scanning the chain ridiculously fast.  Those methods will modified to be more appropriate for a production client -- it was originally was developed as an fun experiment in ultra speed-optimization, before the blockchain was 500 MB large, and then adapted when I started developing the client.   I specialize in data-structures, and at the time of writing the library, my focus was on speed optimization (and I succeeded), but not space-optimization.  That will change and I look forward to doing it... and doing it really well

(2) A lot of the robustness in Armory comes from leveraging bitcoin-qt/bitcoind for networking -- which implements all the state-of-the-art Bitcoin networking so I don't have to.  It is in my plans to merge an existing networking base into Armory, not re-implement it.  It could be 2-6 months worth of work to re-implement all the networking, and in the end it will be worse.  Plus, if 50% of users use program A and 50% use program B, then it's way too easy to end up with a blockchain fork -- which is a obviously sub-optimal.   

I'd really love to see the main devs isolate their networking code so that can be used for integration into other clients (like this one).  Maybe that's what libcoin is for.   The devs have done an amazing job with the security and networking robustness, and I think it's a good thing for others to be able to use that to avoid having to spend 3+ months reimplementing...

It's not quite that simple, but it's close.  I already got this working in the mmap branch in Linux and started testing on a Ubuntu 10.04 VM with 1GB of RAM.  But I got a bit more testing there, and get it ported to Windows, too (requires a preprocessor branch).   Hopefully I'll have all that done and implemented in the next month!

As mentioned, there is a hard plan to make Armory accessible:  both through the python library, and as a daemon accessed via JSON interface.  I just haven't gotten there yet:  I'm a one-man show with way too many things currently labeled "high priority."  It was one of my top goals to encourage business adoption, so giving merchants the opportunity to hook into Armory and leverage the split wallets is a high on my list.  But reducing the RAM is even higher...

It's coming, it's just not there yet.  Until then, it will be "just a client."

Has anyone tested the new wallet migration tool?  I need some feedback before I go ahead an lock it in.  If you are willing to help test, just import the addresses into a new wallet and then remove/delete the wallet when you are done testing.  And, I know there are users out there who have been waiting for this feature!  Use it!

Armory version 0.60-alpha-RC1  (Release Copy)! 

• Download Win-64-bit version here
• Download Win-32-bit version here (offline-only)
• All Armory downloads available at the Github downloads page.
• To test in Linux, switch to the "migratewallet" branch and recompile.

Please help test 0.60 so I can make it an official release!

Changelog:

Due to popular demand, and I created a "Wallet Migration" tool to migrate all of your regular [Satoshi] Bitcoin client wallet files to an Armory wallet.  I have donated 5 BTC to Joric  for providing his pywallet code as public domain!!!   Using pywallet, I was able to figure out how to read and extract private keys from any wallet.dat, even encrypted wallets.  I got a full, catch-most-kinds-of-errors interface integrated into Armory.  I have been testing this all morning and it's been working beautifully!  You can access it through the "Import Wallet" dialog, or through the new "Wallets" menu on the main screen.



NOTE:  PLEASE BACKUP ALL WALLETS BEFORE USING THIS NEW FEATURE!!!  (both, wallet.dat and Armory wallets)

You can import all the private keys into an existing wallet, or it will create a new wallet for you.  It will check for duplicate addresses (in case another Armory wallet already has some of those addresses), and it will prompt you for encryption passwords for wallet.dat and/or your target Armory wallet, if necessary. 

Additionally, added a few other minor updates, such as the "Wallets" menu on the main screen, and displaying address comments/labels on the main ledger if there is no transaction transaction comments.

Negative. For now it's just a straight client without any ability to communicate with it outside the UI.   However, it is a medium-term goal to implement a JSON-RPC interface to it, just for that reason.  I want developers to be able to leverage Armory (especially watching-only) wallets without having to integrate armoryengine code.

On the other hand, the armoryengine code is not too difficult to integrate into python scripts:  i.e. loading the blockchain, creating wallets, searching for transactions, getting balances, sending transactions, getting zero-conf transactions.  It's not exactly what you're looking for, but it's not terrible, either.  If you (or anyone else) is interested in using it, let me know and I'll create some code samples tailored to your use-case.

Thanks!  Well at least PM me your email address, and I'll send you the encryption seminar.  There's no reason for any of the donors not to get that

kjj,

There's a couple reason why the solution currently implemented in Armory is the way it is:

(1)  The offline computer does know what it's signing.  If you look at BIP 0010, you'll see that it includes all the supporting transactions of all the inputs it is signing for.  All inputs reference the TxOuts being spent by (TxHash, TxOutIndex).  By including those transactions themselves in the BIP 0010 packet, the offline system can hash the transaction, compare it to the hash of the input being signed, and then look at that transaction and see the value of the input.  Additionally, it will need the TxOut-script being spent, so the previous transaction provides that as well.  There's no way to manipulate or trick the offline system into signing different inputs or misrepresent input values.  Similarly, the outputs are part of the signature.  The target address/hash and the output value is all part of what's being signed.  

So, if someone manipulates the packet at any point, they either break the signature, produce an invalid tx, or the offline system confirmation dialog will show different info than the user is expecting.  This is secure, despite the offline computer not having any blockdata at all (or rather, the offline system is given just as much blockdata as it needs to know what it's signing).

(2)   The ASCII armored BIP 0010 was not designed for offline transactions.  It was designed for multisignature transactions, so that this "packet" could be passed around to relevant parties, and they can add their signatures to it, pass it on, combine with other packets, etc.  The ASCII-armoredness simply improves its "fluidity" so that it can easily be copied inline into emails, if necessary.  

It just so happens that it's useful for offline transactions, too:  offline transactions are simply 1-of-1 multisignature transactions, for which the online computer needs to collect signatures.  By creating BIP 0010, it allows for any combination of programs (that use BIP 0010) to be able to interoperate -- either offline transactions, or multisigs.

Sorry, I misunderstood the statement that "all transactions should be P2SH scripts."  That's what I get for rushing through the description...

My concern was that moving from vanilla OP_CHECKMULTISIG to P2SH meant that it was no longer possible to just make one backup of your [deterministic] wallet.  You have to continually backup scripts and script-hashes after every multi-sig transaction.  But there are good reason to use P2SH, I feel like it's the better of two evils . But I will still complain about the extra backup complexity associated with it -- the scripts to be backed up are not-sensitive, but important, and many users may not want to setup autobackups of their entire wallet, encrypted or not.  So it will require saving the scripts in separate files and maintaining a separate backup system for it, and must be executed after every transaction.  And I need to build in a system for restoring an entire wallet from a private-key-only file plus script-backup-file.  And figuring out how to recover as much info as possible in case the script-backup-file is not recoverable.  Again, that's what that other thread is for.

When I heard "all tx to use P2SH" I immediately started thinking that all transactions were going to suffer the same backup complexity.  But the proposal is really more about changing the format of the standard scripts, so you will still be able to scan the blockchain for regular transactions -- they will just have a different form.  I was thinking more like proposals where even the regular tx is "obfuscated", requiring you to save some critical information in addition to your private keys, in order to identify and redeem it.

^This.   Although I see the value in P2SH or any similar system, I am deeply concerned about the backup issues.  I put in a lot of work to make paper backups in Armory, to make it as simple as possible for users to make one backup ever, and not have to worry about it again.  "Regular users" who must rely on a consistent backup solution will fail.  It doesn't happen.  No matter what you do, they will forget to set it up, not realize their backup drive was disconnected, not set it up again after a system restore, or reinstall OS, etc.

But with proposals that require all everything to be hidden behind script hashes: your wallet must be backed up (or at least the script information) after every single transaction.  Your system dies right after a transaction before you've had a chance to save the script, and you'll never recover it again.  This is something I'm battling with multi-sig scripts, but was comforted by the fact that at least regular users who want to avoid all of it don't have to deal with it and can use regular addresses which can be scanned for in the blockchain.

That's what this thread was about.  Gavin addressed the issue for multi-sig and escrow.

kjj,

Maybe you already know this, but just to clarify:  I already have a very serious offline mode.   Armory successfully implements offline wallets, but not quite the same way as was proposed in the thread you linked.  Instead of the offline computer creating and signing the transaction (which requires the blockchain), the online computer has a "watching-only wallet" and constructs the transaction for you (as well as generates addresses and verifies incoming payments for regular usage).  The unsigned tx is passed to the offline computer which doesn't even need the blockchain, it displays the tx data to the user who confirms+decrypts wallet+signs.  Then, it's transferred back and broadcast.  It doesn't use any kind of JSON interface, it's based on passing ASCII packets back and forth much like PGP ASCII-armored signature blocks.  And BIP 0010 was created so that if other clients implement it, you could have different clients online and offline and it will still work.  And none of it is sensitive, so there's no need to encrypt the data, or worry about wireless transmission.

Back to your idea:  I really like it, and I will look into the USB-serial-port adapters.  Maybe parallel ports, too (I'm seeing adapters for both).  If it's $20 to get this serial link established with no risk of arbitrary code execution, then it's a win!  As long as it's not too much work to get setup on different OS's -- I'll have to do some reasearch concerning the complexity of establishing serial links via USB adapters in Linux, Windows and Mac.   Ideally, each system would just see it as a native serial port and then it would just work... but I doubt it's ever that simple.

Anyone have experience sending bits over USB serial ports?  I envision that most old-laptops will have one, so many users would get away with just one adapter (online USB to offline serial).  But other users would need one for each:  one USB-to-Serial(M) and one USB-to-Serial(F).  Would these two setups have different charactistic (i.e. do I have to accommodate them separately in the code?)  I've never actually pushed data over serial/parallel ports, other than knowing it's a fairly simplistic interface.

This is a most-intriguing error.  That code wasn't touched at all, nothing even tangential was touched. 

What's more interesting is that if you are using the master-branch armoryengine.py, then line 123 actually corresponds to the "if OS_WINDOWS:" code block.  For some reason, your OSX machine is being detected as Windows...?  For fun, can you go into the python interpretter and type the following:


What does it say?  Mine says "Linux" because I'm in Ubuntu.  I don't even know what Mac is supposed to say, it was a Mac user that told me to look for "darwin" or "osx" to identify Mac...

Not everyone has a spare ethernet port on their online computer, and doing all the system configurations for one-way SSH is probably non-trivial and quite prone to error (some users will end up less security than the USB key solution because they did it wrong).  Plus we have to trust that SSH is secure the way we think it is.  Sure, it's a high-quality protocol, but still requires "trust" that no one has found some crazy vulnerability in it (and that it was setup correctly).  On the other hand, transferring raw ASCII tx through an IR stream is trust-less:  it's simply impossible for the online system to trigger arbitrary code execution on the offline system.  Hence why I call it 100%.

If users are going to be inconvenienced by this solution (i.e. do a lot of work to use it), it should be at 100% mark, not 99% (and I think USB keys with appropriate OS preparation is close to 99% already).    On the other hand, I'm not against the use of your proposal in general, but I don't think it's a good, cross-platform, any-regular-user-can-do-it idea.  Or perhaps I am overestimating the amount of work it takes.   But if the person is using a Windows online system, it may be tough to setup SSH server properly (or at all!).  The idea should use SW/HW supported across all platforms (with minimal driver fuss), and not require any complicated OS configurations.  (that's why I love the audio idea)

P.S. - I just executed a rather "large" offline transaction:  there were a lot of inputs and large supporting transactions (used for input value verification).  It is probably the longest I've seen so far.  And it was 14.5 kB.   Using the audio solution, that's about 1 minute to move the data one way.  Another minute to move it back after signing...  Hmm...

Anyone familiar with Panda USB Vaccine? 

It's a free tool that supposedly will disable autorun completely on the host machine, but also has a way of creating a dummy, write-proof autorun.inf file that can only be overwritten through a drive format.  This guarantees that that no other program can create a malicious autorun.inf.

Of course, there are other vulnerabilities with USB drives, but I believe the auto-run is the worst.  If I find enough favorable reviews, I will run this tool over all the USB keys that I distribute as crowdfunding rewards.  Hell, if it really is as good as it sounds, I might as well put Panda on the drive, to be used on the offline computer the first time (manually initiated, of course).

Anyone have other recommendations for securing USB keys and autorun vulnerabilities?    I remember there used to be a vulnerability having to do with file icons, that caused compromise the moment the file browser opens (I think it was a png library bug).  I think this thread is a perfect place to discuss these kinds of threats and how to avoid them.

What I'm getting from this thread is that I should have two options:

(1) Default:  Current USB key transfer, with instructions for how to secure your offline system to minimize risk (and keeping up-to-date A/V, etc on the online computer).  I believe this method is working so far for the few people that have used it, and very straightforward since everyone knows how to use USB keys.

(2) Pseudo-Hidden Ultra-Security Option:  One of the above methods that achieves actual 100% (i.e. pure ASCII data transfer over very narrow-band, such as audio, or QR codes).  It will be available to those that seek it, but will not be the default and will require some work to get to it.   I believe that having it directly out there as a regular option would be counterproductive:  people will naturally select the "more secure" option, then probably give up on it entirely when it's too complicated.   

I'd rather let people use the USB option and feel safe about it, than risk them not using anything.  The ultra-paranoid users will be made aware of the "mythical" ultra-security option, and can go seek out how to set it up and use it (or may see it while sifting through menus/settings).

That is why I created BIP 0010, to make sure that at least the data being transmitted is standardized in some way.  I'm currently using BIP 0010 in Armory for the offline transaction, but I haven't received any real feedback from any other developers about possible improvements to the "standard" to make it usable in more diverse settings.  In particular, I will have to change BIP 0010 to accommodate P2SH scripts -- BIP 10 originally assumed vanilla OP_CHECKMULTISIG transactions...

If I'm going to update BIP 0010, I might as well update it with over developers' feedback along with P2SH scripts and comment lines...  But that's probably for a different thread.  In fact, there is no official BIP 0010 thread... maybe I'll start one.

It's a shame that the bit-rate is too slow for the audio solution.  It was starting to look appealing, before you mentioned its speed.

I think, for most users, the USB key setup is absolutely fine.  I'll just add some warnings and links to information about protecting yourself against autoplay attacks.  However, some users with more $10,000 worth of BTC will happily battle a 100% solution, especially if it only needs to be done once.  A little inconvenience is worth the 100% peace of mind.  In that case, minor inconvenience is not a show-stopper, the only requirements are that it is truly 100% and that the process does not become remarkably complicated for mixed OS setups.

In that case, perhaps QR codes and webcams are the way to go.  It might be a little bulky, but getting two USB webcams that can be moved around by hand to scan the displays is probably acceptable.  The determined user will figure out how to get their webcam setup, and they really only need to do it once.  It's just a bit more work for me to setup the interface.  And the interface might be confusing or overwhelming, but I will hide it under an "Ultra-security" user-mode targeted at users that really want this solution.
 
P.S. - Jim618, I really like your idea.  I saw that thread a long time ago and thought it was kinda silly.  But nearly all systems have speakers and microphones, it would just be a bit of work to do the signal processing for it:  but that's actually my specialty at my job!  Hmm....