Download - Bitcoin

any good backup strategy for wallets?

Hello!
Man, I'm not going to live for ever. I'm just 25 years old young man, but I had outgrow that sense of immortality people have when they are adolescents (and the sooner, the better).
I have uploaded files like pictures and videos and stuff to the Internet so the rest of my family have access to that stuff that was used to be stored on my laptop's hard driver. The only thing left is backing up my Vertcoin wallet.
I really want my parents and my brothers to inherit my vertcoins in case I die, they don't have much value right now, but the coin have such technical potential that I cannot help but see its value skyrocketing in the future. In any case, what I have will help them monetarily. This means that they have to be able to access the wallet without needing to decipher it or inserting any password, but in such state, it would be a serious mistake to store in digital form.
I thought on printing the private keys where the verts are store, but after reading this (it applies to Vertcoin-qt as well, right?), well, I have my doubts that no coin will be lost.
I was thinking on a hardware wallet, man, they seems to be good, but I don't know if they are compatible with Vertcoin and besides, I would like to have something backed up for today, like, soon as possible, because death can happen to anyone in any moment and thinking you don't need to think about it until you are old is pure BS.
Any suggestions? I appreciate any insight and advice about making my backup possible.

EDIT:

Since I'm not moving my vertcoins from my wallet often (like, never), I decided to go for a paperwallet route.
submitted by shackra to vertcoin [link] [comments]

Question, I backed up my wallet about 6 months ago, since then I've done about 10 transactions and transferred the coins from one address to another within the same wallet. Will I still have my balance when I restore the wallet?

SEE UPDATE AT BOTTOM
Thank you, I think I may have messed up.
I believe I created the address and transferred my balance to that address. Then I lost my wallet. Did the address that has my balance in my wallet, even though I created it after backing it up?
After reading this, i'm not sure how this works:
The wallet contains a pool of queued keys. By default there are 100 keys in the key pool. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins. Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.
UPDATE
Just got it all thank you... needed to download all the block chains to get my balance and it took a long time.
I was actually fairly confident I would get my coins back before the balance came through as I could trace which account was holding the coins using blockchain.info and doing the following:
I had the address of my first address in Bitcoin-QT, it was in my address book when I loaded the backed up wallet. I located the address on blockchain.info then followed transactions until I found an account that had a balance I recognized. Then I was able to use the debug function part of bitcoin-qt to see that I owned the public and private key in my backed up wallet. I used the following method:
-validateaddress 1BZZnJG6q95aJqPZweSCGnno2rxcXyfaLo
submitted by onowahoo to Bitcoin [link] [comments]

weird behavior of electrum+bitcoin-qt

past week installed the new plugin that allow me to connect my electrum wallet to bitcoin-core, i use a hardware wallet and worked like a charm.
Then today was updating the node and used bitcoin-qt instead of bitcoind and when was waiting suddendly i see some text in the gui where it says "recent transactions", and a lot of transactions where there.
Then was like WTF happened here, someone stole my btc?, or installed a compromised version of electrum(i use archlinux and install from the repos). Why some transactions where there, i neved imported my wallet to bitcoin-gui.
Inmediately deleted the wallet.dat and did the same in electrum, but my question is:
Was something imported into bitcoin-qt?, all my history was redeable from the gui, i never imported into bitcoin-qt, and as far i know the seed never leave the hardware wallet.
This is normal?, at least all my funds are still there but im really worried.
PS: everything happened with my hardwallet unplugged.
TL:DR: Connected my cold wallet to electrum(connected to bitcoind) past week, never to bitcoin-qt, today opened bitcoin-qt and all my history of transactions from my cold wallet(unplugged) was there(bitcoin-qt), is this normal?.
submitted by relgueta to Bitcoin [link] [comments]

weird behavior of electrum

past week installed the new plugin that allow me to connect my electrum wallet to bitcoin-core, i use a hardware wallet and worked like a charm.
Then today was updating the node and used bitcoin-qt instead of bitcoind and when was waiting suddendly i see some text in the gui where it says "recent transactions", and a lot of transactions where there.
Then was like WTF happened here, someone stole my btc?, or installed a compromised version of electrum(i use archlinux and install from the repos). Why some transactions where there, i neved imported my wallet to bitcoin-gui.
Inmediately deleted the wallet.dat and did the same in electrum, but my question is:
Was something imported into bitcoin-qt?, all my history was redeable from the gui, i never imported into bitcoin-qt, and as far i know the seed never leave the hardware wallet.
This is normal?, at least all my funds are still there but im really worried.
PS: everything happened with my hardwallet unplugged.
TL:DR: Connected my cold wallet to electrum(connected to bitcoind) past week, never to bitcoin-qt, today opened bitcoin-qt and all my history of transactions from my cold wallet was there(bitcoin-qt), is this normal?.
submitted by relgueta to Electrum [link] [comments]

Connecting bitcoin-qt to bitcoind on local network

Hello,
I have a bitcoin node running on a headless box (bitcoind) and I would like to connect to it using bitcoin-qt on my desktop. I'm getting a little confused with the process.... does bitcoin-qt need to connect to bitcoind using RPC? Do I store my wallet file on the bitcoind box, or bitcoin-qt box?
The bitcoin node is already setup to work with an electrum server, so I already have rpcbind=0.0.0.0, rpcallowip=$ELECTRUX_IP, and rpcuserpcpassword set. I tried adding my desktop IP to rpcallowip, and setting the appropriate username/password in bitcoin-qt's bitcoin.conf, but no luck. I can see in debug.log for bitcoin-qt that the connection is rejected.

The node runs over TOR and I have onlynet=onion set in bitcoind's bitcoin.conf, but that doesn't seem to stop electrumx connecting via RPC over clearnet, so this shouldn't be an issue right?

Am I missing something here? Help would be much appreciated!
submitted by backfromBTCpast to Bitcoin [link] [comments]

Run a 0.14 Full-Node on RaspberryPi3 Pruned(less than 16GB SD needed)

