Download - Bitcoin

Forgot to upgrade your node? Here's how to get back onto the upgraded BCH network:

These instructions are for those who left old versions (0.20.12 or older) of Bitcoin ABC running through the May 15th, 2020 upgrade. Follow these instructions to get back on the main network.
If you are using bitcoin-qt, follow these steps:
  1. Stop your running node
  2. Delete the list of nodes you have banned: rm ~/.bitcoin/banlist.dat
  3. Download version 0.21.x from
  4. Start up the new version (./bin/bitcoin-qt)
  5. Open Help -> Debug window
  6. In the console type reconsiderblock 00000000000000000033dfef1fc2d6a5d5520b078c55193a9bf498c5b27530f7
  7. Wait until your node is on the correct chain. This could take some time if your old node was running for a while, and other nodes banned you on the network. You can check that you are on the correct chain by typing getblockchaininfo and verifying the information with a public block explorer such as,, or
If you are running bitcoind, follow these steps:
  1. Stop your running node
  2. Delete the list of nodes you have banned: rm ~/.bitcoin/banlist.dat
  3. Download version 0.21.x from
  4. Start up the new version (./bin/bitcoind)
  5. Use bitcoin-cli to type: ./bin/bitcoin-cli reconsiderblock 00000000000000000033dfef1fc2d6a5d5520b078c55193a9bf498c5b27530f7
  6. Wait until your node is on the correct chain. This could take some time if your old node was running for a while, and other nodes banned you on the network. You can check that you are on the correct chain by typing ./bin/bitcoin-cli getblockchaininfo and verifying the information with a public block explorer such as,, or
submitted by Mengerian to btc [link] [comments]

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

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 - 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 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)


This is the manual how to get started on you PC / MAC / Linux (I did it on Win7)
Go to: 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
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:
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:
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.


Here is what I did:
1) I installed Raspian Pixel ( 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:
Please have a look at it - I have copied the Headlines in capitals to let you know what I did, and what I skipped.
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 [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 cd bitcoin ./
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

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)
That's it for the raspi.
update: To signal UASF enter in a new line:


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:
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
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 and enable portforwarding for your raspberry pi - and open ports 8333 - that's it!
You can now go to:
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 @
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 )
  • 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, select Armory..
It leads to a Download from Git:
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 \ --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:
(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:
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 -
Inside the script, it has the line:
python --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 --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) - Unsupported language specified. Defaulting to English (en) (ERROR) - Failed to start Armory database: cannot concatenate 'str' and 'int' objects Traceback (most recent call last): File "", line 1808, in startArmoryDBIfNecessary TheSDM.spawnDB(str(ARMORY_HOME_DIR), TheBDM.armoryDBDir) File "/BitcoinArmory/", 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
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) - 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 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: ./
(which uses command line:)
python --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
So, this is the command which it reports that it starts with:
(WARNING) - 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..
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]

Please help - why is my Bitcoin Conf file in the wrong directory?

I am running a Bitcoin Core GUI-based full node on Windows 10. The conf file is in my bitcoin data directory, instead of being in the appdata/roaming folder. But bitcoind and bitcoin-cli continue to look for the conf file in that appdata/roaming folder, which I guess is the reason the bitcoind server never appears to start. However, Bitcoin-qt (the GUI) appears to work fine and is also pointing to the conf file correctly. I checked by opening the conf file from the settings>options.

How do I start bitcoind and check if it is running or not? If I run it on cmd, it appears to start downloading the whole blockchain again, which is unnecessary because I already have all of it.
submitted by niranjanrao1 to Bitcoin [link] [comments]

Bitcoin Core 0.10.1 Released

Bitcoin Core version 0.10.1 is now available from:
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:

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

0.10.1 Change log

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


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.



submitted by doge_messiah to dogecoin [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?
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:
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 > > > > 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 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 ( 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 -->
submitted by Mattjhagen to Bitcoin [link] [comments]

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

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]

-reindex option doesn't fix a corrupted blockchain, it's downloading all over again.

This is a follow up to the corrupted blockchain problem described by me 5 days ago:
As bitusher suggested, I ran:
./bitcoind.exe -reindex --datadir=G:\Bitcoin\Bitcoin_core\Bitcoin\blockchain 
Before that I had even tried the option -reindex-chainstate but it failed for some reason.
After about 8 hours, the reindex finished but it's downloading the blockchain all over again although I already have 200 GB of blockchain data. I can see this by running:
Bitcoin\daemon> .\bitcoin-cli.exe getblockcount 323136 (wait some minutes...) Bitcoin\daemon> .\bitcoin-cli.exe getblockcount 326069 
The point when it went from reindexing to downloading the blockchain all over again looks like this in debug.log:
2018-07-24 08:32:09 Reindexing block file blk01265.dat... 2018-07-24 08:33:57 Loaded 962 blocks from external file in 107945ms 2018-07-24 08:33:57 Reindexing finished 2018-07-24 08:33:57 Pre-allocating up to position 0x100000 in rev00000.dat 2018-07-24 08:33:58 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1txo) 2018-07-24 08:33:58 UpdateTip: new best=000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd height=2 version=0x00000001 log2_work=33.584985 tx=3 date='2009-01-09 02:55:44' progress=0.000000 cache=0.0MiB(2txo) ... 2018-07-24 15:28:52 UpdateTip: new best=00000000000000000c84841e1450c8644dfe5a85528ae551f8862a688b55db61 height=331606 version=0x00000002 log2_work=81.568221 tx=52347394 date='2014-11-25 21:30:09' progress=0.149665 cache=2153.7MiB(16335495txo) 2018-07-24 15:28:52 Pre-allocating up to position 0x200000 in rev00200.dat 2018-07-24 15:28:53 UpdateTip: new best=0000000000000000103e002b3231dbee391cf38a2890e310b3e9ee3b785a172a height=331607 version=0x00000002 log2_work=81.568291 tx=52348058 date='2014-11-25 21:40:24' progress=0.149667 cache=2153.7MiB(16334996txo) 2018-07-24 15:28:53 UpdateTip: new best=00000000000000001ac7a4a8f8b910236cfbe1ec2343af4fbe9b8dd1691b7433 height=331608 version=0x00000002 log2_work=81.56836 tx=52348254 date='2014-11-25 21:42:35' progress=0.149667 cache=2153.6MiB(16334923txo) 2018-07-24 15:28:53 UpdateTip: new best=000000000000000006ecf1eb304f3edf56f8ebea62183f8ffbb37653433d196b height=331609 version=0x00000002 log2_work=81.56843 tx=52348821 date='2014-11-25 21:52:17' progress=0.149669 cache=2153.7MiB(16334989txo) 2018-07-24 15:28:53 UpdateTip: new best=00000000000000001864ff1e384b409d9c26745e3dc36a77cb3068959c6244f7 height=331610 version=0x00000002 log2_work=81.5685 tx=52349053 date='2014-11-25 21:55:54' progress=0.149670 cache=2153.7MiB(16335046txo) 2018-07-24 15:28:53 UpdateTip: new best=000000000000000019ff0a26dd1c684661a624f52a78185ba60ad63a464be92e height=331611 version=0x00000002 log2_work=81.568569 tx=52349229 date='2014-11-25 21:57:40' progress=0.149670 cache=2153.6MiB(16334946txo) 2018-07-24 15:28:54 UpdateTip: new best=00000000000000000775b876ee6d5ef4e74ec728d92ea37f249cf4183e8d8447 height=331612 version=0x00000002 log2_work=81.568639 tx=52350965 date='2014-11-25 22:27:56' progress=0.149675 cache=2153.7MiB(16335409txo) 2018-07-24 15:28:54 Pre-allocating up to position 0x1200000 in rev00199.dat 2018-07-24 15:28:54 UpdateTip: new best=000000000000000009547c69932fa9cc2a8d2c9f6449ef23db13da3f71ac8d40 height=331613 version=0x00000002 log2_work=81.568709 tx=52351547 date='2014-11-25 22:36:56' progress=0.149677 cache=2153.6MiB(16334933txo) 
I am feeling pretty frustrated because I can't run a simple bitcoin node every once in a while. Seems like every time I close bitcoind or bitcoin-qt the blockchain gets corrupted. I have found several people complaining about this problem online but I haven't found any definitive solution. Seems like avoiding windows is a good thing (I like to use the same blockchain folder that I store in an external hard drive in both windows and linux).
1 - How to avoid getting a corrupted blockchain in both windows and linux and both bitcoin-qt and bitcoind?
2 - How to fix a corrupted blockchain quickly, if this is even possible. -reindex and -reindex-chainstate don't seem to work in my case.
If this doesn't get solved here, I am opening an issue in bitcoin's github.
submitted by johnturtle to BitcoinBeginners [link] [comments]

