bitcoin core - How exactly does -rescan work? - Bitcoin

How-to: setup your multisignature Cold wallet in Bitcoin Core 0.20 (highest security setup)

Last release of Core is amazing !
The main new feature is sortedmulti descriptor. This allows you to import your multisig setup in Core almost as if it was Electrum when combine to the new PSBT export in GUI !
As it needs command line and some weird checksum, you also need to input very long command in the console and if you made a mistake, you cannot copy the last command you made. So take your time when the commands are long to check everything and don't miss anything, use copy paste before validating the long command. You only have to do this once fortunately :)
I detail here how you do it with a k of n setup, good luck:
And you are DONE ! You should get the exact same addresses than Electrum and you can created receiving addresses in Qt ! To send money, just go to the send section, use the new coin control feature and export a partially signed transaction. You can use HWI or Electrum to sign it with your hardware wallets !
Notice: You can import more or less than 2000 addresses of each type. If less, blockchain rescan is faster but you may need to redo what we have done here later when all addresses will have been used once. If more, it is the contrary.

You now have the most possibly secure setup in one software: multisig with hardware on the full node wallet. When Bitcoin Core 0.21.0 will be out, we will also have native descriptor wallet so maybe we will have HD version of this. But for now, this is the best you can do ! Enjoy :)

P.S. : if you like doing things in one shot you can do the last two steps in one big command: importmulti '[{"desc": "wsh(sortedmulti(k,[path1]xpub1.../0/*,[path2]xpub2.../0/*,...,[pathn]xpubn/0/*))#check_sum0", "timestamp": birth_timestamp, "range": [0,2000], "watchonly": true, "keypool": true}, {"desc": "wsh(sortedmulti(k,[path1]xpub1.../1/*,[path2]xpub2.../1/*,...,[pathn]xpubn/1/*))#check_sum1", "timestamp": birth_timestamp, "range": [0,2000], "watchonly": true, "internal": true}]'
submitted by Pantamis to Bitcoin [link] [comments]

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

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.
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), run the dmg and drag Groestlcoin Core to Applications.

Other Linux


Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).





ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\ 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [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]

Can I reuse part of the blockchain for Bitcoin forks?

Hello dear friends,
I am trying to claim coins from a few Bitcoin forks.
I was wondering if there is a way to avoid having to download 9 1/2 years of blockchain each time the wallet of the forked coin needs syncing.
Suppose I download the blockchain with Bitcoin core QT wallet up to August 2017 and then make a copy of the Bitcoin data directory, can I reuse that data to force a forked coin wallet to just reindex/rescan and download ONLY from August 2017?
If so, do I need to delete any coin-specific files each time?
If this feasible? If not, what is your recommended way to deal with syncing forked coin wallets if not by using the blockchain time and time again as fast as possible if an Electrum-like wallet is not available?
Many thanks for your help and patience.
submitted by fabioganga to Bitcoin [link] [comments]

I recovered my lost Bitcoins!

Just thought I would give an update to this post. It’s related to the issue of change going to a different address that has been in contention lately, so figured it was relevant.
I managed to get my coins back today, and wow it feels good!
The cause of the missing coins was because I was making payments from the same wallet on two computers while they were syncing with the block chain. For whatever reason, a change address for a transaction went missing. I had tried many times to load different wallets and rescan the blockchain again and again and never had any luck. In the end I had a mess of different wallet files, 16 in total, none of which included the relevant address when loaded in Bitcoin-qt.
Well after the price went over $100 I figured I would have another crack at it and took a different approach to see if I could recover the coins.
I installed pywallet and did a dump of each wallet file that I had. I have never deleted a wallet file and this is what saved me.
I searched the dumped wallet files and in one of the files I found the address I was looking for! I assumed I must have missed this wallet so I loaded up Bitcoin with the relevant wallet and let it sync….
I was disappointed; the transactions as they loaded did not contain the change I had expected. But I had seen it in the dump of the wallet.dat it must be there!
I ran the following command within the Bitcoin console after unlocking the wallet.
My heart skipped a beat, it returned a key!
I then imported this key to a wallet using the import feature and my balance adjusted! I had recovered my missing Bitcoins! I then transferred them to my new secure wallet and the transaction confirmed, happiest day of my life.
Here are some things I have learned that should probably be common knowledge for anyone using Bitcoin.
Keep your Bitcoins safe everyone! Tips: 1LJtAE6FVa2u7oy6ENnpYorhnrwyymt6UL
Edit: formatting.
submitted by Beast_Man to Bitcoin [link] [comments]

Lore v2 QT on Raspberry Pi