Hi!
Happy if this guide helps you.
Tip if you want: 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
UPDATE 04/06/17
Add 'uacomment=UASF-SegWit-BIP148' into your bitcoin.conf if you want to signal UASF.
UPDATE 03/13/17
ADDED a tl;dr; Version at the end of this Post.
UPDATE 03/12/17:
Just to test it - I reinstalled all on 8GB SD and it works as well. But maybe you should use at least 16GB for the beginning.
Using a 128GB card for the first version was a little bit stupid - so I reinstalled everything on a 8GB SD card. Including Linux and a pruned blockchain - and it works.
I used prune=550 and Jessie Lite (headless / command line) - without wallet and gui.
The SD is almost full, but it works so far
I also updated the whole manual a bit to make things more clear. Thank you for all your feedback!
Just started my Bitcoin Node today and wanted to share the way I did it with people who are interested in running their own full node. It took some time to write everything down - hopefully correct so far.
I am sure, many people around bitcoin are way more informed and educated as I am - I am the noob. So I wrote this manual to help users like me - noobs, to get started with a cheap, simple bitcoin node on raspberry pi.
Have fun!
I wanted to get my Raspberry Pi 3 working as a node to support the network. Actually the process of installing and running the node was more or less easy - but for Noobs (like I am) it might be a bit tricky to start the whole thing, because there are different ways.
Did you - like me - think you would need +120GB on the raspi, external USB HDD to be a full node? You won't!
If you have a Raspberry and you know what Bitcoin is, I guess, you are a little bit aware of linux, networks and of course bitcoin - so I won't go into detail too much.
This guide is just a little helper to get a full node running on your raspberry pi. Thanks to the help of the nice people in this sub and of course the documentation by the developers, I got it working - and of course also special thanks to raspnode.com - as I followed their tutorial to start - I went some other ways here and there - so please read carefully.
For the Part 2 I would suggest to have http://raspnode.com/diyBitcoin.html open and read through my manual.
I split the tutorial in 2 Parts - PART ONE is about installing the client on your PC and downloading the Blockchain.
PART TWO is about the setup of the raspberryPi and transferring the pruned blockchain to the pi and run it as a full node!
The first thing to be aware of is: You actually need to download the whole blockchain to get this working - if you already have your bitcoin client synced on the PC / MAC great you can reuse it!
Now you might think "but you said less than 16GB in the title!"
Yes, but the good thing is you won't need to download it on your Raspberry, neither you need to sync it completely on your raspberry which took ages (weeks!) before. When you finished this Guide, you will just have a max. 4GB Blockchain on your Raspberry Pi - but it still is a full node! The magic word is Pruning.
Maybe even a 8GB SD Card works just fine including Linux (jessie lite)!
So, if you already have a full node on your PC - Great you can almost skip PART ONE - BUT have at how to Prune in PART ONE if you don't know about it.
For PART TWO you'll need a Raspberry Pi 2 or 3 (I used 3) min. 8GB (works also) or better 16GB SD Card. (I used a 128GB for the first version of this manual - which is way too big)

PART ONE

This is the manual how to get started on you PC / MAC / Linux (I did it on Win7)
Go to: https://bitcoin.org/en/download and download the core Client for your Machine (I used win64).
Install it and configure it to save the Blockchaindata to the directory of your choice - so instead getting 120GB on your C drive, I would suggest to download it to another place like a USB drive.
You can set this up during the install. Standard folder for the blockchain folder is "%APPDATA%\Bitcoin" on Windows.
or you can do it after the install by creating a bitcoin.conf file inside your installation folder / or %APPDATA%\Bitcoin and add
datadir=l:\yourfolder
to the file. Line by line.
By the way here you could also just add dbcache - to use more memory to speed up the process a bit:
dbcache=4096
if you don't want to use the settings inside the program. (you can also set this inside the program under settings! If you have this inside the bitcoin.conf you will see the amount you set there from inside the program - it overrides the values)
You can check inside the windows client under settings, if you can see a manual dbcache is set by having a look at the left footer area. When your dbcache value shows up, everything is fine.
So the Blockchain download process will take time - maybe a few days! Depending on your machine, internet connection and HDD.
The Blockchain is huge as it contains every single transaction of the past until today. You won't need to keep your PC running all the time, you can turn it off and on and it will resync automatically when you start bitcoin-qt.exe!
Make sure to close the client always via "quit" - ctrl+q.
After you have your bitcoin core installed, the blockchain downloaded and synced - you are ready to PRUNE!
First - close the Client and let it close smoothly. After it is really closed you can follow these steps:
By pruning, your blockchain will dramatically shrink. From 120GB to just a few GB.
Be aware, that you will lose your Downloaded Blockchain as pruning will erase a big chunk of it! If you have enough space, you could of course keep the full blockchain saved somewhere on another HDD.
You can prune by editing your bitcoin.conf file by adding:
prune=550
I used prune=1024 - not sure where the differences are right now (min. prune=550). (for my 8GB version I used 550! I suggest to use this.)
Save the bitcoind.conf file and restart your windows client.
It will now clean up the Blockchain. So just the latest blocks are saved. The client should start without any problems. Maybe it takes some time to prune the blockchain data.
Check if everything works normally (the client opens as usual, you can see an empty wallet) than close the client.
Inside the Bitcoin Folder, you'll find two folders called:
blocks chainstate
those are the interesting folders containing the important data (now pruned) - and we will transfer those two to the raspberry later!
Now you are good to start the raspi transfer explained in the next part.

PART 2

Here is what I did:
1) I installed Raspian Pixel (https://www.raspberrypi.org/downloads/raspbian/) using a 128 GB SD - which is not needed because of "Pruning" - I think a 16GB card might work, too! (You can also install Raspian Jessie Lite - which saves you even more space, as it runs headless - only command line) (Updated: It is better to use Jessie Lite to save a lot of space - when you are fine with only command line)
2) I followed partly this tutorial to get everything running and setup:
http://raspnode.com/diyBitcoin.html
Please have a look at it - I have copied the Headlines in capitals to let you know what I did, and what I skipped.
On Tutorial Page: Start with RASPBIAN (OPTIONAL) CONFIG OPTIONS.
Set You RasPi up including "EDITING FILES" to save your Layout at the tutorial page and come back here.
I skipped the CONFIGURE USB AND SET AUTOMOUNT process, as we are going to use PRUNING to reduce the 120GB to a tiny filesize - so USB Devices are not needed here!
It was necessary to ENLARGE SWAP FILE to install bitcoin core - otherwise it didn't went through which ended in a frozen raspi.
So have a close look by following the raspnode tutorial at: ENLARGE SWAP FILE.
I have my raspi running via cable to router - but you can also WiFi setup everything described under NETWORKING ON THE RASPBERRY PI.
Now comes the interesting part: Follow the steps at DOWNLOADING BITCOIN CORE DEPENDENCIES - they work fine for 0.14.0 too. Git should be on Board already when you installed Pixel - otherwise you would need to install it.
sudo apt-get install git -y (only jessy lite)
I skipped the next command lines - as I don't use bitcoin-qt wallet. If you want to use it as wallet - do the step.
mkdir ~/bin cd ~bin
Now you are in the folder you want your bitcoin core data be downloaded to via git. I didn't Downloaded the Berkeley Database source code - so I also skipped the whole next command lines
[email protected]~/bin$ wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz [email protected]~/bin$ tar -xzvf db-4.8.30.NC.tar.gz [email protected]~/bin$ cd db-4.8.30.NC/build_unix/ [email protected]~/bin/db-4.8.30.NC/build_unix$ ../dist/configure --enable-cxx [email protected]~/bin/db-4.8.30.NC/build_unix$ make -j4
and went on with "INSTALLING BITCOIN"!
I followed the first part but instead downloading 0.13 I took of course the latest version:0.14
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git cd bitcoin ./autogen.sh
this might take some time to start.
If you have trouble with hanging RESOLVING DELTAS - just restart the Raspberry Pi and remove the bitcoin folder inside /~bin using
rm -rf bitcoin
this command will delete the folder and you can reuse
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git