PSA: Run A Full Node on Windows -- without the wallet!

For a long time now, I've wanted to run a full bitcoin node on my Windows computer and NOT run the wallet part of Bitcoin Core (formerly -QT). I wanted to contribute a full node to the network, but not use the Core wallet, nor have the wallet software load up and sit there taking up system resources for no reason except to contribute the node.
I read and asked a lot, before I finally figured it out. Here's how: Dowload and install Bitcoin Core from the official download page -- -- but DO NOT START THE PROGRAM in the usual way. Instead, open the Windows Command Prompt program and enter
cd\program files\bitcoin\daemon [return] .. then
bitcoind [return]
That starts the program, even though you see no indication of that in the window. You can't close the Command Prompt window or the program stops; but you can minimize it to the tray and it continues to run fine. After it's downloaded the blockchain and begun doing its regular function, you can check that it's running well this way: Open a second Command Prompt window and enter
cd\program files\bitcoin\daemon [return] .. then
bitcoin-cli getinfo
If you've opened Port 8333, you should see more than 8 connections, and all is well with the world.
To stop running the node, you can just close the Command Prompt window it's running in.
submitted by allgoodthings1 to Bitcoin [link] [comments]

Colored coin client preview #1 (based on Bitcoin Armory)

I think it's already good enough for people to play with it. (Although certainly it's not ready for anything serious.)
For people who are not familiar with concept, colored coins is a technology which allows people to represent arbitrary tokens (e.g. issue private currencies, stocks, bonds, etc.) using small quantities of bitcoins. It is interesting because it would allow us to create decentralized and secure markets. (As decentralized and secure as Bitcoin itself, at least in theory.) See here.
Notes about current release:
Windows binaries:
There are no Linux binaries, but it's really easy to build it on Ubuntu or Debian:
(Note: if you're already using Armory, it is a good idea to hide you ~/.armory so it won't be seen by this experimental Armory mod. Or, perhaps, just don't run this experimental mod.)
Before you run it, make sure that bitcoind or Bitcoin-Qt is running and fully sync'ed. Armory takes up to 10 minutes to start (this version is slower because it additionally scans for colored transactions) and requires ~ 1 GB of RAM.
At start it will offer to create a wallet, do not enable encryption, otherwise issuing colored coins won't work.
Send some bitcoins to this new wallet, 0.02 BTC is probably enough to issue some colored coins and to pay for tx fees.
There is a drop down to choose color. Balance is displayed for a currently chosen color (i.e. if you chose TESTcc it will show how many TESTcc units this wallet owns), and when you send coins you send coins of that color.
Initially 'uncolored' is selected, it means normal BTC. This drop down also has TESTcc ("test colored coins") and "All colors" (this mode is just for debugging, you cannot send coins in this mode).
Here's what you can do now:
  1. Ask somebody to send you TESTcc. (We want to make it automatic, Satoshi Dice style, but unfortunately that code isn't quite ready.)
  2. Find and install other color definitions.
  3. Issue your own colored coins and send them to somebody who wants them. (LOL.)
Let's start from option #3. There is 'Hallucinate' menu. (It is called 'hallucinate' because colors do not exist on blockchain level, it is a client-side convention.) Choose 'Issue colored coins'. Likely all you need to change is name, but you can tweak satoshi-per-unit and number of units if you want.
When you click Issue it will create a new transaction (using your uncolored BTC) and will create a color definition. Optionally it will also upload your color definition to color definition registry. (This registry runs on my server, it might be down.)
You should note ColorID, this is how other people can refer to these coins (name is ambiguous).
You can now choose this new color in drop down and it will show your balance. (E.g. 1000 units.)
Now you'll perhaps want to send these coins to somebody. That person would need to install your color definition first. If you send colored coins without warning they might be lost, i.e. mixed with uncolored ones. For same reason it makes no sense to send them to wallet which isn't color aware.
For example, you can post on some forum:
I've issued LOLwut coins (ColorID: 36738fe78a443656535503efb585fee140a37d54), each unit represents a bond with face value of 0.1 BTC payable by me, Trololo, via buy back. I promise to buy back all bonds in a month.
Now people who are interested in this LOLwut coin issue will copy ColorID, paste it into Hallucinate > Download color definition dialog, and if this color definition is published it will be downloaded and installed. Armory restart is required to complete installation.
After installation that person will be able to see these LOLwut coins.
Note that if you do not trust my registration server, you can publish color definition yourself: go to ~/.armory/colordefs, find 36738fe78a443656535503efb585fee140a37d54.colordef and upload it to your web server. Then you can give people URL like and they can download it by URL.
Or they can just obtain this file by any means and copy it to ~/.armory/colordefs directory. It is decentralized, nobody can prevent you from issuing colored coins.
I think that's all. There is also Hallucinate > Manage color definitions dialog, but I hope it's easy to figure out how it works.
We are working on improved version, particularly on p2p exchange feature.
I've set up an IRC channel for people to talk about trying out colored coins: #colored-coins-otc on Freenode.
submitted by killerstorm to Bitcoin [link] [comments]

Blackcoin Wallet Passphrase mistyped - Bruteforce

Summary: I executed a (limited!) brute force attack on a wallet where I mistyped the passphrase. Attached is a short tutorial how to make it.
Long story: some months ago I created a wallet. I keyed in my passphrase with 70 characters long (yes it is long), wrote it down, bought Blackcoin. Next day I tried to open it, but it seems to be that I mistyped (two times) the passphrase. So I started to make a long research how to "hack" it. I finally figured that I can make a limited brute force attack by using RPC. So, I got familiar with curl (RPC tool) and created a batch-script with Excel where I just changed one character per try. I ended with 5200 tries.
And boom: It worked! It was try number 2814 which worked. So, I really just mistyped one single character. The wallet has been opened once again. So now I have access to my Blackcoins.
I was using the old blackcoin-qt (on windows) because the wallet was created with this one. I do not know if it is compatible with lore. Situation is that you remember (more or less) the passphrase, but you think that you just mistyped one character. Idea is to make a limited brute force attack on the wallet - so, to test different passphrase which are similar to your remembered one.
we will create a script (batch) which calls the blackcoin-qt (as server) via RPC and try to open the wallet with different passphrases.
What did not work
I found some hints concerning hashcat and bitcoin2john (also for Blackcoin), which enable you to retrieve the seed out of the wallet and to make a bruteforce on the hash of the seed (with hashcat). But it did not work, because the blackcoin wallet seems to be different than the bitcoin wallet.
There is also no direct commandline parameter for opening the wallet with passphrase. So I started to work with RPC.
Using the blackcoin-qt as a server
Switch into C:\Users\myusername\AppData\Roaming\BlackCoin and place a blackcoin.conf file here. This should contain (at least) these entries:

server=1 tells BlackCoin to accept JSON-RPC commands.


You must set rpcuser and rpcpassword to secure the JSON-RPC api


Listen for RPC connections on this TCP port:


You can use BlackCoin or blackcoind to send commands to Bitcoin/bitcoindBlackCoin/blackcoind

running on another host using this option:

...Start blackcoin from the commandline with the server parameter like this: blackcoin-qt -server=1
Test RPC Calls with curl
Download curl (an RPC tool for the commandline):
For this test you should use a new generated wallet with a password you know.
First test with the getinfo method, which shows you if the connection to the Blackcoin Daemon is established: curl --header "Content-Type: application/json" --data-binary "{\"jsonrpc\":\"1.0\",\"id\":\"curltest\",\"method\":\"getinfo\",\"params\":[]}" http://user:[email protected]:15715/
If you do not get any connection, you can also use netstat -a to see if your machine is listening on the port 15715.
Finally, the method to open the wallet via RPC (uses two parameters) curl --header "Content-Type: application/json" --data-binary "{\"jsonrpc\":\"1.0\",\"id\":\"curltest\",\"method\":\"walletpassphrase\",\"params\":[\"mySecretWalletPassword\",50]}" http://user:[email protected]:15715/
Note the output you get, when you use the correct password: {"result":null,"error":null,"id":"curltest"}
Later we want to search in a logfile for the expression "error":null in order to identify the correct password
Generating the Bruteforce Script
I used an Excel file to create a script. On the basis of the so-far-remembered-passphrase and a selection of possible characters this scripts changes for each row only one character. I ended up with roughly 5000 rows, but I used a very long passphrase (70 characters). Using the Excel output you can create a script out of it.
If you are interested in the Excel file you can contact me on bitcointalk - my username is "Euro1000"
Start the script (batch) and pipe the output into a log: myScript.bat > log.txt
When the batch finished search for the expression "error":null If you found it, you found the password in the line above the expression.
I used the old blackcoin-qt (not Lore), because the wallet has been generated with blackcoin-qt. Lore should use the same RPC implementation, but it is untested if this tutorial also works with Lore.
I used this on Windows I do not know if this will also work on Linux.
Some special characters are a little bit tricky in curl, because some of them like "<" let curl crashes. Perhaps you can escape these special characters somehow.
submitted by coindestroyer to blackcoin [link] [comments]

Keep your Bitcoin Core UASF node up to date

Note to folks with a fake uacomment: that neither helps nor works. Upgrade to BIP148!
Those who want to use BIP148 have two main choices: UASF BIP148 and Bitcoin Knots. The first has bip148 enabled by default. The second follows a PR originally proposed to Bitcoin Core (and rejected) which adds bip148=0 (option, disabled by default) so it needs to be enabled in configuration file or at runtime.
Make a backup of your wallet.dat, just in case.

Bitcoin Core SegWit UASF BIP148

This is the "original" BIP148 version.
1) Get the source at
Current release: v1.0 -
As a reminder, your install options are as follows:
a) Binaries: Bitcoin Core v0.14.2-based UASF SegWit BIP148 can be downloaded here (decompress and then run desired binary (bitcoind for daemon/server, bitcoin-cli for the CLI, etc.) which you can find in bin subdirectory; there's also a PPA for Ubuntu users who prefer apt-get install).
b) Source: get the source at the URL at the top. Build as usual, following official Bitcoin Core instructions.
To install, stop and (if you want) remove existing Bitcoin Core. Then install and run Bitcoin SegWit UASF BIP148. Windows users who use installer (filenames that end with *setup-unsigned.exe) should first uninstall existing Bitcoin Core before they install this version.
How to verify binaries (signatures):
You can also verify checksums by importing Luke's PGP key and ensuring checksums in SHA256SUMS.asc(example here) match those of the downloaded file(s).

