Honestly, it's not hard at all -- but there is tremendous value in the simplicity of the current design. Armory is a very large, complicated beast. Any time I can come up with a solid solution that doesn't requiring maintaining/synchronizing new files to disk, and doesn't require any new interfaces, data entry, error checking, etc -- is better for me and less bugs for users. Pulling all the data from the blockchain scan and organizing it into a table is pretty darned easy. Most importantly, is that I get to avoid all issues with serialization/deserialization, and partially-written/corrupted files that crash Armory. It works 99.99% of the time, but then I spend many hours chasing down bugs for users that ends up being a corrupted address book file, or a bug in the code that reads/writes the data incorrectly and corrupts other things, causes crashing, or just a cascade of buggy behavior. In fact, I have had this happen with mempool.bin, and is actually why I added the "Revert All Settings" option. On second thought, this could piggyback on the Armory wallet file itself. Create a new entry type and create an interface for converting user data into the new entry type. This is favorable, because the wallet files have some corruption resistence built into them, and it makes sense to put address-book data in there anyway. |
|
|
|
Hi, I just waited for the bitcoin client to update the blockchain, so I could try out armory. (I have been using multibit, but I want to transfer to something more secure)
It took forever (didn't help that my connection sucks...)
But when I start armory, it always says offline mode.
Does anyone know how to troubleshoot this??
The software should tell you (on the dashboard) why it's in offline mode. Usually, it's because it can't find Bitcoin-Qt/bitcoind running, it can't find the blockfiles (in the Bitcoin-Qt home directory), or it can't find the internet. There's ways around all of this. If you're stuck and not sure what's going on, you can PM or email me a log-file, "File"->"Export Log File", and then attach it to an email or send it to me via email (which can be found at the very bottom of the main Armory webpage. |
|
|
|
I know about Electrum. Thanks for the tip about the reference client or Armory. What I want may be in Armory's "expert" mode and custom change behavior, but I want the client to pick maybe the oldest address that wasn't yet used for the change. So the bitcoins go around in circles within the fixed wallet, not just to originating address.
Bitcoin Spinner is one app, but it uses only 1 key, and it's for Android. Good for the phone but I'm also interested in a computer version.
I do not want a deterministic wallet. I want a randomly generated wallet. Specifically, I do not want a sequence of keys that can come out from a single password or root key as in the case of deterministic wallets.
I understand what they are, they have advantages, but I simply don't want them.
In general, Armory is going to pick the oldest addresses for sending new coins, so you would probably get the behavior you want. It also has coin-control in "Expert" mode, so you could super-customize its behavior if you wanted (though, age of coins is not displayed). I'm curious why you are so against deterministic wallets -- the number of ways that a deterministic wallet could be compromised that a random-key wallet would avoid, is basically non-existent (in an overwhelming majority of use cases). There's a reason Bitcoin-Qt/bitcoind will be moving to deterministic wallets by default: the advantages are staggering, with very little impact to security. Thanks for the Armory info, that is close to what I would want, so just a little bit more and it will do what I want. Sort of. I am against deterministic wallets because I do not want to take the chance that my wallet will be compromised. Yes, I understand it is negligibly small. With a random wallet, if one private key is compromised, I can take steps to secure the rest of my coins knowing that the other private keys are probably not yet compromised. If my deterministic wallet gets compromised (the root key), then my whole wallet is gone. By the time I find out, all my coins would probably have already been stolen. This problem is different from a stolen wallet.dat file. In both cases, you might lose all your coins if someone has physical access to your private key file wallet, or you get a trojan or other malware. I can confidently say that due to my computing practices, the chances of having my wallet remotely stolen or compromised is a lot smaller than someone getting physical access to my machine. I just don't get random malware, despite using Windows. And if my machine is stolen, being encrypted, I have enough time to transfer my coins to a new wallet. Besides, I want control of my private keys, I also use vanity keys (or private keys generated randomly by another software.) You might want to implement a deterministic wallet with a fixed number of keys (and no new ones get added) for one wallet, that might make me change my mind. The way I understand it, deterministic wallets currently implemented allow for unlimited key generation, or 13 billion keys in your example. But you have the same risk with a fixed number of keys. If your fixed pool of keys is compromised, then it's no different than a deterministic wallet. They get your wallet, and any time in the future, they can empty your account. Here's why you'll agree with me: In your example of a fixed set of keys, you are simply creating a new pool of keys every now and then, or when you suspect they are compromised. Well, why couldn't you just do the same thing with a deterministic wallet? Use 100 keys in the deterministic wallet (which you can do with Armory by setting "Send change back to first input address" and "Remember my choice"), and then you retire it every now and then and create a new deterministic wallet. With Armory, you can even keep the old wallet around in case you need it, or someone else sends it money. In both cases, you're creating a pool of keys, and changing them every so often. The difference is that with the deterministic wallet, each pool of keys can be backed up with only a couple lines of easily-typed data, instead of 100 lines of individual private keys. Even better than messing with change addresses: just use each wallet for 2 months, and then create a new one and switch. Then you can get new addresses for every transaction, which is much simpler, helps maintain your privacy, and your attack surface is identical to using a random set of keys that will be changed in 2 months. This is especially important, because the days of random-key wallets is going away. There's just too much benefit to them... all the major clients are moving over. Including Bitcoin-Qt and Multibit. |
|
|
|
Yes, but I use the Armory code to load the blockchain to produce the reports. It loads the blockchain that the bitcoin-qt client writes to disk.
Dooglus, I should apologize that you got stuck with the original analysis script I wrote. It was intended half as "sample armoryengine.py code" and half "Let's see how much information we can deduce about SD." As such, I implemented the search on the python side which was much simpler but painfully slow. If I'd done it "right", it could've been on the C++ side, where it's literally about 100x faster. Oh well. If it's a problem, I might be able to outsource some of the search code to C++ for you... this thread has become important enough... Even though I started the thread, I have been watching with great interest, and appreciate that you took over when I had no more time. I just sent you a donation for the value you have provided me (regardless of whether you think it's weird that I'd be donating to you for this  ). |
|
|
|
I want to put this in Armory, but maybe Bitcoin-Qt would do the same thing: roughly predict the time to finish downloading and verifying the chain in Bitcoin-Qt. It doesn't need to be exact by any means, but it shouldn't be like the Windows copy dialog. Anyone have any empirical data on this? Sure, I could do some experiments myself, but why if someone else already has it? I expect it would be some linear combination of the number of blocks remaining and the number MB remaining. I expect to be able to approximate both, along with rates of download/verification, and come up with something accurate to within 15 minutes. Perhaps only the MB-remaining-to-download is the important metric. Or maybe as simple as a reverse-lookup table based on previous measurements, that says 'if you are up to block 178k that's 50%, 202k is 75%", etc. I just want to set expectations appropriately for the first-time user. |
|
|
|
I've written the paper backup on notes by hand (I don't own a printer) and haven't noted the version of the wallet. It this a necessity?
So far, 1.35 is the only wallet version that has ever existed. And 2.0 will be the next, and hopefully final one. I expect that there will be a drop-down list to select the version -- given that paper backup information will look dramatically different for each version, it should be clear which version you used, just by the entry fields that show up when you select 1.35. |
|
|
|
Okay I understand your intention Two more question -> - When my armory wallet is encrypted, is the paper wallet encrypted too? - Do I have to worry that the wallet format of the paper wallet is no more supported in x years !? I really love your client and hope you won't stop the development someday! Paper backups are never encrypted. Part of the reason is to guarantee that you have a useful backup in X years when you need it -- and most people would forget the encryption passphrase by then and it would be like not having a backup at all. The paper backup displays the "Wallet Version", which is all you need to know. Even though I'm making a new wallet version now, I will still support the old one. Even in 10 years, any prior version of Armory that ever worked will let you recover the wallet and print off a list of all your private keys. Either way, the code to create the private keys from your paper backup should be a permanent part of Armory, even if Armory doesn't produce those wallets anymore, but because I promised you it would still work 10 years from now |
|
|
|
It *might* work with 12.04/12.10 but only the 32-bit versions. Please let me know if you try this. I have been meaning to make a 64-bit version, and/or 12.04/12.10, but I hate adding more things to support (luckily, that's not part of the regular release schedule, only occasionally remake the offline bundle since offline version isn't so important).
Okay I will let you know if I will try it. I have one more question regarding to offline wallet: Armory and your site tells me to make a paper backup of my wallet but I guess a digital copy does the job too or can the backup only be restored with a paper wallet? Maybe a stupid question but I want to get sure. Thank you! Either one will work, though you will need your encryption password for your digital backup. The reason I recommend paper is because if the paper is intact, it's guaranteed to be useful 10-20 years from now when you need it (even if it's thoroughly faded, you'll still be able to recover it). Making only one digital backup is like betting your life-savings that a $3 USB key sitting in box somewhere will still work 20 years from now. I wouldn't make that bet |
|
|
|
I would like to add addresses to my address list without having to send/receive coins from it.
Is this possible?
Am I missing something?
EDIT:
And by this, I mean I want in my list of people to send stuff to to be populated with the people I want to send stuff to without having to send anything in the first place.
Unfortunately not. There actually is no saved address book system ... it simply constructs your address book from your transaction history, meaning that address must have been used in a transaction anywhere. One day, I will add proper address book support, but for now this solution is extremely simple and reliable, even if it's not very flexible... Thank you for getting back to me. I'm glad it came right from the developer and not someone else. I've been learning python myself so i figure i'd tinker around and see what i can learn by editing/ doing stuff with your app... Jump right in! Python is fun, and the code should be fairly well-commented (though organization could be improved). Let me know if you have any questions about anything, I'm always happy to help people get interested in the code. If you were to make modifications that do what you're looking for, let me know and I'll try to review them and find a way to integrate them... |
|
|
|
I would like to add addresses to my address list without having to send/receive coins from it.
Is this possible?
Am I missing something?
EDIT:
And by this, I mean I want in my list of people to send stuff to to be populated with the people I want to send stuff to without having to send anything in the first place.
Unfortunately not. There actually is no saved address book system ... it simply constructs your address book from your transaction history, meaning that address must have been used in a transaction anywhere. One day, I will add proper address book support, but for now this solution is extremely simple and reliable, even if it's not very flexible... |
|
|
|
Hi!
I love this client.
Is there a offline linux bundle for ubuntu 12.10 available or does the existing work with it?
thanks for your help
What do you mean "offline linux bundle"? The version of armory from Github compiles just fine on Ubuntu 12.10 with the property dependencies installed. It's for users who want to wipe a computer/laptop and reinstall the OS without any initial connection to the internet. Usually those dependencies are downloaded by the OS. The bundle is everything you need for a first boot of an offline 10.04-32bit installation to work with Armory. It *might* work with 12.04/12.10 but only the 32-bit versions. Please let me know if you try this. I have been meaning to make a 64-bit version, and/or 12.04/12.10, but I hate adding more things to support (luckily, that's not part of the regular release schedule, only occasionally remake the offline bundle since offline version isn't so important). |
|
|
|
I know about Electrum. Thanks for the tip about the reference client or Armory. What I want may be in Armory's "expert" mode and custom change behavior, but I want the client to pick maybe the oldest address that wasn't yet used for the change. So the bitcoins go around in circles within the fixed wallet, not just to originating address.
Bitcoin Spinner is one app, but it uses only 1 key, and it's for Android. Good for the phone but I'm also interested in a computer version.
I do not want a deterministic wallet. I want a randomly generated wallet. Specifically, I do not want a sequence of keys that can come out from a single password or root key as in the case of deterministic wallets.
I understand what they are, they have advantages, but I simply don't want them.
In general, Armory is going to pick the oldest addresses for sending new coins, so you would probably get the behavior you want. It also has coin-control in "Expert" mode, so you could super-customize its behavior if you wanted (though, age of coins is not displayed). I'm curious why you are so against deterministic wallets -- the number of ways that a deterministic wallet could be compromised that a random-key wallet would avoid, is basically non-existent (in an overwhelming majority of use cases). There's a reason Bitcoin-Qt/bitcoind will be moving to deterministic wallets by default: the advantages are staggering, with very little impact to security. |
|
|
|
First of all, if your concern is backups, then use a client that has "deterministic wallets" (Armory and Electrum). That means that all addresses are derived from root key information and only needs to be backed up once. Ever. Seriously, you can use 13 billion addresses, and you'll still be backed up. Put a copy in your safe-deposit box, and you're good. Forever. Second of all, if you have other reasons for wanting to keep your key pool limited, then you can use Armory in "Expert" usermode, generate as many addresses as you want, then set the "Custom Change Behavior" to always send the change back to one of the originating addresses. This guarantees that sending coins will not create a new address in the wallet to receive change, and it will stay within the addresses that already have coins. After that, when you want to receive coins, you simply go into your wallet, select the address you want to receive to, and copy the address (or click "Receive payment to this address" to get the payment request dialog). Then you will always be receiving coins to your existing addresses, and change will only be sent back to them. My guess is, though, that you really just want a deterministic wallet. |
|
|
|
Sounds reasonable. Having random x values doesn't do any harm (unless you pick 0, but that is essentially impossible).
Actually, the secret is stored in the highest-order coefficient of the polynomial. So in the case of M=2, the secret is the slope of the line. Then it doesn't matter which points you pick. |
|
|
|
|
That's a good point about arbitrary-ness of the x-coord. I forget why I had originally decided that X needed to be randomly selected. It probably wasn't a very good reason, other than my brain thought of that idea first and never went back and reconsidered it.
On the upside, it could be super-simple to upgrade the script without bothering any one -- the line prefixes are there for a reason. Update the script to use "x:" for new backups, and the new unfrag script will simply read the hex repr of x and expand to 32-bytes if it's there or use x1-x4 if that's there.
As for the integer math, it almost seemed like there was no reason not to do it this way, since python has native huge-integer-handling.
|
|
|
|
|
By the way, TierNolan's comment below simply suggested an optimization to my current implementation of Shamir's Secret Sharing. There is nothing wrong with this implementation (accuracy-wise), it's just that the fragments could have been represented with about 1/2 the amount of data.
Given that this is a temporary solution (for the next few months), I will not complicate it by changing the format or calculations. I did this mainly for myself and wanted others to have access to it. These wallets will be deprecated in a couple months, anyway so I will focus on getting the new features implemented instead (though the code for recombining these fragments will remain in the repo forever).
|
|
|
|
Background: "Fragmenting" your wallet backup was going to be a feature in Armory's new wallets, but other priorities have come up and I can't finish the new wallets yet. But I still wanted to make this feature available since the math was fully implemented. Rather than complicate the GUI with more backup options that will have to change once again when I finally do finish the new wallets, I decided to make a command-line utility. Re-post of this message. Reposting because I figured this was in demand by a wider audience, and there's plenty of folks in the D&TD forum that don't mind using command-line tools (though, this is the only command-line-required function of Armory). The "correctness" of the utility should be self-evident. The output of the "fragging" script is N files in the execution directory. The input to the "unfragging" script is to have M+ files in the execution directory. And the unfragging script has a built in "test" so you can see it work correctly on multiple subsets of fragments. And it puts the git-commit version in the output so you know exactly what version created it (though, it will forever be in the master branch now, and I don't expect it to change).
Features:- Create M-of-N fragmented backup, for any value of N, and 2<=M<=8 (uses Shamir's Secret Sharing)
- Works with any Armory *.wallet files, encrypted or not (will prompt for passphrase if encrypted)
- Creates N text files that can easily be opened and printed (sorry, no QR codes from terminal)
- Having M-1 files gives attacker no advantage to brute forcing your wallet any more than having zero pieces. For a 7-of-20 backup, having 6 pieces is no more useful than having 0.
- Deterministic fragments means you can re-print lost fragments, or create more later (increase N)
- The git-commit version is put in the text file, in case you want to know exactly what version created it
- Error correction up to one character per line. Identifies which file&line has 2+ errors that can't be corrected automatically.
- Use the "unfrag" script right after "fragging" to test recombining various subsets of fragment files (for your own peace of mind)
- Endless error checking to make sure you get it right, or know what you did wrong.
Also, there is a completely dependency-less script "sss.py", which contains everything needed to restore these fragments. If you have python installed, you can run that script in isolation (default python installation, without installing Armory). The reason for making it, is it's easy to print off for the ultra-paranoid that think that the git-repo won't be available in the future for some reason. The script doesn't do the unfragging for you, but it has everything you need in a couple hundred lines of code and could be printed out on one or two sheets of paper.
Use Cases:To be used with regular Armory wallets. - 2-of-3: Instead of backing up your wallet to one place where anyone who finds it can recover your funds, create three pieces, of which any two is sufficient for recovering the wallet. Keep one in your house, one in a safe-deposit box at a bank, and give one to a family member.
- 5-of-7: If a company has 7 members, require a large majority of them to recover the funds. There will still be one or two people managing the offline computer, but it allows that offline computer to be backed up without risk of any one (or 4) members to steal the money.
- 3-of-5 or 3-of-6: A nice description here.
This still assumes a single-sig wallet, and that there is probably an offline computer with an encrypted version of it, accessible by you. The problem is that it needs to be backed up, and you don't want your backups to become the weakest point in the vulnerability chain. "Linked wallets" with multi-sig/multi-device is still in the works, and this is not a replacement for that. This is simply an alternative to backing up your wallet if you're concerned about physical security.
The scripts are in the extras directory. They have been pushed to the master branch.Sorry, this only works if you can run python scripts (possible in Windows, but you have to install all the python packages listed here for windows, and copy the .pyd file from the installation directory). Usage:$ python frag_wallet.py ~/.armory/armory_2QQkCkdt_.wallet 3 5
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --test
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt
Use the extras/frag_wallet.py script to break your paper backup in N files, and then you can immediately use the extras/unfrag_wallet.py script to execute the recovery process on 20 different subsets of M fragment files. Without the --test option, it will ask you for the appropriate encryption options, and then create an armory*.wallet file that can imported natively into Armory. Output of the fragging script$ python frag_wallet.py ~/.armory/armory_2QQkCkdt_.wallet 3 5
********************************************************************************
* Executing wallet-fragmenting script. Split your Armory wallet
* into N pieces, requiring any M to recover the wallet.
********************************************************************************
Found hash of current git commit: cf8ebe7cecf4bbd0457e8f984354aabb6e869e66
Here is the paper backup information for this wallet.
Root Key: hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
Chaincode: kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
Will create 3-of-5 fragmentation of your paper backup.
Continue? [Y/n]: y
About to create the fragments. Any other info/identifiers you would
like to add to each of the fragment files? Enter it on the next line:
(Enter info or leave blank): This fragment belongs to forum user etotheipi
Fragment 1: wallet_2QQkCkdt_frag1_need_3.txt
ID: 0301 02d1 93af fa6f
x1: aiow gnrr haaj hthf hsnf rskj tooi kjta ajuf
x2: jgto kgir ekgs whod kdkr rwsr hase jdui irdh
x3: rugh hoas sghk sowr esdj kgnw hihe jnri jehu
x4: eagt fair gjan ifwd retd ewnd aofu gnur jdut
y1: owrn sowu nfrw oeeo gggs ikkw feii ueja hwns
y2: aogt osig wonk jkis fkur gfhk kowt gwdu tter
y3: eats akge jeot rdug oeki frgd onia einn rddj
y4: dkfj nsed tijj nfkn dkne nieu ittf gnrg gkhj
Fragment 2: wallet_2QQkCkdt_frag2_need_3.txt
ID: 0302 02d1 93af fa6f
x1: fadf gtko nwii gfwd nogk osak jodn tess dgdt
x2: wris jthf kgdu jiwj jeho suii ugnw rewd rtoi
...
Fragment 5: wallet_2QQkCkdt_frag5_need_3.txt
ID: 0305 02d1 93af fa6f
x1: hfte nufh utis sseh aweu jkgw ugno iaow kdue
x2: nkwo ndsw jief taar tfrg kejn knwg tfkt akuw
x3: ofat fgui iwsk eofg toeo widn gwnh hauk knhg
x4: ugut wfww rfon kdkg uddi rutn nefh ftid iorn
y1: oerh rdie rnth dnda iaws ateg utaf drhh grnu
y2: hrte iaoh khwa jrfa dfeh doej usit infh fjhj
y3: uije nsga suod jiid sjau rhwh swsg rfgn gwud
y4: nwnd eheo issg tdrw kdei fhoj joun iuit jirf
NOTE: If you rerun this fragment script on the same wallet
with the same fragments-required value, M, then you will
get the same fragments. Use this to replace fragments,
or using a higher N-value to produce more pieces (but you
MUST use the same M value!)
$ ls -l
...
-rw-rw-r-- 1 alan alan 1008 Mar 6 11:32 wallet_2QQkCkdt_frag1_need_3.txt
-rw-rw-r-- 1 alan alan 1008 Mar 6 11:32 wallet_2QQkCkdt_frag2_need_3.txt
-rw-rw-r-- 1 alan alan 1008 Mar 6 11:32 wallet_2QQkCkdt_frag3_need_3.txt
-rw-rw-r-- 1 alan alan 1008 Mar 6 11:32 wallet_2QQkCkdt_frag4_need_3.txt
-rw-rw-r-- 1 alan alan 1008 Mar 6 11:32 wallet_2QQkCkdt_frag5_need_3.txt
...
Wallet ID: 2QQkCkdt
Create Date: 2013-Mar-06 12:29am
Git Commit: cf8ebe7cecf4bbd0457e8f984354aabb6e869e66
This fragment belongs to forum user etotheipi
This Fragment: #1
Fragments Needed: 3
Fragments Created: 5 (more fragments may have been created later)
The following is a single fragment of your wallet. Execute
the reconstruction script with any 3 of these fragment files
in the execution directory to recover your original wallet.
Each file can be reconstructed by manually typing the data
into a text editor. Only the following 9 lines (with prefixes)
are necessary in each file. All other data can be omitted.
ID: 0301 02d1 93af fa6f
x1: aiow gnrr haaj hthf hsnf rskj tooi kjta ajuf
x2: jgto kgir ekgs whod kdkr rwsr hase jdui irdh
x3: rugh hoas sghk sowr esdj kgnw hihe jnri jehu
x4: eagt fair gjan ifwd retd ewnd aofu gnur jdut
y1: owrn sowu nfrw oeeo gggs ikkw feii ueja hwns
y2: aogt osig wonk jkis fkur gfhk kowt gwdu tter
y3: eats akge jeot rdug oeki frgd onia einn rddj
y4: dkfj nsed tijj nfkn dkne nieu ittf gnrg gkhj
(it works without the --test flag, if you have more than M files) $ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --test
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
Recovered paper backup: 2QQkCkdt
hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
Testing reconstruction on 20 subsets:
Using fragments (0,1,3) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (2,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (1,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (1,2,3) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,1,2) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,2,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
...
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
Recovered paper backup: 2QQkCkdt
hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
You have supplied more pieces (5) than needed for reconstruction (3).
Are you trying to run the reconstruction test instead of actually
recovering the wallet? If so, wallet recovery will be skipped. [Y/n] n
Proceeding with wallet recovery...
Would you like to encrypt the recovered wallet? [Y/n]: y
Choose an encryption passphrase:
Passphrase:
Again:
Set the key-stretching parameters:
Seconds to compute (default 0.25): 2
Max RAM used, in MB (default 32): 16
Creating new wallet...
Please wait while the address pool is being populated....
Created armory_2QQkCkdt_recovered.wallet
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --testnet
ERROR: Some files are duplicates!
wallet_2QQkCkdt_frag1_need_3.txt is Fragment 1
wallet_2QQkCkdt_frag2_need_3.txt is Fragment 1
wallet_2QQkCkdt_frag4_need_3.txt is Fragment 4
Aborting
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --testnet
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
(WARNING) armoryengine.py:1235 - ***Checksum error! Attempting to fix...
(WARNING) armoryengine.py:1259 - Checksum fix failed
ERROR: Uncorrectable error
File: wallet_2QQkCkdt_frag1_need_3.txt
Line: y2
|
|
|
|
Since it's going to be a while before the new wallet format, I decided to go ahead and make "Fragmented Backups" available via the command line. Take your regular (single-sig) wallet, and plug it into the "frag_wallet.py" script, to break it into M-of-N pieces (N pieces, need any M to reconstruct). Use the unfrag script to test reconstruction to give yourself peace of mind that it really works. Then distribute the fragments how you see fit. Recollect M of them at a later time, put them in that directory, and it will recreate the Armory wallet for you! I was going to wait for the new wallets, since they use considerably less data for the paper backup... but given the infrequency of actually having to use this solution (and it's got built-in error correction), a little inconvenience is acceptable in my mind. - Create M-of-N fragmented backup, for any value of N, and 2<=M<=8
- Works with any Armory *.wallet files, encrypted or not (will prompt for passphrase if encrypted)
- Creates N text files that can easily be opened and printed (sorry, no QR codes from terminal)
- Deterministic fragments means you can re-print lost fragments, or create more later (increase N)
- The git-commit version is put in the text file, in case you want to know exactly what version created it
- Error correction up to one character per line. Identifies which file&line has 2+ errors that can't be corrected automatically.
- Use the "unfrag" script right after "fragging" to test recombining various subsets of fragment files (for your own peace of mind)
- Endless error checking to make sure you get it right, or know what you did wrong.
See my post about it here. |
|
|
|
Well, you guys were too slow and I just did it anyway. I also left out one critical reason: I really wanted this feature for myself! And I don't want to wait 2 months for it! I knew it would take me a day, and I'm sure someone would benefit from it, now. Also, it's not wasted effort -- it's more sample code for other users, and I got the fragment data structures ironed out which will be recycled when I implement it in the GUI. I have tested the heck out of it, and successfully restored quite a few test wallets with it. Let me know what you think! - Create M-of-N fragmented backup, for any value of N, and 2<=M<=8
- Works with any Armory *.wallet files, encrypted or not (will prompt for passphrase if encrypted)
- Creates N text files that can easily be opened and printed (sorry, no QR codes from terminal)
- Deterministic fragments means you can re-print lost fragments, or create more later (increase N)
- The git-commit version is put in the text file, in case you want to know exactly what version created it
- Error correction up to one character per line. Identifies which file&line has 2+ errors that can't be corrected automatically.
- Use the "unfrag" script right after "fragging" to test recombining various subsets of fragment files (for your own peace of mind)
- Endless error checking to make sure you get it right, or know what you did wrong.
Checkout the armoryd branch, and the scripts are in the extras directory.Sorry, this only works if you can run python scripts (possible in Windows, but you have to install some stuff). $ python frag_wallet.py ~/.armory/armory_2QQkCkdt_.wallet 3 5
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --test
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt
Use the extras/frag_wallet.py script to break your paper backup in N files, and then you can immediately use the extras/unfrag_wallet.py script to execute the recovery process on 20 different subsets of M fragment files. Without the --test option, it will ask you for the appropriate encryption options, and then create an armory*.wallet file that can imported natively into Armory. Output of the fragging script$ python frag_wallet.py ~/.armory/armory_2QQkCkdt_.wallet 3 5
********************************************************************************
* Executing wallet-fragmenting script. Split your Armory wallet
* into N pieces, requiring any M to recover the wallet.
********************************************************************************
Found hash of current git commit: cf8ebe7cecf4bbd0457e8f984354aabb6e869e66
Here is the paper backup information for this wallet.
Root Key: hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
Chaincode: kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
Will create 3-of-5 fragmentation of your paper backup.
Continue? [Y/n]: y
About to create the fragments. Any other info/identifiers you would
like to add to each of the fragment files? Enter it on the next line:
(Enter info or leave blank): This fragment belongs to forum user etotheipi
Fragment 1: wallet_2QQkCkdt_frag1_need_3.txt
ID: 0301 02d1 93af fa6f
x1: aiow gnrr haaj hthf hsnf rskj tooi kjta ajuf
x2: jgto kgir ekgs whod kdkr rwsr hase jdui irdh
x3: rugh hoas sghk sowr esdj kgnw hihe jnri jehu
x4: eagt fair gjan ifwd retd ewnd aofu gnur jdut
y1: owrn sowu nfrw oeeo gggs ikkw feii ueja hwns
y2: aogt osig wonk jkis fkur gfhk kowt gwdu tter
y3: eats akge jeot rdug oeki frgd onia einn rddj
y4: dkfj nsed tijj nfkn dkne nieu ittf gnrg gkhj
Fragment 2: wallet_2QQkCkdt_frag2_need_3.txt
ID: 0302 02d1 93af fa6f
x1: fadf gtko nwii gfwd nogk osak jodn tess dgdt
x2: wris jthf kgdu jiwj jeho suii ugnw rewd rtoi
...
Fragment 5: wallet_2QQkCkdt_frag5_need_3.txt
ID: 0305 02d1 93af fa6f
x1: hfte nufh utis sseh aweu jkgw ugno iaow kdue
x2: nkwo ndsw jief taar tfrg kejn knwg tfkt akuw
x3: ofat fgui iwsk eofg toeo widn gwnh hauk knhg
x4: ugut wfww rfon kdkg uddi rutn nefh ftid iorn
y1: oerh rdie rnth dnda iaws ateg utaf drhh grnu
y2: hrte iaoh khwa jrfa dfeh doej usit infh fjhj
y3: uije nsga suod jiid sjau rhwh swsg rfgn gwud
y4: nwnd eheo issg tdrw kdei fhoj joun iuit jirf
NOTE: If you rerun this fragment script on the same wallet
with the same fragments-required value, M, then you will
get the same fragments. Use this to replace fragments,
or using a higher N-value to produce more pieces (but you
MUST use the same M value!)
Wallet ID: 2QQkCkdt
Create Date: 2013-Mar-06 12:29am
Git Commit: cf8ebe7cecf4bbd0457e8f984354aabb6e869e66
This fragment belongs to forum user etotheipi
This Fragment: #1
Fragments Needed: 3
Fragments Created: 5 (more fragments may have been created later)
The following is a single fragment of your wallet. Execute
the reconstruction script with any 3 of these fragment files
in the execution directory to recover your original wallet.
Each file can be reconstructed by manually typing the data
into a text editor. Only the following 9 lines (with prefixes)
are necessary in each file. All other data can be omitted.
ID: 0301 02d1 93af fa6f
x1: aiow gnrr haaj hthf hsnf rskj tooi kjta ajuf
x2: jgto kgir ekgs whod kdkr rwsr hase jdui irdh
x3: rugh hoas sghk sowr esdj kgnw hihe jnri jehu
x4: eagt fair gjan ifwd retd ewnd aofu gnur jdut
y1: owrn sowu nfrw oeeo gggs ikkw feii ueja hwns
y2: aogt osig wonk jkis fkur gfhk kowt gwdu tter
y3: eats akge jeot rdug oeki frgd onia einn rddj
y4: dkfj nsed tijj nfkn dkne nieu ittf gnrg gkhj
(it works without the --test flag, if you have more than M files) $ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --test
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
Recovered paper backup: 2QQkCkdt
hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
Testing reconstruction on 20 subsets:
Using fragments (0,1,3) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (2,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (1,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (1,2,3) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,1,2) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (2,3,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
Using fragments (0,2,4) Reconstructed (first line): hrfr dejf snwf rtun rtin dhri snor aihd wiut
...
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
Recovered paper backup: 2QQkCkdt
hrfr dejf snwf rtun rtin dhri snor aihd wiut
otjf osws teaa gjei ihoa ffaa fojn swng tusg
kwig jorj agtj ragt kwrn dnhf ojgw tkwg snti
hdst aurh osfj ajhd nwra ogdd dsiw saff fwra
You have supplied more pieces (5) than needed for reconstruction (3).
Are you trying to run the reconstruction test instead of actually
recovering the wallet? If so, wallet recovery will be skipped. [Y/n] n
Proceeding with wallet recovery...
Would you like to encrypt the recovered wallet? [Y/n]: y
Choose an encryption passphrase:
Passphrase:
Again:
Set the key-stretching parameters:
Seconds to compute (default 0.25): 2
Max RAM used, in MB (default 32): 16
Creating new wallet...
Please wait while the address pool is being populated....
Created armory_2QQkCkdt_recovered.wallet
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --testnet
ERROR: Some files are duplicates!
wallet_2QQkCkdt_frag1_need_3.txt is Fragment 1
wallet_2QQkCkdt_frag2_need_3.txt is Fragment 1
wallet_2QQkCkdt_frag4_need_3.txt is Fragment 4
Aborting
$ python unfrag_wallet.py wallet_2QQkCkdt_frag*.txt --testnet
********************************************************************************
* Restoring wallet from 3-of-N fragmented backup!
********************************************************************************
(WARNING) armoryengine.py:1235 - ***Checksum error! Attempting to fix...
(WARNING) armoryengine.py:1259 - Checksum fix failed
ERROR: Uncorrectable error
File: wallet_2QQkCkdt_frag1_need_3.txt
Line: y2
|
|
|
|
I do. I've got a Raspberry Pi connected to my computer via serial->USB cable. It's had its serial TTY disabled and is running a python script I wrote which listens for ProcolBuffer messages. When it receives a message asking it to sign a transaction, it accepts the wallet's passphrase on its own keyboard, then signs the transaction and passes it back in another PB message. Armory, meanwhile, is also listening for these messages and displays the now signed transaction once it is received and allows me to broadcast it to the network.
@chrisrico, Are you willing to donate that code to the Armory project? I've been meaning to setup something very similar, but it looks like you've already done most of the hard work. I want to checkout that code, review it thoroughly, and adapt pieces of it into the master branch. I haven't really looked at it yet, but I expect I'll be breaking it down and integrating it in my own way/style (or perhaps you've already done most of what I planned to do...?). If so, can you send me an email to discuss this? etotheipi at gmail. |
|
|
|
|
Show Posts
