diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in
index 58c65fb7e25..26fe26244e3 100644
--- a/doc/Doxyfile.in
+++ b/doc/Doxyfile.in
@@ -32,7 +32,7 @@ DOXYFILE_ENCODING      = UTF-8
 # title of most generated pages and in a few other places.
 # The default value is: My Project.
 
-PROJECT_NAME           = "Bitcoin Core"
+PROJECT_NAME           = "Peercoin"
 
 # The PROJECT_NUMBER tag can be used to enter a project or revision number. This
 # could be handy for archiving the generated documentation or if some version
@@ -51,7 +51,7 @@ PROJECT_BRIEF          = "P2P Digital Currency"
 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
 # the logo to the output directory.
 
-PROJECT_LOGO           = doc/bitcoin_logo_doxygen.png
+PROJECT_LOGO           = src/qt/res/icons/peercoin.png
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
 # into which the generated documentation will be written. If a relative path is
diff --git a/doc/README.md b/doc/README.md
index 901c123a6da..70cc861d08b 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -4,7 +4,7 @@ Setup
 ---------------------
 Peercoin Core is the original Peercoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Peercoin transactions (which is currently more than 100 GBs); 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 Peercoin Core, visit [peercoin.net](https://peercoin.net/download).
+To download Peercoin, visit [peercoin.net](https://peercoin.net/download).
 
 Running
 ---------------------
@@ -27,8 +27,9 @@ Drag Peercoin-Core to your applications folder, and then run Peercoin-Core.
 
 ### Need Help?
 
-* See the documentation at the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page)
-for help and more information. Peercoin is very similar to bitcoin, so you can use their wiki.
+* See the documentation at the [Peercoin Wiki](https://docs.peercoin.net/)
+for help and more information.
+* Peercoin is very similar to bitcoin, so you can use their wiki [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page).
 * Ask for help on [#general](https://peercoin.chat/) on peercoin.chat.
 
 Building
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
index a1a8567f0e0..0785736fde5 100644
--- a/doc/README_windows.txt
+++ b/doc/README_windows.txt
@@ -25,6 +25,6 @@ However, it downloads and stores the entire history of Peercoin transactions;
 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.
 
-See the bitcoin wiki at:
-  https://en.bitcoin.it/wiki/Main_Page
+See the peercoin documentation at:
+  https://docs.peercoin.net/
 for more help and information.
diff --git a/doc/REST-interface.md b/doc/REST-interface.md
index f3dc124ece9..7837b3d0106 100644
--- a/doc/REST-interface.md
+++ b/doc/REST-interface.md
@@ -100,4 +100,4 @@ Only supports JSON as output format.
 
 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 peercoind 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/assets-attribution.md b/doc/assets-attribution.md
index 2dd930d6a4f..b01f1cfcd81 100644
--- a/doc/assets-attribution.md
+++ b/doc/assets-attribution.md
@@ -1 +1 @@
-The list of assets used in the bitcoin source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).
+The list of assets used in the peercoin source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).
diff --git a/doc/benchmarking.md b/doc/benchmarking.md
index 99d36cb2261..9a305f2e2e0 100644
--- a/doc/benchmarking.md
+++ b/doc/benchmarking.md
@@ -1,12 +1,12 @@
 Benchmarking
 ============
 
-Bitcoin Core has an internal benchmarking framework, with benchmarks
+Peercoin has an internal benchmarking framework, with benchmarks
 for cryptographic algorithms such as SHA1, SHA256, SHA512 and RIPEMD160. As well as the rolling bloom filter.
 
 Running
 ---------------------
-After compiling bitcoin-core, the benchmarks can be run with:
+After compiling peercoin, the benchmarks can be run with:
 
     src/bench/bench_bitcoin
 
diff --git a/doc/build-netbsd.md b/doc/build-netbsd.md
index 5bf2d6b59b8..95c06be8e76 100644
--- a/doc/build-netbsd.md
+++ b/doc/build-netbsd.md
@@ -2,7 +2,7 @@ NetBSD build guide
 ======================
 (updated for NetBSD 7.0)
 
-This guide describes how to build bitcoind and command-line utilities on NetBSD.
+This guide describes how to build peercoind and command-line utilities on NetBSD.
 
 This guide does not contain instructions for building the GUI.
 
@@ -25,12 +25,12 @@ python27
 
 Download the source code:
 ```
-git clone https://github.com/bitcoin/bitcoin
+git clone https://github.com/peercoin/peercoin
 ```
 
 See [dependencies.md](dependencies.md) for a complete overview.
 
-### Building Bitcoin Core
+### Building Peercoin
 
 **Important**: Use `gmake` (the non-GNU `make` will exit with an error).
 
diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md
index 0817821221d..a40e63f80be 100644
--- a/doc/build-openbsd.md
+++ b/doc/build-openbsd.md
@@ -2,7 +2,7 @@ OpenBSD build guide
 ======================
 (updated for OpenBSD 6.2)
 
-This guide describes how to build bitcoind and command-line utilities on OpenBSD.
+This guide describes how to build peercoind and command-line utilities on OpenBSD.
 
 OpenBSD is most commonly used as a server OS, so this guide does not contain instructions for building the GUI.
 
@@ -18,7 +18,7 @@ pkg_add automake # (select highest version, e.g. 1.15)
 pkg_add python # (select highest version, e.g. 3.6)
 pkg_add boost
 
-git clone https://github.com/bitcoin/bitcoin.git
+git clone https://github.com/peercoin/peercoin.git
 ```
 
 See [dependencies.md](dependencies.md) for a complete overview.
@@ -49,7 +49,7 @@ from the root of the repository. Then set `BDB_PREFIX` for the next section:
 export BDB_PREFIX="$PWD/db4"
 ```
 
-### Building Bitcoin Core
+### Building Peercoin
 
 **Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.
 
diff --git a/doc/build-unix.md b/doc/build-unix.md
index f4ea3935c9e..8f4a53bd4bd 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -1,6 +1,6 @@
 UNIX BUILD NOTES
 ====================
-Some notes on how to build Peercoin Core in Unix.
+Some notes on how to build Peercoin in Unix.
 
 (for OpenBSD specific instructions, see [build-openbsd.md](build-openbsd.md))
 
@@ -55,7 +55,7 @@ Memory Requirements
 --------------------
 
 C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
-memory available when compiling Peercoin Core. On systems with less, gcc can be
+memory available when compiling Peercoin. On systems with less, gcc can be
 tuned to conserve memory with additional CXXFLAGS:
 
 
@@ -80,7 +80,7 @@ install necessary parts of boost:
         sudo apt-get install libboost-all-dev
 	
 BerkeleyDB is required for the wallet functionality.
-Historically Bitcoin was first deployed with now deprecated BerkeleyDB-4.8, which has resulted in the need to upkeep the compatibility with those ancient deployments to this day. BerkeleyDB-4.8 is not compatible with more modern BerkeleyDB-5.1 and BerkeleyDB-5.3. Peercoin has inherited this in the first versions and this is why Peercoin is still officially shipped out with BerkeleyDB-4.8.
+Historically Peercoin was first deployed with now deprecated BerkeleyDB-4.8, which has resulted in the need to upkeep the compatibility with those ancient deployments to this day. BerkeleyDB-4.8 is not compatible with more modern BerkeleyDB-5.1 and BerkeleyDB-5.3. Peercoin has inherited this in the first versions and this is why Peercoin is still officially shipped out with BerkeleyDB-4.8.
 However if you running a new wallet on a new installation there is absolutely no need to run old and deprecated BerkeleyDB-4.8. Just use the one avaliable in the repository of your distribution.
 
 **For Ubuntu only:** db4.8 packages are available [here](https://launchpad.net/~bitcoin/+archive/bitcoin).
diff --git a/doc/build-windows.md b/doc/build-windows.md
index d546d23e6cc..f65a866baac 100644
--- a/doc/build-windows.md
+++ b/doc/build-windows.md
@@ -1,12 +1,12 @@
 WINDOWS BUILD NOTES
 ====================
 
-Below are some notes on how to build Bitcoin Core for Windows.
+Below are some notes on how to build Peercoin for Windows.
 
-The options known to work for building Bitcoin Core on Windows are:
+The options known to work for building Peercoin on Windows are:
 
 * On Linux using the [Mingw-w64](https://mingw-w64.org/doku.php) cross compiler tool chain. Ubuntu Bionic 18.04 is required
-and is the platform used to build the Bitcoin Core Windows release binaries.
+and is the platform used to build the Peercoin Windows release binaries.
 * On Windows using [Windows
 Subsystem for Linux (WSL)](https://msdn.microsoft.com/commandline/wsl/about) and the Mingw-w64 cross compiler tool chain.
 
@@ -78,15 +78,15 @@ Ubuntu Bionic 18.04 <sup>[1](#footnote1)</sup>:
 
 Once the tool chain 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 Peercoin source path MUST be somewhere in the default mount file system, for
+example /usr/src/peercoin, 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 located directly on the host Windows file system to perform the build.
 
 The next three steps are an example of how to acquire the source in an appropriate way.
 
     cd /usr/src
-    sudo git clone https://github.com/bitcoin/bitcoin.git
-    sudo chmod -R a+rw bitcoin
+    sudo git clone https://github.com/peercoin/peercoin.git
+    sudo chmod -R a+rw peercoin
 
 Once the source code is ready the build steps are below.
 
@@ -108,15 +108,15 @@ For Ubuntu Bionic 18.04 and Windows Subsystem for Linux <sup>[1](#footnote1)</su
 
     sudo update-alternatives --config i686-w64-mingw32-g++  # Set the default mingw32 g++ compiler option to posix.
 
-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 Peercoin source path MUST be somewhere in the default mount file system, for
+example /usr/src/peercoin, 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 located directly on the host Windows file system to perform the build.
 
 The next three steps are an example of how to acquire the source in an appropriate way.
 
     cd /usr/src
-    sudo git clone https://github.com/bitcoin/bitcoin.git
-    sudo chmod -R a+rw bitcoin
+    sudo git clone https://github.com/peercoin/peercoin.git
+    sudo chmod -R a+rw peercoin
 
 Then build using:
 
@@ -138,9 +138,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\peercoin`, for example:
 
-    make install DESTDIR=/mnt/c/workspace/bitcoin
+    make install DESTDIR=/mnt/c/workspace/peercoin
 
 Footnotes
 ---------
@@ -149,5 +149,5 @@ Footnotes
 compiler options to allow a choice between either posix or win32 threads. The default option is win32 threads which is the more
 efficient since it will result in binary code that links directly with the Windows kernel32.lib. Unfortunately, the headers
 required to support win32 threads conflict with some of the classes in the C++11 standard library in particular std::mutex.
-It's not possible to build the bitcoin code using the win32 version of the Mingw-w64 cross compilers (at least not without
-modifying headers in the bitcoin source code).
+It's not possible to build the peercoin code using the win32 version of the Mingw-w64 cross compilers (at least not without
+modifying headers in the peercoin source code).
diff --git a/doc/dependencies.md b/doc/dependencies.md
index 5c5645de978..ec24c480e9a 100644
--- a/doc/dependencies.md
+++ b/doc/dependencies.md
@@ -1,7 +1,7 @@
 Dependencies
 ============
 
-These are the dependencies currently used by Bitcoin Core. You can find instructions for installing them in the `build-*.md` file for your platform.
+These are the dependencies currently used by Peercoin. You can find instructions for installing them in the `build-*.md` file for your platform.
 
 | Dependency | Version used | Minimum required | CVEs | Shared | [Bundled Qt library](https://doc.qt.io/qt-5/configure-options.html) |
 | --- | --- | --- | --- | --- | --- |
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 9dc63a1e4b6..f7a8e0530df 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -153,7 +153,7 @@ to see it.
 
 **testnet and regtest modes**
 
-Run with the -testnet option to run with "play bitcoins" on the test network, if you
+Run with the -testnet option to run with "play peercoins" on the test network, if you
 are testing multi-machine code that needs to operate across the internet.
 
 If you are testing something that can run on one machine, run with the -regtest option.
@@ -162,7 +162,7 @@ that run in -regtest mode.
 
 **DEBUG_LOCKORDER**
 
-Bitcoin Core is a multithreaded application, and deadlocks or other multithreading bugs
+Peercoin is a multithreaded application, and deadlocks or other multithreading bugs
 can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure
 CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks
 are held, and adds warnings to the debug.log file if inconsistencies are detected.
@@ -252,7 +252,7 @@ Ignoring IDE/editor files
 In closed-source environments in which everyone uses the same IDE it is common
 to add temporary files it produces to the project-wide `.gitignore` file.
 
-However, in open source software such as Bitcoin Core, where everyone uses
+However, in open source software such as Peercoin, where everyone uses
 their own editors/IDE/tools, it is less common. Only you know what files your
 editor produces and this may change from version to version. The canonical way
 to do this is thus to create your local gitignore. Add this to `~/.gitconfig`:
@@ -282,9 +282,9 @@ Development guidelines
 ============================
 
 A few non-style-related recommendations for developers, as well as points to
-pay attention to for reviewers of Bitcoin Core code.
+pay attention to for reviewers of Peercoin code.
 
-General Bitcoin Core
+General Peercoin
 ----------------------
 
 - New features should be exposed on RPC first, then can be made available in the GUI
@@ -400,7 +400,7 @@ Strings and formatting
 
 - For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
 
-  - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
+  - *Rationale*: Peercoin uses tinyformat, which is type safe. Leave them out to avoid confusion
 
 Variable names
 --------------
@@ -514,12 +514,12 @@ Subtrees
 
 Several parts of the repository are subtrees of software maintained elsewhere.
 
-Some of these are maintained by active developers of Bitcoin Core, in which case changes should probably go
+Some of these are maintained by active developers of Peercoin, in which case changes should probably go
 directly upstream without being PRed directly against the project.  They will be merged back in the next
 subtree merge.
 
 Others are external projects without a tight relationship with our project.  Changes to these should also
-be sent upstream but bugfixes may also be prudent to PR against Bitcoin Core so that they can be integrated
+be sent upstream but bugfixes may also be prudent to PR against Peercoin so that they can be integrated
 quickly.  Cosmetic changes should be purely taken upstream.
 
 There is a tool in contrib/devtools/git-subtree-check.sh to check a subtree directory for consistency with
@@ -582,7 +582,7 @@ Git and GitHub tips
 
         [remote "upstream-pull"]
                 fetch = +refs/pull/*:refs/remotes/upstream-pull/*
-                url = git@github.com:bitcoin/bitcoin.git
+                url = git@github.com:peercoin/peercion.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`. Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`,
@@ -648,7 +648,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
 - Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")`
   do different things.
 
-  - *Rationale*: This is impossible to use with `bitcoin-cli`, and can be surprising to users.
+  - *Rationale*: This is impossible to use with `peeritcoin-cli`, and can be surprising to users.
 
   - *Exception*: Some RPC calls can take both an `int` and `bool`, most notably when a bool was switched
     to a multi-value, or due to other historical reasons. **Always** have false map to 0 and
@@ -667,7 +667,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
 
 - Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
 
-  - *Rationale*: `bitcoin-cli` and the GUI debug console use this table to determine how to
+  - *Rationale*: `peercoin-cli` and the GUI debug console use this table to determine how to
     convert a plaintext command line to JSON. If the types don't match, the method can be unusable
     from there.
 
@@ -689,7 +689,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
   RPCs whose behavior does *not* depend on the current chainstate may omit this
   call.
 
-  - *Rationale*: In previous versions of Bitcoin Core, the wallet was always
+  - *Rationale*: In previous versions of Peercoin, the wallet was always
     in-sync with the chainstate (by virtue of them all being updated in the
     same cs_main lock). In order to maintain the behavior that wallet RPCs
     return results as of at least the highest best-known block an RPC
diff --git a/doc/dnsseed-policy.md b/doc/dnsseed-policy.md
index 55a5c28258c..364ede05c7d 100644
--- a/doc/dnsseed-policy.md
+++ b/doc/dnsseed-policy.md
@@ -1,12 +1,12 @@
 Expectations for DNS Seed operators
 ====================================
 
-Bitcoin Core attempts to minimize the level of trust in DNS seeds,
+Peercoin attempts to minimize the level of trust in DNS seeds,
 but DNS seeds still pose a small amount of risk for the network.
 As such, DNS seeds must be run by entities which have some minimum
-level of trust within the Bitcoin community.
+level of trust within the Peercoin community.
 
-Other implementations of Bitcoin software may also use the same
+Other implementations of Peercoin software may also use the same
 seeds and may be more exposed. In light of this exposure, this
 document establishes some basic expectations for operating dnsseeds.
 
@@ -16,7 +16,7 @@ and not sell or transfer control of the DNS seed. Any hosting services
 contracted by the operator are equally expected to uphold these expectations.
 
 1. The DNS seed results must consist exclusively of fairly selected and
-functioning Bitcoin nodes from the public network to the best of the
+functioning Peercoin nodes from the public network to the best of the
 operator's understanding and capability.
 
 2. For the avoidance of doubt, the results may be randomized but must not
@@ -26,7 +26,7 @@ urgent technical necessity and disclosed.
 3. The results may not be served with a DNS TTL of less than one minute.
 
 4. Any logging of DNS queries should be only that which is necessary
-for the operation of the service or urgent health of the Bitcoin
+for the operation of the service or urgent health of the Peercoin
 network and must not be retained longer than necessary nor disclosed
 to any third party.
 
@@ -42,8 +42,8 @@ details of their operating practices.
 related to the DNS seed operation.
 
 If these expectations cannot be satisfied the operator should
-discontinue providing services and contact the active Bitcoin
-Core development team as well as posting on
+discontinue providing services and contact the active Peercoin
+development team as well as posting on
 [bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev).
 
 Behavior outside of these expectations may be reasonable in some
@@ -51,4 +51,4 @@ situations but should be discussed in public in advance.
 
 See also
 ----------
-- [bitcoin-seeder](https://github.com/sipa/bitcoin-seeder) is a reference implementation of a DNS seed.
+- [peercoin-seeder](https://github.com/peercoin/peercoin-seeder) is a reference implementation of a DNS seed.
diff --git a/doc/files.md b/doc/files.md
index 2eac7ed6641..e9d58048727 100644
--- a/doc/files.md
+++ b/doc/files.md
@@ -1,14 +1,14 @@
 
 * banlist.dat: stores the IPs/Subnets of banned nodes
-* bitcoin.conf: contains configuration settings for bitcoind or bitcoin-qt
-* bitcoind.pid: stores the process id of bitcoind while running
+* peercoin.conf: contains configuration settings for peercoind or peercoin-qt
+* peercoind.pid: stores the process id of peercoind while running
 * blocks/blk000??.dat: block data (custom, 128 MiB per file); since 0.8.0
 * blocks/rev000??.dat; block undo data (custom); since 0.8.0 (format changed since pre-0.8)
 * blocks/index/*; block index (LevelDB); since 0.8.0
 * chainstate/*; block chain state database (LevelDB); since 0.8.0
 * database/*: BDB database environment; only used for wallet since 0.8.0; moved to wallets/ directory on new installs since 0.16.0
 * db.log: wallet database log file; moved to wallets/ directory on new installs since 0.16.0
-* debug.log: contains debug information and general logging generated by bitcoind or bitcoin-qt
+* debug.log: contains debug information and general logging generated by peercoind or peercoin-qt
 * fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation; since 0.10.0
 * mempool.dat: dump of the mempool's transactions; since 0.14.0.
 * peers.dat: peer IP address database (custom format); since 0.7.0
diff --git a/doc/fuzzing.md b/doc/fuzzing.md
index 5dedcb51c89..5c1ffb0e78e 100644
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -1,7 +1,7 @@
-Fuzz-testing Bitcoin Core
+Fuzz-testing Peercoin
 ==========================
 
-A special test harness `test_bitcoin_fuzzy` is provided to provide an easy
+A special test harness `test_peercoin_fuzzy` is provided to provide an easy
 entry point for fuzzers and the like. In this document we'll describe how to
 use it with AFL.
 
@@ -20,13 +20,13 @@ export AFLPATH=$PWD
 Instrumentation
 ----------------
 
-To build Bitcoin Core using AFL instrumentation (this assumes that the
+To build Peercoin using AFL instrumentation (this assumes that the
 `AFLPATH` was set as above):
 ```
 ./configure --disable-ccache --disable-shared --enable-tests CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
 export AFL_HARDEN=1
 cd src/
-make test/test_bitcoin_fuzzy
+make test/test_peercoin_fuzzy
 ```
 We disable ccache because we don't want to pollute the ccache with instrumented
 objects, and similarly don't want to use non-instrumented cached objects linked
@@ -35,7 +35,7 @@ in.
 The fuzzing can be sped up significantly (~200x) by using `afl-clang-fast` and
 `afl-clang-fast++` in place of `afl-gcc` and `afl-g++` when compiling. When
 compiling using `afl-clang-fast`/`afl-clang-fast++` the resulting
-`test_bitcoin_fuzzy` binary will be instrumented in such a way that the AFL
+`test_peercoin_fuzzy` binary will be instrumented in such a way that the AFL
 features "persistent mode" and "deferred forkserver" can be used. See
 https://github.com/mcarpenter/afl/tree/master/llvm_mode for details.
 
@@ -65,7 +65,7 @@ Fuzzing
 
 To start the actual fuzzing use:
 ```
-$AFLPATH/afl-fuzz -i ${AFLIN} -o ${AFLOUT} -m52 -- test/test_bitcoin_fuzzy
+$AFLPATH/afl-fuzz -i ${AFLIN} -o ${AFLOUT} -m52 -- test/test_peercoin_fuzzy
 ```
 
 You may have to change a few kernel parameters to test optimally - `afl-fuzz`
diff --git a/doc/gitian-building.md b/doc/gitian-building.md
deleted file mode 100644
index 3a48f4a0b39..00000000000
--- a/doc/gitian-building.md
+++ /dev/null
@@ -1,4 +0,0 @@
-Gitian building
-================
-
-This file was moved to [the Bitcoin Core documentation repository](https://github.com/bitcoin-core/docs/blob/master/gitian-building.md) at [https://github.com/bitcoin-core/docs](https://github.com/bitcoin-core/docs).
diff --git a/doc/init.md b/doc/init.md
index 75f9013f296..4654cbfbb62 100644
--- a/doc/init.md
+++ b/doc/init.md
@@ -1,36 +1,36 @@
-Sample init scripts and service configuration for bitcoind
+Sample init scripts and service configuration for peercoind
 ==========================================================
 
 Sample scripts and configuration files for systemd, Upstart and OpenRC
 can be found in the contrib/init folder.
 
-    contrib/init/bitcoind.service:    systemd service unit configuration
-    contrib/init/bitcoind.openrc:     OpenRC compatible SysV style init script
-    contrib/init/bitcoind.openrcconf: OpenRC conf.d file
-    contrib/init/bitcoind.conf:       Upstart service configuration file
-    contrib/init/bitcoind.init:       CentOS compatible SysV style init script
+    contrib/init/peercoind.service:    systemd service unit configuration
+    contrib/init/peercoind.openrc:     OpenRC compatible SysV style init script
+    contrib/init/peercoind.openrcconf: OpenRC conf.d file
+    contrib/init/peercoind.conf:       Upstart service configuration file
+    contrib/init/peercoind.init:       CentOS compatible SysV style init script
 
 Service User
 ---------------------------------
 
-All three Linux startup configurations assume the existence of a "bitcoin" user
+All three Linux startup configurations assume the existence of a "peercoin" user
 and group.  They must be created before attempting to use these scripts.
-The OS X configuration assumes bitcoind will be set up for the current user.
+The OS X configuration assumes peercoind will be set up for the current user.
 
 Configuration
 ---------------------------------
 
-At a bare minimum, bitcoind requires that the rpcpassword setting be set
+At a bare minimum, peercoind requires that the rpcpassword setting be set
 when running as a daemon.  If the configuration file does not exist or this
-setting is not set, bitcoind will shutdown promptly after startup.
+setting is not set, peercoind will shutdown promptly after startup.
 
 This password does not have to be remembered or typed as it is mostly used
-as a fixed token that bitcoind and client programs read from the configuration
+as a fixed token that peercoind and client programs read from the configuration
 file, however it is recommended that a strong and secure password be used
 as this password is security critical to securing the wallet should the
 wallet be enabled.
 
-If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set,
+If peercoind is run with the "-server" flag (set by default), and no rpcpassword is set,
 it will use a special cookie file for authentication. The cookie is generated with random
 content when the daemon starts, and deleted when it exits. Read access to this file
 controls who can access it through RPC.
@@ -38,13 +38,13 @@ controls who can access it through RPC.
 By default the cookie is stored in the data directory, but it's location can be overridden
 with the option '-rpccookiefile'.
 
-This allows for running bitcoind without having to do any manual configuration.
+This allows for running peercoind without having to do any manual configuration.
 
 `conf`, `pid`, and `wallet` accept relative paths which are interpreted as
 relative to the data directory. `wallet` *only* supports relative paths.
 
 For an example configuration file that describes the configuration settings,
-see `contrib/debian/examples/bitcoin.conf`.
+see `contrib/debian/examples/peercoin.conf`.
 
 Paths
 ---------------------------------
@@ -53,24 +53,24 @@ Paths
 
 All three configurations assume several paths that might need to be adjusted.
 
-Binary:              `/usr/bin/bitcoind`  
-Configuration file:  `/etc/bitcoin/bitcoin.conf`  
-Data directory:      `/var/lib/bitcoind`  
-PID file:            `/var/run/bitcoind/bitcoind.pid` (OpenRC and Upstart) or `/var/lib/bitcoind/bitcoind.pid` (systemd)  
-Lock file:           `/var/lock/subsys/bitcoind` (CentOS)  
+Binary:              `/usr/bin/peercoind`  
+Configuration file:  `/etc/peercoin/peercoin.conf`  
+Data directory:      `/var/lib/peercoind`  
+PID file:            `/var/run/peercoind/peercoind.pid` (OpenRC and Upstart) or `/var/lib/peercoind/peercoind.pid` (systemd)  
+Lock file:           `/var/lock/subsys/peercoind` (CentOS)  
 
 The configuration file, PID directory (if applicable) and data directory
-should all be owned by the bitcoin user and group.  It is advised for security
+should all be owned by the peercoin user and group.  It is advised for security
 reasons to make the configuration file and data directory only readable by the
-bitcoin user and group.  Access to bitcoin-cli and other bitcoind rpc clients
+peercoin user and group.  Access to peercoin-cli and other peercoind rpc clients
 can then be controlled by group membership.
 
 ### Mac OS X
 
-Binary:              `/usr/local/bin/bitcoind`  
-Configuration file:  `~/Library/Application Support/Bitcoin/bitcoin.conf`  
-Data directory:      `~/Library/Application Support/Bitcoin`  
-Lock file:           `~/Library/Application Support/Bitcoin/.lock`  
+Binary:              `/usr/local/bin/peercoind`  
+Configuration file:  `~/Library/Application Support/Peercoin/peercoin.conf`  
+Data directory:      `~/Library/Application Support/Peercoin`  
+Lock file:           `~/Library/Application Support/Peercoin/.lock`  
 
 Installing Service Configuration
 -----------------------------------
@@ -81,19 +81,19 @@ Installing this .service file consists of just copying it to
 /usr/lib/systemd/system directory, followed by the command
 `systemctl daemon-reload` in order to update running systemd configuration.
 
-To test, run `systemctl start bitcoind` and to enable for system startup run
-`systemctl enable bitcoind`
+To test, run `systemctl start peercoind` and to enable for system startup run
+`systemctl enable peercoind`
 
 ### OpenRC
 
-Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d.  Double
+Rename peercoind.openrc to peercoind and drop it in /etc/init.d.  Double
 check ownership and permissions and make it executable.  Test it with
-`/etc/init.d/bitcoind start` and configure it to run on startup with
-`rc-update add bitcoind`
+`/etc/init.d/peercoind start` and configure it to run on startup with
+`rc-update add peercoind`
 
 ### Upstart (for Debian/Ubuntu based distributions)
 
-Drop bitcoind.conf in /etc/init.  Test by running `service bitcoind start`
+Drop peercoind.conf in /etc/init.  Test by running `service peercoind start`
 it will automatically start on reboot.
 
 NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
@@ -101,22 +101,22 @@ use old versions of Upstart and do not supply the start-stop-daemon utility.
 
 ### CentOS
 
-Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`.
+Copy peercoind.init to /etc/init.d/peercoind. Test by running `service peercoind start`.
 
-Using this script, you can adjust the path and flags to the bitcoind program by
-setting the BITCOIND and FLAGS environment variables in the file
-/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
+Using this script, you can adjust the path and flags to the peercoind program by
+setting the PEERCOIND and FLAGS environment variables in the file
+/etc/sysconfig/peercoind. You can also use the DAEMONOPTS environment variable here.
 
 ### Mac OS X
 
-Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by
-running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`.
+Copy org.peercoin.peercoind.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/org.peercoin.peercoind.plist`.
 
-This Launch Agent will cause bitcoind to start whenever the user logs in.
+This Launch Agent will cause peercoind to start whenever the user logs in.
 
-NOTE: This approach is intended for those wanting to run bitcoind as the current user.
-You will need to modify org.bitcoin.bitcoind.plist if you intend to use it as a
-Launch Daemon with a dedicated bitcoin user.
+NOTE: This approach is intended for those wanting to run peercoind as the current user.
+You will need to modify org.peercoin.peercoind.plist if you intend to use it as a
+Launch Daemon with a dedicated peercoin user.
 
 Auto-respawn
 -----------------------------------
diff --git a/doc/reduce-traffic.md b/doc/reduce-traffic.md
index 697099beabe..a2cf0d80a1c 100644
--- a/doc/reduce-traffic.md
+++ b/doc/reduce-traffic.md
@@ -3,7 +3,7 @@ Reduce Traffic
 
 Some node operators need to deal with bandwidth caps imposed by their ISPs.
 
-By default, bitcoin-core allows up to 125 connections to different peers, 8 of
+By default, Peercoin allows up to 125 connections to different peers, 8 of
 which are outbound. You can therefore, have at most 117 inbound connections.
 
 The default settings can result in relatively significant traffic consumption.
@@ -33,5 +33,5 @@ blocks and transactions to fewer nodes.
 ## 3. Reduce maximum connections (`-maxconnections=<num>`)
 
 Reducing the maximum connected nodes to a minimum could be desirable if traffic
-limits are tiny. Keep in mind that bitcoin's trustless model works best if you are
+limits are tiny. Keep in mind that peercoin's trustless model works best if you are
 connected to a handful of nodes.
diff --git a/doc/release-notes.md b/doc/release-notes.md
index f8b9192abd2..fc905265e2e 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.16.x is now available from:
+Peercoin version 0.8.x is now available from:
 
   <https://bitcoincore.org/bin/bitcoin-core-0.16.x/>
 
@@ -40,10 +40,10 @@ wallets that were created with older versions are not affected by this.
 Compatibility
 ==============
 
-Bitcoin Core is extensively tested on multiple operating systems using
+Peercoin is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.
 
-Bitcoin Core should also work on most other Unix-like systems but is not
+Peercoin should also work on most other Unix-like systems but is not
 frequently tested on them.
 
 Notable changes
diff --git a/doc/release-process.md b/doc/release-process.md
index f429b4bbdb9..de1af99ddb8 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -38,7 +38,7 @@ Check out the source code in the following directory hierarchy.
     git clone https://github.com/devrandom/gitian-builder.git
     git clone https://github.com/bitcoin/bitcoin.git
 
-### Bitcoin maintainers/release engineers, suggestion for writing release notes
+### Peercoin maintainers/release engineers, suggestion for writing release notes
 
 Write release notes. git shortlog helps a lot, for example:
 
@@ -108,7 +108,7 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from
 
 The gbuild invocations below <b>DO NOT DO THIS</b> by default.
 
-### Build and sign Bitcoin Core for Linux, Windows, and OS X:
+### Build and sign Bitcoin for Linux, Windows, and OS X:
 
     pushd ./gitian-builder
     ./bin/gbuild --num-make 2 --memory 3000 --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
@@ -292,18 +292,18 @@ bitcoin.org (see below for bitcoin.org update instructions).
 
   - bitcoin-dev and bitcoin-core-dev mailing list
 
-  - Bitcoin Core announcements list https://bitcoincore.org/en/list/announcements/join/
+  - Bitcoin announcements list https://bitcoincore.org/en/list/announcements/join/
 
   - bitcoincore.org blog post
 
-  - Update title of #bitcoin on Freenode IRC
+  - Update title of #peercoin on Freenode IRC
 
-  - Optionally twitter, reddit /r/Bitcoin, ... but this will usually sort out itself
+  - Optionally twitter, reddit /r/Peercoin, ... but this will usually sort out itself
 
   - Notify BlueMatt so that he can start building [the PPAs](https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin)
 
   - Archive release notes for the new version to `doc/release-notes/` (branch `master` and branch of the release)
 
-  - Create a [new GitHub release](https://github.com/bitcoin/bitcoin/releases/new) with a link to the archived release notes.
+  - Create a [new GitHub release](https://github.com/peercoin/peercoin/releases/new) with a link to the archived release notes.
 
   - Celebrate
diff --git a/doc/shared-libraries.md b/doc/shared-libraries.md
index dc363582cc8..791b7374f61 100644
--- a/doc/shared-libraries.md
+++ b/doc/shared-libraries.md
@@ -1,9 +1,9 @@
 Shared Libraries
 ================
 
-## bitcoinconsensus
+## peercoinconsensus
 
-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.
+The purpose of this library is to make the verification functionality that is critical to Peercoin's consensus available to other applications, e.g. to language bindings.
 
 ### API
 
diff --git a/doc/tor.md b/doc/tor.md
index a05979fca84..0e421e2fdec 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -1,16 +1,16 @@
-TOR SUPPORT IN BITCOIN
+TOR SUPPORT IN PEERCOIN
 ======================
 
-It is possible to run Bitcoin as a Tor hidden service, and connect to such services.
+It is possible to run Peercoin as a Tor hidden service, and connect to such services.
 
 The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly
 configure Tor.
 
 
-1. Run bitcoin behind a Tor proxy
+1. Run peercoin behind a Tor proxy
 ---------------------------------
 
-The first step is running Bitcoin behind a Tor proxy. This will already make all
+The first step is running Peercoin behind a Tor proxy. This will already make all
 outgoing connections be anonymized, but more is possible.
 
 	-proxy=ip:port  Set the proxy server. If SOCKS5 is selected (default), this proxy
@@ -31,17 +31,17 @@ outgoing connections be anonymized, but more is possible.
 
 In a typical situation, this suffices to run behind a Tor proxy:
 
-	./bitcoin -proxy=127.0.0.1:9050
+	./peercoin -proxy=127.0.0.1:9050
 
 
-2. Run a bitcoin hidden server
+2. Run a peercoin hidden server
 ------------------------------
 
 If you configure your Tor system accordingly, it is possible to make your node also
 reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent
 config file):
 
-	HiddenServiceDir /var/lib/tor/bitcoin-service/
+	HiddenServiceDir /var/lib/tor/peercoin-service/
 	HiddenServicePort 8333 127.0.0.1:8333
 	HiddenServicePort 18333 127.0.0.1:18333
 
@@ -68,49 +68,49 @@ your bitcoind's P2P listen port (8333 by default).
 
 In a typical situation, where you're only reachable via Tor, this should suffice:
 
-	./bitcoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
+	./peercoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
 
 (obviously, replace the Onion address with your own). It should be noted that you still
 listen on all devices and another node could establish a clearnet connection, when knowing
 your address. To mitigate this, additionally bind the address of your Tor proxy:
 
-	./bitcoind ... -bind=127.0.0.1
+	./peercoind ... -bind=127.0.0.1
 
 If you don't care too much about hiding your node, and want to be reachable on IPv4
 as well, use `discover` instead:
 
-	./bitcoind ... -discover
+	./peercoind ... -discover
 
 and open port 8333 on your firewall (or use -upnp).
 
 If you only want to use Tor to reach onion addresses, but not use it as a proxy
 for normal IPv4/IPv6 communication, use:
 
-	./bitcoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
+	./peercoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
 
 3. Automatically listen on Tor
 --------------------------------
 
 Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
 API, to create and destroy 'ephemeral' hidden services programmatically.
-Bitcoin Core has been updated to make use of this.
+Peercoin has been updated to make use of this.
 
 This means that if Tor is running (and proper authentication has been configured),
-Bitcoin Core automatically creates a hidden service to listen on. This will positively 
+Peercoin automatically creates a hidden service to listen on. This will positively 
 affect the number of available .onion nodes.
 
-This new feature is enabled by default if Bitcoin Core is listening (`-listen`), and
+This new feature is enabled by default if Peercoin is listening (`-listen`), and
 requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
 and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
 To show verbose debugging information, pass `-debug=tor`.
 
 Connecting to Tor's control socket API requires one of two authentication methods to be 
-configured. For cookie authentication the user running bitcoind must have write access 
+configured. For cookie authentication the user running peercoind must have write access 
 to the `CookieAuthFile` specified in Tor configuration. In some cases this is 
 preconfigured and the creation of a hidden service is automatic. If permission problems 
 are seen with `-debug=tor` they can be resolved by adding both the user running tor and 
-the user running bitcoind to the same group and setting permissions appropriately. On 
-Debian-based systems the user running bitcoind can be added to the debian-tor group, 
+the user running peercoind to the same group and setting permissions appropriately. On 
+Debian-based systems the user running peercoind can be added to the debian-tor group, 
 which has the appropriate permissions. An alternative authentication method is the use 
 of the `-torpassword` flag and a `hash-password` which can be enabled and specified in 
 Tor configuration.
@@ -118,7 +118,7 @@ Tor configuration.
 4. Privacy recommendations
 ---------------------------
 
-- Do not add anything but bitcoin ports to the hidden service created in section 2.
+- Do not add anything but peercoin ports to the hidden service created in section 2.
   If you run a web service too, create a new hidden service for that.
   Otherwise it is trivial to link them, which may reduce privacy. Hidden
   services created automatically (as in section 3) always have only one port
diff --git a/doc/translation_process.md b/doc/translation_process.md
index 1702637d53e..0183976f830 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -1,12 +1,12 @@
 Translations
 ============
 
-The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool.
+The Peercoin project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Peercoin makes use of the Transifex online translation management tool.
 
 ### Helping to translate (using Transifex)
 Transifex is setup to monitor the GitHub repo for updates, and when code containing new translations is found, Transifex will process any changes. It may take several hours after a pull-request has been merged, to appear in the Transifex web interface.
 
-Multiple language support is critical in assisting Bitcoin’s global adoption, and growth. One of Bitcoin’s greatest strengths is cross-border money transfers, any help making that easier is greatly appreciated.
+Multiple language support is critical in assisting Peercoin’s global adoption, and growth. One of Peercoin’s greatest strengths is cross-border money transfers, any help making that easier is greatly appreciated.
 
 See the [Transifex Bitcoin project](https://www.transifex.com/projects/p/bitcoin/) to assist in translations. You should also join the translation mailing list for announcements - see details below.
 
diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md
index b95259cdc9d..7b0d7d4fe7d 100644
--- a/doc/translation_strings_policy.md
+++ b/doc/translation_strings_policy.md
@@ -1,7 +1,7 @@
 Translation Strings Policy
 ===========================
 
-This document provides guidelines for internationalization of the Bitcoin Core software.
+This document provides guidelines for internationalization of the Peercoin software.
 
 How to translate?
 ------------------
diff --git a/doc/travis-ci.md b/doc/travis-ci.md
index 38085cec353..7c4faba65e5 100644
--- a/doc/travis-ci.md
+++ b/doc/travis-ci.md
@@ -32,7 +32,7 @@ trigger cache-invalidation and rebuilds as necessary.
 
 These caches can be manually removed if necessary. This is one of the very few
 manual operations that is possible with Travis, and it can be done by the
-Bitcoin Core committer via the Travis web interface.
+Peercoin committer via the Travis web interface.
 
 In some cases, secure strings may be needed for hiding sensitive info such as
 private keys or URLs. The travis client may be used to create these strings:
diff --git a/doc/zmq.md b/doc/zmq.md
index 38c58fb7fdf..b0a5a3ba19f 100644
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -5,8 +5,8 @@ connections, inter-process communication, and shared-memory,
 providing various message-oriented semantics such as publish/subscribe,
 request/reply, and push/pull.
 
-The Bitcoin Core daemon can be configured to act as a trusted "border
-router", implementing the bitcoin wire protocol and relay, making
+The Peercoin daemon can be configured to act as a trusted "border
+router", implementing the peercoin wire protocol and relay, making
 consensus decisions, maintaining the local blockchain database,
 broadcasting locally generated transactions into the network, and
 providing a queryable RPC interface to interact on a polled basis for
@@ -33,7 +33,7 @@ buffering or reassembly.
 
 ## Prerequisites
 
-The ZeroMQ feature in Bitcoin Core requires ZeroMQ API version 4.x or
+The ZeroMQ feature in Peercoin requires ZeroMQ API version 4.x or
 newer. Typically, it is packaged by distributions as something like
 *libzmq3-dev*. The C++ wrapper for ZeroMQ is *not* needed.
 
@@ -45,7 +45,7 @@ operation.
 
 By default, the ZeroMQ feature is automatically compiled in if the
 necessary prerequisites are found.  To disable, use --disable-zmq
-during the *configure* step of building bitcoind:
+during the *configure* step of building peercoind:
 
     $ ./configure --disable-zmq (other options)
 
@@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
 
 For instance:
 
-    $ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-               -zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw
+    $ peercoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
+               -zmqpubrawtx=ipc:///tmp/peercoind.tx.raw
 
 Each PUB notification has a topic and body, where the header
 corresponds to the notification type. For instance, for the
@@ -75,7 +75,7 @@ notification `-zmqpubhashtx` the topic is `hashtx` (no null
 terminator) and the body is the transaction hash (32
 bytes).
 
-These options can also be provided in bitcoin.conf.
+These options can also be provided in peercoin.conf.
 
 ZeroMQ endpoint specifiers for TCP (and others) are documented in the
 [ZeroMQ API](http://api.zeromq.org/4-0:_start).
@@ -87,9 +87,9 @@ arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
 
 ## Remarks
 
-From the perspective of bitcoind, the ZeroMQ socket is write-only; PUB
+From the perspective of peercoind, the ZeroMQ socket is write-only; PUB
 sockets don't even have a read function. Thus, there is no state
-introduced into bitcoind directly. Furthermore, no information is
+introduced into peercoind directly. Furthermore, no information is
 broadcast that wasn't already received from the public P2P network.
 
 No authentication or authorization is done on connecting clients; it
@@ -102,5 +102,5 @@ retrieve the chain from the last known block to the new tip.
 
 There are several possibilities that ZMQ notification can get lost
 during transmission depending on the communication type your are
-using. Bitcoind appends an up-counting sequence number to each
+using. Peercoind appends an up-counting sequence number to each
 notification which allows listeners to detect lost notifications.