Is it compile the source?
No, it installs the official .deb package (compiled and signed by the Armory devs). |
|
|
|
Some of the labels have gone missing, but more seriously so is my recent purchase.
Is the receiving address visible in your wallet? If not, check the keypool size by running getwalletinfo in the debug console, and assuming the keypool isn't empty, creating a new address should result in the same address you created earlier. I have done a -rescan which didn't do much, and a -reindex which looks as if
the wallet is working properly.
Have you tried a -rescan after the -reindex? I have a backup from a few days ago, but it doesn't have the newly created address in it.
If your current wallet is corrupted, try restoring the backup (but of course backup your current wallet first), and then check its keypool size. If its keypool isn't empty, your address should be in it (and should appear when you create a few new receiving addresses). |
|
|
|
Would it be an idea to create an Ubuntu/Debian repo for Armory, and add this to the system's repos when the Armory package is installed? Then, after installing Armory once, all updates will just be installed along with the system updates. The Ubuntu Google Chrome package does this. It's pretty handy, means you only have to install once and not worry about updates after that.
Until something like this happens, if anyone's interested I just posted a script that will download and install/update Armory to the latest stable version over in this thread. Cheers |
|
|
|
This is an install script for Armory on Ubuntu. It's nothing real special, but I needed it for myself (for Travis CI) and thought I may as well share. It locates and automatically downloads, verifies, and installs the latest stable version of Armory plus all required prerequisites. Please note that on Ubuntu Server edition, there are a lot of GUI-related prerequisites that while technically required (and installed by this script), aren't required in practice, so you may prefer not to use this script in that case. #!/bin/bash
set -e
DOWNLOADS="`curl -fsS --retry 10 https://s3.amazonaws.com/bitcoinarmory-media/announce.txt | awk '/^downloads/{print $2}'`"
echo "$DOWNLOADS" | grep -q '^https://' || { echo "Can't find Armory downloads URL"; exit 1; }
uname -m | grep -q '64$' && BITS=64 || BITS=32
LATEST="`curl -fsS --retry 10 \"$DOWNLOADS\" | grep "^Armory [0-9.]* Ubuntu [0-9.,]*\`lsb_release -rs\`[0-9.,]* $BITS " | sort -k 2V | tail -1 | awk '{print $6}'`"
echo "$LATEST" | grep -q '^https://' || { echo "Can't find latest Armory download URL"; exit 1; }
curl -fsS --retry 10 -o '/tmp/armory.deb' "$LATEST"
sudo apt-get update
sudo apt-get install dpkg-sig gdebi-core
gpg -q --keyserver keyserver.ubuntu.com --recv-keys 98832223
dpkg-sig --verify /tmp/armory.deb | grep -q 'GOODSIG.*821F122936BDD565366AC36A4AB16AEA98832223' || { echo "Signature verification failed"; exit 1; }
sudo gdebi /tmp/armory.deb
rm /tmp/armory.deb
Here's a version for unattended installation (the one I use for Travis CI, more or less): #!/bin/bash
set -e
DOWNLOADS="`curl -fsS --retry 10 https://s3.amazonaws.com/bitcoinarmory-media/announce.txt | awk '/^downloads/{print $2}'`"
echo "$DOWNLOADS" | grep -q '^https://' || { echo "Can't find Armory downloads URL"; exit 1; }
uname -m | grep -q '64$' && BITS=64 || BITS=32
LATEST="`curl -fsS --retry 10 \"$DOWNLOADS\" | grep "^Armory [0-9.]* Ubuntu [0-9.,]*\`lsb_release -rs\`[0-9.,]* $BITS " | sort -k 2V | tail -1 | awk '{print $6}'`"
echo "$LATEST" | grep -q '^https://' || { echo "Can't find latest Armory download URL"; exit 1; }
curl -fsS --retry 10 -o '/tmp/armory.deb' "$LATEST"
sudo apt-get -q update
sudo apt-get -yq install dpkg-sig gdebi-core
gpg -q --keyserver keyserver.ubuntu.com --recv-keys 98832223
dpkg-sig --verify /tmp/armory.deb | grep -q 'GOODSIG.*821F122936BDD565366AC36A4AB16AEA98832223' || { echo "Signature verification failed"; exit 1; }
sudo gdebi -nq /tmp/armory.deb
rm /tmp/armory.deb
It's not as thorough as the built-in secure downloader because it only checks the signatures of the very last download (the install .deb file itself), but it was good enough for my purposes. |
|
|
|
Thanks for the help. The VPS is running Ubuntu 12.04.4 LTS. According to free -m there is no swap space, which might be causing the problem.
Oh well. No full node for me.
Silly question perhaps, but have you tried adding swap space? cat /proc/swaps
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudoedit /etc/fstab
# Add the following one line to the end of fstab, then save & exit:
/swapfile none swap sw
sudo swapon -a
cat /proc/swaps
Just be aware that this might cost you $ with some VPS providers, e.g. Amazon EC2 (although it's free with others, e.g. Digital Ocean). |
|
|
|
Ok so my friend recently wanted me to help him with his lost password he said he knows most of it but there are a few characters which he has either mistyped or forgotten. But because we live far away from each other I suggested that he doesn't upload his wallet.dat on the internet and use the pywallet and dump the keys etc (so he doesn't have to worry about losing any of it)
However, I Haven't got much knowledge of what to do when I receive that information. Can someone let me know what to do with the information he gave me from the pywallet dump?
Thanks in advance.
Most importantly, please be aware that the information which pywallet dumps is just as sensitive as the wallet.dat file itself, so they both should be treated carefully! If you have a decent idea of what the password contains, you have at least some chance of recovering the wallet file. There is an open source tool, btcrecover, over here that may help (full disclosure: I'm the author). The tutorial is here. Also, this thread has a wealth of information on the subject. If you're worried about transferring wallet information over the Internet, that tool has a potential solution for that issue as well. If you have any questions or need assistance with it, please let me know. |
|
|
|
Just one quick question in case your not on when i get home does the file path have to be in quotes "C:\myfilenamehere" or are the quotes not needed?
Include the quotes. Ok, a few questions here crhis,
1: what format (.txt, .bat, .dat etc.) does the address file have to be in. I cannot seem to get it to work. it ran as a .txt but then i did not see any addresses in any fields in the wallet so i assume they did not import.
The import file is a normal ASCII .txt file, the kind you'd create with Notepad. 2: if they did import where do i go to look as i cannot find anything as of now.
You could check the debug log: Help menu -> Debug window, then click the Open button, or look for debug.log in the %AppData%\Bitcoin folder. It should have "Importing" lines if the imports succeeded. You didn't include "change=1" or "reserve=1" did you? If you did, you've effectively hidden them all.... If you were importing into an empty wallet, I'd create a new empty wallet and try again. If you were importing into an existing wallet, do you have any backups of the wallet that you can restore and then try the import again? Whatever you do, make sure to keep lots of backups of the wallet.dat before you start mucking around  |
|
|
|
The documentation is the integrated online help. use the help rpc on any rpc.
Yup, that's how I came across it. It's a very helpful addition. It's just that the import format has to be reversed engineered from the dumpwallet file / the source code if you want to build your own file. |
|
|
|
How would a hacker gain access if you are not running a service that listens for connections?
Bitcoin 0.9.0 and earlier was vulnerable if you used the remote RPC feature but not if you didn't (edited brain fart)
I agree he should update OpenSSL library, but his computer is only vulnerable if he has services listening.
Actually version 0.9.0 has an additional vulnerability not present in 0.8.x (so OP's version isn't affected). Version 0.9.0 added support for the payment protocol (BIP70) and for payment protocol URIs (BIP72). If an attacker could convince you to to click on a BIP72 payment link, Bitcoin Core would establish an SSL connection to a remote server under the attacker's control which could then exploit Heartbleed. The general advice is that if you've ever clicked on any payment link before while having version 0.9.0 installed, you should upgrade and then recreate your wallet, and stop using your old receiving addresses. |
|
|
|
I found on another thread a reference to a RPC command "importwallet" although i can find no documentation about it anywhere so i am looking for a different approach.
How would a person import a list of private keys into Bitcoin QT through either debug window or Bitcoind? Not a single address but a long list of private keys.
Yeah it's not documented here where most of the other RPC commands are, but I thought I had already mostly answered you in the original thread over here. The only "official documentation" as far as I know is in the actual source code. Or of course you could use one of the better documented APIs as bitsta recommended. |
|
|
|
First off, I wonder if running bitcoin with the -rescan option would help? I dump private keys then imported private keys in a new wallet and it corrected my problem but is there a faster command than one address at a time? some type of convention like a comma between addresses or is that the limitation without going to pywallet or other program?
You can use the dumpwallet and importwallet RPC/debug window commands, e.g: walletpassphrase "my-passphrase" 60
dumpwallet "c:\exportedkeys.txt
walletpassphrase "my-passphrase" 60
importwallet "c:\exportedkeys.txt"
Just be aware that the keys in the export file are not encrypted, so you should probably use sdelete, shred, or similar to delete it once you're done. |
|
|
|
Sorry for semi-hijacking the thread Terra
BTCchirs, Totally noob when it comes to the advance stuff. To do what you said i would basically open Bitcoind, and in the command line just type importwallet C:\myfilenamehere then hit enter? and from there it would import the entire file? or is there some step i am missing? i am not too familiar with the backend stuff or RPC
First off, this is only for importing wallets that were exported using the "dumpwallet" command or in the same format, it won't import an actual wallet.dat file (which you probably already know, but I'm just making sure...) Are you using the full bitcoin-qt.exe program, with the graphical interface for sending/receiving? Or the command-line bitcoind.exe? If you're using the full bitcoin-qt.exe, you'd start it up, click the Help menu, choose Debug window, and then click the Console tab. At the bottom of this window, there's a text entry box, and in this box you'd type exactly this, including the quotes, and then hit enter: importwallet "C:\myfilenamehere"
If you're using bitcoind.exe (I'm guessing you're not), you'd start it up first, and then type this at a Command Prompt, including the quotes: cd \Program Files\Bitcoin\daemon
bitcoin-cli importwallet "C:\myfilenamehere"
|
|
|
|
This is exactly what I want to know. It is very helpful and thanks a lot!
But then I came up with a question (probably very silly), what if this wallet.dat file is manually being deleted, is there any backup itself ?
Bitcoin Core does not make any automated backups. You need to either backup the wallet.dat file yourself (but only when Bitcoin isn't running), or use the Backup Wallet option in the menu. Backups should be created at least once for every 100 new receiving addresses created. Some clients do perform automated backups (of course, backups to the same hard drive aren't all that useful...): - Armory maintains one backup file.
- MultiBit Classic creates new backup files after each new receiving address is created.
- Blockchain.info by default keeps a local backup in addition to encrypted wallet stored on their servers, and they have options for other types of off-site backups as well.
- Armory and Electrum, being deterministic, both have backup-to-paper options which only need be done once at wallet creation.
|
|
|
|
For that number of addresses you really need a full-node client. (Armory or Core) If you don't, then querying the lite-wallet servers will probably get you soft-banned from querying them (they'll view you as DOSing them) I would use Core and write a script that will run the following RPC call for each private key importprivkey <privatekey> "" False (The private keys should be in WIF format and without the <> or any "" around them...) The [ "" False ] part is a must. only remove that false (or change it to True) on the LAST private key you import... If you don't, it will rescan the blockchain after every import and take a REAAAAALLLY long time, if it doesn't crash. Maybe Armory has a better solution, but afaik bitcoind would be the best way to go. I'd tend to agree with using Bitcoin Core, even though it looks like that's what you were using when the problem occurred. Bitcoin Core uses Berkeley DB as its wallet.dat format. Berkeley DB is a bit bloated, but it's mature, very scalable, and has some reasonably decent recovery tools. I'm not aware of any other client that would be equally scalable (not that I'm an expert on alternative clients though...). As much as I like Armory, I don't think it would scale as well (although it's wallet format is nice and simple and more error-resistant than any other wallet format I'm aware of). For importing, as an alternative you could use the RPC command: The wallet import format is a bunch of lines like so: Kx2GEDGhepMhkUnymSFtrU2Q59KMPY75oYjBVofYV9032p5L4a2b 2014-06-19T00:58:01Z change=1 reserve=1 label=label%20with%20spaces
The first two fields are required. If you don't have the address creation time, you can replace that field with something meaningless (e.g. "DATE-UNKNOWN") but something needs to be there. The last three fields are each optional. Only a single rescan is done at the end of the file import, and if you do have all of the creation times, the rescan will intelligently start at the right time instead of starting at the genesis block. |
|
|
|
Did you ever get this fixed? I think this error is related to the .lock file in the data directory. To open the data directory, go to Start -> Run, then type in: If there is a .lock file in this folder, delete it. If this doesn't help, as others have already mentioned there might be a permissions problem with the directory. Go up one level, then right click on the Bitcoin directory, then click properties. Click on the Security tab, then click Advanced. You should have three lines listed that look something like this (a different order is OK): | Type | Name | Permission | Inherited From | | Allow | SYSTEM | Full control | Anything but <not inherited> | | Allow | Administrator | Full control | Anything but <not inherited> | | Allow | Your_Username | Full control | Anything but <not inherited> |
Also, if you click on the Owner tab, next to Current Owner you should have Your_Username listed. If any of this is different, it might be the source of the problem. |
|
|
|
and as for the OpenSSL bug. YES you are theoretically vulnerable as long as you use the old OpenSSL version.
Actually the good news is that 0.8.x is only vulnerable to the Heartbleed bug if you're using RPCSSL. If you've ever used the -rpcssl plus the -rpcallowip option when starting Bitcoin, then you should probably consider your wallet compromised to be safe. This means you should create a new wallet.dat file, send all your btc to it (via the network), and stop using all of your old addresses. If you've never used those options, then you're safe from this particular bug. Having said all that, it's still a good idea to upgrade anyways (and of course keeping up to date with all of your operating system updates is even more important). |
|
|
|
We have backed up the wallet
Why should we encrypt the wallet?
Thanks !
Back up the wallet to avoid being locked out. Encrypt it to avoid having your coins stolen. Malware (viruses) has become very clever (it's big business these days). If malware does manage to find its way onto your computer, it can easily steal your wallet if you don't encrypt it. Even if you do encrypt it, more sophisticated malware can still steal your wallet (read up on "keyloggers" for more details). If this concerns you, and it should if you have a lot of Bitcoin stored in your wallet that you can't afford to lose, read up on how to use cold storage. |
|
|
|
You could give btcrecover a try (it's a Bitcoin password recovery tool which supports Electrum). I've never tried it on OSX before but I believe it should work (if you can find the wallet file that is...). Let me know if you have any trouble setting it up. Edited to add: I believe the default wallet filename for Electrum is called default_wallet on all operating systems, although I don't know where it's located on OSX... (full disclosure: I'm the developer of btcrecover) |
|
|
|
It's complicated The wallet.dat file itself is a set of key/value pairs in Berkeley DB BTREE v9 format. Most of it is not encrypted, except for certain values including the private keys themselves and the master key. More specifically: A 32-byte random master key or "mkey" is generated using OpenSSL's RAND_bytes(). This PRNG is seeded by /dev/urandom on Linux or by CryptGenRandom() on Windows. Additionally on Windows, Bitcoin adds additional entropy from a screen shot and from Windows perfmon counters (possibly because OpenSSL didn't use CryptGenRandom() in early versions?). The mkey is used as an encryption key to encrypt each individual Bitcoin private key using AES-256 in CBC mode with PKCS7 padding and an initialization vector of SHA-256(SHA-256(the respective public key)). Your password, plus an 8-byte salt which is initially generated using RAND_bytes() and stored in wallet.dat, is fed into PBKDF1-SHA-512 (normal PBKDF1 doesn't use SHA-512) with a certain number of iterations (stored in wallet.dat) to generate 512 bits of derived key data. The iteration count is initially set such that it will take about 1/10th of a second to run the iterations on whichever CPU the password is added (or modified). This derived data is divided into three parts. The first 256 bits are used as an encryption key, the next 128 bits are used as in initialization vector, and the remaining bits are discarded. This encryption key and initialization vector are then used to encrypt the mkey (again using using AES-256 in CBC mode with PKCS7 padding), and the encrypted mkey is stored in wallet.dat. Upon a password change, only the encrypted mkey needs to be recomputed and written back to wallet.dat, while it's unencrypted value and all of the Bitcoin private keys which it encrypts remain unchanged. |
|
|
|
|
Show Posts