To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (, I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
These instructions assume you are starting from scratch with a completely blank OS.
Download Jessie with Pixel from:
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window and type:
sudo nano /etc/dphys-swapfile 
and Change the CONF_SWAPSIZE from 100 to:
Exit nano with control + x to write out the file.
Then, run the following to restart the swapfile manager:
sudo /etc/init.d/dphys-swapfile stop sudo /etc/init.d/dphys-swapfile start 
Now, launch the browser and download the Lore 2.12 binaries for ARM here:!k2InxZhb!iaLhUPreA7LZqZ-Az-0StRBUshSJ82XjldPsvhGBBH4 (Version with fee fix from 6 September 2017)
(If you prefer to compile it yourself instead, it is possible by following the instructions in the original article by Mindphuk just taking into account this is the newer version of the Lore client than when that was written ( and the versions of Boost and the Berkeley DB need to be the same as below.)
Double click the zip and extract the Lore binary files. Yes, at the moment they are all called 'bitcoin', not 'blackcoin' or 'Lore' - this is because the code derives from a recent bitcoin core implementation so this has not yet been updated. You can place these wherever you like.
In the Terminal window, change directory to where you put the binaries, e.g.:
cd Downloads/lore-raspberrypi-armv7-jessie-pixel chmod +x * 
That marks the binaries as executable.
Now, we need the Boost libraries installed for any of the Lore binaries to work. The project was done with Boost 1.62.0. Unfortunately the Jessie repository only goes up to 1.55, so we need to download and build 1.62 manually on the device.
wget tar -xvzf download cd boost_1_62_0 sudo ./ sudo ./b2 install 
(This will take almost 2 hours. Have a nice cup of tea and a sit down.)
When I came to run the binaries, I found they couldn't find Boost. Running this command fixes that:
sudo ldconfig 
Now we are going to install the packages which aren't already included in the default OS installation which the binaries need in order to run:
sudo apt-get install qrencode libprotobuf-dev libevent-pthreads-2.0-5 
Now we need to install the Berkeley Database version 6.2.23. This is the version Lore v2 uses. Bitcoin still uses 4.8 which is 10 years old! This doesn't take too long.
wget tar -xvzf db-6.2.23.tar.gz cd db-6.2.23/build_unix ../dist/configure --prefix=/usr --enable-compat185 --enable-dbm --disable-static --enable-cxx 
I find this next section of the Berkeley instructions worked better just switching to root, which can be fudged by running sudo su before the rest:
sudo su make make docdir=/usshare/doc/db-6.2.23 install chown -v -R root:root /usbin/db_* /usinclude/db{,_185,_cxx}.h /uslib/libdb*.{so,la} /usshare/doc/db-6.2.23 
Now we're going to go up a couple of directories to where the binaries were:
cd ../.. 
Then run the client!
And there you have it. Should hopefully end up looking a bit like this:
Using the Bootstrap can save a while syncing. Download it at:
Place the bootstrap.dat file into the ~/.lore directory.
Run ./bitcoin-qt again, it will say 'Importing Blocks' rather than 'Synchronising with Network'. My pi sync'ed fully in about 5-6 hours.
If you want peace of mind that Lore will always start on bootup into the Jessie w/Pixel desktop (i.e. after a power cycle), then you need to create a .desktop file in the following place.
sudo nano ~/.config/autostart/Lore.desktop 
And in it, enter the following (tailoring the Exec line below to the whereabouts of your bitcoin-qt file):
[Desktop Entry] Name=Blackcoin Lore Comment=Mining without the waste Exec=/home/pi/Downloads/lore-raspberrypi-armv7-jessie-pixel/bitcoin-qt Type=Application Encoding=UTF-8 Terminal=false Categories=None; 
Power usage and payback time
After a good while leaving it going by itself, the CPU load averages got down to almost zero, all of the time. Idling, the Pi uses a bit less than 3 watts. This means it would take two weeks to use one 1Kw/h of electricity.
If you pay e.g. 12.5 cents a unit, that's what you'd expect this to cost to run in a fortnight. That's around $0.25 a month or $3 a year. Green and cheap and helping to secure the BLK network. I paid for the year's worth of electricity in 2 days staking with 25k BLK. Makes mining look silly, huh? ;)
Securing your Pi
With staking, your wallet needs to be unlocked and as such, the keys to your wallet are on the device. In a clean and newly installed environment as described above, and if you don't allow others to use your device and there is no other software or nasties running on it, there is no real cause for concern. However, there are some basic security precautions you can take.
Firstly, if you have enabled SSH and are playing with your pi across your LAN (or worse, the Internet), you should immediately change the password for the default 'pi' user (which is preconfigured to be 'raspberry'). Simply log in as normal, then type:
You'll be prompted to enter the old and the new passwords.
Security by default
Your Pi is likely, by default, to not be exposed to incoming connections from the outside world because your router is likely generating a private address range for your LAN (192.168.x.x or 10.0.x.x or 172.x.x.x) which means all incoming connections are effectively blocked at the router anyway unless you set up a 'port forward' record to allow packets arriving on certain ports to be forwarded to a specific internal IP address.
As for accessing your Pi across the internet, if you have set up a port forward, this likely has security ramifications. Even basic old fashioned protocols have proven in recent times to have uncaught flaws, so it's always advisable to lock down your device as much as possible, and even if you only plan to access the Pi over your LAN, install a firewall to configure this. I used one called ufw, because it's literally an uncomplicated firewall.
sudo apt-get install ufw sudo ufw allow from to any port 22 sudo ufw --force enable 
This allows just port 22 (SSH) to be open on the Pi to any device on my LAN's subnet (192.168.0.x). You can change the above to a single IP address if paranoid, or add several lines, if you want to lock it down to your LAN and a specific external static IP address (e.g. a VPN service you use). To find out what subnet your router uses, just type:
and you'll see on the interface you are using (either hard wired or wifi) the 192.168 or 10. or 172. prefix. Change the above rule so it matches the first two octets correctly (e.g. if you're on a 10.0. address).
You may already use VNC to access your Pi's desktop across your LAN, this uses port 5900. Add a line like above to lock it down to an internal address. It's not a good idea to expose this port to the wider world because those connections are not encrypted and potentially could be subjected to a MITM attack.
You can query the status of the firewall like this:
ufw status 
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options:
Back up & Recovery
There are again many ways to tackle this so I'll just speak about my basic precautions in this regard. Don't take it as a be-all-and-end-all!
The wallet.dat file is the key file (literally) containing all the private/public keys and transactions. This can be found in:
You can navigate there using Jessie w/Pixel's own file manager or in a terminal window (cd ~/.lore). You can copy this file or, if you'd rather keep a plain text file of all your public and private keys, use the 'dumpwallet' command in the console. In Lore, go to Help > Debug Window > Console and type 'dumpwallet myfilename' where myfilename is the file you want it to spit out with all your keys in it. This file will end up in the same place you launch bitcoin-qt from.
The instructions earlier on, when running Lore for the first time intentionally left out encrypting your wallet.dat file because in order for the wallet to stake upon startup, it needs to have a decrypted key already. This isn't perfect, but after a power cycle, it would never stake unless you left it decrypted. So the best practice here is as soon as the wallet.dat file has left your device, i.e. you copy it to a USB stick for example, put it in an encrypted folder or drive (or both).
In Windows, one way is to use Bitlocker drive encryption for the entire drive. You should follow the instructions here to encrypt your flash drive before your wallet.dat is on there, and don't forget the password!!
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself:   There are almost certainly free packages with similar functionality, I have just used that one for years.
Either way, if you want to just make sure your USB drive is encrypted, you can do so in one-click in Finder before you put the sensitive files on it:
Note that these disk encryption methods may mean having to access the USB stick on a PC or Mac in order to retrieve the files in the event of a disaster. Be aware this may mean exposing them to more security issues if your computer is in any way compromised or someone nefarious has access to your computer. There are more 'manual' ways of backing up and recovering, such as literally writing down private/public key pairs which this guide doesn't go into, but may suit you better if paranoid about your setup.
The wallet.dat file has everything in it you need to recover your wallet, or if you used 'dumpwallet', the file you saved out has all the keys.
Wallet.dat method: Install Lore as normal then replace any auto-generated wallet.dat in ~/.lore directory with your backup. If a lot of time has elapsed and many transactions have occurred since your backup, launch lore with:
./bitcoin-qt -rescan 
And if that doesn't do the job, do a full reindex of the blockchain:
./bitcoin-qt -reindex 
If you used the dumpwallet command, install Lore then place the file containing all the keys that you saved out in the same directory as bitcoin-qt. In Lore, go to Help > Debug Window > Console and type 'importwallet myfilename' where myfilename is that file containing all the keys. The wallet should automatically rescan for transactions at that point and you should be good to go.
There are a million ways to do effective security and disaster recovery, but I hope this shows you a couple of basic precautionary ways. There are discussions about better ways to stake without compromising too much security which are happening all the time and developments in this regard will happen in time.
In the meantime, feel free to comment with your best practices.
submitted by patcrypt to blackcoin [link] [comments]

