diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index ae92fc78f2..97882db944 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -11,7 +11,7 @@ first. See CONTRIBUTING.md
 
 <!--
 Please provide clear motivation for your patch and explain how it improves
-Bitcoin Core user experience or Bitcoin Core developer experience
+Qtum Core user experience or Qtum Core developer experience
 significantly:
 
 * Any test improvements or new tests that improve coverage are always welcome.
@@ -24,7 +24,7 @@ significantly:
   was fixed.
 * Features are welcome, but might be rejected due to design or scope issues.
   If a feature is based on a lot of dependencies, contributors should first
-  consider building the system outside of Bitcoin Core, if possible.
+  consider building the system outside of Qtum Core, if possible.
 * Refactoring changes are only accepted if they are required for a feature or
   bug fix or otherwise improve developer experience significantly. For example,
   most "code style" refactoring changes require a thorough explanation why they
@@ -36,7 +36,7 @@ significantly:
 -->
 
 <!--
-Bitcoin Core has a thorough review process and even the most trivial change
+Qtum Core has a thorough review process and even the most trivial change
 needs to pass a lot of eyes and requires non-zero or even substantial time
 effort to review. There is a huge lack of active reviewers on the project, so
 patches often sit for a long time.
diff --git a/README.md b/README.md
index 2eab2315eb..019c038945 100644
--- a/README.md
+++ b/README.md
@@ -1,39 +1,257 @@
-Bitcoin Core integration/staging tree
-=====================================
+What is Qtum?
+-------------
 
-https://bitcoincore.org
+Qtum is a decentralized blockchain project built on Bitcoin's UTXO model, with support for Ethereum Virtual Machine based smart contracts, and secured by a proof of stake consensus model. It achieves this through the revolutionary Account Abstraction Layer which allows the EVM to communicate with Qtum's Bitcoin-like UTXO blockchain. For more general information about Qtum as well as links to join our community, go to https://qtum.org
 
-For an immediately usable, binary version of the Bitcoin Core software, see
-https://bitcoincore.org/en/download/.
+Welcome to the Qtum Fastlane Main Network. This is the main network where the tokens hold value and should be guarded very carefully. If you are testing the network, or developing unstable software on Qtum, we highly recommend using either testnet or regtest mode. 
 
-What is Bitcoin Core?
----------------------
+The major features of the Qtum network include:
 
-Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully
-validate blocks and transactions. It also includes a wallet and graphical user
-interface, which can be optionally built.
+1. Compatibility with the Ethereum Virtual Machine, which allows for compatibility with most existing Solidity based smart contracts. No special solidity compiler is required to deploy your smart contract to Qtum. 
+2. A Proof of Stake consensus system which is optimized for Qtum's contract model. Any user can stake and help to secure the network. There is no voting, master nodes, or minimum amount required. There have been transactions as small as 2 Qtum that have created blocks in the past. Staking from smart contracts is under development.
+3. The Decentralized Governance Protocol is completely implemented and functional, which allows certain network parameters to be modified without a fork or other network disruption. This currently controls parameters like block size, gas prices, etc. 
+4. Uses the UTXO transaction model and is compatible with Bitcoin, allowing for existing tooling and workflows to be used with Qtum. This allows for the infamous SPV protocol to be used which is ideal for light wallets on mobile phones and IoT devices.
 