Bitcoin Knots

This is Luke-Jr's Bitcoin release with many enhancements and a BIP148 option. You can find more at
Get it at Install procedure for binaries is the same as for UASF BIP148 binaries, but with one added step:
Windows users who use installer (filenames that end with *setup-unsigned.exe) need to first uninstall existing Bitcoin Core before they can install this version.
If you want to build from the source, refer to Bitcoin Knots documentation (because it has a number of different options compared to Bitcoin Core).
How to verify binaries (signatures): download and import Luke's PGP key, refresh PGP keys, then verify the signed checksums file corresponds to the checksum of the binary you downloaded for your system.

Updating installed binaries

If you're updating either UASF BIP148 or Knots binaries (which you downloaded as zip or tgz file and decompressed to your disk), stop Bitcoin, decompress newer binaries over old binaries, then start service again. You can also move old binaries and then deploy the latest binaries.

Reverting to Bitcoin Core

Before chain split

Prior to chain split (such as before Aug 1), you can "go back" by simply removing BIP148 or Knots and installing Bitcoin Core 0.14.2. You can't go back to an earlier release such as 0.12 (same behavior as with Bitcoin Core).
Starting with UASF BIP148 v1.0, however, there's less need to be concerned about going back to Bitcoin Core - as mentioned above, Bitcoin Core 0.14.2 behavior can be achieved by restarting UASF BIP148 v1.0 or Bitcoin Knots with bitp148=0.
Should you want to remove UASF BIP148-compatible and run Bitcoin Core 0.14.2, you can do this:
Then install Bitcoin Core 0.14.2.