bitcoin-qt ready for use within half an hour … download an up-to-date pruned blockchain

Let us discuss how safe this is :-)
This tutorial is for Linux only but people using other operating systems will understand what to do.
Download the bitcoin blockchain
This will download (~20 minutes) the 2485 MB file:
It contains only blocks, no wallet or log files. It has been created with -prune=550
tar -zxvf bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz
and observe it contains only blocks and chain state data. This will create the directory:
Let’s assume you move this to ~/.bitcoin_pruned, so
mv .bitcoin_pruned_550MB_19aug2016 ~/.bitcoin_pruned
Run bitcoin-qt
When you start bitcoin-qt, a new wallet will be created: back it up first. My advice is to use bitcoin-qt 0.13.0rc3, because it creates a HD wallet that never runs out of addresses.
Start bitcoin-qt in fast start-up mode first:
bitcoin-qt –prune=550 –checklevel=2 –checkblocks=10 –checkblocksverify=10 –datadir=yourpath/.bitcoin_pruned
and let it sync quickly. Check more thoroughly next time with 10 -> 500000.
You can have a quick look at what’s happening:
tail ~/.bitcoin_pruned/debug.log.
FOR NOW, the drawback is that if you want to add addresses (watch-only or spendable) that already contain bitcoins, you have to create the pruned blockchain from scratch yourself, which takes a lot of time (or have someone with a full blockchain rescan the wallet for you). This is not really necessary: if the user is not interested in the history of his transactions, the balances can be obtained directly from the UTXO set. It has already been approved to add this feature in some future Core release:, #8497.
I will automatically update the google drive with new up-to-date blockchains soon.
openssl dgst -sha256 bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz SHA256(bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz)= ce36bcb9ab691c358b27d3051f8f38452bc182ca636eae992563c60805a9d4b0
submitted by sumBTC to Bitcoin [link] [comments]

Unconfirmed Bitcoin Transaction