For some reason RESOLVING DELTAS is a common problem with different downloads - so just retry it and at least after 3 times it should work!

as I didn't use the GUI/ Wallet, I ran
./configure --enable-upnp-default --disable-wallet
as I don't need the wallet functionality.
I didn't need to use "MAKE" which saves you maybe up to 2.5 hours.
instead you can just go ahead with:
sudo make install
(If I am wrong in doing so - please let me know)
The install takes some time - and just a heads up: when it gets stuck somewhere - just redo the installation process - it took three times to went through - stuck at some processing.
After the installation took place you can finally get your Raspberry Pi Node running in no time!
To test if the the installation went through - you can just start bitcoind using:
bitcoind &
than check if everything is working so far:
bitcoin-cli getinfo
after a few seconds you should see version: etc...
if not, something went wrong. Try to redo the steps in the raspnode tutorial.
(don't give up if it failed - retry! Ask your questions here)
IMPORTANT: you need to stop bitcoin on your raspberry now!
bitcoin-cli stop
If you don't need an external USB Drive - what I hope - as we are going to use pruning just go ahead and skip the USB part and create a file inside (or follow the raspnode tutorial on how to setup the USB drive):
cd .bitcoin
sudo nano bitcoin.conf
and enter the exact same pruning size you have used on your Desktop Machine to prune. I used 1024 but the minimum is 550. (used 550 for the 8GB SD card on PC and Raspberry)
prune=550
That's it for the raspi.
update: To signal UASF enter in a new line:
uacomment=UASF-SegWit-BIP148

TRANSFER

Now you have to transfer the two folders CHAINSTATE and BLOCKS from your PC bitcoind directory to your raspberry.
I am using a program called "WINSCP" - it is free and easy to use: https://winscp.net/eng/download.php
We need this to transfer the files to the Raspberry pi. Pretty sure you can also do it via SSH - but I am the noob. So let's keep it simple.
Open Winscp and put in the IP Address of your Raspberry Pi, User and Password (same as in SSH)
You should now see the directories on your Raspberry Pi. There is a folder called
.bitcoin
enter it and you will see the two folders
blocks & chainstate
you can delete them on the raspberry as they have some data from your previous test inside.
Make sure you can also see the bitcoin.conf file in that directory, which needs to contain the exact same prune line, like the one on your desktop machine. If not, make sure to edit it via SSH. The line "datadir=l:\yourfolder" is obviously not needed in the Raspberry bitcoin.conf file.
Now grab the two folders CHAINSTATE and BLOCKS from your PC and copy them to your .bitcoind folder.
I also copied banlist.dat, fee_estimation.dat, mempool.dat and peers.dat to the folder - not really knowing if needed! Not needed.
The whole copy process might take some minutes (against some weeks in the old way).
After copying is finished, you can now start bitcoind on the Raspberry.
bitcoind &
the & symbol let you still use the command line while the process is running btw.
The process - if succesfull - will take some time to finish.
bitcoin-cli getinfo
Will give you some informations what is going on right now. When you can see, that it is checking the blocks, this is good!
If you get an error - double check - if you have the correct prune size (same as on desktop machine) - in bitcoin.conf and that this file is inside .bitcoin on RaspberryPi. It took me some time, to find my mistakes.
Congrats! You are almost a part of the network!
To make your node now a fullnode, you will need to go to your router (often 192.168.1.1) and enable portforwarding for your raspberry pi - and open ports 8333 - that's it!
You can now go to: https://bitnodes.21.co/nodes/
scroll down to "JOIN THE NETWORK" and check check if your node IP is connected!
It will show up as soon as the blocks are checked and the raspi is running.
Well done!
Now you are running a full node, with a small Blockchain and got it working in Minutes, not weeks!
I really hope, my little tutorial worked for you and your are part of the Node network now.
If you have problems or I made a mistake in this helper tut, just let me know and I will try to make it better.
Have fun and NODL!
the noob
tl;dr; (if you are a real noob start with the non-tl;dr version!)
tl;dr; PART ONE
1) Download & install / setup bitcoincore @ https://bitcoin.org/de/download
2) change dbcache to something smaller than your memory and download the whole Blockchain (120GB).
3) create a file called bitcoin.conf put the line prune=550 (or higher) in to activate pruning on win inside %appData%/bitcoin
4) Open ports 8333 on your Router to make this a full node with a smaller Blockchain.
You are running a full node on your PC.
tl;dr; PART TWO
1) Install jessie lite and the needed dependencies on your SDCard - Raspberry
( >git clone -b 0.14 https://github.com/bitcoin/bitcoin.git )
  • see tutorial for more info.
2) create a file called bitcoin.conf inside .bitcoin and add the same prune=Number you had on your PC.
3) transfer the pruned folders BLOCKS and CHAINSTATE to the Raspberry Folder .bitcoin
4)Start "bitcoind &"
5) let everything sync
6) Make sure you have port 8333 opened on your router.
You are running a full node on your Raspberry with a super small Blockchain (I put all on a 8GB SDcard)
Tip if you want : 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
updated 03/12 - will update more, soon.
updated 03/12.2 - I updated the whole process a bit and also added some improvements.
updated 03/14/ Added a tl;dr version at the end.
submitted by I-am-the-noob to Bitcoin [link] [comments]

A Guide to Keeping Keys Offline Using Armory +rPi

Hi Redditors.
I am going to post in this thread my experiences in getting my Desktop (Debian) machine running Armory in watch-only mode, and coupling that with an offline Raspberry Pi (which holds my private keys) for signing the transactions previously made in watch-only mode.
I actually compiled Armory from source directly on my Pi. This guide is probably more for the bitcoin 'power user', as to run Armory online, and broadcast the signed transactions, you need to have a bitcoin full node running (bitcoind).
Basic requirements:
Aimed-for Setup:
I'll post the guide in digestible sections...

