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.
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:
(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 (https://github.com/janko33bd/bitcoin/releases) 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 https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.gz/download tar -xvzf download cd boost_1_62_0 sudo ./bootstrap.sh 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:
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:
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 192.168.0.0/16 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. 10.0.0.0/16 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:
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options: https://help.ubuntu.com/community/UFW
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).
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself: http://www.belightsoft.com/products/conceale There are almost certainly free packages with similar functionality, I have just used that one for years.
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:
And if that doesn't do the job, do a full reindex of the blockchain:
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.
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 https://drive.google.com/drive/folders/0B0nH34wIYOSlSG81ZUZUZGZjVkE?usp=sharing This will download (~20 minutes) the 2485 MB file: bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz It contains only blocks, no wallet or log files. It has been created with -prune=550 Unpack tar -zxvf bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz and observe it contains only blocks and chain state data. This will create the directory: .bitcoin_pruned_550MB_19aug2016 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: https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+is%3Aopen+label%3AWallet, #8497. I will automatically update the google drive with new up-to-date blockchains soon. EDIT: openssl dgst -sha256 bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz SHA256(bitcoin_blockchain_pruned_550MB_19aug2016.tar.gz)= ce36bcb9ab691c358b27d3051f8f38452bc182ca636eae992563c60805a9d4b0
Guide: How to redeem and sell bitcoin diamond (bcd) from ledger nano s (Segwit)
I spent two days to figure this out but I think I know how to solve this, just currently stuck and need your help! I had btc stored on a nano s segwit wallet before the fork. Bitcoin diamond was forked from bitcoin on block #495866 (nov 24 2017) and launched the mainnet Jan 5 2018 (I think). There is currently very little information about this project and very little support on exchanges, wallets and mining. http://btcd.io The only light wallet currently have a splitting tool is Bither for Android but they do not support Segwit. If you had your btc in a segwit wallet before the fork you can't use this method. Otherwise follow this: https://steemit.com/bitcoin/@tiberiu/how-i-claimed-sbtc-super-bitcoin-from-my-paper-wallet Or this: https://www.reddit.com/BitcoinMarkets/comments/7oekie/guide_how_to_redeem_and_sell_all_bitcoin_fork/ You get 10 bcd for every btc and current price is 0.001 btc. That means you get $160/ forked btc which is 1% free money. Is it worth it? For me it is. You can use same method for both SBTC and BCD. Other methods can be used for BTX, BCX and BFX but have to wait for me. Need segwit support in Coinomi and/or Bither. In my BCD case it was a bit more complicated but hopefully possible.
Enter your ledger 24 word mnemonic. Select BIP49 derivation path. Find your btc address that contained btc right before block 495866, copy private key. Use a block explorer: https://blockchain.info
Find the tx ID that sent those btc and verify in bcd explorer if you have any bcd before you continue (click on the actual address will not work for some reason, shows empty). My tx had 3000 confirmations. http://explorer.btcd.io
Actually quite cool you can run Ubuntu on Windows 10! You can build for 32 bit as well but not when you have installed dependencies for x64. The last step will copy the binaries to your windows folder: "make install DESTDIR=/mnt/c/workspace/bitcoindiamond"
Run bitcoindiamond-qt in windows and let it sync with network. Took me 12h with fiber connection.
Go to help and open console. If your wallet is encrypted, decrypt for 10min using: "walletpassphrase your-wallet-passphrase 600".
Import old btc address as watch-only to check bcd balance. True means it will rescan the blockchain. Rescan took 1h with a decent PC (no SSD):
If you see your BCD balance, now Import your btc private key into the watch-only address. No need to rescan again, thus "false".:
Ok here is where I'm stuck. I can see my balance but it's not spendable. I also tried to import private key directly (with sync) with empty core wallet but balance is still zero. It does not pick up the transaction! Anyone know how to solve this? Rest of the guide when this is solved:
You should now be able to access your bcd!
Go to gate.io (register). Deposit bcd to exchange from bitcoindiamond-qt. Try small amount first, use a proper fee.
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:
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 blockchain. 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 it. 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
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? NOPE. 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?
Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015
Wladimir on Feb 16 2015: Bitcoin Core version 0.10.0 is now available from: https://bitcoin.org/bin/0.10.0/ This is a new major version release, bringing both new features and bug fixes. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues The whole distribution is also available as torrent: https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F 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). Downgrading warning Because release 0.10.0 makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with older 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. Notable changes Faster synchronization Bitcoin Core now uses 'headers-first synchronization'. This means that we first ask peers for block headers (a total of 27 megabytes, as of December 2014) and validate those. In a second stage, when the headers have been discovered, we download the blocks. However, as we already know about the whole chain in advance, the blocks can be downloaded in parallel from all available peers. In practice, this means a much faster and more robust synchronization. On recent hardware with a decent network link, it can be as little as 3 hours for an initial full synchronization. You may notice a slower progress in the very first few minutes, when headers are still being fetched and verified, but it should gain speed afterwards. A few RPCs were added/updated as a result of this:
getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we have requested from peers (but haven't received yet) are also listed as 'inflight'.
A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for. Transaction fee changes This release automatically estimates how high a transaction fee (or how high a priority) transactions require to be confirmed quickly. The default settings will create transactions that confirm quickly; see the new 'txconfirmtarget' setting to control the tradeoff between fees and confirmation times. Fees are added by default unless the 'sendfreetransactions' setting is enabled. Prior releases used hard-coded fees (and priorities), and would sometimes create transactions that took a very long time to confirm. Statistics used to estimate fees and priorities are saved in the data directory in the fee_estimates.dat file just before program shutdown, and are read in at startup. New command line options for transaction fee changes:
-txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting is over-ridden by the -paytxfee option.
-sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0) New RPC commands for fee estimation:
estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough transactions have been observed to compute a good estimate.
estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not enough free transactions have been observed to compute a good estimate. RPC access control changes Subnet matching for the purpose of access control is now done by matching the binary network address, instead of with string wildcard matching. For the user this means that -rpcallowip takes a subnet specification, which can be
a single IP address (e.g. 126.96.36.199 or fe80::0012:3456:789a:bcde)
a network/CIDR (e.g. 188.8.131.52/24 or fe80::0000/64)
a network/netmask (e.g. 184.108.40.206/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address matches one of them. For example: | 0.9.x and before | 0.10.x | |--------------------------------------------|---------------------------------------| | -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) | | -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 | | -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 | | -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) | Using wildcards will result in the rule being rejected with the following error in debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 220.127.116.11), a network/netmask (e.g. 18.104.22.168/255.255.255.0) or a network/CIDR (e.g. 22.214.171.124/24).
REST interface A new HTTP API is exposed when running with the -rest flag, which allows unauthenticated access to public node data. It is served on the same port as RPC, but does not need a password, and uses plain HTTP instead of JSON-RPC. Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded binary) or json. For more details, see the doc/REST-interface.md document in the repository. RPC Server "Warm-Up" Mode The RPC server is started earlier now, before most of the expensive intialisations like loading the block index. It is available now almost immediately after starting the process. However, until all initialisations are done, it always returns an immediate error with code -28 to all calls. This new behaviour can be useful for clients to know that a server is already started and will be available soon (for instance, so that they do not have to start it themselves). Improved signing security For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic. This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille. There exist attacks against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it's a better practice to avoid the exposure. OpenSSL has code in their source repository for derandomization and reduction in timing leaks that we've eagerly wanted to use for a long time, but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we're aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.  https://eprint.iacr.org/2014/161.pdf Watch-only wallet support The wallet can now track transactions to and from wallets for which you know all addresses (or scripts), even without the private keys. This can be used to track payments without needing the private keys online on a possibly vulnerable system. In addition, it can help for (manual) construction of multisig transactions where you are only one of the signers. One new RPC, importaddress, is added which functions similarly to importprivkey, but instead takes an address or script (in hexadecimal) as argument. After using it, outputs credited to this address or script are considered to be received, and transactions consuming these outputs will be considered to be sent. The following RPCs have optional support for watch-only: getbalance, listreceivedbyaddress, listreceivedbyaccount, listtransactions, listaccounts, listsinceblock, gettransaction. See the RPC documentation for those methods for more information. Compared to using getrawtransaction, this mechanism does not require -txindex, scales better, integrates better with the wallet, and is compatible with future block chain pruning functionality. It does mean that all relevant addresses need to added to the wallet before the payment, though. Consensus library Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library. The purpose of this library is to make the verification functionality that is critical to Bitcoin's consensus available to other applications, e.g. to language bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or alternative node implementations. This library is called libbitcoinconsensus.so (or, .dll for Windows). Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h). In its initial version the API includes two functions:
bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface for existing methods should remain stable. Standard script rules relaxed for P2SH addresses The IsStandard() rules have been almost completely removed for P2SH redemption scripts, allowing applications to make use of any valid script type, such as "n-of-m OR y", hash-locked oracle addresses, etc. While the Bitcoin protocol has always supported these types of script, actually using them on mainnet has been previously inconvenient as standard Bitcoin Core nodes wouldn't relay them to miners, nor would most miners include them in blocks they mined. bitcoin-tx It has been observed that many of the RPC functions offered by bitcoind are "pure functions", and operate independently of the bitcoind wallet. This included many of the RPC "raw transaction" API functions, such as createrawtransaction. bitcoin-tx is a newly introduced command line utility designed to enable easy manipulation of bitcoin transactions. A summary of its operation may be obtained via "bitcoin-tx --help" Transactions may be created or signed in a manner similar to the RPC raw tx API. Transactions may be updated, deleting inputs or outputs, or appending new inputs and outputs. Custom scripts may be easily composed using a simple text notation, borrowed from the bitcoin test suite. This tool may be used for experimenting with new transaction types, signing multi-party transactions, and many other uses. Long term, the goal is to deprecate and remove "pure function" RPC API calls, as those do not require a server round-trip to execute. Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making key and script operations easily accessible via command line. Mining and relay policy enhancements Bitcoin Core's block templates are now for version 3 blocks only, and any mining software relying on its getblocktemplate must be updated in parallel to use libblkmaker either version 0.4.2 or any version from 0.5.1 onward. If you are solo mining, this will affect you the moment you upgrade Bitcoin Core, which must be done prior to BIP66 achieving its 951/1001 status. If you are mining with the stratum mining protocol: this does not affect you. If you are mining with the getblocktemplate protocol to a pool: this will affect you at the pool operator's discretion, which must be no later than BIP66 achieving its 951/1001 status. The prioritisetransaction RPC method has been added to enable miners to manipulate the priority of transactions on an individual basis. Bitcoin Core now supports BIP 22 long polling, so mining software can be notified immediately of new templates rather than having to poll periodically. Support for BIP 23 block proposals is now available in Bitcoin Core's getblocktemplate method. This enables miners to check the basic validity of their next block before expending work on it, reducing risks of accidental hardforks or mining invalid blocks. Two new options to control mining policy:
-datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
-datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs. The relay policy has changed to more properly implement the desired behavior of not relaying free (or very low fee) transactions unless they have a priority above the AllowFreeThreshold(), in which case they are relayed subject to the rate limiter. BIP 66: strict DER encoding for signatures Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new consensus rule, which prohibits non-DER signatures. Such transactions have been non-standard since Bitcoin v0.8.0 (released in February 2013), but were technically still permitted inside blocks. This change breaks the dependency on OpenSSL's signature parsing, and is required if implementations would want to remove all of OpenSSL from the consensus code. The same miner-voting mechanism as in BIP 34 is used: when 751 out of a sequence of 1001 blocks have version number 3 or higher, the new consensus rule becomes active for those blocks. When 951 out of a sequence of 1001 blocks have version number 3 or higher, it becomes mandatory for all blocks. Backward compatibility with current mining software is NOT provided, thus miners should read the first paragraph of "Mining and relay policy enhancements" above. 0.10.0 Change log Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. RPC:
f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
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), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version.
Windows 64-bit installer
New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it. NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP and the SHA256SUMS.asc file to make sure your binaries are correct. In the final 0.9.0 release, Windows setup.exe binaries will be code-signed.
The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9 and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine).
Rebranding to Bitcoin Core
To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core.
Autotools build system
For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles. Using the standard "./autogen.sh; ./configure; make" to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project. Be sure to check doc/build-*.md for your platform before building from source.
Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality ("tell the running bitcoin daemon to do THIS") was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.
The behavior of the walletpassphrase RPC when the wallet is already unlocked has changed between 0.8 and 0.9. The 0.8 behavior of walletpassphrase is to fail when the wallet is already unlocked:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays)
The new behavior of walletpassphrase is to set a new unlock time overriding the old one:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time)
Transaction malleability-related fixes
This release contains a few fixes for transaction ID (TXID) malleability issues:
-nospendzeroconfchange command-line option, to avoid spending zero-confirmation change
IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions
Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs.
Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.
New option: -zapwallettxes to rebuild the wallet's transaction information
This release drops the default fee required to relay transactions across the network and for miners to consider the transaction in their blocks to 0.01mBTC per kilobyte. Note that getting a transaction relayed across the network does NOT guarantee that the transaction will be accepted by a miner; by default, miners fill their blocks with 50 kilobytes of high-priority transactions, and then with 700 kilobytes of the highest-fee-per-kilobyte transactions. The minimum relay/mining fee-per-kilobyte may be changed with the minrelaytxfee option. Note that previous releases incorrectly used the mintxfee setting to determine which low-priority transactions should be considered for inclusion in blocks. The wallet code still uses a default fee for low-priority transactions of 0.1mBTC per kilobyte. During periods of heavy transaction volume, even this fee may not be enough to get transactions confirmed quickly; the mintxfee option may be used to override the default.
0.9.0 Release notes
New notion of 'conflicted' transactions, reported as confirmations: -1
'listreceivedbyaddress' now provides tx ids
Add raw transaction hex to 'gettransaction' output
Updated help and tests for 'getreceivedby(account|address)'
In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility
Add 'verifychain', to verify chain database at runtime
Add 'dumpwallet' and 'importwallet' RPCs
'keypoolrefill' gains optional size parameter
Add 'getbestblockhash', to return tip of best chain
Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output
Make RPC password resistant to timing attacks
Clarify help messages and add examples
Add 'getrawchangeaddress' call for raw transaction change destinations
Reject insanely high fees by default in 'sendrawtransaction'
Add RPC call 'decodescript' to decode a hex-encoded transaction script
Make 'validateaddress' provide redeemScript
Add 'getnetworkhashps' to get the calculated network hashrate
New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output
Adding new 'addrlocal' field to 'getpeerinfo' output
Add verbose boolean to 'getrawmempool'
Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
Explicitly ensure that wallet is unlocked in importprivkey
Add check for valid keys in importprivkey
New option: -nospendzeroconfchange to never spend unconfirmed change outputs
New option: -zapwallettxes to rebuild the wallet's transaction information
Rename option '-tor' to '-onion' to better reflect what it does
Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet)
Update default '-rpcsslciphers' to include TLSv1.2
make '-logtimestamps' default on and rework help-message
RPC client option: '-rpcwait', to wait for server start
Allow -noserver with bitcoind
Block-chain handling and storage:
Update leveldb to 1.15
Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded)
Allow txindex to be removed and add a reindex dialog
Log aborted block database rebuilds
Store orphan blocks in serialized form, to save memory
Limit the number of orphan blocks in memory to 750
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. For Mac OS it is a DMG disk image. Linux versions include a PPA package for Ubuntu or a TAR.GZ archive. Figure 3-1. Bitcoin - Choose A Bitcoin Client Running Bitcoin Core for the first time If you download an installable package, such as an EXE, DMG or PPA, you can install it the same way as any application on your operating system. #16982 Factor out qt translations from build system (laanwj) #16926 Add OpenSSL termios fix for musl libc (nmarley) #16927 Refresh ZeroMQ 4.3.1 patch (nmarley) #17005 Qt version appears only if GUI is being built (ch4ot1c) #16468 Exclude depends/Makefile in .gitignore (promag) Tests and QA What exactly did `Bitcoin-Qt -rescan -reindex` do? Ask Question ... 6 years, 6 months ago. Active 4 years ago. Viewed 8k times 9. 5. 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. ... Goodbye, Prettify. Hello highlight.js! Swapping out our Syntax Highlighter. Linked. 6 ... Notable changes Wallet changes Segwit Wallet. Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new -addresstype argument has been added, which supports legacy, p2sh-segwit (default), and bech32 addresses. It controls what kind of addresses are produced by getnewaddress, getaccountaddress, and createmultisigaddress.
Crypto News Bitconnect Launch ICO! 1% Of BTC Used For Laundering. More Tether Minted Than US GOV - Duration: 25:54. Bull & Bear Cryptocurrency Analysis, News & Education 3,313 views Mine took 6 hours to sync to the blockchain!! In this video I will show you how to quickly fix the syncing issue with Bitconnect QT wallet on a Mac. If this fix does not work please CLICK the ... Download your QT wallet here https://github.com/bitconnectcoin/bitconnectcoin/tree/master/setup Get your Node List here https://chainz.cryptoid.info/bcc/#!ne... Quick Fix Bitconnect QT Wallet Out of Sync 🖥️ Mac OSX - Duration: 5:30. Nad Daniels 2,327 views. ... Bitcoin Daytrader 3,823 views. 16:16. How to Repair a DEAD Computer - Duration: 37:05. bitcoin qt trader bitcoin qt rescan bitcoin q a bitcoin q es bitcoins q son ... Bitcoin 101 - Getting Your BTCs out of Your Paper Wallets & Cold Storage - Fun with Sloppy Wallets - Duration: 10:54.