Hey everyone, I'm new to reddit so I'm not sure if this is the correct place to ask my question...but it is related to an unconfirmed Bitcoin transaction.
Details- On December 29th, ~11 PM (Eastern Standard Time), I sent ~.5 bitcoins FROM my desktop wallet (Bitcoin Knots) TO my account on Binance (exchange).
When I view my TRANSACTIONS page in my Bitcoin Knots wallet, I see the following information -
Status: 0/unconfirmed, in memory pool Date: 12/29/2017 23:07 To: Binance 19x7XhTaLRWuBZsLfkHRP8yhQPk7q8MAqu Debit: -0.50129628 BTC Transaction fee: -0.00049177 BTC Net amount: -0.50178805 BTC Transaction ID: bb61c6f8a686f21f5679562586056a6b7c28e4427ee2f2db5d9549a59e7615c3 Transaction total size: 782 bytes Output index: 0
Here is the BlockChain information related to this transaction -
And here is the Block Explorer information related to this transaction -
As you can see, the RECEIVED TIME is different across all three (the wallet, the first website, and the second website).
Could anyone explain what might be going on and how to fix this?
Just an FYI...I already performed the -rescan option on my "bitcoin-qt.exe" file. It did some "update database file" or something like that (which was about 2 hours ago) but still no confirmed transaction.
Oh yeah, one more thing, on my TRANSACTIONS page in Bitcoin Knots, the "Cancel Transaction" and "Increase Transaction Fee" is disabled/greyed out when I 'right-click' the transaction record - so, I'm not sure what that indicates either.
Any help is much appreciated!
submitted by Butt0nSmash3r to Bitcoin [link] [comments]

opening an old wallet.dat

I had about $8 USD worth of bitcoin in a wallet, and I backed up the wallet.dat to my dropbox. According to the modified date of the file this was in April 2013, so it was probaby from bitcoin qt version 0.8.1, or maybe a little earlier.
I basically left it there and haven't done anything with bitcoin since then. Since it is worth probably at least $100 now I decided to check the exact amount.
I downloaded the latest version of bitcoin core, added the wallet.dat file to the data directory, started it with -rescan, and waited almost a month (!) for the blockchain data to get up to date. The balance showed as 0 the whole time. I thought it would update once the blockchain was totally downloaded, but it still just says 0.
Is this a problem with old vs new versions? Did I do something wrong? Next time, should I expect the balance to show a non-zero amount even if I haven't downloaded the whole blockchain yet?
Update: ok, I feel kind of dumb, turns out the transaction was made in a multibit wallet, not a bitcoin qt wallet, but I still have a copy of that too. I opened the wallet in the latest version of multibit classic, and it has the receiving address in question, and checking the address on I can see that it received the transaction... but the transaction and the balance both don't show in the program. I wonder if I need the same multibit version I had before? the transaction was made in feb 2014
Update 2: was able to use the private key to sweep the balance into electrum
submitted by valanbrown to Bitcoin [link] [comments]

Questions regarding wallet recovery

Been in the Bitcoin space since 2012, so I am a bit embarrassed to ask these questions.
I have a bunch of Bitcoin QT/core wallets ranging from 2013-2015 that I know for a fact have transactions histories on them. I am trying to look at potential funds on them (0.1BTC and whatnot left over on them). However, when I look at them, I find a 0 balance and no transaction history, even when the wallet.dat file is like 300-500kb when they are usually 80kb. All of my wallets would have been encrypted. My question is, would you see the balance/transaction history before decrypting the wallet? If so, can anyone think of a reason why I don't see anything in these wallets?
Which leads me to my next question, when I move these wallets, every time I restart Bitcoin Core it rescans the network. Is there any way/software that I can import multiple wallet.dat files to check all the wallets at once rather than waiting 1-2 hours between files for rescans.
Thank you all so much, and god bless Bitcoin!
submitted by btcwalletquestion to Bitcoin [link] [comments]

Sent BTC from wallet to another, both wallets empty

I wanted to move my bitcoins from Bitcoin QT to Electrum. I took electrum's address, sent it from QT and both wallets are empty. I had to do some critical system funcitons which was the impetus to this move. QT was 50% of my harddrive. I made the move, was too pressed for time to confirm the transaction, and deleted bitcoin folder.
I made a backup of the wallet just in case. A few days later, I noticed the funds never made it to electrum. Loaded the backup on QT just to be sure, and QT is empty as well.
Are the bitcoins gone or can I investigate this further? It was .91 BTC.
edit: Resolved! For anyone who may be having the same issue and searches for this.. There was a lot of good info but litecoin-p2pool pointed out that due to a datadir command I performed to mvoe the directory from C:\ to d:\, I inadvertently created a new wallet. Bringing the original wallet back to d:\ performed a rescan which turned up the coins.
submitted by pawsforbear to BitcoinBeginners [link] [comments]

Re-sending a double-spent transaction?

So I recently found some bitcoin on a bitcoin-qt wallet that I hadn't used in a while. My plan was to send all of it to my coinbase account for now since I won't have access to this computer in a couple months. I first sent it using a stupidly low fee (something like 20 sat/byte) and it of course never got confirmed, so I abandoned the transaction using bitcoin-qt. I sent it again a couple days ago using a fee of about 400 sat/byte, but it still has 0 confirmations and suggests that I should really be using 630 sat/byte, at the time of this post at least.
The problem is that all of my transactions in bitcoin-qt were greyed out and I couldn't abandon the stuck one, so I ran the client again using -zapwallettxes, which cleared all of my transactions but now it says I have a balance of 0.00000000BTC!
Here is a link to the transaction. It mentions that it is a double-spent transaction, but I don't really care since I am trying to send all of the BTC from the wallet, so it can't exactly take more BTC than is actually there. I'm running a rescan of the blockchain right now but that obviously takes a while. Any tips on how to unstick this transaction?
submitted by Gabe_20 to Bitcoin [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]