Section 1

I should begin by saying I installed source code from git, and got Armory to build the DB on my desktop initially, WITHOUT creating a wallet.. (This allowed me to debug what was going on a little!)
Go to Bitcoin.org, select Armory..
It leads to a Download from Git:
https://github.com/goatpig/BitcoinArmory/releases
Followed the procedure for Linux Debian verify code, compile, install, all straight-forward..
Began by running bitcoind, and telling Armory where to find it. This is the command I used, obviously it was all on one line and didn't include the arrows/explanations!:
python ArmoryQt.py \ --satoshi-datadir=/BlockChain/chain20180414/blocks \ # <-----(where my bitcoind blocks live) --datadir=/ArmoryDataDi \ # <-----(this is instead of ~/.armory) --dbdir=/ArmoryDataDidatabases # <-------(again, non std. place used for Armory's databases.. my choice.) 
So, on the Desktop, after the initial "build databases"
(NB the initial "Build Databases" took about 1.5h and my two CPUs were maxed the whole time, Temps up to 62C. Not ideal; Im not in a rush!)
I then wanted to import a watch-only wallet.
Before I did this, I took a full backup of the Armory data dir:
/ArmoryDataDi
(or ~/.armory in a default installation).
I'd hate to have to make Armory do another full sync with the bitcoind node!

Section 2

Next step: offline wallet (with Private Keys) is on a Raspberry Pi.
I downloaded the source and managed to compile it on the pi itself! :)
Though there were some gymnastics needed to setup the Pi.
My Pi is running Raspbian based on Wheezy.. quite old!
I did the following on the Pi:
apt-get update apt-get upgrade (<---took about an hour!) apt-get install autotools-dev apt-get install autoconf 
Then I followed the instructions exactly as I had done for my Debian Desktop machine, EXCEPT:
I had to increase the Pi's swap space. I upped it from 100Mb to 400Mb.
The compilation took 7 hours, and my poor SD card got a thrashing.
But after compilation, I put the Swap back to 100Mb and Armory runs ok with about 150Mb of memory (no swap needed).
Swap increase on the Pi:
use your favourite editor, and open the file /etc/dphys-swapfile
add/change the following line:
CONF_SWAPSIZE=400 
Then, REBOOT the Pi:
sudo shutdown -h -P now 
Once the compilation was done on the Pi, put the swap back, rebooted and created an Armory wallet.
I added manual entropy and upped the encryption 'time' from 250ms to 2500ms - since the Pi is slow, but I'll be happy to wait for more iterations in the Key Derivation Function.
Once the wallet was created, it obviously prompts you for backup.
I want to add a private key of my own (i.e. import), so don't do the backup until this is over.
I import my Private Key, and Armory checks that this corresponds to a Public Key, which I check is correct.
This is the point now where the Pi storage medium (e.g an SD card) has to be properly destroyed if you ever get rid of it.
I had thought that now would be a good time to decide if your new wallet will generate Segwit receiving addresses, and also addresses used to receive 'change' after a transaction..
But it seems Armory WON'T let you switch to P2SH-P2WPKH unless your Armory is connected to a node offering "WITNESS" service.
Obviously, my Pi is offline and will never connect to a node, so the following will not work on the Pi:
NB: I thought about setting this on the Debian "watch-only" wallet, but that would surely mean doom, as the Pi would not know about those addresses and backups might not keep them.. who knows...
So, end result:- no segwit for me just yet in my offline funds.

--If anyone can offer a solution to this, I'd be very grateful--

Section 3

Ok, now this is a good point to back up your wallet on the Pi. It has your imported keys. I choose a Digital Backup - and put it on a USB key, which will never touch the internet and will be stored off-site. I also chose to encrypt it, because I'm good with passwords..
NB: The Armory paper backup will NOT back up your imported private keys, so keep those somewhere if you're not sweeping them. It would be prudent to have an Armory paper backup anyway, but remember it will likely NOT help you with that imported key.
Now for the watch-only copy of the wallet. I want to get the "watch-only" version onto my Desktop Debian machine.
On the Pi, I created (exported to a USB key) a "watching-only" copy of my wallet.
I would use the RECOMMENDED approach, export the "Entire Wallet File".
As you will see below, I initially exported only the ROOT data, which will NOT capture the watching-only part of the Private Key I entered manually above (i.e. the public Key!).
Now, back on the Debian Desktop machine...
I stopped all my crontab jobs; just give Armory uninterrupted CPU/memory/disk...
I also stopped bitcoind and made a backup prior to any watch-only wallet being imported.
I already made a backup of Armory on my Desktop, before any wallet import.
(this was needed, as I made a mistake.. see below)
So on the Debian Desktop machine, I begin by firing up bitcoind.
my command for this is:
./bitcoind -daemon -datadir=/BlockChain/chain20180414 -dbcache=400 -maxmempool=400 

Section 4

