For those that aren't part of the Alt-Clients thread, I just posted a tool I created to leverage Joric's PyWallet to migrate your Satoshi wallet to Armory.  You can find it here:  https://bitcointalk.org/index.php?topic=56424.msg791695#msg791695

This is a temporary solution until I get something integrated into Armory.  If you don't mind some command line stuff this should work great -- tested on Win 7 64-bit.  Should work on linux if you already have all the packages installed to run Armory, and copy the .so file from Armory into this downloaded directory.

Simply run PyWallet (included in zip-file) to pull your keys out of your Satoshi wallet, then run my tool (ArmoryBulkImport.py) to import them into your Armory wallet.  Because of the keypool size, you are guaranteed to get at least 100 addresses added to your Armory wallet.  This should work fine offline, and then you can create your watching-only copy and put it on your online computer. 

Click the link above for more details.



Did it work?  (besides the send-tx bug that gives an error which I can't fix until next week...)

Experimental Wallet Migration Tool
https://github.com/downloads/etotheipi/BitcoinArmory/Armory_MigrateWallet.zip
https://github.com/downloads/etotheipi/BitcoinArmory/Armory_MigrateWallet_Win32.zip (for 32-bit)


WARNING:  This tool is experimental, so please make sure everything is backed up appropriately before trying this!

Something very similar will be integrated into Armory, but probably not for another couple weeks.  If you can't wait, go ahead and use this tool.

The zip file linked above contains Joric's pywallet.py, a script I wrote called ArmoryBulkImport.py, and then all the stuff you need to run it on Windows.  You should only need to have python installed (2.7.2 is ideal) to run these scripts.  

If you are on Linux, you should unpack either zipfile, and copy the compiled _CppBlockUtils.so and CppBlockUtils.py files from your BitcoinArmory directory into this one (it is created after the "make swig" step in the instructions).  I am not on a Linux machine, so I can't test it just yet, but the Windows version has been tested (64-bit only).  If there are any problems with it, it will have to wait until next week, but I thought I might be able to get this out the door right now to help people who can't proceed with offline wallets.

Wallet Migration Tool

This is two tools:  pywallet.py from Joric, which will allow you to dump your wallet.dat file from the Satoshi client into a file, and then ArmoryBulkImport.py which will read any file containing a bunch of private keys and import them into a target Armory wallet (it literally breaks down the entire contents of the file, and grabs everything that looks like a private key).

With pywallet, you must use --dumpwallet flag and pipe everything to a file.  Use --datadir=/path/containing/wallet.dat/ if wallet.dat is in a non-std locations.  Use --password if your Satoshi wallet is encrypted.


Once you have the keys in the file (or any file containing lots of private keys), you can run


The script has a ton of checks built-in, including only importing private keys that have a checksum:  this guarantees that arbitrary 32-byte strings are not treated as private keys.  And if your target Armory wallet is encrypted, it will prompt you for a password to unlock it (without leaving anything in your shell history).

Please let me know if something doesn't work quite right.  I'll take a shot at fixing it, but likely won't get to it until next week.

-Eto

Otoh,

You're absolutely right.  I was amused by the comment, without regards to who or why it was said.  It's comforting to me to see folks really sticking up for my project, even if it was inappropriate.  In this case, it was inappropriate -- I have no intention to create a hostile environment,  and I never wanted to suggest that people need to donate to participate.  Sometimes I'm a little tactless... 

I am very much interested in seeing discussion about the program, and understand how others are receiving it.  Feedback will help this project tremendously, completely separate from donations, and I do appreciate your comments.  I think it's a little late for me to re-brand the program.  The name was original "Bitcoin Armory" which didn't have quite the same "violent" connotation as an arbitrary "Armory."  By the time I changed the name to just "Armory" I was already desensitized to the underlying meaning of the word.  Assuming no legal troubles related to "The Armory", I expect I will just keep it and hope the same happens to everyone else.  Hindsight is 20/20, but there's worse situations to be in...

I hope you will forgive my tactlessness and consider spending some time with the program itself, and let me know what you think.
 

You are right, it's fairly complicated.  I spent about 20 minutes looking at it, and got the gist of it:  it looks like each party is producing and sharing lots of polynomials with all the other participants, in such a way that some common information can be recovered later on... But I'm going to need a lot more than 20 minutes to fully absorb it. 

When they say information is exchanged over a secure channel, I assume that something like ECDH is used to establish an encryption key, or simply using ECIES to establish a secure channel...?  Either way, it looks like it would require a lot of work to get 100 different participants to engage in this setup, requiring each participant to contact each other participant (which is what it looks like from the statement that participant Pi sends fi(xj) to participant Pj). 

Beyond the large "social" overhead of execution, my biggest concern is that these papers seem very theoretical, without any evidence that the complexity is actually secure.  I totally agree with you about the OP_CHECKMULTISIG not scaling well, but I'm not sure that a few theoretical papers can be trusted to the level of NIST-approved ECDSA operations, which I believe is necessary for any money system.  I'm sure you're familiar with all the things that can go wrong with asymmetric encryptions if you don't pay attention:  such as picking prime numbers, p & q for RSA such that (p-1) and (q-1) don't have large prime factors.  Or reusing "random" numbers in ECDSA signatures.  I remember in my Crypto class learning all sorts of abstract no-nos for use in cryptography.

Even though OP_CHECKMULTISIG doesn't scale well, I still feel like 99% of the usability is there (as part of P2SH scripts).  I would be interested to learn more about this, though...

Your best bet is Joric's PyWallet.  About a month ago, Joric figured out the Satoshi wallet encryption, and released an update that will extract the keys if you enter the encryption passphrase.  I've used it once or twice, and it's pretty slick.  You can use it as a command-line tool, or you can run it in server mode, and access it via a nice web interface by putting "localhost:8989" into your browser. 

The biggest issue is that you're probably going to get a lot of keys dumped out, so you have to know which one is the right one.  Luckily with the full-RAM Armory, checking the balance of a fresh address takes less than 1 sec!  The copy&paste procedure will be the bottleneck (at least until I get a bulk-import UI).

Yup, I'll be sending you the encryption seminar shortly.  And please email me with an address if you want a T-shirt or USB key.  I will be getting them made and distributed after the funding period is over.


I totally agree with you on this.  I only proposed the script as a temporary solution for the really-determined folks until I can get something integrated into the UI.  The script is probably 10 lines of python.  But integrating Pywallet and bulk-import into a nice, pleasant, bug-free interface is considerably more lines of code

Finally hit the $3k mark!  Sure, I don't think I can make the full $12k, but $3k is certainly enough to make a difference here.  And I'll be getting an article on BitcoinMedia soon, so that will hopefully draw in some folks not on the forums   If not, I may have to commit to using a large chunk of unpaid leave instead of actually going part-time... nonetheless, any full-day chunks of time I can spend on Armory while the house is empty is when I make the most substantial progress...

So there's a lot to respond to here... amazing what accumulates over the course of one day!

@ Muyuu, Holliday & Cypherdoc,

Armory wallets are completely different than Satoshi-client wallets, and for a very good reason:  the Satoshi-client wallets are terrible.  They require a DB engine, which requires an extra library, and the DB itself is what was responsible for the wallet-not-actually-encrypted bug.  Supporting Satoshi wallets is a step backwards, and a substantial time investment.  Not to mention, there has been some talk recently among the devs of switching away from the current Satoshi wallet format -- so I feel like it's not worth it. 

However, I will support migration.  I will leverage Joric's pywallet tool to help pull all the private keys out and import them into an Armory wallet.  It's the best I can do amidst my priorities.

In the meantime, the thing stopping users from manually doing this, is the lack of a bulk-import feature in Armory.  It was already part of my RAM-upgrade, but that's not going to be done for a while (but will be necessary when it takes 30s per address import).   Until then, I can probably put together a super-quick python script that will simply import a list of private keys in a specified Armory wallet -- then the determined users can use Joric's pywallet to dump the private keys.  Or maybe I will send that script to Joric:  maybe he would be up for making an import tool like this...


@ Rassah

This is something I've thought about, but there are a lot of risks associated with holding a pruned blockchain.  I believe it will have to be done eventually, but that there will also be a network-level accommodation for it:  such as including unspent-tx-out-tree-hashes in the coinbase transactions, so that nodes can verify their pruned blockchains against other nodes.  I am wholly in support of such a scheme if it can be made to work, but I feel like there's going to be a big paradigm shift to make this doable in Armory without it (and maintain a high confidence in the security of the application)

Regardless, I don't see this as a solution to the RAM problem, because I don't want to bank on the pruned blockchain taking up less RAM than some arbitrary system.  One day Armory works, the next day someone creates a ton of unspent outputs and Armory won't load anymore.    I have a solution for the RAM issue (without pruning), that I have already confirmed works in Linux, and I don't see why it wouldn't work in Windows.  I just have to get a solid chunk of time to get it all implemented, debugged, and tested.  It'll be a couple weeks.

@ Otoh

It's easy to say in hindsight I should've picked a different name.  Sure, the word "Armory" has different initial impressions to different people, but in the end it was concise, unique, memorable, and held some meaning related to what I wanted.  Just like "Google" (googol) or "Oracle", one day it just becomes a name, instead of a common word doubling as a name. 

@ Indeminfied

Lol.  Thanks for your actual donation, and bullying others to donate, as well.  Perhaps you can be the official bouncer for this thread

Muyuu,

I have intentionally avoided wallet importing because of all sorts of weird and nasty things that can happen when two programs are using the same wallet.  I'd prefer if users starts new wallets and transfer coins to them.  However, that doesnt' mean I'll never allow it, I just want to prevent users from shooting themselves in the foot right now, and I'll work on wallet import (with appropriate built-in precautions), later.


I had plans to do something like that, eventually, but it's low on my priority list.  On the other hand, my code base is setup to pretty easily allow one to quickly see what addresses have money and select or deselect addresses to be used to fund a given transaction.  So, I guess I could bump it up in priority given that I'm well-prepared for it  Either way, I gotta fix the RAM issue first, and then I'll think about stuff like this.  



This is actually a different kind of anonymity.  It doesn't include or exclude specific addresses, it only optimizes the coin selection to use(/link) as few input addresses as possible, make the outputs look indistinguishable, and minimize tx fee.  It's already built into the Armory codebase, I just need to set up an options page so that users can specify their preference.  But this wouldn't replace the full-scale anonymity feature.

This is a very interesting discussion, exactly the kind of stuff I want to address with Armory when the time comes...

I really like the idea of incentivizing miners, and I'm sure any specific multi-sig scheme like this can be made straightforward with enough UI innovation.  as long as we don't build too much flexibility and options into it, which will really complicate things.  But this may be a very specific case worthy of its own UI just for miner incentivization, and particularly important with the pending block reward decrease.

I believe nLocktime technically works, but replacement is completely disabled, which means a lot of different kinds of contracts are not feasible.  Is locktime currently usable, even without replacement?  (i.e. can we create locked transactions that become valid in the future?)

There's also a strong reliance on alternate hashcodes, which by themselves are pretty powerful.  However, I am similarly unclear about the availability of alternate hashcodes.  I'm sure they are non-standard, but are they completely disabled?  Will a block be rejected by the Satoshi client if it involves a alternate hashcode?  If so, will nodes also forward those transactions?

I think the Bitcoin contracts page is a great place for the theoretical discussion, but I'm intensely interested in what will actually be usable when multi-sig is enabled.  Mainly because I'm planning to tackle multi-sig UIs in Armory at full speed, once it is enabled on the network, but I need to focus on what will actually be accepted by the network, right now.

To summarize everything I have talked about above:  I could theoretically implement:

• 1-of-2 transactions in a very pleasant, straightforward way
• 1-of-N transactions, but it would require manually circulating a single packet for everyone to cumulatively sign before you can even compute the 1-of-N address
• 2-of-2 transactions: but only for the case where the distribution is entirely up to one party, and the other party doesn't mind giving up the private key
• N-of-N transactions (3-of-3, 4-of-4, etc):  but it has the same creation complexity of the 1-of-N above, and the spend-complexity of the 2-of-2 above (requiring all parties except one to send their private keys to one party who gets full control over the coins)

Until Mike Hearn mentioned something, I was not aware that thresholding schemes even existed for ECDSA (like 2-of-3 txs).  It seems that this problem would be a lot easier with RSA (because signing&verification operations are much cleaner, simpler and commutative).  But key lengths are 10-20x the size, and obviously BTC doesn't use RSA...

I think it's all moot with real multi-sig around the corner.  It's a fun mathematical exercise, but I think that's all it is, since it would probably take me longer to implement these ideas, than it will take before real multi-sig is enabled on the network.

Thanks Indemnified!

With the recent, high-profile BTC thefts, I have updated this thread to more-directly market Armory as the solution.  It sounds like the only reason Slush didn't lose more money, was because he was using cold-storage for most of his funds.  Multi-signature transactions would help, but they are stalled indefinitely.  And, most users do not have the patience or skill to figure out "cold-storage" on their own, which is where Armory shines!  I guess I should rename Armory Offline Wallets to Armory Cold-Storage Solutions! 

So, I am bumping my own thread with a title change, in hope of really highlighting why users should be interested in Armory.  I think even after multi-signature transactions are enabled, offline wallets will be the best way to protect yourself, even against highly-targeted attackers.

Note: I am on vacation until the end of the week, and it appears I have introduced a send-tx bug into Armory just before I left (in version 0.55-alpha)!  Gah!  If you are trying out Armory for the first time and you try to send Bitcoins from your Armory wallet, you will get an error that it was not accepted by the network:  but the transaction did go through!  Just be patient and wait a few blocks (Armory still collects new block information, but it won't acknowledge the transaction until it appears in the blockchain).  When I get back from vacation, I will be fixing the bug! 

Gah!  The sky is falling, the moment I leave on vacation!  I'll have to attend to all this next week.  Sorry!

P.S. - Red Emerald, does task manager still show ArmoryQt.exe?   If not, it shouldn't be locking RAM anymore.

Fornit, I see you're learning quickly    Unfortunately, now that I'm distributing full binaries, I cannot just push new .py files, I have to do a full recompile and re-distribution of binaries.  So it sounds like Holliday is going to have to wait.  What a great time to leave town for a week!  


Yeah, the requirement is 1+ confirmation for tx from other people, 0 confirmations for change-back-to-self outputs.  It appears that I did introduce a bug recently, and now I'm out and won't be able to attend to it for a week  Glad to hear it's still usable, at least...

PS what OS are you in that you experience the same problems?

Holliday,  this is actually an interesting topic,  since I haven't dealt much with P2Pool.   Is there a reason that you have to run the server from a non-default location?   Is this going to be common among all P2Pool users?   Does the P2Pool server behave like a regular instance of Bitcoind?   I most definitely want to accommodate setups like this that I don't use,  but a lot of other people do.

I thought you said you were setting up an offline wallet,  so I was jumping ahead of you there... Definitely get you blk0001.dat file in the right place,  and this will go *a lot* smoother :-)  I'll check on the command line options,  later

Holliday,  the primary issue is that the blockchain is not being loaded.   I think all other problems will clear up when you get that.

Also, when you import a watching-only wallet, it will default to not being yours.  This is to prevent an inexperienced user from being persuaded to import someone else's wallet and believing the money is their own.

So,  once you import the watching only wallet,  you have to go into the wallet properties and change the belongs-to field.   I thought I had that in the instructions... I will add a pop-up windows for when you import a watching-only wallet, that asks whether it is yours,  or that this step can be skipped entirely.

Since I'm not in a position to check whether the is a blkdir option, maybe someone else who doesn't mind looking at the python code could check for me and report back.   I honestly can't remember if I implemented it!  If not,  then you'll have to put your bitcoin dir back to default,  or wait a couple days for me to get access to a development system and commit a fix :-(

Sounds like there's a lot of little problems here.  Armory will probably go into offline mode of it can't find the blockchain maintained by bitcoind.  However I intended to put in a CLI option for specifying the dir holding the blockchain if it's not standard.   I don't remember if I ever implemented it,  and I'm on my phone right now not in a position to check.  But you can check yourself by going to the github project page and searchingfor "optparse" in Armory.py.   

As for the other issue,  I bet that you did not mark the wallet as your own.  Is the wallet identified on the main screen with a standard white background or with the dark blue?  Does it say "Watch-Only",  or "Offline"?  My guess is that it isn't marked as belonging to you,  and the default filter on the mainstream is set to "My Wallets. "  you can change the filter on the bottom left of the main screen to "All Wallets" which will start including "watch-only" wallets. 

To avoid this in the future,  click on the "Belongs to:" field in wallet properties and check the checbox.  The wallet will then appear with dark blue background and it's balance will be included in your main balance.

As for why it shows offline,  I'm not totally sure without more info.  My guess is that it's the lack of blockchain,  even though it's technically connected to bitcoind.

Red Emerald, thanks so much.  I like to think I am good at UI design, and I definitely have a high level of patience to polish everything,  catch every error,  and warn users about potentially stupid actions :-)  etc..
 
Maybe you could repeat that comment on my crowdfunding page...? :-)   It would give it a nice bump,  and I will modify the description to include the phrase "cold-storage. "  it sounds like "Bringing cold storage to the regular user" would be a much better marketing slogan than "offline wallets" and then having to describe what they are...  It sounds like slush saved himself a lot of money using cold-storage, so it makes a lot of sense to point out that's what Armory gives you...