[uncensored-r/Bitcoin] Unconfirmed Bitcoin Transaction

The following post by Butt0nSmash3r is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link: Bitcoin/comments/7nb1cu
The original post's content was as follows:
Hey everyone, I'm new to reddit so I'm not sure if this is the correct place to ask my question...but it is related to an unconfirmed Bitcoin transaction.
Details- On December 29th, ~11 PM (Eastern Standard Time), I sent ~.5 bitcoins FROM my desktop wallet (Bitcoin Knots) TO my account on Binance (exchange).
When I view my TRANSACTIONS page in my Bitcoin Knots wallet, I see the following information -
Status: 0/unconfirmed, in memory pool Date: 12/29/2017 23:07 To: Binance 19x7XhTaLRWuBZsLfkHRP8yhQPk7q8MAqu Debit: -0.50129628 BTC Transaction fee: -0.00049177 BTC Net amount: -0.50178805 BTC Transaction ID: bb61c6f8a686f21f5679562586056a6b7c28e4427ee2f2db5d9549a59e7615c3 Transaction total size: 782 bytes Output index: 0
Here is the BlockChain information related to this transaction -
And here is the Block Explorer information related to this transaction -
As you can see, the RECEIVED TIME is different across all three (the wallet, the first website, and the second website).
Could anyone explain what might be going on and how to fix this?
Just an FYI...I already performed the -rescan option on my "bitcoin-qt.exe" file. It did some "update database file" or something like that (which was about 2 hours ago) but still no confirmed transaction.
Oh yeah, one more thing, on my TRANSACTIONS page in Bitcoin Knots, the "Cancel Transaction" and "Increase Transaction Fee" is disabled/greyed out when I 'right-click' the transaction record - so, I'm not sure what that indicates either.
Any help is much appreciated!
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Bitcoin-QT index issues

I spent a ton of time today trying to get Bitcoin-Qt to sync using the bootstrap.dat file and could not get it to work. I found an answer on this forum saying to use: /Applications/ -rescan -reindex But it tells me that the folder does not exist. I just checked my library folder and there's no folder named Applications, all I can see is a folder named Application Support Please see this picture of my folder:
Also note that the language is in danish, but Bibliotek means Library. Am I doing something wrong?
submitted by smirkypigeon to Bitcoin [link] [comments]

State of the Redd-Nation :: May 23, 2016

Reddcoin Weekly Development Update

Welcome again Reddheads to another weekly update of Reddcoin Development.
This past week has achieved quite a few updates.

New v2.0 Wallet and testing progress

During this last week, I have been performing testing on the switch-over logic from v3 to v4 blocks on testnet using both the version 1.4.1 wallet and version wallet. Results have been better than expected and I am very happy with the progress so far.

Network Testing with Super-Majority

The recent testing with testnet was performed by setting the super-majority to 510/1000 blocks (51%). That is, when there have been 510 v4 blocks created in the last 1000 blocks, the rules for v4 blocks are enabled (Enforce DER Signatures). v3 blocks will then be rejected by the network.
On mainnet, the setting will be updated to be a Super-Majority 85%

Staking with different versions

Wallet Staking Block Ver Accepted by v1.4.1 Accepted by v2.0.0 Rejected by v2.0.0
Ver 1.4.1 YES v3 YES NO YES
Ver 2.0.0 YES v4 YES YES NO
SOME NOTES: After the switch of Super-Majority completes, version 1.4.1 nodes will continue to stake however, the network will reject those blocks. This is expected behaviour.

Transferring between versions

v1.4.1 v2.0.0
v1.4.1 YES YES
v2.0.0 YES YES
SOME NOTES Current testing of transferring coins between different wallet versions has been successful. Current indications are that if you are not staking, you will be able to continue to use v1.4.1 wallets. More testing to be done.
If you have any questions, or would like to know more on this, please let me know.


Translations continue to be updated which is great to see. Thank you to all those who are contributing their time and effort.
@Serkan34 continues to dominate on the European languages.
This is the running list of desired languages, and if you like you can also check the overall running list on transiflex here.

Wallet Recovery

As mentioned last week, wallet recover is no easy task. There are a few tools around on the net that can help, but it is no way guaranteed to provide 100% recovery.
So, it is important that you get in the habit of routinely backing up your wallet.dat file
For the second time in as many weeks, I have used the utility called pywallet that in my case has done a reasonable job to recover broken wallets. It is a python based tool that allows some low level manipulation of wallet files.
In this second case, it involved recovering the private keys from a testnet wallet (100K keys in total). The wallet.dat would load into Reddcoin-Qt, but then the application would sit spinning its wheels, without error, and no way to dump. Running the QT application with -salvage wallet would truncate the number of addresses that should have been available ion the wallet.
So, using the pywallet, I was able to load up read the available privatekeys in the wallet and dump the keys to a text file. This essentially was the same as last week. 100% of the privkeys were salvageable
I still have some problems importing those directly into a new wallet using the pywallet tool, and with such a large number of private keys, manual input was not an option.
I wrote a little script to pull the private keys from a text file and send a importprivatekey RPC command to the wallet. A little slower, but none the less it was effective and successful.
After starting the wallet with -rescan, it brought everything upto date with those associated addresses and their tx's into the wallet.

Large number of Micro Transactions on mainnet