I try running Armory like this:
(I'm actually starting Armory from a script - StartArm.sh)
Inside the script StartArm.sh, it has the line:
python ArmoryQt.py --ram-usage=4 --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
I know from bitter experience that doing a scan over the blockchain for a new wallet takes a looong time and a lot of CPU, and I'd like it to play nicely; not gobble all the memory and swap and run my 2xCPUs both at 100% for four hours...
So... I aim to run with --ram-usage=X and --thread-count=X
(For me in the end, X=1 but I began with X=4)
I began with --ram-usage=4 (<--- = 4x128Mb)
The result is below...
TypeError: cannot concatenate 'str' and 'int' objects 
It didn't recognise the ram-usage and carried on, crippling my Debian desktop PC.
This is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up, and it can take over 30 minutes just to exit nicely from bitcoind and ArmoryDB.
So, I ssh to the machine from another computer, and keep an eye on it with the command
"free -h" 
I'd also be able to do a "sudo reboot now" if needed from here.

Section 5

So, trying to get my --ram-usage command recognised, I tried this line (added quotes):
python ArmoryQt.py --ram-usage="4" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
But no, same error...
Loading Armory Engine: Armory Version: 0.96.4 Armory Build: None PyBtcWallet Version: 1.35 Detected Operating system: Linux OS Variant : ('debian', '9.4', '') User home-directory : /home/ Satoshi BTC directory : /BlockChain/chain20180414 Armory home dir : /ArmoryDataDi ArmoryDB directory : /ArmoryDataDidatabases Armory settings file : /ArmoryDataDiArmorySettings.txt Armory log file : /ArmoryDataDiarmorylog.txt Do wallet checking : True (ERROR) ArmoryUtils.py:3723 - Unsupported language specified. Defaulting to English (en) (ERROR) ArmoryQt.py:1833 - Failed to start Armory database: cannot concatenate 'str' and 'int' objects Traceback (most recent call last): File "ArmoryQt.py", line 1808, in startArmoryDBIfNecessary TheSDM.spawnDB(str(ARMORY_HOME_DIR), TheBDM.armoryDBDir) File "/BitcoinArmory/SDM.py", line 387, in spawnDB pargs.append('--ram-usage=' + ARMORY_RAM_USAGE) TypeError: cannot concatenate 'str' and 'int' objects 

Section 6

So, I edit the Armory python file SDM.py:
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=4') #COMMENTED THIS, SO I CAN HARDCODE =4 # ' + ARMORY_RAM_USAGE) 
Running it, I now have acknowledgement of the --ram-usage=4:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=4 
Also, even with ram-usage=4, it used too much memory, so I told it to quit.
It took over 30 minutes to stop semi-nicely. The last thing it reported was:
ERROR - 00:25:21: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unexpected fcgi header version 
But that didn't seem to matter or corrupt the Armory Database, so I think it's ok.
So, I get brave and change SDM.py as below, and I make sure my script has a command line for --ram-usage="ABCDE" and --thread-count="FGHIJ"; the logic being that these strings "ABCDE" will pass the IF criteria below, and my hardcoded values will be used...
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=1') #COMMENTED THIS, SO I CAN HARDCODE =1 # ' + ARMORY_RAM_USAGE) if ARMORY_THREAD_COUNT != -1 pargs.append('--thread-count=1') #COMMENTED THIS, SO I CAN HARDCODE =1 #' + ARMORY_THREAD_COUNT) 
So, as usual, I use my script and start this with: ./StartArm.sh
(which uses command line:)
python ArmoryQt.py --ram-usage="ABCDE" --thread-count="FGHIJ" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
(this forces it to use my hard-coded values in SDM.py...)
So, this is the command which it reports that it starts with:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=1 --thread-count=1 
Again, this is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up. So I ssh to the machine and keep an eye on it with:
"free -h" 

Section 7

So, on the Debian Desktop PC, I inserted the USB stick with the watch-only wallet I exported from the Pi.
Start Armory...
Import "Entire Wallet File" watch-only copy.
Wait 4 hours..
YAY!!!
After running Armory for about 30m, the memory usage dropped by 400m... wierd...
It took ~2 hours to get 40% completion.
After 3.5 hours it's almost there...
The memory went up to about 1.7Gb in use and 900Mb of Swap, but the machine remained fairly responsive throughout, apart from a few (10?) periods at the start, where it appeared to freeze for 10-30s at a time.
(That's where my ssh session came in handy - I could check the machine was still ok with a "free -h" command)
Now, I can:
Create an unsigned transaction on my Desktop,
Save the tx to USB stick,
Move to the Pi,
Sign the tx,
Move back to the Desktop,
Broadcast the signed tx.

Section 8

My initial Mistake:
This caused me to have to roll-back my Armory database, using the backup. so you should try to avoid doing this..
On the Pi, I exported only the ROOT data, which will NOT capture the watching-only part of the Private Key
It is RECOMMENDED to use the Digital Export of Entire Wallet File from the Pi when making a watch-only copy. If you just export just the "ROOT data", not the "Entire Wallet File", you'll have problems if you used an imported Private Key in the offline wallet, like I did.
Using the ROOT data text import, after it finished... my balance was zero. So,. I tried a Help->Rescan Balance (Restart Armory, takes 1minute to get back up and running) No Luck. Still zero balance.
So, I try Rescan Databases.. This will take longer. Nah.. no luck.
So, I tried again, thinking it might be to do with the fact that I imported the text "root data" stuff, instead of following the (Recommended) export of watching-wallet file.
So, I used my Armory backup, and wound back the ArmoryDataDi to the point before the install of the (zero balance) wallet. (you should not need to do this, as you will hopefully use the RECOMMENDED approach of exporting the "Entire Wallet File"!)
submitted by fartinator to Bitcoin [link] [comments]

BTCPay Server + EPS + RTL - how?

I am trying to build a box with: - Linux Ubuntu 18.04 - BTCPay Server, using docker - EPS (Electrum Personal Server) - RTL (Ride the lightning)
I have the full bitcoin data synced in a folder already, from a previous bitcoin-qt/bitcoind instance.
  1. Can I install BTCPay Server with docker and then run beside another docker with EPS?
  2. I understand that RTL is already integrated into BTCPay, so I just have to update the server and activate it?
  3. Is possible to integrate also EPS into the BTCPay docker file, after the installation? Or is it in "works" to be integrated in the same docker installation/update server by BTCPay ?
  4. Is possible to run EPS without docker, but using the bitcoind from BTCPay docker instance?
  5. Is possible to connect a mobile wallet (ex. Samourai) to that bitcoind instance from BTCPay Server ?
  6. One last question: is there a procedure to backup all the BTCPay server settings, for in case of disaster recovery moment? So to restore all data at once after reinstall OS ?
This is very important thing, if I start to put a BTCPay server at work in production and the machine gets fucked, how easy is to restore it?
Please somebody can respond to these questions, not in a super technical manner so many others can understand it?
Maybe u/belcher_ and u/CardCollector1 or u/NicolasDorier can help with some answers here, please?
EDIT: I hope I don't have to add a meme to this post to bring more attention... seems that lately only memes are "important" here, subjects like this are ignored. EDIT2: 21 hours and still not any answer... fuck, nobody uses BTCPay ?
submitted by Mr--Robot to Bitcoin [link] [comments]

Bitcoin Core 0.10.1 Released

Bitcoin Core version 0.10.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.10.1/
This is a new minor version release, bringing bug fixes and translation updates. If you are using 0.10.0, it is recommended to upgrade to this version.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.

Notable changes

This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md

0.10.1 Change log

Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates.
RPC:
Block (database) and transaction handling:
P2P protocol and network code:
Validation:
Build system:
Wallet:
GUI:
Tests:
Miscellaneous:

Credits

Thanks to everyone who contributed to this release:
As well as everyone that helped translating on Transifex.
submitted by harda to Bitcoin [link] [comments]

Lost most of my Doge late 2013. There may be one last solution to getting some back. Does anyone have a copy of "DogeCoin version v0.6.4.0-unk-beta" or know which release it is directly linked to?

My keys corrupted and i didn't have a recent backup, after the upgrade lost all the doges.

I think there might be one more hope of finding some, and would appreciate if anyone knows which version " v0.6.4.0-unk-beta" which is on the debug.log output.

Noticed after all this time after digging through Bitcoin release notes that before bip32/hd wallets came in or as a matter of fact As they came in too (thanks devs). Most if not everyone i asked thought backing up the wallet.dat file is good enough, or the old --salvagewallet nor -zapwalletxes. They either aggressively scrambled the wallet making it more likely destroy even more keys, sure saved a few coins but most of the addresses in the keypool which has a size of 100 didn't have a corresponding private key anywhere in the wallet AFAIKT,
Sorry before i rant, i just need some info on if this wallet if linked to a specific Dogecoin version and just happens to say v0.6.4.0 in the debug log file.

I can't update directly to any other version without the wallet breaking up. Apparently i need the exact version that was last used, and turn it off extra safely so the log files which hold some parts of the keys go back to the Wallet.dat or something.

I tried all solutions, this might just work. from the "Bitcoin version 0.7.1 Readme file."
How to Upgrade
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).
If you were running on Linux with a version that might have been compiled with a different version of Berkeley DB (for example, if you were using an Ubuntu PPA version), then run the old version again with the -detachdb argument and shut it down; if you do not, then the new version will not be able to read the database files and will exit with an error.
Explanation of -detachdb (and the new “stop true” RPC command): The Berkeley DB database library stores data in both “.dat” and “log” files, so the database is always in a consistent state, even in case of power failure or other sudden shutdown. The format of the “.dat” files is portable between different versions of Berkeley DB, but the “log” files are not– even minor version differences may have incompatible “log” files. The -detachdb option moves any pending changes from the “log” files to the “blkindex.dat” file for maximum compatibility, but makes shutdown much slower. Note that the “wallet.dat” file is always detached, and versions prior to 0.6.0 detached all databases at shutdown.
or on shut down the coin client using the -detatchdb comas coins use both log and dat files with berkeley.