In the case of a chain split

Please remember to pay special attention to wallet.dat if you use one. This section only deals with the change of the binary and blockchain rewind, and not coin splitting and wallet backups.
If chains splits on or after August 1st, you would have to rewind the blockchain in order to use a different Bitcoin release on another chain. Details will vary depending on the circumstances (for example, we can't know in advance which chains will exist.)
UASF BIP148 v1.0 (not older releases) makes it possible to set bip148=0 and restart which automatically rewinds the blockchain to be consistent with Core. If you wanted to change to Bitcoin Core, you could first restart UASF BIP148 or Knots with bip148=0 to rewind the blockchain, then uninstall the binaries and install Bitcoin Core.
If a chain split happens, check or this subreddit for specific details.

Be back in late July!

In the second half of July, check for updates on a weekly basis. There may be further updates or improvements.


2017-07-12 - reminder to pay attention to wallet backup in case of changing the binaries or startup options after a chain split
2017-07-11 - download links updated for v1.0, added about auto-rewind in v1.0, other small edits
Edit: this post may be updated prior to August 1st.
submitted by eustan to UASF [link] [comments]

Linux noob needs help getting a Bitcoin Classic node running on Lubuntu

I've installed Lubuntu 15.10 on an old laptop that used to be Windows XP. Seems to run fine. I tried Ubuntu but the laptop struggled to run it.
I've downloaded bitcoin-0.11.2-linux32.tar.gz as my Lubuntu installation is 32 bit.
I've extracted the contents but don't have a clue how to install - dont laugh, I've only ever used Windows before.
The bitcoin-0.11.2 folder contains the following folders:
Bin Include Lib
I assume the file I want to run to install is in bin?
The options are:
Bitcoin-cli Bitcoind Bitcoin-qt Bitcoin-tx
And two others starting 'test'
Which of the above do I run to install Classic?
And how do I run, is it a matter of simply double clicking, or do I use the Terminal? If so, what is the terminal command?
Thanks for your help.
submitted by vyhvdrujnbdryu to Bitcoin_Classic [link] [comments]

Colored coins: NGCCC preview build v0.0.2

(my pubkey)
This build fixes several bugs and make it easier to share asset definitions: it is now possible to copy the whole thing in JSON format.
Wallet is in testnet mode by default. (And I strongly recommend against using it in mainnet mode, even though it is possible.)
Use either gui (ngccc-gui) or command-line interface (ngccc-cli --help).
It requires bitcoind/bitcoin-qt in testnet mode running locally. To install it:
  1. Download bitcoin-qt from
  2. Create bitcoin.conf with rpcuser and rpcpassword
  3. Run it like bitcoin-qt -server -testnet -txindex
submitted by killerstorm to coloredcoin [link] [comments]

Bitcoin Core 0.11.0 released | Wladimir J. van der Laan | Jul 12 2015

Wladimir J. van der Laan on Jul 12 2015:
Hash: SHA512
Bitcoin Core version 0.11.0 is now available from:
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
The entire distribution is also available as torrent:
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:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
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. There are no
known problems when downgrading from 0.11.x to 0.10.x.
Important information

Transaction flooding
At the time of this release, the P2P network is being flooded with low-fee
transactions. This causes a ballooning of the mempool size.
If this growth of the mempool causes problematic memory use on your node, it is
possible to change a few configuration options to work around this. The growth
of the mempool can be monitored with the RPC command getmempoolinfo.
One is to increase the minimum transaction relay fee minrelaytxfee, which
defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be
rejected, and thus fewer transactions entering the mempool.
The other is to restrict the relaying of free transactions with
limitfreerelay. This option sets the number of kB/minute at which
free transactions (with enough priority) will be accepted. It defaults to 15.
Reducing this number reduces the speed at which the mempool can grow due
to free transactions.
For example, add the following to bitcoin.conf:
minrelaytxfee=0.00005 limitfreerelay=5 
More robust solutions are being worked on for a follow-up release.
Notable changes

Block file pruning
This release supports running a fully validating node without maintaining a copy
of the raw block and undo data on disk. To recap, there are four types of data
related to the blockchain in the bitcoin system: the raw blocks as received over
the network (blk???.dat), the undo data (rev???.dat), the block index and the
UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once
it's been validated and used to build the databases. At that point, the raw data
is used only to relay blocks to other nodes, to handle reorganizations, to look
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
for rescanning the wallet. The block index continues to hold the metadata about
all blocks in the blockchain.
The user specifies how much space to allot for block & undo files. The minimum
allowed is 550MB. Note that this is in addition to whatever is required for the
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
minutes per block). In rare instances it is possible that the amount of space
used will exceed the pruning target in order to keep the required last 288
blocks on disk.
Block pruning works during initial sync in the same way as during steady state,
by deleting block files "as you go" whenever disk space is allocated. Thus, if
the user specifies 550MB, once that level is reached the program will begin
deleting the oldest block and undo files, while continuing to download the
For now, block pruning disables block relay. In the future, nodes with block
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
active chain.
Block pruning is currently incompatible with running a wallet due to the fact
that block data is used for rescanning the wallet and importing keys or
addresses (which require a rescan.) However, running the wallet with block
pruning will be supported in the near future, subject to those limitations.
Block pruning is also incompatible with -txindex and will automatically disable
Once you have pruned blocks, going back to unpruned state requires
re-downloading the entire blockchain. To do this, re-start the node with
  • -reindex. Note also that any problem that would cause a user to reindex (e.g.,
disk corruption) will cause a pruned node to redownload the entire blockchain.
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
and rev???.dat files in the data directory prior to restarting the download.
To enable block pruning on the command line:
  • - -prune=N: where N is the number of MB to allot for raw block & undo data.
Modified RPC calls:
    • getblockchaininfo now includes whether we are in pruned mode or not.
    • getblock will check if the block's data has been pruned and if so, return an
  • - getrawtransaction will no longer be able to locate a transaction that has a