Over the course of several weeks, there have been a number of instances where a large number of small transactions were broadcast onto the network.
It was brought up in a couple of forum messages on reddit and reddcointalk, so I thought it might be worthwhile just to touch on it again here.
Firstly, I would like to say, this is similar to reports that occurred on Bitcoin network where small transactions were sent to fill blocks. So I was interested to monitor just how such behaviours would occur on Reddcoins Mainnet and what the effects might be.
Reddcoin mainnet has in effect a 10x larger capacity that Bitcoin. The blocksize for Reddcoin is 1M, and the block generation time is targeted every minute (Bitcoin is 1M blocks every 10 minutes).
In the 'worst' case the maximum capacity that these transactions took on the network, was to occupy less than 25% of each block (about 230K in total)
With the number of transactions that were occurring, there were at times excesses of transactions that spilled over into subsequent blocks (again, only filling each of those to 25% capacity). When this occurred,e there were runs of up to 10-12 blocks that were filled.
In the current state of the network, where volume of transactions generally is low, it has been a good exercise to monitor the behaviour of sudden peak demand. I didnt hear of nay cases where normal transactions or staking were affected.
Thats is not to say, we are immune, If the normal operating capacity of a block was 50% or more, this would be more a concern and there could be an impact to the time of confirmation of a transaction.
Suffice to say, the current side effect is, a number of you may have a lot of small transactions sitting in your addresses. I would not be too concerned at this point, and would suggest to let the PoSV staking take care of those in due course (it will take a while to get selected due to the size), or in your next transfer, manually select a few to send them on their way.

Performance of PoSV

One of the things that has interested me for a long time with Reddcoin is how the POS mechanism behaves over time.
PoSV is unique amongst the POS crypto-currencies in the way that the weighting mechanism works, and in the way the stake reward is weighted depending on how long the coins have had to age.
A lot of things can influence the amount for each of your stake rewards,
Working with @deadpool, and @reddibrek, they have been trying to define it is simple to understand terms
But I am also studying the network in much greater detail in relation to a post on the ReddcoinTalk forum regarding PoSV v2.
This was the original statement made about 1 year ago, and I believe there is merit in re-visiting this PoSV v2 proposal. It provides and extra incentive to everyone who continues to stake, and in doing so get a bigger percentage of return.
So in my spare time I have been extracting information about the current network, the blockchain and the metrics of how it is functioning, what returns stakers currently get and whether this remains a viable option.

Getting involved

We are a global community, and cross many borders but boundaries do not need to hinder us.
The crypto currency world has not reached its tipping point yet, but when it does, it is sure to escalate at an amazing rate. There are going to be many ups and downs, and an interesting ride for sure.
If you would like to get involved and dont know where to start, reach out and we will see where you can jump in @Deadpool has a great Trello site going with activities that need looking at.

In Closing

There is still plenty to do, but we are getting closer and I look forward to another productive week.
So where ever you are, enjoy your week ahead
Keep on staking!
x-posted (
submitted by cryptognasher to reddCoin [link] [comments]

Lost 65BTC, looking for advice.

Around 5 months ago, my friend received 65BTC for services rendered. Recently he approached me to help him get his bitcoins because his btcoin-qt client kept crashing everytime he tried to open the application. I figured it would be about a two minute fix to run a rescan/resynchronize to to clean up a minor corruption.
After taking his wallet.dat I noticed the only address associated with it was 18nPHGz1B4Hrww7wn5qwj8we6s9WL1hL74, not the address he received payment on. I tried to gather the timeline of events as best I could to figure out where he even got 1HG6A4fCnVEKR25T9GgVxH9vVyTv5eLn87. From what i can recreate, at some point in time, he opened his bitcoin-qt client and copy and pasted his address that was displayed and sometime shortly after bitcoin-qt crashed and never could be reopened. Fastforward to where we are today.
I assumed somehow his wallet.dat was deleted, overwritten, or something. He's on a 60G @ /dev/disk0 mac book air, solid state, but since it has been 5 months since the transaction, the chances of recovering this private key seems very slim.
I attempted to recover using pywallet, and it wasn't able to recover any full wallets, but it did leave a recovered_wallet.dat with some data, but when looking at the hex, nothing seems relevant to a private key. (from what i gathered i should be looking for)
I also tried using photorec with no success.
I have not tried because i wasn't sure how to build the binary for a mac os machine.
Is it time to give up?
submitted by rromanchuk to Bitcoin [link] [comments]

Don't make the same mistakes I made

I first got "into" bitcoin about 2 years ago when bitcoin was about $5-10 each. I started mining with my gpu on slush's pool and got to 1 bitcoin and had it sent to my wallet. I then raised the threshold to 10 bitcoins, but I only got to 2.88 bitcoins before I lost my interest because at the time (and even now) I don't have a lot of money and couldn't afford to replace my gpu if it died an early life from being ran at 100% for so long, especially with bitcoins being as cheap as they were.
So here's where I made my 3 essential mistakes:
1: I didn't pay attention to what I was doing
2: I left bitcoins in the mining pool account
3: I didn't continue mining
I got a new larger SSD and backed up some stuff onto an external and wiped the old one for a fresh install of windows. I didn't realize that I didn't make sure to back up my wallet until months later, but by that time I didn't really care too much. I did backup my entire windows profile though (I'm sure you see where this is going). So I spent the last year and a half thinking that bitcoin was gone as I watched the price of bitcoin climb, climb, and climb some more, getting a little more upset at each hurdle, but still thinking "well at least I still have that 2.88 bitcoins"
So then I fast forward to about a week or so ago when bitcoin flew past 700+. I think "oh I should log into slush's pool" and what do I find when I log in? an empty balance. Somehow someone took my coins! Now that was really devastating, but I only have myself to blame for not making sure I transferred those funds to my own wallet.
But tonight I had a spark of dumb genius luck. I tried doing data recovery on my old SSD with low hopes since that computer has been in use for so long, the data has likely been overwritten. Obviously I found nothing. I give up and lie down in bed, but I can't sleep still. So I get up and plug my external in and start searching, and what else do I find but a bitcoin folder in my appdata folder, and what's this? it contains a bitcoin.dat! All this time I assumed that the bitcoin.dat was contained in the program files directory, not appdata! So first thing I do is backup my current wallet.dat, and put this one in its place and rescan with bitcoin-qt. After scanning, the program opens and my first 1BTC is sitting right before my eyes, back in my possession after all this time.
It's kindof a bittersweet ending, because yeah, I still am out 2.88BTC, and the full amount could have paid for half of the debt I'm in, and I'm sure if I waited out longer, I could have paid it all off in full which would have been great because all the money going towards bills could be put back into investing in bitcoin. But not all is lost, and I'm definitely being more careful from here on out.
submitted by WolfDemon to Bitcoin [link] [comments]

