diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in
index 680ed3599ba7..7f5dc9131a4b 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 = "XPChain Core"
# 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
@@ -1265,7 +1265,7 @@ DOCSET_FEEDNAME = "Doxygen generated docs"
# The default value is: org.doxygen.Project.
# This tag requires that the tag GENERATE_DOCSET is set to YES.
-DOCSET_BUNDLE_ID = org.bitcoin.Bitcoin-Core
+DOCSET_BUNDLE_ID = io.xpchain.XPChain-Core
# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
# the documentation publisher. This should be a reverse domain-name style
@@ -1273,7 +1273,7 @@ DOCSET_BUNDLE_ID = org.bitcoin.Bitcoin-Core
# The default value is: org.doxygen.Publisher.
# This tag requires that the tag GENERATE_DOCSET is set to YES.
-DOCSET_PUBLISHER_ID = org.bitcoin.Bitcoin-Core
+DOCSET_PUBLISHER_ID = io.xpchain.XPChain-Core
# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
# The default value is: Publisher.
diff --git a/doc/README.md b/doc/README.md
index 5ffff825b43a..29c3b260895a 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,41 +1,41 @@
-Bitcoin Core
+XPChain 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 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.
+XPChain Core is the original XPChain client and it builds the backbone of the network. It downloads and, by default, stores the entire history of XPChain 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 Bitcoin Core, visit [bitcoincore.org](https://bitcoincore.org/en/releases/).
+To download XPChain Core, visit [xpchaincore.org](https://xpchaincore.org/en/releases/).
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 XPChain Core on your native platform.
### Unix
Unpack the files into a directory and run:
-- `bin/bitcoin-qt` (GUI) or
-- `bin/bitcoind` (headless)
+- `bin/xpchain-qt` (GUI) or
+- `bin/xpchaind` (headless)
### Windows
-Unpack the files into a directory, and then run bitcoin-qt.exe.
+Unpack the files into a directory, and then run xpchain-qt.exe.
### macOS
-Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
+Drag XPChain Core to your applications folder, and then run XPChain Core.
### Need Help?
-* See the documentation at the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page)
+* See the documentation at the [XPChain Wiki](https://en.bitcoin.it/wiki/Main_Page)
for help and more information.
* Ask for help on [#bitcoin](http://webchat.freenode.net?channels=bitcoin) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=bitcoin).
* Ask for help on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Technical Support board](https://bitcointalk.org/index.php?board=4.0).
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 XPChain 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)
@@ -47,7 +47,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 XPChain repo's [root README](/README.md) contains relevant information on the development process and automated testing.
- [Developer Notes](developer-notes.md)
- [Release Notes](release-notes.md)
@@ -65,7 +65,7 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
### Resources
* Discuss on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Development & Technical Discussion board](https://bitcointalk.org/index.php?board=6.0).
* Discuss project-specific development on #bitcoin-core-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=bitcoin-core-dev).
-* Discuss general Bitcoin development on #bitcoin-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=bitcoin-dev).
+* Discuss general XPChain development on #bitcoin-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=bitcoin-dev).
### Miscellaneous
- [Assets Attribution](assets-attribution.md)
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
index 07d61b3bda13..5e59a4c21bc9 100644
--- a/doc/README_windows.txt
+++ b/doc/README_windows.txt
@@ -1,23 +1,23 @@
-Bitcoin Core
-=============
-
-Intro
------
-Bitcoin is a free open source peer-to-peer electronic cash system that is
-completely decentralized, without the need for a central server or trusted
-parties. Users hold the crypto keys to their own money and transact directly
-with each other, with the help of a P2P network to check for double-spending.
-
-
-Setup
------
-Unpack the files into a directory and run bitcoin-qt.exe.
-
-Bitcoin Core is the original Bitcoin client and it builds the backbone of the network.
-However, it downloads and stores the entire history of Bitcoin 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
-for more help and information.
+XPChain Core
+=============
+
+Intro
+-----
+XPChain is a free open source peer-to-peer electronic cash system that is
+completely decentralized, without the need for a central server or trusted
+parties. Users hold the crypto keys to their own money and transact directly
+with each other, with the help of a P2P network to check for double-spending.
+
+
+Setup
+-----
+Unpack the files into a directory and run xpchain-qt.exe.
+
+XPChain Core is the original XPChain client and it builds the backbone of the network.
+However, it downloads and stores the entire history of XPChain 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 xpchain wiki at:
+ https://en.bitcoin.it/wiki/Main_Page
+for more help and information.
diff --git a/doc/assets-attribution.md b/doc/assets-attribution.md
index 2dd930d6a4f9..d5cf6eab4953 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 xpchain 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 48f81cf6c18f..df986b037fe4 100644
--- a/doc/benchmarking.md
+++ b/doc/benchmarking.md
@@ -1,12 +1,12 @@
Benchmarking
============
-Bitcoin Core has an internal benchmarking framework, with benchmarks
+XPChain Core has an internal benchmarking framework, with benchmarks
for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160), as well as the rolling bloom filter.
Running
---------------------
-After compiling bitcoin-core, the benchmarks can be run with:
+After compiling xpchain-core, the benchmarks can be run with:
src/bench/bench_bitcoin
diff --git a/doc/build-freebsd.md b/doc/build-freebsd.md
index 48746ce0c2ca..db34310bcd75 100644
--- a/doc/build-freebsd.md
+++ b/doc/build-freebsd.md
@@ -2,7 +2,7 @@ FreeBSD build guide
======================
(updated for FreeBSD 11.1)
-This guide describes how to build bitcoind and command-line utilities on FreeBSD.
+This guide describes how to build xpchaind and command-line utilities on FreeBSD.
This guide does not contain instructions for building the GUI.
@@ -24,10 +24,10 @@ See [dependencies.md](dependencies.md) for a complete overview.
Download the source code:
```
-git clone https://github.com/bitcoin/bitcoin
+git clone https://github.com/xpchain/xpchain
```
-## Building Bitcoin Core
+## Building XPChain Core
**Important**: Use `gmake` (the non-GNU `make` will exit with an error).
@@ -43,4 +43,3 @@ gmake
*Note on debugging*: The version of `gdb` installed by default is [ancient and considered harmful](https://wiki.freebsd.org/GdbRetirement).
It is not suitable for debugging a multi-threaded C++ program, not even for getting backtraces. Please install the package `gdb` and
use the versioned gdb command (e.g. `gdb7111`).
-
diff --git a/doc/build-netbsd.md b/doc/build-netbsd.md
index 5bf2d6b59b87..e364c62d3b91 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 xpchaind 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/xpchain/xpchain
```
See [dependencies.md](dependencies.md) for a complete overview.
-### Building Bitcoin Core
+### Building XPChain Core
**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 63288acf1610..7c93c7546c23 100644
--- a/doc/build-openbsd.md
+++ b/doc/build-openbsd.md
@@ -2,7 +2,7 @@ OpenBSD build guide
======================
(updated for OpenBSD 6.3)
-This guide describes how to build bitcoind and command-line utilities on OpenBSD.
+This guide describes how to build xpchaind 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.
@@ -17,7 +17,7 @@ pkg_add autoconf # (select highest version, e.g. 2.69)
pkg_add automake # (select highest version, e.g. 1.15)
pkg_add python # (select highest version, e.g. 3.6)
-git clone https://github.com/bitcoin/bitcoin.git
+git clone https://github.com/xpchain/xpchain.git
```
See [dependencies.md](dependencies.md) for a complete overview.
@@ -48,7 +48,7 @@ from the root of the repository. Then set `BDB_PREFIX` for the next section:
export BDB_PREFIX="$PWD/db4"
```
-### Building Bitcoin Core
+### Building XPChain Core
**Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.
@@ -95,7 +95,7 @@ The standard ulimit restrictions in OpenBSD are very strict:
data(kbytes) 1572864
This, unfortunately, in some cases not enough to compile some `.cpp` files in the project,
-(see issue [#6658](https://github.com/bitcoin/bitcoin/issues/6658)).
+(see issue [#6658](https://github.com/xpchain/xpchain/issues/6658)).
If your user is in the `staff` group the limit can be raised with:
ulimit -d 3000000
@@ -103,4 +103,3 @@ If your user is in the `staff` group the limit can be raised with:
The change will only affect the current shell and processes spawned by it. To
make the change system-wide, change `datasize-cur` and `datasize-max` in
`/etc/login.conf`, and reboot.
-
diff --git a/doc/build-osx.md b/doc/build-osx.md
index 448918e8cb43..6c5b98cee4d2 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -38,17 +38,17 @@ from the root of the repository.
**Note**: You only need Berkeley DB if the wallet is enabled (see the section *Disable-Wallet mode* below).
-Build Bitcoin Core
+Build XPChain Core
------------------------
-1. Clone the Bitcoin Core source code and cd into `bitcoin`
+1. Clone the XPChain Core source code and cd into `xpchain`
- git clone https://github.com/bitcoin/bitcoin
- cd bitcoin
+ git clone https://github.com/xpchain/xpchain
+ cd xpchain
-2. Build Bitcoin Core:
+2. Build XPChain Core:
- Configure and build the headless Bitcoin Core binaries as well as the GUI (if Qt is found).
+ Configure and build the headless XPChain Core binaries as well as the GUI (if Qt is found).
You can disable the GUI build by passing `--without-gui` to configure.
@@ -67,30 +67,30 @@ Build Bitcoin Core
Running
-------
-Bitcoin Core is now available at `./src/bitcoind`
+XPChain Core is now available at `./src/xpchaind`
Before running, it's recommended that you create an RPC configuration file.
- echo -e "rpcuser=bitcoinrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+ echo -e "rpcuser=xpchainrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/XPChain/xpchain.conf"
- chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+ chmod 600 "/Users/${USER}/Library/Application Support/XPChain/xpchain.conf"
-The first time you run bitcoind, it will start downloading the blockchain. This process could take several hours.
+The first time you run xpchaind, it will start downloading the blockchain. This process could take several hours.
You can monitor the download process by looking at the debug.log file:
- tail -f $HOME/Library/Application\ Support/Bitcoin/debug.log
+ tail -f $HOME/Library/Application\ Support/XPChain/debug.log
Other commands:
-------
- ./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/xpchaind -daemon # Starts the xpchain daemon.
+ ./src/xpchain-cli --help # Outputs a list of command-line options.
+ ./src/xpchain-cli help # Outputs a list of RPC commands when the daemon is running.
Notes
-----
* Tested on OS X 10.10 Yosemite through macOS 10.13 High Sierra on 64-bit Intel processors only.
-* Building with downloaded Qt binaries is not officially supported. See the notes in [#7714](https://github.com/bitcoin/bitcoin/issues/7714)
+* Building with downloaded Qt binaries is not officially supported. See the notes in [#7714](https://github.com/xpchain/xpchain/issues/7714)
diff --git a/doc/build-unix.md b/doc/build-unix.md
index a01ff59fa6f7..5f25cbaae3ec 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -1,12 +1,12 @@
UNIX BUILD NOTES
====================
-Some notes on how to build Bitcoin Core in Unix.
+Some notes on how to build XPChain Core in Unix.
(For BSD specific instructions, see `build-*bsd.md` in this directory.)
Note
---------------------
-Always use absolute paths to configure and compile Bitcoin Core and the dependencies,
+Always use absolute paths to configure and compile XPChain Core and the dependencies,
for example, when specifying the path of the dependency:
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
@@ -24,7 +24,7 @@ make
make install # optional
```
-This will build bitcoin-qt as well if the dependencies are met.
+This will build xpchain-qt as well if the dependencies are met.
Dependencies
---------------------
@@ -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 Bitcoin Core. On systems with less, gcc can be
+memory available when compiling XPChain Core. On systems with less, gcc can be
tuned to conserve memory with additional CXXFLAGS:
@@ -78,7 +78,7 @@ BerkeleyDB is required for the wallet.
You can add the repository and install using the following commands:
sudo apt-get install software-properties-common
- sudo add-apt-repository ppa:bitcoin/bitcoin
+ sudo add-apt-repository ppa:xpchain/xpchain
sudo apt-get update
sudo apt-get install libdb4.8-dev libdb4.8++-dev
@@ -87,7 +87,7 @@ BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distri
are based on BerkeleyDB 4.8. If you do not care about wallet compatibility,
pass `--with-incompatible-bdb` to configure.
-See the section "Disable-wallet mode" to build Bitcoin Core without wallet.
+See the section "Disable-wallet mode" to build XPChain Core without wallet.
Optional (see --with-miniupnpc and --enable-upnp-default):
@@ -99,7 +99,7 @@ ZMQ dependencies (provides ZMQ API 4.x):
#### Dependencies for the GUI
-If you want to build bitcoin-qt, make sure that the required packages for Qt development
+If you want to build xpchain-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`.
@@ -111,7 +111,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 xpchain-qt executable will be
built by default.
@@ -137,7 +137,7 @@ libqrencode (optional) can be installed with:
Notes
-----
-The release is built with GCC and then "strip bitcoind" to strip the debug
+The release is built with GCC and then "strip xpchaind" to strip the debug
symbols, which reduces the executable size by about 90%.
@@ -178,7 +178,7 @@ If you need to build Boost yourself:
Security
--------
-To help make your Bitcoin Core installation more secure by making certain attacks impossible to
+To help make your XPChain Core installation more secure by making certain attacks impossible to
exploit even if a vulnerability is found, binaries are hardened by default.
This can be disabled with:
@@ -202,7 +202,7 @@ Hardening enables the following features:
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
- scanelf -e ./bitcoin
+ scanelf -e ./xpchain
The output should contain:
@@ -211,13 +211,13 @@ Hardening enables the following features:
* Non-executable Stack
If the stack is executable then trivial stack-based buffer overflow exploits are possible if
- vulnerable buffers are found. By default, Bitcoin Core should be built with a non-executable stack,
+ vulnerable buffers are found. By default, XPChain Core should be built with a non-executable stack,
but if one of the libraries it uses asks for an executable stack or someone makes a mistake
and uses a compiler extension which requires an executable stack, it will silently build an
executable without the non-executable stack protection.
To verify that the stack is non-executable after compiling use:
- `scanelf -e ./bitcoin`
+ `scanelf -e ./xpchain`
The output should contain:
STK/REL/PTL
@@ -227,7 +227,7 @@ Hardening enables the following features:
Disable-wallet mode
--------------------
-When the intention is to run only a P2P node without a wallet, Bitcoin Core may be compiled in
+When the intention is to run only a P2P node without a wallet, XPChain Core may be compiled in
disable-wallet mode with:
./configure --disable-wallet
@@ -249,8 +249,8 @@ Setup and Build Example: Arch Linux
This example lists the steps necessary to setup and build a command line only, non-wallet distribution of the latest changes on Arch Linux:
pacman -S git base-devel boost libevent python
- git clone https://github.com/bitcoin/bitcoin.git
- cd bitcoin/
+ git clone https://github.com/xpchain/xpchain.git
+ cd xpchain/
./autogen.sh
./configure --disable-wallet --without-gui --without-miniupnpc
make check
@@ -259,7 +259,7 @@ Note:
Enabling wallet support requires either compiling against a Berkeley DB newer than 4.8 (package `db`) using `--with-incompatible-bdb`,
or building and depending on a local version of Berkeley DB 4.8. The readily available Arch Linux packages are currently built using
`--with-incompatible-bdb` according to the [PKGBUILD](https://projects.archlinux.org/svntogit/community.git/tree/bitcoin/trunk/PKGBUILD).
-As mentioned above, when maintaining portability of the wallet between the standard Bitcoin Core distributions and independently built
+As mentioned above, when maintaining portability of the wallet between the standard XPChain Core distributions and independently built
node software is desired, Berkeley DB 4.8 must be used.
@@ -284,4 +284,3 @@ To build executables for ARM:
For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
-
diff --git a/doc/build-windows.md b/doc/build-windows.md
index 12adadacdc14..f78aaf63617d 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 XPChain Core for Windows.
-The options known to work for building Bitcoin Core on Windows are:
+The options known to work for building XPChain Core 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 XPChain Core 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.
@@ -79,13 +79,13 @@ Ubuntu Bionic 18.04 [1](#footnote1):
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 XPChain Core source path MUST be somewhere in the default mount file system, for
+example /usr/src/xpchain, 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.
Acquire the source in the usual way:
- git clone https://github.com/bitcoin/bitcoin.git
+ git clone https://github.com/xpchain/xpchain.git
Once the source code is ready the build steps are below.
@@ -107,13 +107,13 @@ For Ubuntu Bionic 18.04 and Windows Subsystem for Linux [1](#footnote1)= 1024. For this
reason, on 64-bit Unix systems we rely on an internal LevelDB optimization that
uses `mmap()` + `close()` to open table files without actually retaining
@@ -732,7 +732,7 @@ In addition to reviewing the upstream changes in `env_posix.cc`, you can use `ls
check this. For example, on Linux this command will show open `.ldb` file counts:
```bash
-$ lsof -p $(pidof bitcoind) |\
+$ lsof -p $(pidof xpchaind) |\
awk 'BEGIN { fd=0; mem=0; } /ldb$/ { if ($4 == "mem") mem++; else fd++ } END { printf "mem = %s, fd = %s\n", mem, fd}'
mem = 119, fd = 0
```
@@ -747,14 +747,14 @@ details.
### Consensus Compatibility
It is possible for LevelDB changes to inadvertently change consensus
-compatibility between nodes. This happened in Bitcoin 0.8 (when LevelDB was
+compatibility between nodes. This happened in XPChain 0.8 (when LevelDB was
first introduced). When upgrading LevelDB you should review the upstream changes
to check for issues affecting consensus compatibility.
For example, if LevelDB had a bug that accidentally prevented a key from being
returned in an edge case, and that bug was fixed upstream, the bug "fix" would
be an incompatible consensus change. In this situation the correct behavior
-would be to revert the upstream fix before applying the updates to Bitcoin's
+would be to revert the upstream fix before applying the updates to XPChain's
copy of LevelDB. In general you should be wary of any upstream changes affecting
what data is returned from LevelDB queries.
@@ -800,7 +800,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:xpchain/xpchain.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`,
@@ -824,7 +824,7 @@ To create a scripted-diff:
The scripted-diff is verified by the tool `test/lint/commit-script-check.sh`
-Commit [`bb81e173`](https://github.com/bitcoin/bitcoin/commit/bb81e173) is an example of a scripted-diff.
+Commit [`bb81e173`](https://github.com/xpchain/xpchain/commit/bb81e173) is an example of a scripted-diff.
RPC interface guidelines
--------------------------
@@ -866,7 +866,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 `xpchain-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
@@ -885,7 +885,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*: `xpchain-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.
@@ -907,7 +907,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 XPChain Core, 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 55a5c28258c6..00806d3a2f03 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,
+XPChain Core 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 XPChain community.
-Other implementations of Bitcoin software may also use the same
+Other implementations of XPChain 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 XPChain 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 XPChain
network and must not be retained longer than necessary nor disclosed
to any third party.
@@ -42,7 +42,7 @@ 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
+discontinue providing services and contact the active XPChain
Core development team as well as posting on
[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev).
diff --git a/doc/files.md b/doc/files.md
index 5657b1e6cbeb..245f7a785d05 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
+* xpchain.conf: contains configuration settings for xpchaind or xpchain-qt
+* xpchaind.pid: stores the process id of xpchaind 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 xpchaind or xpchain-qt
* fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation; since 0.10.0
* indexes/txindex/*: optional transaction index database (LevelDB); since 0.17.0
* mempool.dat: dump of the mempool's transactions; since 0.14.0.
diff --git a/doc/fuzzing.md b/doc/fuzzing.md
index 5dedcb51c895..4789bca56311 100644
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -1,4 +1,4 @@
-Fuzz-testing Bitcoin Core
+Fuzz-testing XPChain Core
==========================
A special test harness `test_bitcoin_fuzzy` is provided to provide an easy
@@ -20,7 +20,7 @@ export AFLPATH=$PWD
Instrumentation
----------------
-To build Bitcoin Core using AFL instrumentation (this assumes that the
+To build XPChain Core 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++
@@ -55,7 +55,7 @@ AFLOUT=$PWD/outputs
Example inputs are available from:
-- https://download.visucore.com/bitcoin/bitcoin_fuzzy_in.tar.xz
+- https://download.visucore.com/xpchain/xpchain_fuzzy_in.tar.xz
- http://strateman.ninja/fuzzing.tar.xz
Extract these (or other starting inputs) into the `inputs` directory before starting fuzzing.
diff --git a/doc/gitian-building.md b/doc/gitian-building.md
index 3a48f4a0b397..aea60524a8ba 100644
--- a/doc/gitian-building.md
+++ b/doc/gitian-building.md
@@ -1,4 +1,4 @@
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).
+This file was moved to [the XPChain 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 239b74e4e1d7..725bfa69ab30 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 xpchaind
==========================================================
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/xpchaind.service: systemd service unit configuration
+ contrib/init/xpchaind.openrc: OpenRC compatible SysV style init script
+ contrib/init/xpchaind.openrcconf: OpenRC conf.d file
+ contrib/init/xpchaind.conf: Upstart service configuration file
+ contrib/init/xpchaind.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 "xpchain" user
and group. They must be created before attempting to use these scripts.
-The macOS configuration assumes bitcoind will be set up for the current user.
+The macOS configuration assumes xpchaind 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, xpchaind 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, xpchaind 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 xpchaind 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 xpchaind 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 xpchaind 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 `share/examples/bitcoin.conf`.
+see `share/examples/xpchain.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/xpchaind`
+Configuration file: `/etc/xpchain/xpchain.conf`
+Data directory: `/var/lib/xpchaind`
+PID file: `/var/run/xpchaind/xpchaind.pid` (OpenRC and Upstart) or `/var/lib/xpchaind/xpchaind.pid` (systemd)
+Lock file: `/var/lock/subsys/xpchaind` (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 xpchain 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
+xpchain user and group. Access to xpchain-cli and other xpchaind rpc clients
can then be controlled by group membership.
### macOS
-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/xpchaind`
+Configuration file: `~/Library/Application Support/XPChain/xpchain.conf`
+Data directory: `~/Library/Application Support/XPChain`
+Lock file: `~/Library/Application Support/XPChain/.lock`
Installing Service Configuration
-----------------------------------
@@ -81,23 +81,23 @@ 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 xpchaind` and to enable for system startup run
+`systemctl enable xpchaind`
NOTE: When installing for systemd in Debian/Ubuntu the .service file needs to be copied to the /lib/systemd/system directory instead.
### OpenRC
-Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d. Double
+Rename xpchaind.openrc to xpchaind 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/xpchaind start` and configure it to run on startup with
+`rc-update add xpchaind`
### Upstart (for Debian/Ubuntu based distributions)
Upstart is the default init system for Debian/Ubuntu versions older than 15.04. If you are using version 15.04 or newer and haven't manually configured upstart you should follow the systemd instructions instead.
-Drop bitcoind.conf in /etc/init. Test by running `service bitcoind start`
+Drop xpchaind.conf in /etc/init. Test by running `service xpchaind start`
it will automatically start on reboot.
NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
@@ -105,22 +105,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 xpchaind.init to /etc/init.d/xpchaind. Test by running `service xpchaind start`.
-Using this script, you can adjust the path and flags to the bitcoind program by
+Using this script, you can adjust the path and flags to the xpchaind program by
setting the BITCOIND and FLAGS environment variables in the file
-/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
+/etc/sysconfig/xpchaind. You can also use the DAEMONOPTS environment variable here.
### macOS
-Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by
-running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`.
+Copy io.xpchain.xpchaind.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/io.xpchain.xpchaind.plist`.
-This Launch Agent will cause bitcoind to start whenever the user logs in.
+This Launch Agent will cause xpchaind 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 xpchaind as the current user.
+You will need to modify io.xpchain.xpchaind.plist if you intend to use it as a
+Launch Daemon with a dedicated xpchain user.
Auto-respawn
-----------------------------------
diff --git a/doc/reduce-traffic.md b/doc/reduce-traffic.md
index dd1469f5638e..9dcc70b96b90 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, XPChain Core 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=`)
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 xpchain'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 a24a13408b56..9fce6fc60e00 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,7 +1,7 @@
(note: this is a temporary file, to be added-to by anybody, and moved to
release-notes at release time)
-Bitcoin Core version *version* is now available from:
+XPChain Core version *version* is now available from:
@@ -10,7 +10,7 @@ and performance improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
-
+
To receive security and update notifications, please subscribe to:
@@ -47,10 +47,10 @@ processing the entire blockchain.
Compatibility
==============
-Bitcoin Core is extensively tested on multiple operating systems using
+XPChain Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not supported).
-Bitcoin Core should also work on most other Unix-like systems but is not
+XPChain Core should also work on most other Unix-like systems but is not
frequently tested on them.
From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built using Qt 5.9.x, which doesn't
diff --git a/doc/release-process.md b/doc/release-process.md
index 3ba622ee6db1..afbe6d7e535e 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -3,9 +3,9 @@ Release Process
Before every release candidate:
-* Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
+* Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/xpchain/xpchain/blob/master/doc/translation_process.md#synchronising-translations).
-* Update manpages, see [gen-manpages.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
+* Update manpages, see [gen-manpages.sh](https://github.com/xpchain/xpchain/blob/master/contrib/devtools/README.md#gen-manpagessh).
Before every minor and major release:
@@ -21,10 +21,10 @@ Before every minor and major release:
Before every major release:
-* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example.
+* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/xpchain/xpchain/pull/7415) for an example.
* Update [`BLOCK_CHAIN_SIZE`](/src/qt/intro.cpp) to the current size plus some overhead.
* Update `src/chainparams.cpp` chainTxData with statistics about the transaction count and rate. Use the output of the RPC `getchaintxstats`, see
- [this pull request](https://github.com/bitcoin/bitcoin/pull/12270) for an example. Reviewers can verify the results by running `getchaintxstats ` with the `window_block_count` and `window_last_block_hash` from your output.
+ [this pull request](https://github.com/xpchain/xpchain/pull/12270) for an example. Reviewers can verify the results by running `getchaintxstats ` with the `window_block_count` and `window_last_block_hash` from your output.
* Update version of `contrib/gitian-descriptors/*.yml`: usually one'd want to do this on master after branching off the release - but be sure to at least do it before a new major release
### First time / New builders
@@ -37,9 +37,9 @@ Check out the source code in the following directory hierarchy.
git clone https://github.com/bitcoin-core/gitian.sigs.git
git clone https://github.com/bitcoin-core/bitcoin-detached-sigs.git
git clone https://github.com/devrandom/gitian-builder.git
- git clone https://github.com/bitcoin/bitcoin.git
+ git clone https://github.com/xpchain/xpchain.git
-### Bitcoin maintainers/release engineers, suggestion for writing release notes
+### XPChain maintainers/release engineers, suggestion for writing release notes
Write release notes. git shortlog helps a lot, for example:
@@ -62,7 +62,7 @@ If you're using the automated script (found in [contrib/gitian-build.py](/contri
Setup Gitian descriptors:
- pushd ./bitcoin
+ pushd ./xpchain
export SIGNER="(your Gitian key, ie bluematt, sipa, etc)"
export VERSION=(new version, e.g. 0.8.0)
git fetch
@@ -95,10 +95,10 @@ Create the macOS SDK tarball, see the [macOS readme](README_osx.md) for details,
NOTE: Gitian is sometimes unable to download files. If you have errors, try the step below.
-By default, Gitian will fetch source files as needed. To cache them ahead of time, make sure you have checked out the tag you want to build in bitcoin, then:
+By default, Gitian will fetch source files as needed. To cache them ahead of time, make sure you have checked out the tag you want to build in xpchain, then:
pushd ./gitian-builder
- make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common
+ make -C ../xpchain/depends download SOURCES_PATH=`pwd`/cache/common
popd
Only missing files will be fetched, so this is safe to re-run for each build.
@@ -106,47 +106,47 @@ Only missing files will be fetched, so this is safe to re-run for each build.
NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example:
pushd ./gitian-builder
- ./bin/gbuild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments}
+ ./bin/gbuild --url xpchain=/path/to/xpchain,signature=/path/to/sigs {rest of arguments}
popd
The gbuild invocations below DO NOT DO THIS by default.
-### Build and sign Bitcoin Core for Linux, Windows, and macOS:
+### Build and sign XPChain Core for Linux, Windows, and macOS:
pushd ./gitian-builder
- ./bin/gbuild --num-make 2 --memory 3000 --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
- ./bin/gsign --signer "$SIGNER" --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
- mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../
-
- ./bin/gbuild --num-make 2 --memory 3000 --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
- ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
- mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
- mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../
-
- ./bin/gbuild --num-make 2 --memory 3000 --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
- ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
- mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
- mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../
+ ./bin/gbuild --num-make 2 --memory 3000 --commit xpchain=v${VERSION} ../xpchain/contrib/gitian-descriptors/gitian-linux.yml
+ ./bin/gsign --signer "$SIGNER" --release ${VERSION}-linux --destination ../gitian.sigs/ ../xpchain/contrib/gitian-descriptors/gitian-linux.yml
+ mv build/out/xpchain-*.tar.gz build/out/src/xpchain-*.tar.gz ../
+
+ ./bin/gbuild --num-make 2 --memory 3000 --commit xpchain=v${VERSION} ../xpchain/contrib/gitian-descriptors/gitian-win.yml
+ ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../xpchain/contrib/gitian-descriptors/gitian-win.yml
+ mv build/out/xpchain-*-win-unsigned.tar.gz inputs/xpchain-win-unsigned.tar.gz
+ mv build/out/xpchain-*.zip build/out/xpchain-*.exe ../
+
+ ./bin/gbuild --num-make 2 --memory 3000 --commit xpchain=v${VERSION} ../xpchain/contrib/gitian-descriptors/gitian-osx.yml
+ ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../xpchain/contrib/gitian-descriptors/gitian-osx.yml
+ mv build/out/xpchain-*-osx-unsigned.tar.gz inputs/xpchain-osx-unsigned.tar.gz
+ mv build/out/xpchain-*.tar.gz build/out/xpchain-*.dmg ../
popd
Build output expected:
- 1. source tarball (`bitcoin-${VERSION}.tar.gz`)
- 2. linux 32-bit and 64-bit dist tarballs (`bitcoin-${VERSION}-linux[32|64].tar.gz`)
- 3. windows 32-bit and 64-bit unsigned installers and dist zips (`bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe`, `bitcoin-${VERSION}-win[32|64].zip`)
- 4. macOS unsigned installer and dist tarball (`bitcoin-${VERSION}-osx-unsigned.dmg`, `bitcoin-${VERSION}-osx64.tar.gz`)
+ 1. source tarball (`xpchain-${VERSION}.tar.gz`)
+ 2. linux 32-bit and 64-bit dist tarballs (`xpchain-${VERSION}-linux[32|64].tar.gz`)
+ 3. windows 32-bit and 64-bit unsigned installers and dist zips (`xpchain-${VERSION}-win[32|64]-setup-unsigned.exe`, `xpchain-${VERSION}-win[32|64].zip`)
+ 4. macOS unsigned installer and dist tarball (`xpchain-${VERSION}-osx-unsigned.dmg`, `xpchain-${VERSION}-osx64.tar.gz`)
5. Gitian signatures (in `gitian.sigs/${VERSION}-/(your Gitian key)/`)
### Verify other gitian builders signatures to your own. (Optional)
-Add other gitian builders keys to your gpg keyring, and/or refresh keys: See `../bitcoin/contrib/gitian-keys/README.md`.
+Add other gitian builders keys to your gpg keyring, and/or refresh keys: See `../xpchain/contrib/gitian-keys/README.md`.
Verify the signatures
pushd ./gitian-builder
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../xpchain/contrib/gitian-descriptors/gitian-linux.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../xpchain/contrib/gitian-descriptors/gitian-win.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../xpchain/contrib/gitian-descriptors/gitian-osx.yml
popd
### Next steps:
@@ -167,22 +167,22 @@ Codesigner only: Create Windows/macOS detached signatures:
Codesigner only: Sign the macOS binary:
- transfer bitcoin-osx-unsigned.tar.gz to macOS for signing
- tar xf bitcoin-osx-unsigned.tar.gz
+ transfer xpchain-osx-unsigned.tar.gz to macOS for signing
+ tar xf xpchain-osx-unsigned.tar.gz
./detached-sig-create.sh -s "Key ID"
Enter the keychain password and authorize the signature
Move signature-osx.tar.gz back to the gitian host
Codesigner only: Sign the windows binaries:
- tar xf bitcoin-win-unsigned.tar.gz
+ tar xf xpchain-win-unsigned.tar.gz
./detached-sig-create.sh -key /path/to/codesign.key
Enter the passphrase for the key when prompted
signature-win.tar.gz will be created
Codesigner only: Commit the detached codesign payloads:
- cd ~/bitcoin-detached-sigs
+ cd ~/xpchain-detached-sigs
checkout the appropriate branch for this release series
rm -rf *
tar xf signature-osx.tar.gz
@@ -200,20 +200,20 @@ Non-codesigners: wait for Windows/macOS detached signatures:
Create (and optionally verify) the signed macOS binary:
pushd ./gitian-builder
- ./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
- ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-signed --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-signed ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
- mv build/out/bitcoin-osx-signed.dmg ../bitcoin-${VERSION}-osx.dmg
+ ./bin/gbuild -i --commit signature=v${VERSION} ../xpchain/contrib/gitian-descriptors/gitian-osx-signer.yml
+ ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-signed --destination ../gitian.sigs/ ../xpchain/contrib/gitian-descriptors/gitian-osx-signer.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-signed ../xpchain/contrib/gitian-descriptors/gitian-osx-signer.yml
+ mv build/out/xpchain-osx-signed.dmg ../xpchain-${VERSION}-osx.dmg
popd
Create (and optionally verify) the signed Windows binaries:
pushd ./gitian-builder
- ./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
- ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-signed ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
- mv build/out/bitcoin-*win64-setup.exe ../bitcoin-${VERSION}-win64-setup.exe
- mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe
+ ./bin/gbuild -i --commit signature=v${VERSION} ../xpchain/contrib/gitian-descriptors/gitian-win-signer.yml
+ ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../xpchain/contrib/gitian-descriptors/gitian-win-signer.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-signed ../xpchain/contrib/gitian-descriptors/gitian-win-signer.yml
+ mv build/out/xpchain-*win64-setup.exe ../xpchain-${VERSION}-win64-setup.exe
+ mv build/out/xpchain-*win32-setup.exe ../xpchain-${VERSION}-win32-setup.exe
popd
Commit your signature for the signed macOS/Windows binaries:
@@ -235,23 +235,23 @@ sha256sum * > SHA256SUMS
The list of files should be:
```
-bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz
-bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz
-bitcoin-${VERSION}-i686-pc-linux-gnu.tar.gz
-bitcoin-${VERSION}-x86_64-linux-gnu.tar.gz
-bitcoin-${VERSION}-osx64.tar.gz
-bitcoin-${VERSION}-osx.dmg
-bitcoin-${VERSION}.tar.gz
-bitcoin-${VERSION}-win32-setup.exe
-bitcoin-${VERSION}-win32.zip
-bitcoin-${VERSION}-win64-setup.exe
-bitcoin-${VERSION}-win64.zip
+xpchain-${VERSION}-aarch64-linux-gnu.tar.gz
+xpchain-${VERSION}-arm-linux-gnueabihf.tar.gz
+xpchain-${VERSION}-i686-pc-linux-gnu.tar.gz
+xpchain-${VERSION}-x86_64-linux-gnu.tar.gz
+xpchain-${VERSION}-osx64.tar.gz
+xpchain-${VERSION}-osx.dmg
+xpchain-${VERSION}.tar.gz
+xpchain-${VERSION}-win32-setup.exe
+xpchain-${VERSION}-win32.zip
+xpchain-${VERSION}-win64-setup.exe
+xpchain-${VERSION}-win64.zip
```
The `*-debug*` files generated by the gitian build contain debug symbols
for troubleshooting by developers. It is assumed that anyone that is interested
in debugging can run gitian to generate the files for themselves. To avoid
end-user confusion about which file to pick, as well as save storage
-space *do not upload these to the bitcoin.org server, nor put them in the torrent*.
+space *do not upload these to the xpchain.io server, nor put them in the torrent*.
- GPG-sign it, delete the unsigned file:
```
@@ -261,28 +261,28 @@ rm SHA256SUMS
(the digest algorithm is forced to sha256 to avoid confusion of the `Hash:` header that GPG adds with the SHA256 used for the files)
Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spurious/nonsensical entry.
-- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the bitcoin.org server
- into `/var/www/bin/bitcoin-core-${VERSION}`
+- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the xpchain.io server
+ into `/var/www/bin/xpchain-core-${VERSION}`
- A `.torrent` will appear in the directory after a few minutes. Optionally help seed this torrent. To get the `magnet:` URI use:
```bash
transmission-show -m
```
Insert the magnet URI into the announcement sent to mailing lists. This permits
-people without access to `bitcoin.org` to download the binary distribution.
+people without access to `xpchain.io` to download the binary distribution.
Also put it into the `optional_magnetlink:` slot in the YAML file for
-bitcoin.org (see below for bitcoin.org update instructions).
+xpchain.io (see below for xpchain.io update instructions).
-- Update bitcoin.org version
+- Update xpchain.io version
- - First, check to see if the Bitcoin.org maintainers have prepared a
+ - First, check to see if the XPChain.org maintainers have prepared a
release: https://github.com/bitcoin-dot-org/bitcoin.org/labels/Core
- If they have, it will have previously failed their Travis CI
checks because the final release files weren't uploaded.
Trigger a Travis CI rebuild---if it passes, merge.
- - If they have not prepared a release, follow the Bitcoin.org release
+ - If they have not prepared a release, follow the XPChain.org release
instructions: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/adding-events-release-notes-and-alerts.md#release-notes
- After the pull request is merged, the website will automatically show the newest version within 15 minutes, as well
@@ -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/
+ - XPChain Core announcements list https://xpchaincore.org/en/list/announcements/join/
- - bitcoincore.org blog post
+ - xpchaincore.org blog post
- - Update title of #bitcoin on Freenode IRC
+ - Update title of #xpchain on Freenode IRC
- - Optionally twitter, reddit /r/Bitcoin, ... but this will usually sort out itself
+ - Optionally twitter, reddit /r/XPChain, ... 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/xpchain/xpchain/releases/new) with a link to the archived release notes.
- Celebrate
diff --git a/doc/shared-libraries.md b/doc/shared-libraries.md
index dc363582cc8d..64c0ee483791 100644
--- a/doc/shared-libraries.md
+++ b/doc/shared-libraries.md
@@ -3,7 +3,7 @@ Shared Libraries
## bitcoinconsensus
-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 XPChain's consensus available to other applications, e.g. to language bindings.
### API
diff --git a/doc/tor.md b/doc/tor.md
index 97d86b08fd5a..158f49a662f5 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -1,14 +1,14 @@
-# TOR SUPPORT IN BITCOIN
+# TOR SUPPORT IN XPCHAIN
-It is possible to run Bitcoin Core as a Tor hidden service, and connect to such services.
+It is possible to run XPChain Core 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 Core behind a Tor proxy
+## 1. Run XPChain Core behind a Tor proxy
-The first step is running Bitcoin Core behind a Tor proxy. This will already anonymize all
+The first step is running XPChain Core behind a Tor proxy. This will already anonymize all
outgoing connections, but more is possible.
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
@@ -29,27 +29,27 @@ outgoing connections, but more is possible.
In a typical situation, this suffices to run behind a Tor proxy:
- ./bitcoind -proxy=127.0.0.1:9050
+ ./xpchaind -proxy=127.0.0.1:9050
-## 2. Run a Bitcoin Core hidden server
+## 2. Run a XPChain Core 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): *Needed for Tor version 0.2.7.0 and older versions of Tor only. For newer
versions of Tor see [Section 3](#3-automatically-listen-on-tor).*
- HiddenServiceDir /var/lib/tor/bitcoin-service/
+ HiddenServiceDir /var/lib/tor/xpchain-service/
HiddenServicePort 8798 127.0.0.1:8798
HiddenServicePort 18798 127.0.0.1:18798
The directory can be different of course, but (both) port numbers should be equal to
-your bitcoind's P2P listen port (8798 by default).
+your xpchaind's P2P listen port (8798 by default).
- -externalip=X You can tell bitcoin about its publicly reachable address using
+ -externalip=X You can tell xpchain about its publicly reachable address using
this option, and this can be a .onion address. Given the above
configuration, you can find your .onion address in
- /var/lib/tor/bitcoin-service/hostname. For connections
+ /var/lib/tor/xpchain-service/hostname. For connections
coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs), .onion addresses are given
preference for your node to advertise itself with.
@@ -66,55 +66,55 @@ your bitcoind's P2P listen port (8798 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
+ ./xpchaind -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
+ ./xpchaind ... -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
+ ./xpchaind ... -discover
and open port 8798 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:
- ./bitcoind -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
+ ./xpchaind -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.
+XPChain Core 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
+XPChain Core 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 XPChain Core 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 xpchaind 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 xpchaind to the same group and setting permissions appropriately. On
+Debian-based systems the user running xpchaind 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.
## 4. Privacy recommendations
-- Do not add anything but Bitcoin Core ports to the hidden service created in section 2.
+- Do not add anything but XPChain Core 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 19f145e9bff5..b49ec7820fe0 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -1,14 +1,14 @@
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 XPChain-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, XPChain-Core 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 XPChain’s global adoption, and growth. One of XPChain’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.
+See the [Transifex XPChain 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.
### Writing code with translations
We use automated scripts to help extract translations in both Qt, and non-Qt source files. It is rarely necessary to manually edit the files in `src/qt/locale/`. The translation source files must adhere to the following format:
@@ -43,7 +43,7 @@ git commit
### Creating a Transifex account
Visit the [Transifex Signup](https://www.transifex.com/signup/) page to create an account. Take note of your username and password, as they will be required to configure the command-line tool.
-You can find the Bitcoin translation project at [https://www.transifex.com/projects/p/bitcoin/](https://www.transifex.com/projects/p/bitcoin/).
+You can find the XPChain translation project at [https://www.transifex.com/projects/p/bitcoin/](https://www.transifex.com/projects/p/bitcoin/).
### Installing the Transifex client command-line tool
The client is used to fetch updated translations. If you are having problems, or need more details, see [https://docs.transifex.com/client/installing-the-client](https://docs.transifex.com/client/installing-the-client)
@@ -62,7 +62,7 @@ token =
username = USERNAME
```
-The Transifex Bitcoin project config file is included as part of the repo. It can be found at `.tx/config`, however you shouldn’t need to change anything.
+The Transifex XPChain project config file is included as part of the repo. It can be found at `.tx/config`, however you shouldn’t need to change anything.
### Synchronising translations
To assist in updating translations, we have created a script to help.
@@ -100,6 +100,6 @@ To create a new language template, you will need to edit the languages manifest
**Note:** that the language translation file **must end in `.qm`** (the compiled extension), and not `.ts`.
### Questions and general assistance
-The Bitcoin-Core translation maintainers include *tcatm, seone, Diapolo, wumpus and luke-jr*. You can find them, and others, in the Freenode IRC chatroom - `irc.freenode.net #bitcoin-core-dev`.
+The XPChain-Core translation maintainers include *tcatm, seone, Diapolo, wumpus and luke-jr*. You can find them, and others, in the Freenode IRC chatroom - `irc.freenode.net #bitcoin-core-dev`.
If you are a translator, you should also subscribe to the mailing list, https://groups.google.com/forum/#!forum/bitcoin-translators. Announcements will be posted during application pre-releases to notify translators to check for updates.
diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md
index 737d11f045cc..31cffb1646bf 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 XPChain Core software.
How to translate?
------------------
@@ -75,10 +75,10 @@ In Qt code use tr's third argument for optional plurality. For example:
This adds ``s to the respective `.ts` file, which can be translated separately depending on the language. In English, this is simply:
- %n active connection(s) to Bitcoin network
+ %n active connection(s) to XPChain network
- %n active connection to Bitcoin network
- %n active connections to Bitcoin network
+ %n active connection to XPChain network
+ %n active connections to XPChain network
diff --git a/doc/travis-ci.md b/doc/travis-ci.md
index 38085cec353a..fd513d452d1e 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.
+XPChain Core 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 14cfc8accbbc..2b34f5ef4399 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 XPChain Core daemon can be configured to act as a trusted "border
+router", implementing the xpchain 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 XPChain Core 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.
@@ -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 xpchain.conf.
ZeroMQ endpoint specifiers for TCP (and others) are documented in the
[ZeroMQ API](http://api.zeromq.org/4-0:_start).
@@ -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 you are
-using. Bitcoind appends an up-counting sequence number to each
+using. XPChaind appends an up-counting sequence number to each
notification which allows listeners to detect lost notifications.