Thanks,

D_M


submitted by doge_messiah to dogecoin [link] [comments]

TIL why Newbies still download the Bitcoin-QT client!

Because we told them to. Newbies don't start with reddit or bitcoinforums (unless they are redditors, of course). They start with what looks like an authoritative source. (And journalists do the same.) Let's have a look.
Bitcoin.org has a list of wallets and recommends two good options at the top, MultiBit or Schildbach, but if you take a look at the bottom, it prominently lists: Bitcoin-QT and Armory (which requires Bitcoin-QT/bitcoind). This is fine, I suppose, but it explains the popularity of Bitcoin-QT since most alternatives come with warnings.
weusecoins, a website that is prominently featured as a first stop for newbies, sends users dierectly to Bitcoin-QT, without any explanation or alternatives.
Bitcoin Wiki same same
This guarantees some bad user experience. Can we fix it? Who edits weusecoins.com and bitcoin.it?
submitted by arbeitslos to Bitcoin [link] [comments]

Gridcoin Developer Update May 7th, 2018

Hello everyone and welcome to another Developer Update from the Gridcoin team. I'd like to remind everyone that these posts will be created every two weeks unless a wallet update is pending that week.
 
The last two weeks have largely been spent preparing for the next leisure release. The release would have come sooner, but some last minute additions to the staging branch were pulled in since the previous update post. Some of these pull requests have included:
 
Testnet has been working with PR #1060 which was mentioned in the last Developer Update post. I can now happily report that two superblocks have been successfully staked on testnet by Linux clients using contract forwarding. These results are extremely promising and will be a welcome addition for improved superblock stability on mainnet.
In the coming days I expect a new staging build to be ready for testnet deployment so testing will refocus soon on the PRs mentioned in this post.
 
While not entirely wallet related, I did want to point out some behind the scenes improvements for the https://gridcoin.us website. The site now properly redirects to HTTPS and supports TLS 1.2. Our site is now rated "A+" by SSL Labs. Thanks to our founder Rob for making these changes!
 
Thanks for reading this edition of the Developer Update. Expect to see another update two weeks from today (5/21), unless there is a wallet update released between now and then. If you have any comments or questions for the Gridcoin development team feel free to ask in the comments below. If I am not able to answer your question directly, I can certainly forward it to someone who can!
submitted by barton26 to gridcoin [link] [comments]

need help. My wallet destroyed just now!

***Finally get back from An old .bak file. The .bak file today still can't open. No loss anyway
Thank you my friends.
However, I strongly urge Bitcoin foundation who maintains bitcoind improve its security greatly. It's not hard to solve if you see Bitcoin as money, as people's wealth.
Also, just now I sent the btc to my main wallet. and set the"change" to go to a coinbase address. But after being sent, I saw there is a remind "unknown address", and the 0.00xx btc now lies in the software. WTF?
Could you give users some better experience, Bitcoin Foundation? Bitcoin is no longer a toy, it's now money, you know? You need fear while dealing with things about money.
You can do much better.
Bitcoin as a science is perfect, But the related business/foundation as a technology don't deserve the honor. I know it feels cynicism. But they don't love & don't fear users.
Ok, it seems that I become the new victim of "salvaged fail". 15% of Life savings oh.
I no longer want to accuse Bitcoin foundation. They don't care, so do I.
The story: My laptop ran out of power while Bicoind was running. So the wallet corrupt for ever. Then I was so nervous that I copy another wallet.dat to make a backup without stopping bitcoind, then the 2nd wallet corrupt for ever.
I no longer, no longer want to accuse. i lost strength to accuse.
I ever thought 15% did not deserve to care enough, until one day I lost it.
Sorry, i am too sad
I use windows. SSD (macbook pro)
It seems the reason why this occured is that my laptop ran out of power while the bitcoind runing.
  1. I don't have any backup file.
  2. I have used this wallet.dat for more than one year. And in the past 5 months, I never use it.
  3. just now, I opened the bitcoind with the command -salvagewallet, and it says it needs to reindex, i choose "no". S it closed. And said “salvage failed"
  4. I saw the wallet.dat disappeared, and there appears a new file "wallet.*****(timestamp).bak", which I can't open.
I tried to relaunch bitcoind several times, with or without "-salvagewallet", every time failed.
I still have hope because One webpage I searched says "Warning: wallet.dat corrupt, data salvaged! Original wallet.dat saved as wallet.{timestamp}.bak in /root/.c-note; if your balance or transactions are incorrect you should restore from a backup."
But what I saw is "salvage failed", So I am a little nervous.
Shall I use the "-loadblock=wallet.14***(timestamp).bak" command? thanks
  1. So what can I do now to get my coins back?