Wallet problem: 0/unconfirmed

I have a Problem with my wallet (bitcoin-qt).
  1. I tried to send 0.1 BTC to CoinEx some hours ago, but still they don’t arrive. Transaction: "c13ec3bd34cec50ba13a2891fc03a8a96ba765ca6e99d8b2eb74b8db8b962b36". Ok, I can see them on the blockchain but they are not confirmed. A friend told me it is because I send no fees with it.
  2. After that I decided to send again 0.1 BTC to CoinEx because I need them there now, but this time with a fee of 0.0005 BTC. Now I have an other problem…, when I look for the transaction “a9180ed3d44169e263051828da3e7aba4ff198ca81196148f746c85d7a342fac”, it doesn’t even show up on the blockchain..., what can I do now?, even started the wallet with the “rescan” command.
Here is my wallet:
Greetings, Cédric
Edit: Problem 1 has been resolved by time, still problem 2 exists... :(
Edit2: Problem 2 has been resolved by time, don't know what happend now..., they just showed up hours later... :)
submitted by MorbidArchangel to Bitcoin [link] [comments]

[HELP] bitcoin-qt.exe has stopped working

Hi guys, I'm fairly new to Bitcoins and I'm already scared that I've lost my wallet.
I used bitcoin-qt.exe to create a new one, let it sync, then transferred some funds over to it. Since then, every time I try to run it, it just crashes instantly. I'm running Windows 8.1 and neither the 32-bit nor 64-bit versions of bitcoin-qt work at all.
If I debug with Visual Studio 2012: it displays the following error:
Unhandled exception at 0x00B906CA in bitcoin-qt.exe: 0xC0000005: Access violation reading location 0x00000004.
I tried using Bitcoin Armory and that won't work either.
Is there any alternative Bitcoin client or some method I can use to recover my wallet and its bitcoins? I am desperate for help.
Thank you so much.
Apparently version 0.9.3 works fine. I'm going to see if I can recover my wallet with this version.
I uninstalled absolutely everything related to Bitcoin, deleted everything except my wallet, torrented bootstrap.dat, installed Bitcoin 0.10.0, and it works now, but it won't seem to recognize my wallet backup, even running with -rescan. I'll try some more. Thanks for the help though, you guys.
submitted by Huskehn to Bitcoin [link] [comments]

PSA: Added Step May Be Needed When Restoring a Backup Encrypted wallet.dat to Bitcoin Core

TL;DR: To successfully restore an encrypted wallet.dat file, the instance of Bitcoin Core getting restored to needs to first have Encryption turned on and possibly the same Passphrase set as the wallet.dat file you are restoring. It seems this must be done before you restore your encrypted wallet.dat from backup, or Bitcoin Core will just show a zero balance.
For the record, the set-up for this situation was as follows: Bitcoin Core (formerly Bitcoin-Qt), Windows x86 version, on Windows XP Pro patched for 2019 PoS updates.
Recently, my Bitcoin Core hot wallet had been acting up and crashing after about 6 to 12 hours of uptime. I thought that there was possibly some corruption in Core's database files, so I backed up my wallet.dat and started deleting block chain data/index files to see if a rescan or reindex would correct the problem. I tried to save time by not deleting everything, only certain file types. I managed to somehow screw up and got the dreaded "wallet.dat corrupt, salvage failed" message.
Since I had a backup, I didn't bother trying the "-salvagewallet" command-line option (which might have actually corrected my problem.) Instead, I went straight for a restore from backup.
Some time ago, and on a much older version of Bitcoin-Qt I had familiarized myself with the wallet.dat backup and restore process. I never had a problem with it. But thinking back, I may have done all of my testing with unencrypted wallet.dat files.
In this case, I uninstalled Core, deleted everything in the Bitcoin data directory, reinstalled Core, used bootstrap.dat to catch up as much of the block chain as possible, and let the new install finish syncing from the Internet. Once Core was up-to-date, I closed it and restored my encrypted wallet.dat from backup.
In my previous experience, I'd be done at this point. The next time I started the wallet, it would have automatically rescanned, and I'd be back in business. This time, when the wallet finally started up again, it showed no errors, the block chain was still fully synced up, but the wallet showed a zero balance. Not a good feeling.
I thought maybe I'd need to manually start Core using the "-rescan" command-line option. I tried this, but got the same result.
After mulling things over, I finally guessed that the problem might have something to do with Core's wallet.dat encryption.
I again deleted the wallet.dat file from the Bitcoin data directory and restarted Core. Once it finished generating a new wallet.dat file, I enabled Encryption and set the same Passphrase as the wallet.dat file I was trying to restore. Core shut itself down to complete encrypting the new wallet.dat file. Next, I started Core once again to make sure all was OK with new encrypted but empty wallet.dat. I then closed Core and replaced the zero-balance wallet.dat file with my recent backup. That finally did the trick. On the next start, Core automatically did a rescan and my balance reappeared.
I don't know for sure if this behavior is the same across all the different flavors of Bitcoin Core (x64, OSX, Linux), but I suspect it might be. Also, it might work just to enable Encryption, but it might not be necessary to have the same Passphrase. I can only confirm that it worked in my case with the same Passphrase.
This little adventure was unnerving, particularly since Core issues no errors and just insists there's a zero balance. I thought I should relate what I learned in case someone else encounters the same situation.
Cheers, and to the moon!
EDIT: At least a couple posts so far report not seeing the same behavior I did. I'm glad if it's a non-issue, and I can't explain why it happened to me. I can just suggest if you have similar issues, it might be worth it to give this method a try.
submitted by chinawat to Bitcoin [link] [comments]

Switching from Bitcoin-QT

So after seeing THIS post this morning I opened up my QT client and had quite a startle. I was BitBroke! I quickly checked my transaction log to see if I was one of the victims of the Bitcoin-QT hack. As it turns out my wallet says I never was BitRitch to begin with. (my wallet showed NO addresses at all!!)
Que the panic.... Was I hacked? Was I robbed?
As it turns out at 2.35am on Dec 27 my wallet was created. Now the holidays were a bit blurry to me so I can't verify what exactly happened at that time so I said fuckit and went to my backup.
After multiple harrowing steps (renaming the backup wallet, running -rescan, crying) I was able to restore my wallet, I'm now in the process of synchronizing with the network. (I checked on blockchain, my BitLoot is still there in my wallet. WOOT!)
So the point of all this is multifaceted. 1) Don't holiday and compute at the same time. 2) make a backup 3) keep calm and mine on
I leave you all with a serious question; What is the best client and can i transfer the locally stored blockchain info from QT to another (say armory) ie. I don't want to wait for Armory to sync with the network when I already did that with Bitcoin-QT, can I just point another client at that 15.2GB folder and call it a day?
submitted by projkt4 to Bitcoin [link] [comments]