-Further information about Bitcoin Core is available in the [doc folder](/doc).
+Note: Qtum Core is considered beta software. We make no warranties or guarantees of its security or stability.
+
+Qtum Documentation and Usage Resources
+---------------
+
+These are some resources that might be helpful in understanding Qtum.
+
+Basic usage resources:
+
+* [User guide](https://docs.qtum.site/en/)
+* [Qtum-Qt Wallet Tutorial](https://github.com/qtumproject/documents/tree/master/en/Qtum-Wallet-Tutorial#qtum-qt-wallet-tutorial)
+* [Qtum staking tutorial](https://github.com/qtumproject/documents/tree/master/en/How-to-Stake-with-Qtum)
+* [Qtum tutorial on Raspberry Pi](https://github.com/qtumproject/documents/tree/master/en/Qtum-on-Raspberry-Pi)
+* [Running Qtum on Amazon AWS using Qtum AMI](https://github.com/qtumproject/documents/tree/master/en/Qtum-AWS)
+* [Encrypting and unlocking wallet](https://github.com/qtumproject/documents/tree/master/en/Encrypt-and-Unlock-Qtum-Wallet)
+* [Testnet guide](https://github.com/qtumproject/documents/blob/master/en/Testnet-User-Guide.md)
+* [Block explorer](https://qtum.info), [Older explorer](https://explorer.qtum.org)
+
+
+Development resources:
+
+* [Qtum Book - A Developer's Guide To QTUM](http://book.qtum.site/en/)
+* [Qtum contract usage](https://docs.qtum.site/en/QRC20-Token-Introduce.html)
+* [Deploying a custom token to Qtum](https://blog.qtum.org/qtum-custom-token-walkthrough-467d725fa27d)
+* [QtumJS document](https://qtumproject.github.io/qtumjs-doc/)
+* [Smart contract ICO example](http://book.qtum.site/en/part3/ico.htm)
+* [Early example faucet contract](http://earlz.net/view/2017/06/30/2144/the-qtum-sparknet-faucet)
+
+General Info about Qtum:
+
+* [CIRCLERESEARCH Qtum Primer](https://www.circle.com/marketing/pdfs/research/circle-research-qtum.pdf)
+* [Qtum's PoS vs CASPER](https://www.reddit.com/r/Qtum/comments/788oa5/qtums_pos_vs_casper_and_the_nothingatstake_problem/)
+* [Technical article explaining Qtum's PoS model in depth](http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version)
+
+
+Developer's Tools
+-----------------
+
+* Smart contract deployment tool
+  * https://github.com/qtumproject/solar
+* DApp JavaScript Library
+  * https://github.com/qtumproject/qtumjs
+* A toolkit for building qtum light wallets
+  * https://github.com/qtumproject/qtumjs-wallet
+* CORS qtumd RPC proxy for DApp
+  * https://github.com/qtumproject/qtumportal
+* Docker images for running qtum services
+  * https://github.com/qtumproject/qtum-docker
+* qtum.info API that powers the block explorer and the QTUM Web wallet
+  * https://github.com/qtumproject/qtuminfo-api#qtuminfo-api-documentation
+
+
+What is Qtum Core?
+------------------
+
+Qtum Core is our primary mainnet wallet. It implements a full node and is capable of storing, validating, and distributing all history of the Qtum network. Qtum Core is considered the reference implementation for the Qtum network. 
+
+Qtum Core currently implements the following:
+
+* Sending/Receiving QTUM coins
+* Sending/Receiving QRC20 tokens on the Qtum network
+* Staking and creating blocks for the Qtum network
+* Creating and interacting with smart contracts
+* Running a full node for distributing the blockchain to other users
+* "Prune" mode, which minimizes disk usage
+* Regtest mode, which enables developers to very quickly build their own private Qtum network for Dapp testing
+* Testnet mode, using the public Qtum Testnet, with faucet available
+* Compatibility with the Bitcoin Core set of RPC commands and APIs
+* Full SegWit capability with p2sh-segwit (legacy) and bech32 (native) addresses
+
+Alternative Wallets
+-------------------
+
+Qtum Core uses a full node model, and thus requires downloading the entire blockchain. If you do not need the entire blockchain, and do not intend on developing smart contracts, it may be more ideal to use an alternative wallet such as one of our light wallets that can be synchronized in a matter of seconds. 
+
+### Qtum Web Wallet
+
+A browser wallet that supports the Ledger hardware wallet, offline cold wallet, restoration from mobile wallets, creation of QRC20 tokens and QRC1155 NFTs.
+
+Web site https://qtumwallet.org
+
+User documentation https://github.com/qtumproject/documents/tree/master/en/QTUM-WebWallet-usage
+
+### Qtum Electrum
+
+A light wallet that supports the Ledger and Trezor hardware wallets and is based on the well-known Electrum wallet software. 
+
+Download: https://github.com/qtumproject/qtum-electrum/releases
+
+### iOS and Android Wallets
+
+These wallets run on mobile devices and synchronize quickly. 
+
+Android Download: https://play.google.com/store/apps/details?id=org.qtum.newwallet
+
+iOS Download: https://github.com/qtumproject/qtum-ios (open source, deprecated)
+
+### Qnekt Chrome Wallet
+
+This light wallet runs in your Chrome browser as a browser extension, based on the popular MetaMask wallet.
+
+
+### Community Resources
+
+Make sure to check out these resources as well for more information and to keep up to date with all the latest news about Qtum. At least 1 developer is always around, so if you're developing on Qtum and need help, we'd love to welcome you to our community.
+
+*	@Qtum on Twitter https://twitter.com/qtum
+* Qtum blog https://blog.qtum.org/
+*	Qtum Telegram Group https://t.me/qtumofficial, other languages available
+* Qtum Discord https://discord.com/invite/DCPGvUCms5
+*	/r/Qtum on Reddit https://www.reddit.com/r/Qtum/
+*	Qtum.org https://qtum.org
+*	Qtum on Facebook https://www.facebook.com/QtumOfficial/
+
+### Qtum Smart Contract Limitations
+
+*	EVM smart contracts cannot receive coins from or send coins to any address type other than pay-to-pubkeyhash (starts with Q) addresses. This is due to a limitation in the EVM
+*	Contracts are not allowed to create contracts with an initial endowment of coins. The contract must first be created, and then be sent coins in a separate transaction. Humans are also not allowed to create contracts with an initial endowment of coins.
+*	Although all of the infrastructure is present, Qtum Core does not currently parse Solidity event data. You must parse this yourself using either searchlogs or -record-log-opcodes features.
+*	It is not possible to send a contract coins without also executing the contract. This is also the case of Ethereum. This was promised in earlier discussions and technically does work, but due to lack of time for testing this feature was disabled.
+*	In Qtum there can be multiple addresses used to create a proof-of-stake block. However, the EVM can only see the first output using the coinbase operation in Solidity (this address is also the one registered for the continuous staker rewards after 2000 blocks).
+
+----------
+
+# Building Qtum Core
+
+### Validate and Reproduce Binaries
+
+Qtum uses a tool called Gitian to make reproducible builds that can be verified by anyone. Instructions on setting up a Gitian VM and building Qtum are provided in [Gitan Building](https://github.com/qtumproject/qtum/blob/master/doc/gitian-building.md)
+
+### Build on Ubuntu
+
+This is a quick start script for compiling Qtum on Ubuntu
+
+
+    sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils git cmake libboost-all-dev libgmp3-dev
+    sudo apt-get install software-properties-common
+    
+    # If you want to build the Qt GUI:
+    sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler qrencode
+    
+    git clone https://github.com/qtumproject/qtum --recursive
+    cd qtum
+    
+    # Note autogen will prompt to install some more dependencies if needed
+    ./contrib/install_db4.sh `pwd`
+    ./autogen.sh
+    ./configure 
+    make -j2
+
+### Build on CentOS
+
+Here is a brief description for compiling Qtum on CentOS, for more details please refer to [the specific document](https://github.com/qtumproject/qtum/blob/master/doc/build-unix.md)
+
+    # Compiling boost manually
+    sudo yum install python-devel bzip2-devel
+    git clone https://github.com/boostorg/boost.git
+    cd boost
+    git checkout boost-1.66.0
+    git submodule update --init --recursive
+    ./bootstrap.sh --prefix=/usr --libdir=/usr/lib64
+    ./b2 headers
+    sudo ./b2 -j4 install
+    
+    # Installing Dependencies for Qtum
+    sudo yum install epel-release
+    sudo yum install libtool libdb4-cxx-devel openssl-devel libevent-devel gmp-devel
+    
+    # If you want to build the Qt GUI:
+    sudo yum install qt5-qttools-devel protobuf-devel qrencode-devel
+    
+    # Building Qtum
+    git clone --recursive https://github.com/qtumproject/qtum.git
+    cd qtum
+    ./autogen.sh
+    ./configure
+    make -j4
+
+### Build on Mac OS
+
+The commands in this guide should be executed in a Terminal application.
+The built-in one is located in `/Applications/Utilities/Terminal.app`.
+
+#### Preparation
+
+Install the Mac OS command line tools:
+
+`xcode-select --install`
+
+When the popup appears, click `Install`.
+
+Then install [Homebrew](https://brew.sh).
+
+#### Dependencies
+
+    brew install cmake automake berkeley-db@4 libtool boost@1.76 miniupnpc openssl pkg-config protobuf qt@5 libevent imagemagick librsvg qrencode gmp
+
+After installing all dependencies, make sure to run "brew link boost@1.76"
+NOTE: This will work for building on Intel Macs and Apple Silicon Macs
+
+NOTE: Building with Qt4 is still supported, however, could result in a broken UI. Building with Qt5 is recommended.
+
+#### Build Qtum Core
+
+1. Clone the qtum source code and cd into `qtum`
+
+        git clone --recursive https://github.com/qtumproject/qtum.git
+        cd qtum
+
+2.  Build qtum-core:
+
+    Configure and build the headless qtum binaries as well as the GUI (if Qt is found).
+
+    You can disable the GUI build by passing `--without-gui` to configure.
+
+        ./autogen.sh
+        ./configure
+        make
+
+3.  It is recommended to build and run the unit tests:
+
+        make check
+
+### Run
+
+Then you can either run the command-line daemon using `src/qtumd` and `src/qtum-cli`, or you can run the Qt GUI using `src/qt/qtum-qt`
 
 License
 -------
 
-Bitcoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
-information or see https://opensource.org/licenses/MIT.
+Qtum is GPLv3 licensed.
 
 Development Process
 -------------------
 
-The `master` branch is regularly built (see `doc/build-*.md` for instructions) and tested, but it is not guaranteed to be
-completely stable. [Tags](https://github.com/bitcoin/bitcoin/tags) are created
-regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
-
-The https://github.com/bitcoin-core/gui repository is used exclusively for the
-development of the GUI. Its master branch is identical in all monotree
-repositories. Release branches and tags do not exist, so please do not fork
-that repository unless it is for development reasons.
+The `master` branch is regularly built and tested, but is not guaranteed to be
+completely stable. [Tags](https://github.com/qtumproject/qtum/tags) are created
+regularly to indicate new official, stable release versions of Qtum.
 
-The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md)
+The contribution workflow is described in [CONTRIBUTING.md](https://github.com/qtumproject/qtum/blob/master/CONTRIBUTING.md)
 and useful hints for developers can be found in [doc/developer-notes.md](doc/developer-notes.md).
 
 Testing
diff --git a/doc/JSON-RPC-interface.md b/doc/JSON-RPC-interface.md
index 6cbb6ebd72..96a6b4bc39 100644
--- a/doc/JSON-RPC-interface.md
+++ b/doc/JSON-RPC-interface.md
@@ -1,7 +1,7 @@
 # JSON-RPC Interface
 
-The headless daemon `bitcoind` has the JSON-RPC API enabled by default, the GUI
-`bitcoin-qt` has it disabled by default. This can be changed with the `-server`
+The headless daemon `qtumd` has the JSON-RPC API enabled by default, the GUI
+`qtum-qt` has it disabled by default. This can be changed with the `-server`
 option. In the GUI it is possible to execute RPC methods in the Debug Console
 Dialog.
 
@@ -24,7 +24,7 @@ This endpoint is only activated when the wallet component has been compiled in.
 It can service both wallet and non-wallet requests.
 It MUST be used for wallet requests when two or more wallets are loaded.
 
-This is the endpoint used by bitcoin-cli when a `-rpcwallet=` parameter is passed in.
+This is the endpoint used by qtum-cli when a `-rpcwallet=` parameter is passed in.
 
 Best practice would dictate using the `/wallet/<walletname>/` endpoint for ALL
 requests when multiple wallets are in use.
@@ -53,18 +53,18 @@ Examples:
 
 ```sh
 # "params": ["mywallet", false, false, "", false, false, true]
-bitcoin-cli createwallet mywallet false false "" false false true
+qtum-cli createwallet mywallet false false "" false false true
 
 # "params": {"wallet_name": "mywallet", "load_on_startup": true}
-bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=true
+qtum-cli -named createwallet wallet_name=mywallet load_on_startup=true
 
 # "params": {"args": ["mywallet"], "load_on_startup": true}
-bitcoin-cli -named createwallet mywallet load_on_startup=true
+qtum-cli -named createwallet mywallet load_on_startup=true
 ```
 
 ## Versioning
 
-The RPC interface might change from one major version of Bitcoin Core to the
+The RPC interface might change from one major version of Qtum Core to the
 next. This makes the RPC interface implicitly versioned on the major version.
 The version tuple can be retrieved by e.g. the `getnetworkinfo` RPC in
 `version`.
@@ -76,21 +76,21 @@ were deprecated and how to re-enable them temporarily.
 
 ## Security
 
-The RPC interface allows other programs to control Bitcoin Core,
+The RPC interface allows other programs to control Qtum Core,
 including the ability to spend funds from your wallets, affect consensus
 verification, read private data, and otherwise perform operations that
 can cause loss of money, data, or privacy.  This section suggests how
-you should use and configure Bitcoin Core to reduce the risk that its
+you should use and configure Qtum Core to reduce the risk that its
 RPC interface will be abused.
 
 - **Securing the executable:** Anyone with physical or remote access to
-  the computer, container, or virtual machine running Bitcoin Core can
+  the computer, container, or virtual machine running Qtum Core can
   compromise either the whole program or just the RPC interface.  This
   includes being able to record any passphrases you enter for unlocking
-  your encrypted wallets or changing settings so that your Bitcoin Core
+  your encrypted wallets or changing settings so that your Qtum Core
   program tells you that certain transactions have multiple
   confirmations even when they aren't part of the best block chain.  For
-  this reason, you should not use Bitcoin Core for security sensitive
+  this reason, you should not use Qtum Core for security sensitive
   operations on systems you do not exclusively control, such as shared
   computers or virtual private servers.
 
@@ -100,43 +100,43 @@ RPC interface will be abused.
   and passphrase).  Any program on your computer with access to the file
   system and local network can obtain this level of access.
   Additionally, other programs on your computer can attempt to provide
-  an RPC interface on the same port as used by Bitcoin Core in order to
+  an RPC interface on the same port as used by Qtum Core in order to
   trick you into revealing your authentication credentials.  For this
-  reason, it is important to only use Bitcoin Core for
+  reason, it is important to only use Qtum Core for
   security-sensitive operations on a computer whose other programs you
   trust.
 
 - **Securing remote network access:** You may optionally allow other
-  computers to remotely control Bitcoin Core by setting the `rpcallowip`
+  computers to remotely control Qtum Core by setting the `rpcallowip`
   and `rpcbind` configuration parameters.  These settings are only meant
   for enabling connections over secure private networks or connections
   that have been otherwise secured (e.g. using a VPN or port forwarding
   with SSH or stunnel).  **Do not enable RPC connections over the public
-  Internet.**  Although Bitcoin Core's RPC interface does use
+  Internet.**  Although Qtum Core's RPC interface does use
   authentication, it does not use encryption, so your login credentials
   are sent as clear text that can be read by anyone on your network
   path.  Additionally, the RPC interface has not been hardened to
   withstand arbitrary Internet traffic, so changing the above settings
   to expose it to the Internet (even using something like a Tor onion
   service) could expose you to unconsidered vulnerabilities.  See
-  `bitcoind -help` for more information about these settings and other
+  `qtumd -help` for more information about these settings and other
   settings described in this document.
 
-    Related, if you use Bitcoin Core inside a Docker container, you may
+    Related, if you use Qtum Core inside a Docker container, you may
     need to expose the RPC port to the host system.  The default way to
     do this in Docker also exposes the port to the public Internet.
     Instead, expose it only on the host system's localhost, for example:
     `-p 127.0.0.1:8332:8332`
 
-- **Secure authentication:** By default, Bitcoin Core generates unique
+- **Secure authentication:** By default, Qtum Core generates unique
   login credentials each time it restarts and puts them into a file
-  readable only by the user that started Bitcoin Core, allowing any of
+  readable only by the user that started Qtum Core, allowing any of
   that user's RPC clients with read access to the file to login
-  automatically.  The file is `.cookie` in the Bitcoin Core
+  automatically.  The file is `.cookie` in the Qtum Core
   configuration directory, and using these credentials is the preferred
   RPC authentication method.  If you need to generate static login
   credentials for your programs, you can use the script in the
-  `share/rpcauth` directory in the Bitcoin Core source tree.  As a final
+  `share/rpcauth` directory in the Qtum Core source tree.  As a final
   fallback, you can directly use manually-chosen `rpcuser` and
   `rpcpassword` configuration parameters---but you must ensure that you
   choose a strong and unique passphrase (and still don't use insecure
diff --git a/doc/README.md b/doc/README.md
index c570432aa4..2aa196e6d0 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,30 +1,30 @@
-Bitcoin Core
+Qtum Core
 =============
 
 Setup
 ---------------------
-Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires a few hundred gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
+Qtum Core is the original Qtum client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Qtum transactions, which requires several gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
 
-To download Bitcoin Core, visit [bitcoincore.org](https://bitcoincore.org/en/download/).
+To download Qtum Core, visit [qtumcore.org](https://qtumeco.io/wallet).
 
 Running
 ---------------------
-The following are some helpful notes on how to run Bitcoin Core on your native platform.
+The following are some helpful notes on how to run Qtum Core on your native platform.
 
 ### Unix
 
 Unpack the files into a directory and run:
 
-- `bin/bitcoin-qt` (GUI) or
-- `bin/bitcoind` (headless)
+- `bin/qtum-qt` (GUI) or
+- `bin/qtumd` (headless)
 
 ### Windows
 
-Unpack the files into a directory, and then run bitcoin-qt.exe.
+Unpack the files into a directory, and then run qtum-qt.exe.
 
 ### macOS
 
-Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
+Drag Qtum Core to your applications folder, and then run Qtum Core.
 
 ### Need Help?
 
@@ -36,7 +36,7 @@ for help and more information.
 
 Building
 ---------------------
-The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
+The following are developer notes on how to build Qtum Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
 
 - [Dependencies](dependencies.md)
 - [macOS Build Notes](build-osx.md)
@@ -49,7 +49,7 @@ The following are developer notes on how to build Bitcoin Core on your native pl
 
 Development
 ---------------------
-The Bitcoin repo's [root README](/README.md) contains relevant information on the development process and automated testing.
+The Qtum repo's [root README](/README.md) contains relevant information on the development process and automated testing.
 
 - [Developer Notes](developer-notes.md)
 - [Productivity Notes](productivity.md)
@@ -71,7 +71,7 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
 
 ### Miscellaneous
 - [Assets Attribution](assets-attribution.md)
-- [bitcoin.conf Configuration File](bitcoin-conf.md)
+- [qtum.conf Configuration File](qtum-conf.md)
 - [CJDNS Support](cjdns.md)
 - [Files](files.md)
 - [Fuzz-testing](fuzzing.md)
diff --git a/doc/REST-interface.md b/doc/REST-interface.md
index 2d7d0e3769..551ba8d5d8 100644
--- a/doc/REST-interface.md
+++ b/doc/REST-interface.md
@@ -146,4 +146,4 @@ Refer to the `getrawmempool` RPC help for details. Defaults to setting
 
 Risks
 -------------
-Running a web browser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:8332/rest/tx/1234567890.json">` which might break the nodes privacy.
+Running a web browser on the same node with a REST enabled qtumd can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:8332/rest/tx/1234567890.json">` which might break the nodes privacy.
diff --git a/doc/bitcoin-conf.md b/doc/bitcoin-conf.md
index 1ebfb4c1de..87ccf4d891 100644
--- a/doc/bitcoin-conf.md
+++ b/doc/bitcoin-conf.md
@@ -1,10 +1,10 @@
-# `bitcoin.conf` Configuration File
+# `qtum.conf` Configuration File
 
-The configuration file is used by `bitcoind`, `bitcoin-qt` and `bitcoin-cli`.
+The configuration file is used by `qtumd`, `qtum-qt` and `qtum-cli`.
 
 All command-line options (except for `-?`, `-help`, `-version` and `-conf`) may be specified in a configuration file, and all configuration file options (except for `includeconf`) may also be specified on the command line. Command-line options override values set in the configuration file and configuration file options override values set in the GUI.
 
-Changes to the configuration file while `bitcoind` or `bitcoin-qt` is running only take effect after restarting.
+Changes to the configuration file while `qtumd` or `qtum-qt` is running only take effect after restarting.
 
 Users should never make any configuration changes which they do not understand. Furthermore, users should always be wary of accepting any configuration changes provided to them by another source (even if they believe that they do understand them).
 
@@ -51,24 +51,24 @@ rpcport=4000
 
 ## Configuration File Path
 
-The configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is `bitcoin.conf` and it is located in the Bitcoin data directory, but both the Bitcoin data directory and the configuration file path may be changed using the `-datadir` and `-conf` command-line options.
+The configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is `qtum.conf` and it is located in the Qtum data directory, but both the Qtum data directory and the configuration file path may be changed using the `-datadir` and `-conf` command-line options.
 
-The `includeconf=<file>` option in the `bitcoin.conf` file can be used to include additional configuration files.
+The `includeconf=<file>` option in the `qtum.conf` file can be used to include additional configuration files.
 
 ### Default configuration file locations
 
 Operating System | Data Directory | Example Path
 -- | -- | --
-Windows | `%APPDATA%\Bitcoin\` | `C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf`
-Linux | `$HOME/.bitcoin/` | `/home/username/.bitcoin/bitcoin.conf`
-macOS | `$HOME/Library/Application Support/Bitcoin/` | `/Users/username/Library/Application Support/Bitcoin/bitcoin.conf`
+Windows | `%APPDATA%\Qtum\` | `C:\Users\username\AppData\Roaming\Qtum\qtum.conf`
+Linux | `$HOME/.qtum/` | `/home/username/.qtum/qtum.conf`
+macOS | `$HOME/Library/Application Support/Qtum/` | `/Users/username/Library/Application Support/Qtum/qtum.conf`
 
 An example configuration file can be generated by [contrib/devtools/gen-bitcoin-conf.sh](../contrib/devtools/gen-bitcoin-conf.sh).
 Run this script after compiling to generate an up-to-date configuration file.
-The output is placed under `share/examples/bitcoin.conf`.
+The output is placed under `share/examples/qtum.conf`.
 To use the generated configuration file, copy the example file into your data directory and edit it there, like so:
 
 ```
 # example copy command for linux user
-cp share/examples/bitcoin.conf ~/.bitcoin
+cp share/examples/qtum.conf ~/.qtum
 ```
diff --git a/doc/build-freebsd.md b/doc/build-freebsd.md
index aa10e4a891..e585d76324 100644
--- a/doc/build-freebsd.md
+++ b/doc/build-freebsd.md
@@ -2,7 +2,7 @@
 
 **Updated for FreeBSD [12.3](https://www.freebsd.org/releases/12.3R/announce/)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on FreeBSD.
+This guide describes how to build qtumd, command-line utilities, and GUI on FreeBSD.
 
 ## Preparation
 
@@ -10,22 +10,22 @@ This guide describes how to build bitcoind, command-line utilities, and GUI on F
 Run the following as root to install the base dependencies for building.
 
 ```bash
-pkg install autoconf automake boost-libs git gmake libevent libtool pkgconf
+pkg install autoconf automake boost-libs git gmake libevent libtool pkgconf gmp
 
 ```
 
 See [dependencies.md](dependencies.md) for a complete overview.
 
-### 2. Clone Bitcoin Repo
-Now that `git` and all the required dependencies are installed, let's clone the Bitcoin Core repository to a directory. All build scripts and commands will run from this directory.
+### 2. Clone Qtum Repo
+Now that `git` and all the required dependencies are installed, let's clone the Qtum Core repository to a directory. All build scripts and commands will run from this directory.
 ``` bash
-git clone https://github.com/bitcoin/bitcoin.git
+git clone https://github.com/qtumproject/qtum --recursive
 ```
 
 ### 3. Install Optional Dependencies
 
 #### Wallet Dependencies
-It is not necessary to build wallet functionality to run either `bitcoind` or `bitcoin-qt`.
+It is not necessary to build wallet functionality to run either `qtumd` or `qtum-qt`.
 
 ###### Descriptor Wallet Support
 
@@ -48,7 +48,7 @@ gmake -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_SQLITE=1 NO_NATPMP=1 NO_UPN
 When the build is complete, the Berkeley DB installation location will be displayed:
 
 ```
-to: /path/to/bitcoin/depends/x86_64-unknown-freebsd[release-number]
+to: /path/to/qtum/depends/x86_64-unknown-freebsd[release-number]
 ```
 
 Finally, set `BDB_PREFIX` to this path according to your shell:
@@ -64,7 +64,7 @@ sh/bash: export BDB_PREFIX=[path displayed above]
 #### GUI Dependencies
 ###### Qt5
 
-Bitcoin Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, we need to install `qt5`. Skip if you don't intend to use the GUI.
+Qtum Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, we need to install `qt5`. Skip if you don't intend to use the GUI.
 ```bash
 pkg install qt5
 ```
@@ -79,7 +79,7 @@ pkg install libqrencode
 #### Notifications
 ###### ZeroMQ
 
-Bitcoin Core can provide notifications via ZeroMQ. If the package is installed, support will be compiled in.
+Qtum Core can provide notifications via ZeroMQ. If the package is installed, support will be compiled in.
 ```bash
 pkg install libzmq4
 ```
@@ -93,11 +93,11 @@ pkg install python3 databases/py-sqlite3
 ```
 ---
 
-## Building Bitcoin Core
+## Building Qtum Core
 
 ### 1. Configuration
 
-There are many ways to configure Bitcoin Core, here are a few common examples:
+There are many ways to configure Qtum Core, here are a few common examples:
 
 ##### Descriptor Wallet and GUI:
 This explicitly enables the GUI and disables legacy wallet support, assuming `sqlite` and `qt` are installed.
diff --git a/doc/build-netbsd.md b/doc/build-netbsd.md
index 0f05cdcba7..739829493d 100644
--- a/doc/build-netbsd.md
+++ b/doc/build-netbsd.md
@@ -2,7 +2,7 @@
 
 Updated for NetBSD [9.2](https://netbsd.org/releases/formal-9/NetBSD-9.2.html).
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on NetBSD.
+This guide describes how to build qtumd, command-line utilities, and GUI on NetBSD.
 
 ## Preparation
 
@@ -12,7 +12,7 @@ Install the required dependencies the usual way you [install software on NetBSD]
 The example commands below use `pkgin`.
 
 ```bash
-pkgin install autoconf automake libtool pkg-config git gmake boost libevent
+pkgin install autoconf automake libtool pkg-config git gmake boost libevent gmp
 
 ```
 
@@ -34,23 +34,23 @@ Then, when configuring, pass the following:
 
 See [dependencies.md](dependencies.md) for a complete overview.
 
-### 2. Clone Bitcoin Repo
+### 2. Clone Qtum Repo
 
-Clone the Bitcoin Core repository to a directory. All build scripts and commands will run from this directory.
+Clone the Qtum Core repository to a directory. All build scripts and commands will run from this directory.
 
 ```bash
-git clone https://github.com/bitcoin/bitcoin.git
+git clone https://github.com/qtumproject/qtum --recursive
 ```
 
 ### 3. Install Optional Dependencies
 
 #### Wallet Dependencies
 
-It is not necessary to build wallet functionality to run bitcoind or the GUI.
+It is not necessary to build wallet functionality to run qtumd or the GUI.
 
 ###### Descriptor Wallet Support
 
-`sqlite3` is required to enable support for [descriptor wallets](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md).
+`sqlite3` is required to enable support for [descriptor wallets](https://github.com/qtumproject/qtum/blob/master/doc/descriptors.md).
 
 ```bash
 pkgin install sqlite3
@@ -66,7 +66,7 @@ pkgin install db4
 
 #### GUI Dependencies
 
-Bitcoin Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, we need to install `qt5`.
+Qtum Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, we need to install `qt5`.
 
 ```bash
 pkgin install qt5
@@ -87,14 +87,14 @@ To run the test suite (recommended), you will need to have Python 3 installed:
 pkgin install python37
 ```
 
-### Building Bitcoin Core
+### Building Qtum Core
 
 **Note**: Use `gmake` (the non-GNU `make` will exit with an error).
 
 
 ### 1. Configuration
 
-There are many ways to configure Bitcoin Core. Here is an example that
+There are many ways to configure Qtum Core. Here is an example that
 explicitly disables the wallet and GUI:
 
 ```bash
diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md
index 96ee714341..606c7c0740 100644
--- a/doc/build-openbsd.md
+++ b/doc/build-openbsd.md
@@ -2,7 +2,7 @@
 
 **Updated for OpenBSD [7.3](https://www.openbsd.org/73.html)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on OpenBSD.
+This guide describes how to build qtumd, command-line utilities, and GUI on OpenBSD.
 
 ## Preparation
 
@@ -12,22 +12,22 @@ Run the following as root to install the base dependencies for building.
 ```bash
 pkg_add bash git gmake libevent libtool boost
 # Select the newest version of the following packages:
-pkg_add autoconf automake python
+pkg_add autoconf automake python gmp
 ```
 
 See [dependencies.md](dependencies.md) for a complete overview.
 
-### 2. Clone Bitcoin Repo
-Clone the Bitcoin Core repository to a directory. All build scripts and commands will run from this directory.
+### 2. Clone Qtum Repo
+Clone the Qtum Core repository to a directory. All build scripts and commands will run from this directory.
 ``` bash
-git clone https://github.com/bitcoin/bitcoin.git
+git clone https://github.com/qtumproject/qtum --recursive
 ```
 
 ### 3. Install Optional Dependencies
 
 #### Wallet Dependencies
 
-It is not necessary to build wallet functionality to run either `bitcoind` or `bitcoin-qt`.
+It is not necessary to build wallet functionality to run either `qtumd` or `qtum-qt`.
 
 ###### Descriptor Wallet Support
 
@@ -46,25 +46,25 @@ from ports. However you can build it yourself, [using depends](/depends).
 ```bash
 gmake -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_SQLITE=1 NO_NATPMP=1 NO_UPNP=1 NO_ZMQ=1 NO_USDT=1
 ...
-to: /path/to/bitcoin/depends/x86_64-unknown-openbsd
+to: /path/to/qtum/depends/x86_64-unknown-openbsd
 ```
 
 Then set `BDB_PREFIX`:
 
 ```bash
-export BDB_PREFIX="/path/to/bitcoin/depends/x86_64-unknown-openbsd"
+export BDB_PREFIX="/path/to/qtum/depends/x86_64-unknown-openbsd"
 ```
 
 #### GUI Dependencies
 ###### Qt5
 
-Bitcoin Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, Qt 5 is required.
+Qtum Core includes a GUI built with the cross-platform Qt Framework. To compile the GUI, Qt 5 is required.
 
 ```bash
 pkg_add qt5
 ```
 
-## Building Bitcoin Core
+## Building Qtum Core
 
 **Important**: Use `gmake` (the non-GNU `make` will exit with an error).
 
@@ -80,7 +80,7 @@ export AUTOMAKE_VERSION=1.16
 
 ### 1. Configuration
 
-There are many ways to configure Bitcoin Core, here are a few common examples:
+There are many ways to configure Qtum Core, here are a few common examples:
 
 ##### Descriptor Wallet and GUI:
 This enables the GUI and descriptor wallet support, assuming `sqlite` and `qt5` are installed.
diff --git a/doc/build-osx.md b/doc/build-osx.md
index 76fc357956..1f8ab80a43 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -2,7 +2,7 @@
 
 **Updated for MacOS [11.2](https://www.apple.com/macos/big-sur/)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on macOS
+This guide describes how to build qtumd, command-line utilities, and GUI on macOS
 
 ## Preparation
 
@@ -16,7 +16,7 @@ macOS comes with a built-in Terminal located in:
 ### 1. Xcode Command Line Tools
 
 The Xcode Command Line Tools are a collection of build tools for macOS.
-These tools must be installed in order to build Bitcoin Core from source.
+These tools must be installed in order to build Qtum Core from source.
 
 To install, run the following command from your terminal:
 
@@ -48,24 +48,28 @@ See [dependencies.md](dependencies.md) for a complete overview.
 To install, run the following from your terminal:
 
 ``` bash
-brew install automake libtool boost pkg-config libevent
+brew install cmake automake berkeley-db@4 libtool boost@1.76 miniupnpc openssl pkg-config protobuf qt@5 libevent imagemagick librsvg qrencode gmp
 ```
 
-### 4. Clone Bitcoin repository
+Link the specific boost version:
+``` bash
+brew link boost@1.76
+
+### 4. Clone Qtum repository
 
 `git` should already be installed by default on your system.
-Now that all the required dependencies are installed, let's clone the Bitcoin Core repository to a directory.
+Now that all the required dependencies are installed, let's clone the Qtum Core repository to a directory.
 All build scripts and commands will run from this directory.
 
 ``` bash
-git clone https://github.com/bitcoin/bitcoin.git
+git clone --recursive https://github.com/qtumproject/qtum.git
 ```
 
 ### 5. Install Optional Dependencies
 
 #### Wallet Dependencies
 
-It is not necessary to build wallet functionality to run `bitcoind` or  `bitcoin-qt`.
+It is not necessary to build wallet functionality to run `qtumd` or  `qtum-qt`.
 
 ###### Descriptor Wallet Support
 
@@ -88,7 +92,7 @@ brew install berkeley-db@4
 
 ###### Qt
 
-Bitcoin Core includes a GUI built with the cross-platform Qt Framework.
+Qtum Core includes a GUI built with the cross-platform Qt Framework.
 To compile the GUI, we need to install `qt@5`.
 Skip if you don't intend to use the GUI.
 
@@ -163,14 +167,14 @@ brew install python
 
 #### Deploy Dependencies
 
-You can deploy a `.zip` containing the Bitcoin Core application using `make deploy`.
+You can deploy a `.zip` containing the Qtum Core application using `make deploy`.
 It is required that you have `python` installed.
 
-## Building Bitcoin Core
+## Building Qtum Core
 
 ### 1. Configuration
 
-There are many ways to configure Bitcoin Core, here are a few common examples:
+There are many ways to configure Qtum Core, here are a few common examples:
 
 ##### Wallet (BDB + SQlite) Support, No GUI:
 
@@ -215,7 +219,7 @@ Examine the output of the following command for a full list of configuration opt
 ### 2. Compile
 
 After configuration, you are ready to compile.
-Run the following in your terminal to compile Bitcoin Core:
+Run the following in your terminal to compile Qtum Core:
 
 ``` bash
 make        # use "-j N" here for N parallel jobs
@@ -230,41 +234,41 @@ You can also create a  `.zip` containing the `.app` bundle by running the follow
 make deploy
 ```
 
-## Running Bitcoin Core
+## Running Qtum Core
 
-Bitcoin Core should now be available at `./src/bitcoind`.
-If you compiled support for the GUI, it should be available at `./src/qt/bitcoin-qt`.
+Qtum Core should now be available at `./src/qtumd`.
+If you compiled support for the GUI, it should be available at `./src/qt/qtum-qt`.
 
-The first time you run `bitcoind` or `bitcoin-qt`, it will start downloading the blockchain.
+The first time you run `qtumd` or `qtum-qt`, it will start downloading the blockchain.
 This process could take many hours, or even days on slower than average systems.
 
 By default, blockchain and wallet data files will be stored in:
 
 ``` bash
-/Users/${USER}/Library/Application Support/Bitcoin/
+/Users/${USER}/Library/Application Support/Qtum/
 ```
 
 Before running, you may create an empty configuration file:
 
 ```shell
-mkdir -p "/Users/${USER}/Library/Application Support/Bitcoin"
+mkdir -p "/Users/${USER}/Library/Application Support/Qtum"
 
-touch "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+touch "/Users/${USER}/Library/Application Support/Qtum/qtum.conf"
 
-chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+chmod 600 "/Users/${USER}/Library/Application Support/Qtum/qtum.conf"
 ```
 
 You can monitor the download process by looking at the debug.log file:
 
 ```shell
-tail -f $HOME/Library/Application\ Support/Bitcoin/debug.log
+tail -f $HOME/Library/Application\ Support/Qtum/debug.log
 ```
 
 ## Other commands:
 
 ```shell
-./src/bitcoind -daemon      # Starts the bitcoin daemon.
-./src/bitcoin-cli --help    # Outputs a list of command-line options.
-./src/bitcoin-cli help      # Outputs a list of RPC commands when the daemon is running.
-./src/qt/bitcoin-qt -server # Starts the bitcoin-qt server mode, allows bitcoin-cli control
+./src/qtumd -daemon      # Starts the qtum daemon.
+./src/qtum-cli --help    # Outputs a list of command-line options.
+./src/qtum-cli help      # Outputs a list of RPC commands when the daemon is running.
+./src/qt/qtum-qt -server # Starts the qtum-qt server mode, allows qtum-cli control
 ```
diff --git a/doc/build-unix.md b/doc/build-unix.md
index bf367fc421..df242420c5 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -1,6 +1,6 @@
 UNIX BUILD NOTES
 ====================
-Some notes on how to build Bitcoin Core in Unix.
+Some notes on how to build Qtum Core in Unix.
 
 (For BSD specific instructions, see `build-*bsd.md` in this directory.)
 
@@ -21,7 +21,7 @@ distributions](#linux-distribution-specific-instructions), or the
 ## Memory Requirements
 
 C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
-memory available when compiling Bitcoin Core. On systems with less, gcc can be
+memory available when compiling Qtum Core. On systems with less, gcc can be
 tuned to conserve memory with additional CXXFLAGS:
 
 
@@ -44,7 +44,7 @@ Finally, clang (often less resource hungry) can be used instead of gcc, which is
 
 Build requirements:
 
-    sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3
+    sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3 libgmp3-dev
 
 Now, you can either build from self-compiled [depends](#dependencies) or install the required dependencies:
 
@@ -59,7 +59,7 @@ but these will install Berkeley DB 5.3 or later. This will break binary wallet c
 executables, which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass
 `--with-incompatible-bdb` to configure. Otherwise, you can build Berkeley DB [yourself](#berkeley-db).
 
-To build Bitcoin Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
+To build Qtum Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
 
 Optional port mapping libraries (see: `--with-miniupnpc` and `--with-natpmp`):
 
@@ -75,7 +75,7 @@ User-Space, Statically Defined Tracing (USDT) dependencies:
 
 GUI dependencies:
 
-If you want to build bitcoin-qt, make sure that the required packages for Qt development
+If you want to build qtum-qt, make sure that the required packages for Qt development
 are installed. Qt 5 is necessary to build the GUI.
 To build without GUI pass `--without-gui`.
 
@@ -91,7 +91,7 @@ libqrencode (optional) can be installed with:
 
     sudo apt-get install libqrencode-dev
 
-Once these are installed, they will be found by configure and a bitcoin-qt executable will be
+Once these are installed, they will be found by configure and a qtum-qt executable will be
 built by default.
 
 
@@ -101,7 +101,7 @@ built by default.
 
 Build requirements:
 
-    sudo dnf install gcc-c++ libtool make autoconf automake python3
+    sudo dnf install gcc-c++ libtool make autoconf automake python3 gmp-devel
 
 Now, you can either build from self-compiled [depends](#dependencies) or install the required dependencies:
 
@@ -116,7 +116,7 @@ Berkeley DB 5.3 or later. This will break binary wallet compatibility with the d
 are based on Berkeley DB 4.8. If you do not care about wallet compatibility,
 pass `--with-incompatible-bdb` to configure. Otherwise, you can build Berkeley DB [yourself](#berkeley-db).
 
-To build Bitcoin Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
+To build Qtum Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
 
 Optional port mapping libraries (see: `--with-miniupnpc` and `--with-natpmp`):
 
@@ -132,7 +132,7 @@ User-Space, Statically Defined Tracing (USDT) dependencies:
 
 GUI dependencies:
 
-If you want to build bitcoin-qt, make sure that the required packages for Qt development
+If you want to build qtum-qt, make sure that the required packages for Qt development
 are installed. Qt 5 is necessary to build the GUI.
 To build without GUI pass `--without-gui`.
 
@@ -148,9 +148,75 @@ libqrencode (optional) can be installed with:
 
     sudo dnf install qrencode-devel
 
-Once these are installed, they will be found by configure and a bitcoin-qt executable will be
+Once these are installed, they will be found by configure and a qtum-qt executable will be
 built by default.
 
+Dependency Build Instructions: CentOS
+-------------------------------------
+
+You need to build boost manually, and if it's not in standard library paths, you need to add `/path/to/boost/lib` into `LD_LIBRARY_PATH` env when building Qtum.
+
+Build requirements:
+
+    sudo yum install epel-release
+    sudo yum install gcc-c++ libtool libdb4-cxx-devel openssl-devel libevent-devel gmp-devel
+    
+To build with Qt 5 (recommended) you need the following:
+
+    sudo yum install qt5-qttools-devel protobuf-devel qrencode-devel
+
+### Ubuntu 16
+#### Dependency Build Instructions
+Build requirements:
+```
+./qtum/contrib/script/setup-ubuntu16.sh
+```
+
+#### Build Installation Package
+Build Qtum:
+```
+cd qtum/contrib/script
+./build-qtum-linux.sh -j2
+```
+The home folder for the installation package need to be `qtum/contrib/script`.
+After the build finish, the installation package is present into `qtum/contrib/script`.
+Installation package example: `qtum-22.1-x86_64-pc-linux-gnu.tar.gz`
+
+#### Dependencies Installation Package
+
+The package has the following dependencies when used on Ubuntu 16 machine that is not used for building Qtum:
+
+`qtum-qt` require `libxcb-xinerama0` to be installed on Ubuntu 16 (both 32 and 64 bit versions):
+```
+sudo apt-get install libxcb-xinerama0 -y
+```
+
+Qtum require `GCC 7` standard library be installed for Ubuntu 16 only on 32 bit version:
+```
+sudo add-apt-repository ppa:ubuntu-toolchain-r/test
+sudo apt-get update
+sudo apt-get install gcc-7 g++-7 -y
+```
+
+### CentOS 7
+#### Dependency Build Instructions
+Build requirements:
+```
+su
+./qtum/contrib/script/setup-centos7.sh
+```
+The operating system might restart after finish with installing the build requirements.
+
+#### Build Installation Package
+Build Qtum:
+```
+cd qtum/contrib/script
+./build-qtum-linux.sh -j2
+```
+The home folder for the installation package need to be `qtum/contrib/script`.
+After the build finish, the installation package is present into `qtum/contrib/script`.
+Installation package example: `qtum-22.1-x86_64-pc-linux-gnu.tar.gz`
+
 ## Dependencies
 
 See [dependencies.md](dependencies.md) for a complete overview, and
@@ -165,11 +231,11 @@ want to use any other libraries built in depends, you can do:
 ```bash
 make -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_SQLITE=1 NO_NATPMP=1 NO_UPNP=1 NO_ZMQ=1 NO_USDT=1
 ...
-to: /path/to/bitcoin/depends/x86_64-pc-linux-gnu
+to: /path/to/qtum/depends/x86_64-pc-linux-gnu
 ```
 and configure using the following:
 ```bash
-export BDB_PREFIX="/path/to/bitcoin/depends/x86_64-pc-linux-gnu"
+export BDB_PREFIX="/path/to/qtum/depends/x86_64-pc-linux-gnu"
 
 ./configure \
     BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" \
@@ -182,7 +248,7 @@ export BDB_PREFIX="/path/to/bitcoin/depends/x86_64-pc-linux-gnu"
 
 Disable-wallet mode
 --------------------
-When the intention is to only run a P2P node, without a wallet, Bitcoin Core can
+When the intention is to only run a P2P node, without a wallet, Qtum Core can
 be compiled in disable-wallet mode with:
 
     ./configure --disable-wallet
@@ -202,12 +268,12 @@ Setup and Build Example: Arch Linux
 -----------------------------------
 This example lists the steps necessary to setup and build a command line only distribution of the latest changes on Arch Linux:
 
-    pacman --sync --needed autoconf automake boost gcc git libevent libtool make pkgconf python sqlite
-    git clone https://github.com/bitcoin/bitcoin.git
-    cd bitcoin/
+    pacman --sync --needed autoconf automake boost gcc git libevent libtool make pkgconf python sqlite gmp
+    git clone https://github.com/qtumproject/qtum --recursive
+    cd qtum/
     ./autogen.sh
     ./configure
     make check
-    ./src/bitcoind
+    ./src/qtumd
 
 If you intend to work with legacy Berkeley DB wallets, see [Berkeley DB](#berkeley-db) section.
diff --git a/doc/build-windows.md b/doc/build-windows.md
index 027e8f80f5..278caaa77f 100644
--- a/doc/build-windows.md
+++ b/doc/build-windows.md
@@ -1,9 +1,9 @@
 WINDOWS BUILD NOTES
 ====================
 
-Below are some notes on how to build Bitcoin Core for Windows.
+Below are some notes on how to build Qtum Core for Windows.
 
-The options known to work for building Bitcoin Core on Windows are:
+The options known to work for building Qtum Core on Windows are:
 
 * On Linux, using the [Mingw-w64](https://www.mingw-w64.org/) cross compiler tool chain.
 * On Windows, using [Windows Subsystem for Linux (WSL)](https://learn.microsoft.com/en-us/windows/wsl/about) and Mingw-w64.
@@ -29,7 +29,7 @@ First, install the general dependencies:
 
     sudo apt update
     sudo apt upgrade
-    sudo apt install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git
+    sudo apt install build-essential libtool autotools-dev automake cmake pkg-config bsdmainutils curl git
 
 A host toolchain (`build-essential`) is necessary because some dependency
 packages need to build host utilities that are used in the build process.
@@ -42,8 +42,8 @@ If you want to build the windows installer with `make deploy` you need [NSIS](ht
 
 Acquire the source in the usual way:
 
-    git clone https://github.com/bitcoin/bitcoin.git
-    cd bitcoin
+    git clone https://github.com/qtumproject/qtum --recursive
+    cd qtum
 
 ## Building for 64-bit Windows
 
@@ -62,8 +62,8 @@ sudo apt install g++-mingw-w64-x86-64
 
 Once the toolchain is installed the build steps are common:
 
-Note that for WSL the Bitcoin Core source path MUST be somewhere in the default mount file system, for
-example /usr/src/bitcoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
+Note that for WSL the Qtum Core source path MUST be somewhere in the default mount file system, for
+example /usr/src/qtum, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
 This means you cannot use a directory that is located directly on the host Windows file system to perform the build.
 
 Additional WSL Note: WSL support for [launching Win32 applications](https://learn.microsoft.com/en-us/archive/blogs/wsl/windows-and-ubuntu-interoperability#launching-win32-applications-from-within-wsl)
@@ -93,9 +93,9 @@ Installation
 After building using the Windows subsystem it can be useful to copy the compiled
 executables to a directory on the Windows drive in the same directory structure
 as they appear in the release `.zip` archive. This can be done in the following
-way. This will install to `c:\workspace\bitcoin`, for example:
+way. This will install to `c:\workspace\qtum`, for example:
 
-    make install DESTDIR=/mnt/c/workspace/bitcoin
+    make install DESTDIR=/mnt/c/workspace/qtum
 
 You can also create an installer using:
 
diff --git a/doc/design/multiprocess.md b/doc/design/multiprocess.md
index e6a77dbbc0..c2782c95a9 100644
--- a/doc/design/multiprocess.md
+++ b/doc/design/multiprocess.md
@@ -1,15 +1,15 @@
-# Multiprocess Bitcoin
+# Multiprocess Qtum
 
-On unix systems, the `--enable-multiprocess` build option can be passed to `./configure` to build new `bitcoin-node`, `bitcoin-wallet`, and `bitcoin-gui` executables alongside existing `bitcoind` and `bitcoin-qt` executables.
+On unix systems, the `--enable-multiprocess` build option can be passed to `./configure` to build new `qtum-node`, `qtum-wallet`, and `qtum-gui` executables alongside existing `qtumd` and `qtum-qt` executables.
 
-`bitcoin-node` is a drop-in replacement for `bitcoind`, and `bitcoin-gui` is a drop-in replacement for `bitcoin-qt`, and there are no differences in use or external behavior between the new and old executables. But internally (after [#10102](https://github.com/bitcoin/bitcoin/pull/10102)), `bitcoin-gui` will spawn a `bitcoin-node` process to run P2P and RPC code, communicating with it across a socket pair, and `bitcoin-node` will spawn `bitcoin-wallet` to run wallet code, also communicating over a socket pair. This will let node, wallet, and GUI code run in separate address spaces for better isolation, and allow future improvements like being able to start and stop components independently on different machines and environments.
+`qtum-node` is a drop-in replacement for `qtumd`, and `qtum-gui` is a drop-in replacement for `qtum-qt`, and there are no differences in use or external behavior between the new and old executables. But internally (after [#10102](https://github.com/bitcoin/bitcoin/pull/10102)), `qtum-gui` will spawn a `qtum-node` process to run P2P and RPC code, communicating with it across a socket pair, and `qtum-node` will spawn `qtum-wallet` to run wallet code, also communicating over a socket pair. This will let node, wallet, and GUI code run in separate address spaces for better isolation, and allow future improvements like being able to start and stop components independently on different machines and environments.
 
 ## Next steps
 
 Specific next steps after [#10102](https://github.com/bitcoin/bitcoin/pull/10102) will be:
 
-- [ ] Adding `-ipcbind` and `-ipcconnect` options to `bitcoin-node`, `bitcoin-wallet`, and `bitcoin-gui` executables so they can listen and connect to TCP ports and unix socket paths. This will allow separate processes to be started and stopped any time and connect to each other.
-- [ ] Adding `-server` and `-rpcbind` options to the `bitcoin-wallet` executable so wallet processes can handle RPC requests directly without going through the node.
+- [ ] Adding `-ipcbind` and `-ipcconnect` options to `qtum-node`, `qtum-wallet`, and `qtum-gui` executables so they can listen and connect to TCP ports and unix socket paths. This will allow separate processes to be started and stopped any time and connect to each other.
+- [ ] Adding `-server` and `-rpcbind` options to the `qtum-wallet` executable so wallet processes can handle RPC requests directly without going through the node.
 - [ ] Supporting windows, not just unix systems. The existing socket code is already cross-platform, so the only windows-specific code that needs to be written is code spawning a process and passing a socket descriptor. This can be implemented with `CreateProcess` and `WSADuplicateSocket`. Example: https://memset.wordpress.com/2010/10/13/win32-api-passing-socket-with-ipc-method/.
 - [ ] Adding sandbox features, restricting subprocess access to resources and data. See [https://eklitzke.org/multiprocess-bitcoin](https://eklitzke.org/multiprocess-bitcoin).
 
@@ -26,8 +26,8 @@ cd <BITCOIN_SOURCE_DIRECTORY>
 make -C depends NO_QT=1 MULTIPROCESS=1
 CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure
 make
-src/bitcoin-node -regtest -printtoconsole -debug=ipc
-BITCOIND=bitcoin-node test/functional/test_runner.py
+src/qtum-node -regtest -printtoconsole -debug=ipc
+BITCOIND=qtum-node test/functional/test_runner.py
 ```
 
 The configure script will pick up settings and library locations from the depends directory, so there is no need to pass `--enable-multiprocess` as a separate flag when using the depends system (it's controlled by the `MULTIPROCESS=1` option).
diff --git a/doc/files.md b/doc/files.md
index f88d3f91a1..18f642cc7d 100644
--- a/doc/files.md
+++ b/doc/files.md
@@ -1,4 +1,4 @@
-# Bitcoin Core file system
+# Qtum Core file system
 
 **Contents**
 
@@ -20,19 +20,19 @@
 
 ## Data directory location
 
-The data directory is the default location where the Bitcoin Core files are stored.
+The data directory is the default location where the Qtum Core files are stored.
 
 1. The default data directory paths for supported platforms are:
 
 Platform | Data directory path
 ---------|--------------------
-Linux    | `$HOME/.bitcoin/`
-macOS    | `$HOME/Library/Application Support/Bitcoin/`
-Windows  | `%APPDATA%\Bitcoin\` <sup>[\[1\]](#note1)</sup>
+Linux    | `$HOME/.qtum/`
+macOS    | `$HOME/Library/Application Support/Qtum/`
+Windows  | `%APPDATA%\Qtum\` <sup>[\[1\]](#note1)</sup>
 
 2. A custom data directory path can be specified with the `-datadir` option.
 
-3. All content of the data directory, except for `bitcoin.conf` file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:
+3. All content of the data directory, except for `qtum.conf` file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:
 
 Chain option                   | Data directory path
 -------------------------------|------------------------------
@@ -47,7 +47,7 @@ Subdirectory       | File(s)               | Description
 -------------------|-----------------------|------------
 `blocks/`          |                       | Blocks directory; can be specified by `-blocksdir` option (except for `blocks/index/`)
 `blocks/index/`    | LevelDB database      | Block index; `-blocksdir` option does not affect this path
-`blocks/`          | `blkNNNNN.dat`<sup>[\[2\]](#note2)</sup> | Actual Bitcoin blocks (in network format, dumped in raw on disk, 128 MiB per file)
+`blocks/`          | `blkNNNNN.dat`<sup>[\[2\]](#note2)</sup> | Actual Qtum blocks (in network format, dumped in raw on disk, 128 MiB per file)
 `blocks/`          | `revNNNNN.dat`<sup>[\[2\]](#note2)</sup> | Block undo data (custom format)
 `chainstate/`      | LevelDB database      | Blockchain state (a compact representation of all currently unspent transaction outputs (UTXOs) and metadata about the transactions they are from)
 `indexes/txindex/` | LevelDB database      | Transaction index; *optional*, used if `-txindex=1`
@@ -57,9 +57,9 @@ Subdirectory       | File(s)               | Description
 `wallets/`         |                       | [Contains wallets](#multi-wallet-environment); can be specified by `-walletdir` option; if `wallets/` subdirectory does not exist, wallets reside in the [data directory](#data-directory-location)
 `./`               | `anchors.dat`         | Anchor IP address database, created on shutdown and deleted at startup. Anchors are last known outgoing block-relay-only peers that are tried to re-connect to on startup
 `./`               | `banlist.json`        | Stores the addresses/subnets of banned nodes.
-`./`               | `bitcoin.conf`        | User-defined [configuration settings](bitcoin-conf.md) for `bitcoind` or `bitcoin-qt`. File is not written to by the software and must be created manually. Path can be specified by `-conf` option
-`./`               | `bitcoind.pid`        | Stores the process ID (PID) of `bitcoind` or `bitcoin-qt` while running; created at start and deleted on shutdown; can be specified by `-pid` option
-`./`               | `debug.log`           | Contains debug information and general logging generated by `bitcoind` or `bitcoin-qt`; can be specified by `-debuglogfile` option
+`./`               | `qtum.conf`        | User-defined [configuration settings](bitcoin-conf.md) for `qtumd` or `qtum-qt`. File is not written to by the software and must be created manually. Path can be specified by `-conf` option
+`./`               | `qtumd.pid`        | Stores the process ID (PID) of `qtumd` or `qtum-qt` while running; created at start and deleted on shutdown; can be specified by `-pid` option
+`./`               | `debug.log`           | Contains debug information and general logging generated by `qtumd` or `qtum-qt`; can be specified by `-debuglogfile` option
 `./`               | `fee_estimates.dat`   | Stores statistics used to estimate minimum transaction fees required for confirmation
 `./`               | `guisettings.ini.bak` | Backup of former [GUI settings](#gui-settings) after `-resetguisettings` option is used
 `./`               | `ip_asn.map`          | IP addresses to Autonomous System Numbers (ASNs) mapping used for bucketing of the peers; path can be specified with the `-asmap` option
@@ -67,7 +67,7 @@ Subdirectory       | File(s)               | Description
 `./`               | `onion_v3_private_key` | Cached Tor onion service private key for `-listenonion` option
 `./`               | `i2p_private_key`     | Private key that corresponds to our I2P address. When `-i2psam=` is specified the contents of this file is used to identify ourselves for making outgoing connections to I2P peers and possibly accepting incoming ones. Automatically generated if it does not exist.
 `./`               | `peers.dat`           | Peer IP address database (custom format)
-`./`               | `settings.json`       | Read-write settings set through GUI or RPC interfaces, augmenting manual settings from [bitcoin.conf](bitcoin-conf.md). File is created automatically if read-write settings storage is not disabled with `-nosettings` option. Path can be specified with `-settings` option
+`./`               | `settings.json`       | Read-write settings set through GUI or RPC interfaces, augmenting manual settings from [qtum.conf](bitcoin-conf.md). File is created automatically if read-write settings storage is not disabled with `-nosettings` option. Path can be specified with `-settings` option
 `./`               | `.cookie`             | Session RPC authentication cookie; if used, created at start and deleted on shutdown; can be specified by `-rpccookiefile` option
 `./`               | `.lock`               | Data directory lock file
 
@@ -105,11 +105,11 @@ Subdirectory | File                 | Description
 
 ## GUI settings
 
-`bitcoin-qt` uses [`QSettings`](https://doc.qt.io/qt-5/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored).
+`qtum-qt` uses [`QSettings`](https://doc.qt.io/qt-5/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored).
 
 ## Legacy subdirectories and files
 
-These subdirectories and files are no longer used by Bitcoin Core:
+These subdirectories and files are no longer used by Qtum Core:
 
 Path           | Description | Repository notes
 ---------------|-------------|-----------------
diff --git a/doc/productivity.md b/doc/productivity.md
index e9b7bc270c..5946d73f92 100644
--- a/doc/productivity.md
+++ b/doc/productivity.md
@@ -75,9 +75,9 @@ When rebuilding during development, note that running `make`, without giving a t
 Obviously, it is important to build and run the tests at appropriate times -- but when you just want a quick compile to check your work, consider picking one or a set of build targets relevant to what you're working on, e.g.:
 
 ```sh
-make src/bitcoind src/bitcoin-cli
-make src/qt/bitcoin-qt
-make -C src bitcoin_bench
+make src/qtumd src/qtum-cli
+make src/qt/qtum-qt
+make -C src qtum_bench
 ```
 
 (You can and should combine this with `-j`, as above, for a parallel build.)
@@ -179,7 +179,7 @@ When looking at other's pull requests, it may make sense to add the following se
 ```
 [remote "upstream-pull"]
         fetch = +refs/pull/*/head:refs/remotes/upstream-pull/*
-        url = git@github.com:bitcoin/bitcoin.git
+        url = git@github.com:qtumproject/qtum.git
 ```
 
 This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all` or `git fetch upstream-pull`. It will download and store on disk quite a lot of data (all PRs, including merged and closed ones). Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`, `git checkout` and anywhere a commit id would be acceptable to see the changes from pull request NUMBER.
diff --git a/doc/reduce-memory.md b/doc/reduce-memory.md
index 2710797ef3..07383870c7 100644
--- a/doc/reduce-memory.md
+++ b/doc/reduce-memory.md
@@ -1,6 +1,6 @@
 # Reduce Memory
 
-There are a few parameters that can be dialed down to reduce the memory usage of `bitcoind`. This can be useful on embedded systems or small VPSes.
+There are a few parameters that can be dialed down to reduce the memory usage of `qtumd`. This can be useful on embedded systems or small VPSes.
 
 ## In-memory caches
 
@@ -12,9 +12,9 @@ The size of some in-memory caches can be reduced. As caches trade off memory usa
 
 ## Memory pool
 
-- In Bitcoin Core there is a memory pool limiter which can be configured with `-maxmempool=<n>`, where `<n>` is the size in MB (1000). The default value is `300`.
+- In Qtum Core there is a memory pool limiter which can be configured with `-maxmempool=<n>`, where `<n>` is the size in MB (1000). The default value is `300`.
   - The minimum value for `-maxmempool` is 5.
-  - A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of `bitcoind` that process unconfirmed transactions.
+  - A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of `qtumd` that process unconfirmed transactions.
 
 - Since `0.14.0`, unused memory allocated to the mempool (default: 300MB) is shared with the UTXO cache, so when trying to reduce memory usage you should limit the mempool, with the `-maxmempool` command line argument.
 
@@ -43,12 +43,12 @@ threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a
 
 ## Linux specific
 
-By default, glibc's implementation of `malloc` may use more than one arena. This is known to cause excessive memory usage in some scenarios. To avoid this, make a script that sets `MALLOC_ARENA_MAX` before starting bitcoind:
+By default, glibc's implementation of `malloc` may use more than one arena. This is known to cause excessive memory usage in some scenarios. To avoid this, make a script that sets `MALLOC_ARENA_MAX` before starting qtumd:
 
 ```bash
 #!/usr/bin/env bash
 export MALLOC_ARENA_MAX=1
-bitcoind
+qtumd
 ```
 
-The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Bitcoin Core very little parallel allocation happens, so the impact is expected to be small or absent.
+The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Qtum Core very little parallel allocation happens, so the impact is expected to be small or absent.
diff --git a/test/README.md b/test/README.md
index fee8828d34..97824cdc99 100644
--- a/test/README.md
+++ b/test/README.md
@@ -1,4 +1,4 @@
-This directory contains integration tests that test bitcoind and its
+This directory contains integration tests that test qtumd and its
 utilities in their entirety. It does not contain unit tests, which
 can be found in [/src/test](/src/test), [/src/wallet/test](/src/wallet/test),
 etc.
@@ -8,9 +8,9 @@ This directory contains the following sets of tests:
 - [fuzz](/test/fuzz) A runner to execute all fuzz targets from
   [/src/test/fuzz](/src/test/fuzz).
 - [functional](/test/functional) which test the functionality of
-bitcoind and bitcoin-qt by interacting with them through the RPC and P2P
+qtumd and qtum-qt by interacting with them through the RPC and P2P
 interfaces.
-- [util](/test/util) which tests the utilities (bitcoin-util, bitcoin-tx, ...).
+- [util](/test/util) which tests the utilities (qtum-util, qtum-tx, ...).
 - [lint](/test/lint/) which perform various static analysis checks.
 
 The util tests are run as part of `make check` target. The fuzz tests, functional
@@ -18,7 +18,7 @@ tests and lint scripts can be run as explained in the sections below.
 
 # Running tests locally
 
-Before tests can be run locally, Bitcoin Core must be built.  See the [building instructions](/doc#building) for help.
+Before tests can be run locally, Qtum Core must be built.  See the [building instructions](/doc#building) for help.
 
 ## Fuzz tests
 
@@ -164,29 +164,29 @@ umount /Volumes/ramdisk
 
 ##### Resource contention
 
-The P2P and RPC ports used by the bitcoind nodes-under-test are chosen to make
-conflicts with other processes unlikely. However, if there is another bitcoind
+The P2P and RPC ports used by the qtumd nodes-under-test are chosen to make
+conflicts with other processes unlikely. However, if there is another qtumd
 process running on the system (perhaps from a previous test which hasn't successfully
-killed all its bitcoind nodes), then there may be a port conflict which will
+killed all its qtumd nodes), then there may be a port conflict which will
 cause the test to fail. It is recommended that you run the tests on a system
-where no other bitcoind processes are running.
+where no other qtumd processes are running.
 
 On linux, the test framework will warn if there is another
-bitcoind process running when the tests are started.
+qtumd process running when the tests are started.
 
-If there are zombie bitcoind processes after test failure, you can kill them
+If there are zombie qtumd processes after test failure, you can kill them
 by running the following commands. **Note that these commands will kill all
-bitcoind processes running on the system, so should not be used if any non-test
-bitcoind processes are being run.**
+qtumd processes running on the system, so should not be used if any non-test
+qtumd processes are being run.**
 
 ```bash
-killall bitcoind
+killall qtumd
 ```
 
 or
 
 ```bash
-pkill -9 bitcoind
+pkill -9 qtumd
 ```
 
 
@@ -197,11 +197,11 @@ functional test is run and is stored in test/cache. This speeds up
 test startup times since new blockchains don't need to be generated for
 each test. However, the cache may get into a bad state, in which case
 tests will fail. If this happens, remove the cache directory (and make
-sure bitcoind processes are stopped as above):
+sure qtumd processes are stopped as above):
 
 ```bash
 rm -rf test/cache
-killall bitcoind
+killall qtumd
 ```
 
 ##### Test logging
@@ -216,7 +216,7 @@ levels using the logger included in the test_framework, e.g.
 - when run directly, *all* logs are written to `test_framework.log` and INFO
   level and above are output to the console.
 - when run by [our CI (Continuous Integration)](/ci/README.md), no logs are output to the console. However, if a test
-  fails, the `test_framework.log` and bitcoind `debug.log`s will all be dumped
+  fails, the `test_framework.log` and qtumd `debug.log`s will all be dumped
   to the console to help troubleshooting.
 
 These log files can be located under the test data directory (which is always
@@ -231,7 +231,7 @@ e.g. `self.nodes[0]`.
 To change the level of logs output to the console, use the `-l` command line
 argument.
 
-`test_framework.log` and bitcoind `debug.log`s can be combined into a single
+`test_framework.log` and qtumd `debug.log`s can be combined into a single
 aggregate log by running the `combine_logs.py` script. The output can be plain
 text, colorized text or html. For example:
 
@@ -258,9 +258,9 @@ import pdb; pdb.set_trace()
 ```
 
 anywhere in the test. You will then be able to inspect variables, as well as
-call methods that interact with the bitcoind nodes-under-test.
+call methods that interact with the qtumd nodes-under-test.
 
-If further introspection of the bitcoind instances themselves becomes
+If further introspection of the qtumd instances themselves becomes
 necessary, this can be accomplished by first setting a pdb breakpoint
 at an appropriate location, running the test to that point, then using
 `gdb` (or `lldb` on macOS) to attach to the process and debug.
@@ -283,13 +283,13 @@ test run:
 Use the path to find the pid file in the temp folder:
 
 ```bash
-cat /tmp/user/1000/testo9vsdjo3/node1/regtest/bitcoind.pid
+cat /tmp/user/1000/testo9vsdjo3/node1/regtest/qtumd.pid
 ```
 
 Then you can use the pid to start `gdb`:
 
 ```bash
-gdb /home/example/bitcoind <pid>
+gdb /home/example/qtumd <pid>
 ```
 
 Note: gdb attach step may require ptrace_scope to be modified, or `sudo` preceding the `gdb`.