is it able to get .dat from this new-generated .bak?thanks
thank you very much.
Anyone knows how to get bitcoin qt to recognise the presence of the corrupted wallet? thanks conf?
DB.LOG
file unknown has LSN 1/263145, past end of log at 1/198476 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment Page 0: metadata page corrupted Page 0: could not check metadata page wallet.dat: DB_VERIFY_BAD: Database verification failed file unknown has LSN 1/263145, past end of log at 1/199524 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment wallet.1428881042.bak: DB_VERIFY_BAD: Database verification failed
submitted by binghamtonbitcoin to Bitcoin [link] [comments]

Interested in contributing to the BTC network? Here is the steps to get a full node up and running in Linux.

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to Bitcoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to Bitcoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to BitcoinDiscussion [link] [comments]

Paper Wallet support in bitcoin-core | Dan Libby | Sep 29 2017

Dan Libby on Sep 29 2017:
Hi,
I'm writing to suggest and discuss the addition of paper wallet
functionality in bitcoin-core software, starting with a single new RPC
call: genExternalAddress [type].
-- rationale --
bitcoin-core is the most trusted and most secure bitcoin implementation.
Yet today (unless I've missed something) paper wallet generation
requires use of third party software, or even a website such as
bitaddress.org. This requires placing trust in an additional body of
code from a less-trusted and less peer-reviewed source. Ideally, one
would personally audit this code for one's self, but in practice that
rarely happens.
In the case of a website generator, the code must be audited again each
time it is downloaded. I cannot in good faith recommend to anyone to
use such third party tools for wallet generation.
I would recommend for others to trust a paper wallet that uses
address(es) generated by bitcoin-core itself.
At least for me, this requirement to audit (or implicitly trust) a
secondary body of bitcoin code places an additional hurdle or
disincentive on the use of paper wallets, or indeed private keys
generated outside of bitcoin-core for any purpose.
Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
or getrawchangeaddress for this purpose, because the associated private
keys are added to the bitcoin-core wallet and cannot be removed... or in
the case of hd-wallets are deterministically derived.
As such, I'm throwing out the following half-baked proposal as a
starting point for discussion:
genexternaladdress ( "type" ) Returns a new Bitcoin address and private key for receiving payments. This key/address is intended for external usage such as paper wallets and will not be used by internal wallet nor written to disk. Arguments: 1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh default: p2sh-p2wpkh Result: { "privKey" (string) The private key in wif format. "address" (string) The address in p2pkh or p2sh-p2wpkh format. } Examples: > bitcoin-cli genexternaladdress 
This API is simple to implement and use. It provides enough
functionality for any moderately skilled developer to create their own
paper wallet creation script using any scripting language, or even for
advanced users to perform using bitcoin-cli or debug console.
If consensus here is in favor of including such an API, I will be happy
to take a crack at implementing it and submitting a pull request.
If anyone has reasons why it is a BAD IDEA to include such an RPC call
in bitcoind, I'm curious to hear it.
Also, I welcome suggestions for a better name, or maybe there could be
some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
instead.
---- further work ----
Further steps could be taken in this direction, but are not necessary
for a useful first-step. In particular:
  1. an RPC call to generate an external HD wallet seed.
  2. an RPC call to generate N key/address pairs from a given seed.
  3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
generation (and printing?) for end-users, complete with nice graphics,
qr codes, etc.
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Septembe015120.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Any way to recover wallet access? Reward if you help me recover

Hi all, I'm looking for some insight on whether my wallet is gone or not.
Here's the backstory. I tried to transfer my btc to cold storage in 2015 (and thought I did) but when I tried to open that wallet, it was empty. For some reason, the transaction never went through. I went back to my old SSD, but I had deleted a lot of stuff off of it, including the wallet file (dumb, I know :/). Here was my setup:
I had bitcoin qt installed on my external harddrive. I didn't realize it was storing the wallet file and blockchain on my internal SSD which is how I accidently deleted it. When I opened the app again, it started downloading the blockchain again and it created a new wallet file on the SSD. I sent the SSD to a data recovery specialist, but they could not help.
There are some files on the external HD, but I don't know if they are useful at all. There's an src folder with a lot of H and CPP files, and a few other odds and ends. There's also a daemon folder with a bitcoind application.
Not sure what else I could do. Anyone have any thoughts on this? I'll reward anyone who can help me with a successful recovery. Thank you.
submitted by party6robot to BitcoinSerious [link] [comments]

Fake coinjoin generator for bitcoind/bitcoin-qt

There was post about idea for a solutions to generate fake coinjoin transactions from your wallet. https://www.reddit.com/joinmarket/comments/382645/ideagig_fake_joinmarket_transaction_generato
That post is old and archived, can't comment there, so I created this new one.
I have implemented fake coinjoin transaction generator for bitcoind/bitcoin-qt. It tries to create transactions in a way that they should look the same as JoinMarket CoinJoin transactions from blockchain analysis perspective.
https://github.com/kristapsk/bitcoin-scripts
Hint - if you are running a JoinMarket yield generator bot, you can add one or more fake coinjoin outputs to fund your yg wallet, that way it will look even more as a JoinMarket transaction. :)
submitted by neonzzzzz to joinmarket [link] [comments]

Really like the watch only functionality in bitcoin core!

First of all: thanks core developers for all the efforts!
Reason: if you run a full bitcoin node, to see your total balance without exposing your addresses to others.
Did it like this on my full node (ubuntu linux, no pruning):
Backup your wallet.dat
Start: bitcoind
Execute in a script (or on the command line):
bitcoin-cli importaddress "address1" Label false
bitcoin-cli importaddress "address2" Label false
bitcoin-cli importaddress "address3" Label false
Etc.
Stop: bitcoind
Start: bitcoin-qt -rescan
bitcoin-qt will rescan the wallet and you can see the progress. When finished you will see the balance of all addresses (watch and non watch)
When running bitcoind you can get the total balance of the wallet:
bitcoin-cli getbalance "*" 0 true
To get the total balance without the watch only addresses
bitcoin-cli getbalance "*" 0 false
Combine this with an Apache server and you can watch your balance completely safe anywhere and without exposing your (HD) addresses.
Side note: you can use bitcoin-qt as a wallet without too much hinder like this:
/usbin/taskset -c 0 /usbin/ionice -c 3 /usbin/nice -n 19 /home/usebitcoin-0.11.0/src/qt/bitcoin-qt
taskset: use only one cpu
ionice: low i/o priority
nice: low cpu priority
I hope this is useful for someone.
submitted by sumBTC to Bitcoin [link] [comments]