TIME IS RUNNING OUT - PART 2 WHAAAT?!!! AMAZON ALL-TIME-HIGH!!  BITCOIN BREAKOUT!!!!!!!! Bitcoin bears aanwezig???!!! How to bypass Bitcoin Faucet time limits [WORKING SEPT 2013] Communicate with Bitcoin-qt using C# - .NET (5 of 6)

The client won't download blocks while it's rescanning. And newly-downloaded blocks should update the wallet anyway. The logic is basically that this ensures the rescan process sees the blocks containing any missing transactions, rather than the regular block update logic. Would it be feasible to add a startup mode where rescanning and other optional work is skipped? I don't have a test environment handy at this point in time but I said it was not possible to jonasschnelli commented May 9, 2018. I just started Bitcoin-Qt (official 0.16 release) with --datadir=/tmp and called dumpwallet... seems to work Bitcoin Qt Rescan Bitcoin . Bitcoin Qt Rescan . Apr 8, 2018 DTN Staff. twitter. pinterest. google plus. facebook. Litecoin Wallet Location I was under the impression that the -rescan flag was no longer needed for some time now. Can someone document precisely, when does one need to run bitcoin-qt -rescan? How has this changed throughout the versions of bitcoin-qt? Problem: Bitcoin-QT crash when importing a private key. Bug report. Bitcoin-QT version 0.8.1 Windows version: Windows 7 professional 32-bit Block-chain not downloaded completely - about 7K blocks left. Action that cause the issue: Help -...

[index] [168] [12442] [23457] [6231] [1484] [12049] [21473] [19969] [13948] [4626]


Bitcoin Technical Analysis & Bitcoin News Today: Amazon is at all-time highs and Bitcoin is on the verge of a breakout. I'll use technical analysis on the Bitcoin price to make a Bitcoin price ... bitcoin qt, bitcoin qr scanner, bitcoin que es, bitcoin quantum computer, ... BITCOIN UPDATE! price Update, Time Analysis, momentum analysis , Elliott Wave 6-23-2020 - Duration: 28:26. Basically the jist is you can get around the 30 minute/1 hour time limit of MOST bitcoin faucets. This is especially helpful for the idiots like me who didn't do anything about bitcoins when they ... You will need to use this code in Terminal to launch Bitcoin-Qt from now on. To launch terminal press cmd + spacebar, then search terminal. Following this guide will prune the blockchain on your ... Communicate with Bitcoin-qt using C# - .NET (5 of 6) Lars Holdgaard. ... Most Uncomfortable Celebrity Interviews of All Time - Duration: 20:22. BE AMAZED Recommended for you.

Flag Counter