There has always been this nagging discomfort with me with regards to P2SH...  and now I finally know what it is...  Backups.  I have put a lot of work into deterministic wallets and paper backups in Armory,  to try to solve one of the most frustrating modes of failure: HDD failure or overwrite combined with either no backup or a stale backup. 

The issue that I am finding with P2SH (which would happen with any similar multi signature scheme that hide addresses),  is that the user is back to requiring a persistent backup solution, because he cannot even identify, much less spend his multi-sig-encumbered coins if he doesn't have the P2SH script.

On the upside,  the P2SH scripts are not nearly as sensitive as private keys.   But they are just as important! If you lose them,  you (probably)  lose the money behind it...

This presents a serious implementation issue:  how do I modify Armory to accommodate backing up the scripts.   I had originally made space for them in the wallet file but now I am realizing that will not enable easy backups (not everyone wants to backup their wallets remotely,  encrypted or not).  So I'm thinking that I should instead create a separate P2SH scripts file,  separate from the wallet,  allowing the user to place it in,  say,  the Dropbox folder.   If the user doesn't want the data stored unencrypted (for privacy reasons),  asymmetric encryption can be used to encrypt each script before appending it to the file.   It would seem that there is no grace time for backups like the Satoshi wallet has (generating 100 address pool)   because you don't know what scripts you're going to receive until you actually get/create them.   They need to be backed up immediately. 