The bitcoin-qt core wallet in pruned mode, cold storage and scaling: test results.

CONCLUSION
 
DETAILS
First a wallet was created in the following way:
bitcoin-qt -connect=wrong_ip_address -prune=550 -listen=0 -datadir=/home/use.bitcoin_pruned &
The trick here is to add a wrong ip address so bitcoin-qt won't start loading blocks. The -listen=0 makes it possible to run bitcoin-qt while bitcoind (as a full archival node) is running in the background on the same computer.
 
Now some "watch only" addresses, that already had some bitcoin in them, were added
(in bitcoin-qt: help -> Debug window -> Console)
importaddress watch_only_address "" false
The pruned blockchain was then created by inserting the correct ip address (pointing to my node) or by removing "-connect=ip_address" completely.
 
Because bitcoin-qt was not the only program, creating the pruned blockchain was a very long process that took about 5 days! I could speed up the process a lot by turning off bitcoind and running the pruned node as a bitcoind with some extra priority:
sudo /usbin/ionice -c 2 -n 0 /usbin/nice -n -20 ./bitcoind -datadir=/home/use.bitcoin_pruned/
Had I done that from the start, it could have been much faster and maybe 1 or 2 days would have been enough.
The final pruned blockchain has a size of: 2542 MB so about 2.5 GB.
 
I now moved the wallet.dat to wallet.dat_back and restarted bitcoin-qt. The program will create a new wallet that can be used to receive and then send transactions. If you now add a private key that already has some bitcoins in it, they will NOT be visible. There is no reason for that as the balances (not the history) are in the UTXO set.
 
I now started bitcoin-qt with the original wallet.dat file. The bitcoins in the watch only addresses are now visible. I then imported the private key of one of the addresses but the move of the bitcoins from "Watch only" to "Spendable" was not visible in bitcoin-qt. However, after a restart of bitcoin-qt the funds were visible in the "Spendable" section of the wallet. I then did a transaction to another address. Now in this case I want the change of the transaction to stay within MY "watch only" addresses and they shouldn't move to the (arbitrary) addresses created when the wallet was created. This is fortunate possible in bitcoin-qt. You have to choose in bitcoin-qt:
Settings -> Options -> Wallet -> Enable coin controle features.
It is then possible to choose the return address to be one of the watch only addresses (with or without bitcoins in them). It all worked just fine! It is not clear to me why bitcoin-qt has the option to "importprunedfunds", that doesn't seem necessary.
 
Of course, a big thank you to all developers who implemented the currently available great features.
submitted by sumBTC to Bitcoin [link] [comments]

Multisig Contract in Ethereum Wallet

I've installed the Ethereum Wallet, and/or Mist and/or Geth... I don't know :( I guess the installer installs the three of them.
1) Is Geth the equivalent to bitcoind ?
2) Are the wallet and Mist in the same .exe and are they equivalent to bitcoinQT ?
3) What's the difference between Ethereum Wallet and Mist?
Using the Ethereum Wallet and in sync with the Rinkeby blockchain. I want to test with contracts but I also have some doubts I want to clear before I go ahead.
4) What's the difference between a "wallet contract" with a single owner account, and an account?
5) I have created a multisig wallet contract, I can see it in Etherscan, but not in the wallet, why?
6) To watch the contract I need a JSON interface, how do I get it?
7) I've sent some ether to the multisig contract. Now how can I sign a transaction? Doesn't Ethereum wallet provide an interface to sign multisig transactions?
I would also appreciate some reading tips to help me using Ethereum. Thanks!
submitted by blockwhat to ethereumnoobies [link] [comments]

Blockchain Wallet  How To Create Blockchain Bitcoin ... Programming Bitcoin-qt using the RPC api (1 of 6) Bitcoin Wallet - Download, Encrypt, Backup, & Use - YouTube Bitcoin-QT Wallet Update 9. bitcoind

There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin”), and a 'headless' version (called bitcoind).They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files. Bitcoin Core(旧Bitcoin-Qt) Bitcoin Core(旧Bitcoin-Qt) Bitcoinの公式クライアントです。利用するには、インストール後、数時間~1日以上かけてすべてのブロックチェーン(取引履歴)をダウンロードする必要がある上、セキュリティ面のオプションが少ないため、海外での人気はあまり高くありません。 なお ... The first wallet program called Bitcoin-Qt was released in 2009 by Satoshi Nakamoto as open source code. Bitcoin-Qt, also called "Satoshi client" is sometimes referred to as the reference client because it serves to define the Bitcoin protocol and acts as a standard for other implementations. As of version 0.9, Bitcoin-Qt has been renamed "Bitcoin Core" to more accurately describe its role in ... Bitcoin Core ist ein gemeinschaftliches, freies Software-Projekt, veröffentlicht unter der MIT-Lizenz. Release-Signaturen überprüfen Download über Torrent Quelltext Versionshistorie anzeigen. Bitcoin Core Release Signierschlüssel v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Oder wählen Sie Ihr Betriebssystem . Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit ... Bitcoin Core is a community-driven free software project, released under the MIT license. Verify release signatures Download torrent Source code Show version history. Bitcoin Core Release Signing Keys v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Or choose your operating system. Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit - 32 bit. Linux (Snap Store) Support ...

[index] [27905] [41450] [24117] [27897] [25167] [17210] [21966] [39387] [20182] [35068]

Blockchain Wallet How To Create Blockchain Bitcoin ...

bitcoin-cli and bitcoind - Breaking Down Bitcoin Ep. 2 - Duration: 45:01. ... Step 7.3 Connecting your Wallet to BTCPay Server with xpub Ledger Nano S or other like Electrum - Duration: 5:00 ... This tutorial demonstrates step by step how to download and install your first Bitcoin desktop wallet. More videos to come soon. For more FAQs, site reviews ... How to run Bitcoin-qt as a server with a ... Secure Your Wallet 5,092 views. 8:53. Python Bitcoin Tutorial for Beginners - Duration: 18:04. m1xolyd1an 70,824 views. 18:04. 9. bitcoind - Duration ... RPC commands: - getbalance - getwalletinfo - getnewaddress - getblockcount - getnetworkinfo www.bitcoinhackers.org @402PaymentRequierd bc1qny4am3clu0gcsq3hvj... In this video from http://www.secureyourwallet.com we do a full review of the original Satoshi Bitcoin wallet. We do an install, look at the blockchain data,...

#