UTXO but where its block file has been pruned.
Pruning is disabled by default.
Big endian support
Experimental support for big-endian CPU architectures was added in this
release. All little-endian specific code was replaced with endian-neutral
constructs. This has been tested on at least MIPS and PPC hosts. The build
system will automatically detect the endianness of the target.
Memory usage optimization
There have been many changes in this release to reduce the default memory usage
of a node, among which:
    • Accurate UTXO cache size accounting (#6102); this makes the option -dbcache
    precise where this grossly underestimated memory usage before
    • Reduce size of per-peer data structure (#6064 and others); this increases the
    number of connections that can be supported with the same amount of memory
    • Reduce the number of threads (#5964, #5679); lowers the amount of (esp.
    virtual) memory needed
Fee estimation changes
This release improves the algorithm used for fee estimation. Previously, -1
was returned when there was insufficient data to give an estimate. Now, -1
will also be returned when there is no fee or priority high enough for the
desired confirmation target. In those cases, it can help to ask for an estimate
for a higher target number of blocks. It is not uncommon for there to be no
fee or priority high enough to be reliably (85%) included in the next block and
for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.
Privacy: Disable wallet transaction broadcast
This release adds an option -walletbroadcast=0 to prevent automatic
transaction broadcast and rebroadcast (#5951). This option allows separating
transaction submission from the node functionality.
Making use of this, third-party scripts can be written to take care of
transaction (re)broadcast:
    • Send the transaction as normal, either through RPC or the GUI
    • Retrieve the transaction data through RPC using gettransaction (NOT
    getrawtransaction). The hex field of the result will contain the raw
    hexadecimal representation of the transaction
    • The transaction can then be broadcasted through arbitrary mechanisms
    supported by the script
One such application is selective Tor usage, where the node runs on the normal
internet but transactions are broadcasted over Tor.
For an example script see [bitcoin-submittx](
Privacy: Stream isolation for Tor
This release adds functionality to create a new circuit for every peer
connection, when the software is used with Tor. The new option,
-proxyrandomize, is on by default.
...[message truncated here by reddit bot]...
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.12.1 released | Wladimir J. van der Laan | Apr 15 2016

Wladimir J. van der Laan on Apr 15 2016:
Hash: SHA512
Bitcoin Core version 0.12.1 is now available from:
Or through bittorrent:
This is a new minor version release, including the BIP9, BIP68 and BIP112
softfork, various bugfixes and updated translations.
Please report bugs using the issue tracker at github:
To receive security and update notifications, please subscribe to
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

Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every
fresh sync or reindex, the chainstate is not backwards-compatible with
pre-0.12 versions of Bitcoin Core or other software.
If you want to downgrade after you have done a reindex with 0.12.0 or later,
you will need to reindex when you first start Bitcoin Core version 0.11 or
Notable changes

First version bits BIP9 softfork deployment
This release includes a soft fork deployment to enforce BIP68,
BIP112 and BIP113 using the BIP9 deployment mechanism.
The deployment sets the block version number to 0x20000001 between
midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for
deployment. The version number consists of 0x20000000 to indicate version
bits together with setting bit 0 to indicate support for this combined
deployment, shown as "csv" in the getblockchaininfo RPC call.
For more information about the soft forking change, please see
This specific backport pull-request can be viewed at
BIP68 soft fork to enforce sequence locks for relative locktime
BIP68 introduces relative lock-time consensus-enforced semantics of
the sequence number field to enable a signed transaction input to remain
invalid for a defined period of time after confirmation of its corresponding
For more information about the implementation, see
BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
BIP112 redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Bitcoin scripting system that in combination with
BIP68 allows execution pathways of a script to be restricted based
on the age of the output being spent.
For more information about the implementation, see
BIP113 locktime enforcement soft fork
Bitcoin Core 0.11.2 previously introduced mempool-only locktime
enforcement using GetMedianTimePast(). This release seeks to
consensus enforce the rule.
Bitcoin transactions currently may specify a locktime indicating when
they may be added to a valid block. Current consensus rules require
that blocks have a block header time greater than the locktime specified
in any transaction in that block.
Miners get to choose what time they use for their header time, with the
consensus rule being that no node will accept a block whose time is more
than two hours in the future. This creates a incentive for miners to
set their header times to future values in order to include locktimed
transactions which weren't supposed to be included for up to two more
The consensus rules also specify that valid blocks may have a header
time greater than that of the median of the 11 previous blocks. This
GetMedianTimePast() time has a key feature we generally associate with
time: it can't go backwards.
BIP113 specifies a soft fork enforced in this release that
weakens this perverse incentive for individual miners to use a future
time by requiring that valid blocks have a computed GetMedianTimePast()
greater than the locktime specified in any transaction in that block.
Mempool inclusion rules currently require transactions to be valid for
immediate inclusion in a block in order to be accepted into the mempool.
This release begins applying the BIP113 rule to received transactions,
so transaction whose time is greater than the GetMedianTimePast() will
no longer be accepted into the mempool.
Implication for miners: you will begin rejecting transactions that
would not be valid under BIP113, which will prevent you from producing
invalid blocks when BIP113 is enforced on the network. Any
transactions which are valid under the current rules but not yet valid
under the BIP113 rules will either be mined by other miners or delayed
until they are valid under BIP113. Note, however, that time-based
locktime transactions are more or less unseen on the network currently.
Implication for users: GetMedianTimePast() always trails behind the
current time, so a transaction locktime set to the present time will be
rejected by nodes running this release until the median time moves
forward. To compensate, subtract one hour (3,600 seconds) from your
locktimes to allow those transactions to be included in mempools at
approximately the expected time.
For more information about the implementation, see
The p2p alert system is off by default. To turn on, use -alert with
startup configuration.
0.12.1 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

  • - #7739 7ffc2bd Add abandoned status to listtransactions (jonasschnelli)

Block and transaction handling

  • - #7543 834aaef Backport BIP9, BIP68 and BIP112 with softfork (btcdrak)

P2P protocol and network code

    • #7804 90f1d24 Track block download times per individual block (sipa)
    • #7832 4c3a00d Reduce block timeout to 10 minutes (laanwj)


    • #7821 4226aac init: allow shutdown during 'Activating best chain...' (laanwj)
    • #7835 46898e7 Version 2 transactions remain non-standard until CSV activates (sdaftuar)

Build system

    • #7487 00d57b4 Workaround Travis-side CI issues (luke-jr)
    • #7606 a10da9a No need to set -L and --location for curl (MarcoFalke)
    • #7614 ca8f160 Add curl to packages (now needed for depends) (luke-jr)
    • #7776 a784675 Remove unnecessary executables from gitian release (laanwj)


  • - #7715 19866c1 Fix calculation of balances and available coins. (morcos)


    • #7617 f04f4fd Fix markdown syntax and line terminate LogPrint (MarcoFalke)
    • #7747 4d035bc added depends cross compile info (accraze)
    • #7741 a0cea89 Mark p2p alert system as deprecated (btcdrak)
    • #7780 c5f94f6 Disable bad-chain alert (btcdrak)

Thanks to everyone who directly contributed to this release:
    • accraze
    • Alex Morcos
    • BtcDrak
    • Jonas Schnelli
    • Luke Dashjr
    • MarcoFalke
    • Mark Friedenbach
    • NicolasDorier
    • Pieter Wuille
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
Version: GnuPG v1
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

" Bitcoin bad " [ participating ] Heartbleed vulnerability affects bitcoins ... ( Chinese hackers published technical affirm ) - Transfer from Bitcoin first Chinese community -

Heartbleed vulnerability affects bitcoin ... let the brother in person to tell you how dangerous loophole Heartbleed
Disclaimer: This article caused by subsequent exposure , at your own liability .
Author : btcrobot
Contribute BTC: 1NDnnWCUu926z4wxA3sNBGYWNQD3mKyes8 Originally wanted to write articles related articles side chains , but feel deep enough , the other seems a bit of a MM Frank wrote , brother does not like re- nonsense, direct point of security-related today . . . . .
Evil octal dividing line . . . . . . . . . . . .
About Heartbleed loopholes, as a bit of people , must be sensitive to , ah, brother of the first time I felt vulnerability unlimited , ideas unlimited , unlimited play , as to get rid of xxx, it needs Martian guts , brother still relatively conservative , but in another way detour and the line, this is just to let you experience the next :
Steps are as follows :
1 find various bits coins, currency cottage client IP address , find a specific port, which enable SSL
Get bitcoin client ip installed two ways :
1 Download a qt-bitcoin client, open debug.log, ok it collects inside IP
2014-04-21 01:53:27 init message: loading is complete 2014-04-21 01:53:27 Initialization result: 1 2014-04-21 01:53:28 ERROR: GetMyExternalIP (): connection closed 2014-04-21 01:53:28 receive version message: / Satoshi: 0.8.5 /: version 70001, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:28 Added time data, samples 2, offset -6 (+0 minutes) 2014-04-21 01:53:33 ERROR: GetMyExternalIP (): connection to failed 2014-04-21 01:53:35 receive version message: / Satoshi: /: version 70001, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:35 Added time data, samples 3, offset -13 (+0 minutes) 2014-04-21 01:53:35 No valid UPnP IGDs found 2014-04-21 01:53:35 upnp thread exit 2014-04-21 01:53:36 receive version message: / Satoshi: 0.8.5 /: version 70001, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:36 Added time data, samples 4, offset +12 (+0 minutes) 2014-04-21 01:53:36 socket recv error 10054 2014-04-21 01:53:41 ERROR: GetMyExternalIP (): connection closed 2014-04-21 01:53:48 receive version message: / Satoshi: 0.9.99 /: version 70002, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:48 Added time data, samples 5, offset -12 (+0 minutes) 2014-04-21 01:53:48 nTimeOffset = -6 (+0 minutes) 2014-04-21 01:53:48 ERROR: GetMyExternalIP (): connection to failed 2014-04-21 01:53:48 ext-ip thread exit 2014-04-21 01:53:49 receive version message: / Satoshi: 0.9.1 /: version 70002, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:49 Added time data, samples 6, offset -13 (+0 minutes) 2014-04-21 01:53:50 receive version message: / Satoshi: 0.9.0 /: version 70002, blocks = 296904, us =, them =, peer = : 8333 2014-04-21 01:53:50 Added time data, samples 7, offset -12 (+0 minutes) 2014-04-21 01:53:50 nTimeOffset = -12 (+0 minutes)
Look at these IP right, gather next :)
2 Use blockchain, this can cause huge point , opening
Not only know the IP, and intuitively know the client version used for those versions vulnerable , silent, huh. .
file :/ / / C: \ DOCUME ~ 1 \ ADMINI ~ 1 \ LOCALS ~ 1 \ Temp \ ksohtml \ wps_clip_image-28929.png
3 write a small crawler , automated constantly crawl the IP, NG saved as a file in the following format , do not ask me to code. . . Their play to Xxx Yyy . . . .
4 Improved bleed procedures through the entire document , well, to the point code
func readLines (path string) ([] string, error) { file, err: = os.Open (path) if err! = nil { return nil, err .... 00000580 32 32 2d 31 33 39 32 38 39 37 31 31 31 30 30 30 | 22-1392897111000 | ........
| onnection: keep-| | alive .. If-Modifi | | ed-Since: Fri, 1 | | 1 Apr 2014 10:35 | |: 05 GMT ........; | | `...... ~ 9D .. X. .. |
If 443 , if it is a server , I rely on you regularly collect it, pattern matching. . . . Bypass to the other , web springboard , and the like . . . If ssl + rpc, broken rpc, if not set the wallet password, and then send a command transfer bitcoins , oh, my god ...
Bitcoins are so cottage currency would not have said that if there is 443 loopholes still be out of every minute . . .
heartbleed bitcoin client to attack , in the case of open rpc protocol , using ssl certification, can be attacked . This is the vast majority of the server program will open options. Individual users should not panic. . . .
Well, not much to say , and you figure it out , and quickly upgrade it, rose no harm ! ! ! ! The key is to site users , exchanges, router port mapping is also careful. .
Disclaimer: purely technical discussion, in fact, I guess black circle know. . . Sent to run the risk of being accused of a two-way . . . You feel for it. .
OpenSSL Heartbleed vulnerability 11 April 2014What happened The version of OpenSSL used by Bitcoin Core software version 0.9.0 and earlier contains a bug that can reveal memory to a remote attacker. See for details. What you should do Immediately upgrade to Bitcoin Core version 0.9.1 which is linked against OpenSSL version 1.0.1g. If you use the official binaries, you can verify the version of OpenSSL being used from the Bitcoin Core GUI's Debug window (accessed from the Help menu). If you compiled Bitcoin Core yourself or use the Ubuntu PPA, update your system's OpenSSL. Linux users should also upgrade their system's version of OpenSSL. Android Android version 4.1.1 is vulnerable to Heartbleed. Try if you can upgrade to at least Android 4.1.2. If you are using Bitcoin Wallet on an Android phone, you should upgrade the app to at least version 3.45. How serious is the risk If you are using the Windows version of the Bitcoin Core GUI without a wallet passphrase, it is possible that your wallet could be compromised by clicking on a bitcoin:. Payment request link If you are using bitcoind (on Linux, OSX, or Windows) , have enabled the-rpcssl option, and allow RPC connections from the Internet, an attacker from a whitelisted (-allowip) IP address can very likely discover the rpcpassword and the last rpc request. It is possible (but unlikely) private keys could be sent to the attacker.
submitted by 51btc to Bitcoin [link] [comments]

Found 8 virus on chainstate

Hi: I m trying to use bitcoin in the safest way: I learned that the best thing I could do is running bitcoind and bitcoin-qt, as it is a full-node and outcoming transactions are safer because part of the process is done on my computer due to that huge folder (over 60 GB ) where blockchain is stored.
I choosed Linux as Operative System for bitcoind and bitcoin qt and well, the thing is that I found up to 8 virus on this location:
like for instance:
/home/use.bitcoin/chainstate/427915.ldb: Gen 981 FOUND
well, CLAMAV reports 8 viruses on these .ldb files contained on /home/use.bitcoin/chainstate/
GEN 981, Violetta-B, Gergana-222, Gen 100 Years 1, Phantom, Italian 1, Copyright.2, Syslock.2 are the names
Tried to find out if some other users where afected or how this could be solved, the only thing I found is a similar problem related with sst files on Windows users and some other reports but no forum discussion.
Would like to ask someone who would know about it what should I do next?.
of course I can erase them with
sudo clamscan -r --remove/home
but ... will I mess something on bitcoind, bitcoin-qt ?
What could I do?. I don´t feel like safe using this due to CLAMAV, but little do I understand about virus or malware, apart from scanning. So I m making this post to let the community know about it and in hope I could find a solution and/or explanation.
Kind Regards.
submitted by jantaroa to Bitcoin [link] [comments]

HOWTO: Run a Full Bitcoin Node + Armory

Estimated total time: Up to 2 hours, not including blockchain downloading.
You can install this on a VPS, a spare PC, or on your own PC. You can install it in Virtualbox on your own PC, or into Windows. If you just want to try it out, I recommend installing in Virtualbox.
  1. Download and install Virtualbox from (, and download an Ubuntu 14.04 64bit Desktop ISO from, and follow the guide here (I recommend 2GB of RAM, 3GB if you can spare it): . It's a little outdated but close enough that things are the same.  
  2. After installing Ubuntu in Virtualbox, to make it fullscreen you will need Guest Additions. Run these commands by clicking on the swirl icon top right, typing ter and opening Terminal: sudo apt-get install build-essentials module-assistant and then sudo m-a prepare Before selecting Devices > Insert Guest Additions CD image, telling Ubuntu to install them, and shutting down. //Thanks go to for those instructions.//  
  3. Next I went into the Virtual Machines settings and changed Network Adapter 1 to be "Attached to Bridged Network" instead of "Attached to NAT".  
  4. After booting the machine back up, I followed the steps here: And installed both bitcoin-qt and bitcoind. Skip over the parts where you edit bitcoin-qt's settings to start at boot, or edit cron to start bitcoind at boot, since this will interfere with using armory.  
  5. Next I followed the instructions here to install Armory: The reason I used these instructions was because I was having difficulty getting Armory to install (online or offline) on Ubuntu 14.04. Might just be me.  
  6. I then started up Armory in Offline Mode by clicking on the swirl icon top left and typing Armory. In the program, after clicking Skip, I scrolled down slightly, clicked on Download Bitcoin, Download, and agreed to let it do whatever it wanted to; (which was download and install Satoshi).  
  7. I then closed Armory Offline and opened Armory, which began downloading the blockchain from a torrent. I then went into File > Settings (top left of your screen, near the swirl; menu options will appear once the mouse hits that taskbar) and personally chose to Disable OS and version reporting. There is a setting here for "Enable settings for proxies/Tor" but I haven't ticked it yet, since I haven't set Tor up.  
  8. Follow the instructions here to set up port forwarding so your node is reachable, and to test this:  
If I want to broadcast transactions over Tor, but not receive incoming connections over Tor, is that a problem for the health of the Bitcoin Tor network? Or will those transactions be broadcast out to "clearnet" nodes, as opposed to hidden ones?
Thanks to all writers of articles referenced here for your help.
By the way, even if you don't want to run a bitcoin node full time, I've read that running one even 6 hours a day is useful. These are instructions for ubuntu but you can also run it from Windows on the same machine you work on (I don't know about privacy implications). Perhaps someone should write an article about running a bitcoin node on your PC at work!
submitted by FullNodeGuide to Bitcoin [link] [comments]

Facilitating Discussion of 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT)

To facilitate a detailed discussion of some of the finer points of this update, I added numbering to each bullet in release notes, and also posted it to RapGenius, where people can annotate it if they'd like.
I'm not a programmer, but I'm curious to hear what programmers and other people smarter than me have to say about all the new changes.
EDIT1 : Doh! Reddit detroyed all the formatting and now i'm on baby duty so can't fix it. EDIT 2: Nap time! Just fixed the formatting :)
---- 0.9.0 RELEASE NOTES ----
Part 1. RPC:
1.1 - New notion of 'conflicted' transactions, reported as confirmations: -1
1.2 - 'listreceivedbyaddress' now provides tx ids
1.3 - Add raw transaction hex to 'gettransaction' output
1.4 - Updated help and tests for 'getreceivedby(account|address)'
1.5 - In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility
1.6 - Add 'verifychain', to verify chain database at runtime
1.7 - Add 'dumpwallet' and 'importwallet' RPCs
1.8 - 'keypoolrefill' gains optional size parameter
1.9 - Add 'getbestblockhash', to return tip of best chain
1.10 - Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output
1.11 - Make RPC password resistant to timing attacks
1.12 - Clarify help messages and add examples
1.13 - Add 'getrawchangeaddress' call for raw transaction change destinations
1.14 - Reject insanely high fees by default in 'sendrawtransaction'
1.15 - Add RPC call 'decodescript' to decode a hex-encoded transaction script
1.16 - Make 'validateaddress' provide redeemScript
1.17 - Add 'getnetworkhashps' to get the calculated network hashrate
1.18 - New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output
1.19 - Adding new 'addrlocal' field to 'getpeerinfo' output
1.20 - Add verbose boolean to 'getrawmempool'
1.21 - Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
1.22 - Explicitly ensure that wallet is unlocked in importprivkey
1.23 - Add check for valid keys in importprivkey
Part 2. Command-line options:
2.1 - New option: -nospendzeroconfchange to never spend unconfirmed change outputs
2.2 - New option: -zapwallettxes to rebuild the wallet's transaction information
2.3 - Rename option '-tor' to '-onion' to better reflect what it does
2.4 - Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet)
2.5 - Update default '-rpcsslciphers' to include TLSv1.2
2.6 - make '-logtimestamps' default on and rework help-message
2.7 - RPC client option: '-rpcwait', to wait for server start
2.8 - Remove '-logtodebugger'
2.9 - Allow -noserver with bitcoind
Part 3. Block-chain handling and storage:
3.1 - Update leveldb to 1.15
3.2 - Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded)
3.3 - Allow txindex to be removed and add a reindex dialog
3.4 - Log aborted block database rebuilds
3.5 - Store orphan blocks in serialized form, to save memory
3.6 - Limit the number of orphan blocks in memory to 750
3.7 - Fix non-standard disconnected transactions causing mempool orphans
3.8 - Add a new checkpoint at block 279,000
Part 4. Wallet:
4.1 - Bug fixes and new regression tests to correctly compute the balance of wallets containing double-spent (or mutated) transactions
4.2 - Store key creation time. Calculate whole-wallet birthday
4.3 - Optimize rescan to skip blocks prior to birthday
4.4 - Let user select wallet file with -wallet=foo.dat
4.5 - Consider generated coins mature at 101 instead of 120 blocks
4.6 - Improve wallet load time
4.7 - Don't count txins for priority to encourage sweeping
4.8 - Don't create empty transactions when reading a corrupted wallet
4.9 - Fix rescan to start from beginning after importprivkey
4.10 - Only create signatures with low S values
Part 5. Mining:
5.1 - Increase default -blockmaxsize/prioritysize to 750K/50K
5.2 - 'getblocktemplate' does not require a key to create a block template
5.3 - Mining code fee policy now matches relay fee policy
Part 6. Protocol and network:
6.1 - Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
6.2 - Send tx relay flag with version
6.3 - New 'reject' P2P message (BIP 0061, see for draft)
6.4 - Dump addresses every 15 minutes instead of 10 seconds
6.5 - Relay OP_RETURN data TxOut as standard transaction type
6.6 - Remove CENT-output free transaction rule when relaying
6.7 - Lower maximum size for free transaction creation
6.8 - Send multiple inv messages if mempool.size > MAX_INV_SZ
6.10 - Do not treat fFromMe transaction differently when broadcasting
6.11 - Process received messages one at a time without sleeping between messages
6.12 - Improve logging of failed connections
6.13 - Bump protocol version to 70002
6.14 - Add some additional logging to give extra network insight
6.15 - Added new DNS seed from
Part 7. Validation:
7.1 - Log reason for non-standard transaction rejection
7.2 - Prune provably-unspendable outputs, and adapt consistency check for it
7.3 - Detect any sufficiently long fork and add a warning
7.4 - Call the -alertnotify script when we see a long or invalid fork
7.5 - Fix multi-block reorg transaction resurrection
7.6 - Reject non-canonically-encoded serialization sizes
7.7 - Reject dust amounts during validation
7.8 - Accept nLockTime transactions that finalize in the next block
Part 8. Build system:
8.1 - Switch to autotools-based build system
8.2 - Build without wallet by passing --disable-wallet to configure, this removes the BerkeleyDB dependency
8.3 - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more recent versions
8.4 - Windows 64-bit build support
8.5 - Solaris compatibility fixes
8.6 - Check integrity of gitian input source tarballs
8.7 - Enable full GCC Stack-smashing protection for all OSes
Part 9. GUI:
9.1 - Switch to Qt 5.2.0 for Windows build
9.2 - Add payment request (BIP 0070) support
9.3 - Improve options dialog
9.4 - Show transaction fee in new send confirmation dialog
9.5 - Add total balance in overview page
9.6 - Allow user to choose data directory on first start, when data directory ismissing, or when the -choosedatadir option is passed
9.7 - Save and restore window positions
9.8 - Add vout index to transaction id in transactions details dialog
9.9 - Add network traffic graph in debug window
9.10 - Add open URI dialog
9.11 - Add Coin Control Features
9.12 - Improve receive coins workflow: make the 'Receive' tab into a form to request payments, and move historical address list functionality to File menu
9.13 - Rebrand to Bitcoin Core
9.14 - Move initialization/shutdown to a thread. This prevents "Not responding" messages during startup. Also show a window during shutdown
9.15 - Don't regenerate autostart link on every client startup
9.16 - Show and store message of normal bitcoin:URI
9.17 - Fix richtext detection hang issue on very old Qt versions
9.18 - OS X: Make use of the 10.8+ user notification center to display Growl-like notifications
9.19 - OS X: Added NSHighResolutionCapable flag to Info.plist for better font rendering on Retina displays
9.20 - OS X: Fix bitcoin-qt startup crash when clicking dock icon
9.21 - Linux: Fix Gnome bitcoin: URI handler
Part 10. Miscellaneous:
10.1 - Add Linux script (contrib/qos/ to limit outgoing bandwidth
10.2 - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC
10.3 - Add '' script to contrib, for creating bootstrap.dat
10.4 - Add separate bitcoin-cli client
submitted by WhiteyFisk to Bitcoin [link] [comments]

How to install a Bitcoin Wallet How to run Bitcoin-qt as a server with a configuration file (3 of 6) Installing Bitcoin-QT [Streamed] - Compiling a Bitcoin Wallet for Windows - YouTube how to mine for bitcoin core

Windows 10; Stöbern. c't. Praxis & Tipps. Tipps & Tricks. Speicherort der Bitcoin-Blockchain ändern voriger Artikel; c't 01/2014, S. 148; nächster Artikel; Speicherort der Bitcoin-Blockchain ... 1. Install Bitcoin-Qt Since version 0.9, Bitcoin-Qt was renamed to Bitcoin Core t o reduce confusion between Bitcoin-the-network and Bitcoin-the-software. Bitcoin Core is a full Bitcoin client. It is a thick client, meaning it requires the full blockchain (explained below) on local disk to operate and expose blockchain back to the network to help relay and verify transactions. WINDOWS BUILD NOTES. Below are some notes on how to build Bitcoin Core for Windows. The options known to work for building Bitcoin Core on Windows are: On Linux, using the Mingw-w64 cross compiler tool chain. Ubuntu Bionic 18.04 is required and is the platform used to build the Bitcoin Core Windows release binaries. Bitcoin-Qt is the so – called" official " client of the network, which is developed and promoted by Bitcoin Foundation, a non-profit organization uniting core developers and responsible for the community's contacts with corporations and governments.Bitcoin Foundation branches are opened in several dozens of countries around the world. Recommended: Identify bitcoin-qt.exe related errors Important: Some malware camouflages itself as bitcoin-qt.exe, particularly when located in the C:\Windows or C:\Windows\System32 folder. Therefore, you should check the bitcoin-qt.exe process on your PC to see if it is a threat. We recommend Security Task Manager for verifying your computer's security.

[index] [25057] [49882] [2316] [24684] [21032] [38818] [7459] [9649] [41349] [47626]

How to install a Bitcoin Wallet

Make some extra $$ lending: Signup for DavorCoin: OR Signup for Bitconnect: This is a short video on setting up, ... Episode 1 : Bitcoin Series In this video I teach you how to install a digital wallet to contain your Bitcoins. I also teach you how to utilize the Bitcoin Faucet to get your first free coin. How to run Bitcoin-qt as a server with a configuration file (3 of 6) We cover chapter 3 of Andreas Antonopoulos' book Mastering Bitcoin. Featured are examples of bitcoin-cli commands, and simple Python scripts to interact with the bitcoin blockchain. Referenced links: How to install Armory 0.93 and Bitcoin Core 0.10 on Windows 7, and how to create your first wallet. A guide for beginners. Enable subtitles in the video. If you like the guide, feel free to send a ...