On the other hand,  if these multi-sig scripts require multiple parties,  they are like to have the scripts too,  and you might be able to request them. But this could be a royal pain in the ass if you do business with a lot of different people...

Any recommendations are welcome.  Obviously,  tying the user to dropbox is sub-optimal, but I'm not seeing any other solution that a regular user could put up with that would provide the appropriate level of backups.   Using standard OP_CHECKMULTISIG would solve this,  but there are other reasons it is not being adopted (though I always believed it should be an option even if it isn't the recommended,  but this is a different discussion...)

How could I forget?!  You can also simulate a 1-of-N transaction with this calculator, and without requiring anyone to give up their private keys!

Two parties create addresses and exchange public keys.  They do the ECDH to create a new public key as described before.  Except this will not be used as a public key:  it turns out that they are the only two people that can calculate this elliptic curve point:  which is now a shared secret.  They can then hash the key to come up with a new private key that both of them can calculate.  They then fund the associated address.  

Then, they are the only two people that know the private key, and thus either of them can spend the money however they want.  This is effectively 1-of-2, though a little unsafe since you are both operating with the same private key.  You could do 1-of-N but it's a little more complicated.

I'm sure even more stuff is possible!   And I'm sure there's lots of discussion on the forums about it, but I just haven't looked around enough yet!


EDIT: If real multi-sig wasn't just around the corner, I could implement 1-of-2 deterministic wallets:   you make your own wallet and exchange watching-only wallets.  From this, you can both calculate an infinite sequence of private keys, just like a regular deterministic wallet: except that the second party can access it to.

But I think this is moot, now.  With Multi-sig right around the corner... putting in effort to enable this would not be worth, especially because the community is more interested in 2-of-2 and 2-of-3, not 1-of-2.

I just released version 0.55 (final).  It can be found at http://bitcoinarmory.com/index.php/get-armory.  The only difference (from RC2) is a proactive security upgrade to the message signing.  But it was something that probably couldn't be exploited, anyway, so it's not critical if you are already operating with 0.55-RC2.

I noticed recently that some of my transacations are failing to be acknowledged by Armory, but do actually end up in the blockchain.  I witnessed the same thing when I went back to 0.55-RC1, so it's clearly not a completely fresh bug.  But I'm going out of town for a week, and it appears that Armory transactions still work: you will just get an error message, followed by seeing the transaction show up in the next block.   If this really bugs you, you can go back to Armory version 0.51.  Or maybe I'm the only person seeing it...?  I will investigate further in a week!