Merge branch 'rebrand'

2019-06-06 01:37:01 +08:00
parent 80c2180cec 14c5e6c59a
commit 23c3b7ed32
193 changed files with 941 additions and 1004 deletions
@@ -1,7 +1,7 @@
-Contributing to Bitcoin Core
+Contributing to NYC3
 ============================

-The Bitcoin Core project operates an open contributor model where anyone is
+The NYC3 project operates an open contributor model where anyone is
 welcome to contribute towards development in the form of peer review, testing
 and patches. This document explains the practical process and guidelines for
 contributing.
@@ -21,7 +21,7 @@ list.
 Communication Channels
 ----------------------

-Most communication about Bitcoin Core development happens on IRC, in the
+Most communication about NYC3 development happens on IRC, in the
 #bitcoin-core-dev channel on Freenode. The easiest way to participate on IRC is
 with the web client, [webchat.freenode.net](https://webchat.freenode.net/). Chat
 history logs can be found
@@ -199,11 +199,11 @@ workload on reviewing.
 "Decision Making" Process
 -------------------------

-The following applies to code changes to the Bitcoin Core project (and related
+The following applies to code changes to the NYC3 project (and related
 projects such as libsecp256k1), and is not to be confused with overall Bitcoin
 Network Protocol consensus changes.

-Whether a pull request is merged into Bitcoin Core rests with the project merge
+Whether a pull request is merged into NYC3 rests with the project merge
 maintainers and ultimately the project lead.

 Maintainers will take into consideration if a patch is in line with the general
@@ -302,7 +302,7 @@ about:
 Release Policy
 --------------

-The project leader is the release manager for each Bitcoin Core release.
+The project leader is the release manager for each NYC3 release.

 Copyright
 ---------
@@ -2,4 +2,4 @@ Building Bitcoin
 ================

 See doc/build-*.md for instructions on building the various
-elements of the Bitcoin Core reference implementation of Bitcoin.
+elements of the NYC3 reference implementation of Bitcoin.
@@ -2,7 +2,7 @@ NYC3 (NewYorkCoin3) integration/staging tree
 ============================================


-Built upon Bitcoin Core 0.18; NYC3 offers a blocktime of 10 seconds, consensus operates using the 'Parallel' password hashing algorithm in a POW configuration (SHA512-based) and uses LWMA3 to regulate block-spacing.
+Built upon Bitcoin Core 0.18; NYC3 offers a blocktime of 10 seconds, consensus operates using a modified version of the Argon2 password hashing algorithm (http://github.com/barrystyle/argon2s) in a POW configuration and uses LWMA3 to regulate block-spacing.


 License
@@ -1,9 +1,9 @@
-Building Bitcoin Core with Visual Studio
+Building NYC3 with Visual Studio
 ========================================

 Introduction
 ---------------------
-Solution and project files to build the Bitcoin Core applications (except Qt dependent ones) with Visual Studio 2017 can be found in the build_msvc directory.
+Solution and project files to build the NYC3 applications (except Qt dependent ones) with Visual Studio 2017 can be found in the build_msvc directory.

 Building with Visual Studio is an alternative to the Linux based [cross-compiler build](https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md).

@@ -26,7 +26,7 @@
 #define COPYRIGHT_HOLDERS_FINAL "The Bitcoin Core developers"

 /* Replacement for %s in copyright holders string */
-#define COPYRIGHT_HOLDERS_SUBSTITUTION "Bitcoin Core"
+#define COPYRIGHT_HOLDERS_SUBSTITUTION "NYC3"

 /* Copyright year */
 #define COPYRIGHT_YEAR 2018
@@ -343,10 +343,10 @@
 #define PACKAGE_BUGREPORT "https://github.com/bitcoin/bitcoin/issues"

 /* Define to the full name of this package. */
-#define PACKAGE_NAME "Bitcoin Core"
+#define PACKAGE_NAME "NYC3"

 /* Define to the full name and version of this package. */
-#define PACKAGE_STRING "Bitcoin Core 0.17.99"
+#define PACKAGE_STRING "NYC3 0.17.99"

 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "bitcoin"
@@ -9,7 +9,7 @@ define(_CLIENT_VERSION_IS_RELEASE, true)
 define(_COPYRIGHT_YEAR, 2019)
 define(_COPYRIGHT_HOLDERS,[The %s developers])
 define(_COPYRIGHT_HOLDERS_SUBSTITUTION,[[nyc3]])
-AC_INIT([Bitcoin Core],m4_join([.], _CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MINOR, _CLIENT_VERSION_REVISION, m4_if(_CLIENT_VERSION_BUILD, [0], [], _CLIENT_VERSION_BUILD))m4_if(_CLIENT_VERSION_RC, [0], [], [rc]_CLIENT_VERSION_RC),[https://github.com/bitcoin/bitcoin/issues],[bitcoin],[https://bitcoincore.org/])
+AC_INIT([NYC3],m4_join([.], _CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MINOR, _CLIENT_VERSION_REVISION, m4_if(_CLIENT_VERSION_BUILD, [0], [], _CLIENT_VERSION_BUILD))m4_if(_CLIENT_VERSION_RC, [0], [], [rc]_CLIENT_VERSION_RC),[https://github.com/bitcoin/bitcoin/issues],[bitcoin],[https://bitcoincore.org/])
 AC_CONFIG_SRCDIR([src/validation.cpp])
 AC_CONFIG_HEADERS([src/config/bitcoin-config.h])
 AC_CONFIG_AUX_DIR([build-aux])
@@ -27,10 +27,10 @@ The [Debian](/contrib/debian) subfolder contains the copyright file.
 All other packaging related files can be found in the [bitcoin-core/packaging](https://github.com/bitcoin-core/packaging) repository.

 ### [Gitian-descriptors](/contrib/gitian-descriptors) ###
-Files used during the gitian build process. For more information about gitian, see the [the Bitcoin Core documentation repository](https://github.com/bitcoin-core/docs).
+Files used during the gitian build process. For more information about gitian, see the [the NYC3 documentation repository](https://github.com/bitcoin-core/docs).

 ### [Gitian-keys](/contrib/gitian-keys)
-PGP keys used for signing Bitcoin Core [Gitian release](/doc/release-process.md) results.
+PGP keys used for signing NYC3 [Gitian release](/doc/release-process.md) results.

 ### [MacDeploy](/contrib/macdeploy) ###
 Scripts and notes for Mac builds. 
@@ -5,9 +5,9 @@ Upstream-Contact: Satoshi Nakamoto <satoshin@gmx.com>
 Source: https://github.com/bitcoin/bitcoin

 Files: *
-Copyright: 2009-2019, Bitcoin Core Developers
+Copyright: 2009-2019, NYC3 Developers
 License: Expat
-Comment: The Bitcoin Core Developers encompasses the current developers listed on bitcoin.org,
+Comment: The NYC3 Developers encompasses the current developers listed on bitcoin.org,
         as well as the numerous contributors to the project.

 Files: debian/*
@@ -17,7 +17,7 @@ git diff -U0 HEAD~1.. | ./contrib/devtools/clang-format-diff.py -p1 -i -v
 copyright\_header.py
 ====================

-Provides utilities for managing copyright headers of `The Bitcoin Core
+Provides utilities for managing copyright headers of `The NYC3
 developers` in repository source files. It has three subcommands:

 ```
@@ -90,7 +90,7 @@ def compile_copyright_regex(copyright_style, year_style, name):
 EXPECTED_HOLDER_NAMES = [
    "Satoshi Nakamoto\n",
    "The Bitcoin Core developers\n",
-    "Bitcoin Core Developers\n",
+    "NYC3 Developers\n",
    "BitPay Inc\.\n",
    "University of Illinois at Urbana-Champaign\.\n",
    "Pieter Wuille\n",
@@ -1,5 +1,5 @@
 #!/usr/bin/env python3
-# Copyright (c) 2016-2017 Bitcoin Core Developers
+# Copyright (c) 2016-2017 NYC3 Developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.

@@ -24,4 +24,4 @@ while read fingerprint keyholder_name; do gpg --keyserver hkp://subset.pool.sks-
 ```

 Add your key to the list if you provided Gitian signatures for two major or
-minor releases of Bitcoin Core.
+minor releases of NYC3.
@@ -1,4 +1,4 @@
-description "Bitcoin Core Daemon"
+description "NYC3 Daemon"

 start on runlevel [2345]
 stop on starting rc RUNLEVEL=[016]
@@ -18,7 +18,7 @@ BITCOIND_BIN=${BITCOIND_BIN:-/usr/bin/bitcoind}
 BITCOIND_NICE=${BITCOIND_NICE:-${NICELEVEL:-0}}
 BITCOIND_OPTS="${BITCOIND_OPTS:-${BITCOIN_OPTS}}"

-name="Bitcoin Core Daemon"
+name="NYC3 Daemon"
 description="Bitcoin cryptocurrency P2P network daemon"

 command="/usr/bin/bitcoind"
@@ -5,10 +5,10 @@
 Make sure you obtain the proper release signing key and verify the fingerprint with several independent sources.

 ```sh
-$ gpg --fingerprint "Bitcoin Core binary release signing key"
+$ gpg --fingerprint "NYC3 binary release signing key"
 pub   4096R/36C2E964 2015-06-24 [expires: 2017-02-13]
      Key fingerprint = 01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964
-uid                  Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>
+uid                  Wladimir J. van der Laan (NYC3 binary release signing key) <laanwj@gmail.com>
 ```

 #### Usage:
@@ -124,7 +124,7 @@ if [ $RET -ne 0 ]; then
      echo "Bad signature."
   elif [ $RET -eq 2 ]; then
      #or if a gpg error has occurred
-      echo "gpg error. Do you have the Bitcoin Core binary release signing key installed?"
+      echo "gpg error. Do you have the NYC3 binary release signing key installed?"
   fi

   echo "gpg output:"
@@ -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           = "NYC3"

 # 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
@@ -7,7 +7,7 @@ Dialog.

 ## Versioning

-The RPC interface might change from one major version of Bitcoin Core to the
+The RPC interface might change from one major version of NYC3 to the
 next. This makes the RPC interface implicitly versioned on the major version.
 The version tuple can be retrieved by e.g. the `getnetworkinfo` RPC in
 `version`.
@@ -19,21 +19,21 @@ were deprecated and how to re-enable them temporarily.

 ## Security

-The RPC interface allows other programs to control Bitcoin Core,
+The RPC interface allows other programs to control NYC3,
 including the ability to spend funds from your wallets, affect consensus
 verification, read private data, and otherwise perform operations that
 can cause loss of money, data, or privacy.  This section suggests how
-you should use and configure Bitcoin Core to reduce the risk that its
+you should use and configure NYC3 to reduce the risk that its
 RPC interface will be abused.

 - **Securing the executable:** Anyone with physical or remote access to
-  the computer, container, or virtual machine running Bitcoin Core can
+  the computer, container, or virtual machine running NYC3 can
  compromise either the whole program or just the RPC interface.  This
  includes being able to record any passphrases you enter for unlocking
-  your encrypted wallets or changing settings so that your Bitcoin Core
+  your encrypted wallets or changing settings so that your NYC3
  program tells you that certain transactions have multiple
  confirmations even when they aren't part of the best block chain.  For
-  this reason, you should not use Bitcoin Core for security sensitive
+  this reason, you should not use NYC3 for security sensitive
  operations on systems you do not exclusively control, such as shared
  computers or virtual private servers.

@@ -43,19 +43,19 @@ RPC interface will be abused.
  and passphrase).  Any program on your computer with access to the file
  system and local network can obtain this level of access.
  Additionally, other programs on your computer can attempt to provide
-  an RPC interface on the same port as used by Bitcoin Core in order to
+  an RPC interface on the same port as used by NYC3 in order to
  trick you into revealing your authentication credentials.  For this
-  reason, it is important to only use Bitcoin Core for
+  reason, it is important to only use NYC3 for
  security-sensitive operations on a computer whose other programs you
  trust.

 - **Securing remote network access:** You may optionally allow other
-  computers to remotely control Bitcoin Core by setting the `rpcallowip`
+  computers to remotely control NYC3 by setting the `rpcallowip`
  and `rpcbind` configuration parameters.  These settings are only meant
  for enabling connections over secure private networks or connections
  that have been otherwise secured (e.g. using a VPN or port forwarding
  with SSH or stunnel).  **Do not enable RPC connections over the public
-  Internet.**  Although Bitcoin Core's RPC interface does use
+  Internet.**  Although NYC3's RPC interface does use
  authentication, it does not use encryption, so your login credentials
  are sent as clear text that can be read by anyone on your network
  path.  Additionally, the RPC interface has not been hardened to
@@ -65,21 +65,21 @@ RPC interface will be abused.
  `bitcoind -help` for more information about these settings and other
  settings described in this document.

-    Related, if you use Bitcoin Core inside a Docker container, you may
+    Related, if you use NYC3 inside a Docker container, you may
    need to expose the RPC port to the host system.  The default way to
    do this in Docker also exposes the port to the public Internet.
    Instead, expose it only on the host system's localhost, for example:
    `-p 127.0.0.1:8332:8332`

- **Secure authentication:** By default, Bitcoin Core generates unique
+- **Secure authentication:** By default, NYC3 generates unique
  login credentials each time it restarts and puts them into a file
-  readable only by the user that started Bitcoin Core, allowing any of
+  readable only by the user that started NYC3, allowing any of
  that user's RPC clients with read access to the file to login
-  automatically.  The file is `.cookie` in the Bitcoin Core
+  automatically.  The file is `.cookie` in the NYC3
  configuration directory, and using these credentials is the preferred
  RPC authentication method.  If you need to generate static login
  credentials for your programs, you can use the script in the
-  `share/rpcauth` directory in the Bitcoin Core source tree.  As a final
+  `share/rpcauth` directory in the NYC3 source tree.  As a final
  fallback, you can directly use manually-chosen `rpcuser` and
  `rpcpassword` configuration parameters---but you must ensure that you
  choose a strong and unique passphrase (and still don't use insecure
@@ -1,15 +1,15 @@
-Bitcoin Core
+NYC3
 =============

 Setup
 ---------------------
-Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires a few hundred gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
+NYC3 is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires a few hundred gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.

-To download Bitcoin Core, visit [bitcoincore.org](https://bitcoincore.org/en/download/).
+To download NYC3, visit [bitcoincore.org](https://bitcoincore.org/en/download/).

 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 NYC3 on your native platform.

 ### Unix

@@ -24,7 +24,7 @@ Unpack the files into a directory, and then run bitcoin-qt.exe.

 ### macOS

-Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
+Drag NYC3 to your applications folder, and then run NYC3.

 ### Need Help?

@@ -35,7 +35,7 @@ for help and more information.

 Building
 ---------------------
-The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
+The following are developer notes on how to build NYC3 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)
@@ -1,4 +1,4 @@
-Bitcoin Core
+NYC3
 =============

 Intro
@@ -13,7 +13,7 @@ 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.
+NYC3 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.
@@ -1,7 +1,7 @@
 Benchmarking
 ============

-Bitcoin Core has an internal benchmarking framework, with benchmarks
+NYC3 has an internal benchmarking framework, with benchmarks
 for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160), as well as the rolling bloom filter.

 Running
@@ -1,4 +1,4 @@
-BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.18.0**):
+BIPs that are implemented by NYC3 (up-to-date up to **v0.18.0**):

 * [`BIP 9`](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki): The changes allowing multiple soft-forks to be deployed in parallel have been implemented since **v0.12.1**  ([PR #7575](https://github.com/bitcoin/bitcoin/pull/7575))
 * [`BIP 11`](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki): Multisig outputs are standard since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)).
@@ -19,7 +19,7 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.18.0**):
 * [`BIP 65`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki): The CHECKLOCKTIMEVERIFY softfork was merged in **v0.12.0** ([PR #6351](https://github.com/bitcoin/bitcoin/pull/6351)), and backported to **v0.11.2** and **v0.10.4**. Mempool-only CLTV was added in [PR #6124](https://github.com/bitcoin/bitcoin/pull/6124).
 * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)).
 * [`BIP 68`](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): Sequence locks have been implemented as of **v0.12.1**  ([PR #7184](https://github.com/bitcoin/bitcoin/pull/7184)), and have been activated since *block 419328*.
-* [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). Support can be optionally disabled at build time since **v0.18.0** ([PR 14451](https://github.com/bitcoin/bitcoin/pull/14451)).
+* [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in NYC3 GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). Support can be optionally disabled at build time since **v0.18.0** ([PR 14451](https://github.com/bitcoin/bitcoin/pull/14451)).
 * [`BIP 90`](https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki): Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since **v0.14.0** ([PR #8391](https://github.com/bitcoin/bitcoin/pull/8391)).
 * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, and enforced for all peer versions as of **v0.13.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579) and [PR #6641](https://github.com/bitcoin/bitcoin/pull/6641)).
 * [`BIP 112`](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki): The CHECKSEQUENCEVERIFY opcode has been implemented since **v0.12.1** ([PR #7524](https://github.com/bitcoin/bitcoin/pull/7524)) and has been activated since *block 419328*.
@@ -34,7 +34,7 @@ BerkeleyDB is only necessary for the wallet functionality. To skip this, pass
 export BDB_PREFIX="$PWD/db4"
 ```

-## Building Bitcoin Core
+## Building NYC3

 **Important**: Use `gmake` (the non-GNU `make` will exit with an error):

@@ -47,7 +47,7 @@ from the root of the repository. Then set `BDB_PREFIX` for the next section:
 export BDB_PREFIX="$PWD/db4"
 ```

-### Building Bitcoin Core
+### Building NYC3

 **Important**: Use `gmake` (the non-GNU `make` will exit with an error).

@@ -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 NYC3

 **Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.

@@ -38,17 +38,17 @@ from the root of the repository.

 **Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](/doc/build-osx.md#disable-wallet-mode)).

-Build Bitcoin Core
+Build NYC3
 ------------------------

-1. Clone the Bitcoin Core source code:
+1. Clone the NYC3 source code:

        git clone https://github.com/bitcoin/bitcoin
        cd bitcoin

-2.  Build Bitcoin Core:
+2.  Build NYC3:

-    Configure and build the headless Bitcoin Core binaries as well as the GUI (if Qt is found).
+    Configure and build the headless NYC3 binaries as well as the GUI (if Qt is found).

    You can disable the GUI build by passing `--without-gui` to configure.

@@ -66,7 +66,7 @@ Build Bitcoin Core

 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, NYC3 may be compiled in
 disable-wallet mode with:

    ./configure --disable-wallet
@@ -78,7 +78,7 @@ Mining is also possible in disable-wallet mode using the `getblocktemplate` RPC
 Running
 -------

-Bitcoin Core is now available at `./src/bitcoind`
+NYC3 is now available at `./src/bitcoind`

 Before running, you may create an empty configuration file:

@@ -1,12 +1,12 @@
 UNIX BUILD NOTES
 ====================
-Some notes on how to build Bitcoin Core in Unix.
+Some notes on how to build NYC3 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 NYC3 and the dependencies.
 For example, when specifying the path of the dependency:

 	../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
@@ -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 NYC3. On systems with less, gcc can be
 tuned to conserve memory with additional CXXFLAGS:


@@ -85,7 +85,7 @@ pass `--with-incompatible-bdb` to configure.

 Otherwise, you can build from self-compiled `depends` (see above).

-To build Bitcoin Core without wallet, see [*Disable-wallet mode*](/doc/build-unix.md#disable-wallet-mode)
+To build NYC3 without wallet, see [*Disable-wallet mode*](/doc/build-unix.md#disable-wallet-mode)


 Optional (see --with-miniupnpc and --enable-upnp-default):
@@ -177,7 +177,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 NYC3 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:

@@ -207,7 +207,7 @@ Hardening enables the following features:
    ET_DYN

 * _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, NYC3 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.
@@ -223,7 +223,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, NYC3 may be compiled in
 disable-wallet mode with:

    ./configure --disable-wallet
@@ -254,7 +254,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 NYC3 distributions and independently built
 node software is desired, Berkeley DB 4.8 must be used.


@@ -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 NYC3 for Windows.

-The options known to work for building Bitcoin Core on Windows are:
+The options known to work for building NYC3 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 NYC3 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.

@@ -83,7 +83,7 @@ Ubuntu Bionic 18.04 <sup>[1](#footnote1)</sup>:

 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
+Note that for WSL the NYC3 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.
 This means you cannot use a directory that is located directly on the host Windows file system to perform the build.

@@ -111,7 +111,7 @@ 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
+Note that for WSL the NYC3 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.
 This means you cannot use a directory that located directly on the host Windows file system to perform the build.

@@ -154,5 +154,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 Core code using the win32 version of the Mingw-w64 cross compilers (at least not without
-modifying headers in the Bitcoin Core source code).
+It's not possible to build the NYC3 code using the win32 version of the Mingw-w64 cross compilers (at least not without
+modifying headers in the NYC3 source code).
@@ -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 NYC3. 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#third-party-libraries) |
 | --- | --- | --- | --- | --- | --- |
@@ -1,6 +1,6 @@
-# Support for Output Descriptors in Bitcoin Core
+# Support for Output Descriptors in NYC3

-Since Bitcoin Core v0.17, there is support for Output Descriptors. This is a
+Since NYC3 v0.17, there is support for Output Descriptors. This is a
 simple language which can be used to describe collections of output scripts.
 Supporting RPCs are:
 - `scantxoutset` takes as input descriptors to scan for, and also reports
@@ -172,7 +172,7 @@ steps, or for dumping wallet descriptors including private key material.
 ### Compatibility with old wallets

 In order to easily represent the sets of scripts currently supported by
-existing Bitcoin Core wallets, a convenience function `combo` is
+existing NYC3 wallets, a convenience function `combo` is
 provided, which takes as input a public key, and describes a set of P2PK,
 P2PKH, P2WPKH, and P2SH-P2WPH scripts for that key. In case the key is
 uncompressed, the set only includes P2PK and P2PKH scripts.
@@ -189,7 +189,7 @@ be detected in descriptors up to 501 characters, and up to 3 errors in longer
 ones. For larger numbers of errors, or other types of errors, there is a
 roughly 1 in a trillion chance of not detecting the errors.

-All RPCs in Bitcoin Core will include the checksum in their output. Only
+All RPCs in NYC3 will include the checksum in their output. Only
 certain RPCs require checksums on input, including `deriveaddress` and
 `importmulti`. The checksum for a descriptor without one can be computed
 using the `getdescriptorinfo` RPC.
@@ -22,7 +22,7 @@ Developer Notes
    - [Threads](#threads)
    - [Ignoring IDE/editor files](#ignoring-ideeditor-files)
 - [Development guidelines](#development-guidelines)
-    - [General Bitcoin Core](#general-bitcoin-core)
+    - [General NYC3](#general-bitcoin-core)
    - [Wallet](#wallet)
    - [General C++](#general-c)
    - [C++ data structures](#c-data-structures)
@@ -130,7 +130,7 @@ Refer to [/test/functional/README.md#style-guidelines](/test/functional/README.m
 Coding Style (Doxygen-compatible comments)
 ------------------------------------------

-Bitcoin Core uses [Doxygen](http://www.doxygen.nl/) to generate its official documentation.
+NYC3 uses [Doxygen](http://www.doxygen.nl/) to generate its official documentation.

 Use Doxygen-compatible comment blocks for functions, methods, and fields.

@@ -229,7 +229,7 @@ that run in `-regtest` mode.

 ### DEBUG_LOCKORDER

-Bitcoin Core is a multi-threaded application, and deadlocks or other
+NYC3 is a multi-threaded application, and deadlocks or other
 multi-threading bugs can be very difficult to track down. The `--enable-debug`
 configure option adds `-DDEBUG_LOCKORDER` to the compiler flags. This inserts
 run-time checks to keep track of which locks are held, and adds warnings to the
@@ -313,7 +313,7 @@ See the functional test documentation for how to invoke perf within tests.

 **Sanitizers**

-Bitcoin Core can be compiled with various "sanitizers" enabled, which add
+NYC3 can be compiled with various "sanitizers" enabled, which add
 instrumentation for issues regarding things like memory safety, thread race
 conditions, or undefined behavior. This is controlled with the
 `--with-sanitizers` configure flag, which should be a comma separated list of
@@ -412,7 +412,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 NYC3, 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`:
@@ -442,9 +442,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 NYC3 code.

-General Bitcoin Core
+General NYC3
 ----------------------

 - New features should be exposed on RPC first, then can be made available in the GUI
@@ -602,7 +602,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*: NYC3 uses tinyformat, which is type safe. Leave them out to avoid confusion

 Variable names
 --------------
@@ -769,12 +769,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 NYC3, 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 NYC3 so that they can be integrated
 quickly.  Cosmetic changes should be purely taken upstream.

 There is a tool in `test/lint/git-subtree-check.sh` to check a subtree directory for consistency with
@@ -969,7 +969,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 NYC3, 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
@@ -1,7 +1,7 @@
 Expectations for DNS Seed operators
 ====================================

-Bitcoin Core attempts to minimize the level of trust in DNS seeds,
+NYC3 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.
@@ -1,4 +1,4 @@
-Fuzz-testing Bitcoin Core
+Fuzz-testing NYC3
 ==========================

 A special test harness in `src/test/fuzz/` is provided for each fuzz target to
@@ -43,7 +43,7 @@ export AFLPATH=$PWD

 ### Instrumentation

-To build Bitcoin Core using AFL instrumentation (this assumes that the
+To build NYC3 using AFL instrumentation (this assumes that the
 `AFLPATH` was set as above):
 ```
 ./configure --disable-ccache --disable-shared --enable-tests --enable-fuzz --disable-wallet --disable-bench --with-utils=no --with-daemon=no --with-libs=no --with-gui=no CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
@@ -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 NYC3 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).
@@ -4,10 +4,10 @@
 bitcoin-cli \- manual page for bitcoin-cli v0.18.0.0
 .SH SYNOPSIS
 .B bitcoin-cli
-[\fI\,options\/\fR] \fI\,<command> \/\fR[\fI\,params\/\fR]  \fI\,Send command to Bitcoin Core\/\fR
+[\fI\,options\/\fR] \fI\,<command> \/\fR[\fI\,params\/\fR]  \fI\,Send command to NYC3\/\fR
 .br
 .B bitcoin-cli
-[\fI\,options\/\fR] \fI\,-named <command> \/\fR[\fI\,name=value\/\fR]...  \fI\,Send command to Bitcoin Core (with named arguments)\/\fR
+[\fI\,options\/\fR] \fI\,-named <command> \/\fR[\fI\,name=value\/\fR]...  \fI\,Send command to NYC3 (with named arguments)\/\fR
 .br
 .B bitcoin-cli
 [\fI\,options\/\fR] \fI\,help                List commands\/\fR
@@ -15,7 +15,7 @@ bitcoin-cli \- manual page for bitcoin-cli v0.18.0.0
 .B bitcoin-cli
 [\fI\,options\/\fR] \fI\,help <command>      Get help for a command\/\fR
 .SH DESCRIPTION
-Bitcoin Core RPC client version v0.18.0.0
+NYC3 RPC client version v0.18.0.0
 .SH OPTIONS
 .HP
 \-?
@@ -106,7 +106,7 @@ Use the test chain
 .SH COPYRIGHT
 Copyright (C) 2009-2019 The Bitcoin Core developers

-Please contribute if you find Bitcoin Core useful. Visit
+Please contribute if you find NYC3 useful. Visit
 <https://bitcoincore.org> for further information about the software.
 The source code is available from <https://github.com/bitcoin/bitcoin>.

@@ -6,7 +6,7 @@ bitcoin-qt \- manual page for bitcoin-qt v0.18.0.0
 .B bitcoin-qt
 [\fI\,command-line options\/\fR]
 .SH DESCRIPTION
-Bitcoin Core version v0.18.0.0 (64\-bit)
+NYC3 version v0.18.0.0 (64\-bit)
 .SH OPTIONS
 .HP
 \-?
@@ -628,7 +628,7 @@ Show splash screen on startup (default: 1)
 .SH COPYRIGHT
 Copyright (C) 2009-2019 The Bitcoin Core developers

-Please contribute if you find Bitcoin Core useful. Visit
+Please contribute if you find NYC3 useful. Visit
 <https://bitcoincore.org> for further information about the software.
 The source code is available from <https://github.com/bitcoin/bitcoin>.

@@ -9,7 +9,7 @@ bitcoin-tx \- manual page for bitcoin-tx v0.18.0.0
 .B bitcoin-tx
 [\fI\,options\/\fR] \fI\,-create \/\fR[\fI\,commands\/\fR]   \fI\,Create hex-encoded bitcoin transaction\/\fR
 .SH DESCRIPTION
-Bitcoin Core bitcoin\-tx utility version v0.18.0.0
+NYC3 bitcoin\-tx utility version v0.18.0.0
 .SH OPTIONS
 .HP
 \-?
@@ -107,7 +107,7 @@ Set register NAME to given JSON\-STRING
 .SH COPYRIGHT
 Copyright (C) 2009-2019 The Bitcoin Core developers

-Please contribute if you find Bitcoin Core useful. Visit
+Please contribute if you find NYC3 useful. Visit
 <https://bitcoincore.org> for further information about the software.
 The source code is available from <https://github.com/bitcoin/bitcoin>.

@@ -3,9 +3,9 @@
 .SH NAME
 bitcoin-wallet \- manual page for bitcoin-wallet v0.18.0.0
 .SH DESCRIPTION
-Bitcoin Core bitcoin\-wallet version v0.18.0.0
+NYC3 bitcoin\-wallet version v0.18.0.0
 .PP
-wallet\-tool is an offline tool for creating and interacting with Bitcoin Core wallet files.
+wallet\-tool is an offline tool for creating and interacting with NYC3 wallet files.
 By default wallet\-tool will act on wallets in the default mainnet wallet directory in the datadir.
 To change the target wallet, use the \fB\-datadir\fR, \fB\-wallet\fR and \fB\-testnet\fR/\-regtest arguments.
 .SS "Usage:"
@@ -54,7 +54,7 @@ Get wallet info
 .SH COPYRIGHT
 Copyright (C) 2009-2019 The Bitcoin Core developers

-Please contribute if you find Bitcoin Core useful. Visit
+Please contribute if you find NYC3 useful. Visit
 <https://bitcoincore.org> for further information about the software.
 The source code is available from <https://github.com/bitcoin/bitcoin>.

@@ -4,9 +4,9 @@
 bitcoind \- manual page for bitcoind v0.18.0.0
 .SH SYNOPSIS
 .B bitcoind
-[\fI\,options\/\fR]                     \fI\,Start Bitcoin Core Daemon\/\fR
+[\fI\,options\/\fR]                     \fI\,Start NYC3 Daemon\/\fR
 .SH DESCRIPTION
-Bitcoin Core Daemon version v0.18.0.0
+NYC3 Daemon version v0.18.0.0
 .SH OPTIONS
 .HP
 \-?
@@ -602,7 +602,7 @@ Accept command line and JSON\-RPC commands
 .SH COPYRIGHT
 Copyright (C) 2009-2019 The Bitcoin Core developers

-Please contribute if you find Bitcoin Core useful. Visit
+Please contribute if you find NYC3 useful. Visit
 <https://bitcoincore.org> for further information about the software.
 The source code is available from <https://github.com/bitcoin/bitcoin>.

@@ -1,6 +1,6 @@
-# PSBT Howto for Bitcoin Core
+# PSBT Howto for NYC3

-Since Bitcoin Core 0.17, an RPC interface exists for Partially Signed Bitcoin
+Since NYC3 0.17, an RPC interface exists for Partially Signed Bitcoin
 Transactions (PSBTs, as specified in
 [BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)).

@@ -46,7 +46,7 @@ The names above in bold are the names of the roles defined in BIP174. They're
 useful in understanding the underlying steps, but in practice, software and
 hardware implementations will typically implement multiple roles simultaneously.

-## PSBT in Bitcoin Core
+## PSBT in NYC3

 ### RPCs

@@ -89,10 +89,10 @@ hardware implementations will typically implement multiple roles simultaneously.

 ### Workflows

-#### Multisig with multiple Bitcoin Core instances
+#### Multisig with multiple NYC3 instances

 Alice, Bob, and Carol want to create a 2-of-3 multisig address. They're all using
-Bitcoin Core. We assume their wallets only contain the multisig funds. In case
+NYC3. We assume their wallets only contain the multisig funds. In case
 they also have a personal wallet, this can be accomplished through the
 multiwallet feature - possibly resulting in a need to add `-rpcwallet=name` to
 the command line in case `bitcoin-cli` is used.
@@ -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, NYC3 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.
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.18.x is now available from:
+NYC3 version 0.18.x is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.18.x/>

@@ -35,16 +35,16 @@ wallet versions are still supported.
 Compatibility
 ==============

-Bitcoin Core is supported and extensively tested on operating systems
+NYC3 is supported and extensively tested on operating systems
 using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
-recommended to use Bitcoin Core on unsupported systems.
+recommended to use NYC3 on unsupported systems.

-Bitcoin Core should also work on most other Unix-like systems but is not
+NYC3 should also work on most other Unix-like systems but is not
 as 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 support versions of macOS older than
-10.10. Additionally, Bitcoin Core does not yet change appearance when
+10.10. Additionally, NYC3 does not yet change appearance when
 macOS "dark mode" is activated.

 In addition to previously-supported CPU platforms, this release's
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.10.0 is now available from:
+NYC3 version 0.10.0 is now available from:

  https://bitcoin.org/bin/0.10.0/

@@ -25,7 +25,7 @@ Downgrading warning

 Because release 0.10.0 makes use of headers-first synchronization and parallel
 block download (see further), the block files and databases are not
-backwards-compatible with older versions of Bitcoin Core or other software:
+backwards-compatible with older versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -50,7 +50,7 @@ Notable changes
 Faster synchronization
 ----------------------

-Bitcoin Core now uses 'headers-first synchronization'. This means that we first
+NYC3 now uses 'headers-first synchronization'. This means that we first
 ask peers for block headers (a total of 27 megabytes, as of December 2014) and
 validate those. In a second stage, when the headers have been discovered, we
 download the blocks. However, as we already know about the whole chain in
@@ -222,7 +222,7 @@ addresses need to added to the wallet before the payment, though.
 Consensus library
 -----------------

-Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
+Starting from 0.10.0, the NYC3 distribution includes a consensus library.

 The purpose of this library is to make the verification functionality that is
 critical to Bitcoin's consensus available to other applications, e.g. to language
@@ -249,7 +249,7 @@ redemption scripts, allowing applications to make use of any valid
 script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
 While the Bitcoin protocol has always supported these types of script,
 actually using them on mainnet has been previously inconvenient as
-standard Bitcoin Core nodes wouldn't relay them to miners, nor would
+standard NYC3 nodes wouldn't relay them to miners, nor would
 most miners include them in blocks they mined.

 bitcoin-tx
@@ -279,7 +279,7 @@ key and script operations easily accessible via command line.
 Mining and relay policy enhancements
 ------------------------------------

-Bitcoin Core's block templates are now for version 3 blocks only, and any mining
+NYC3's block templates are now for version 3 blocks only, and any mining
 software relying on its `getblocktemplate` must be updated in parallel to use
 libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
 If you are solo mining, this will affect you the moment you upgrade Bitcoin
@@ -292,10 +292,10 @@ achieving its 951/1001 status.
 The `prioritisetransaction` RPC method has been added to enable miners to
 manipulate the priority of transactions on an individual basis.

-Bitcoin Core now supports BIP 22 long polling, so mining software can be
+NYC3 now supports BIP 22 long polling, so mining software can be
 notified immediately of new templates rather than having to poll periodically.

-Support for BIP 23 block proposals is now available in Bitcoin Core's
+Support for BIP 23 block proposals is now available in NYC3's
 `getblocktemplate` method. This enables miners to check the basic validity of
 their next block before expending work on it, reducing risks of accidental
 hardforks or mining invalid blocks.
@@ -313,7 +313,7 @@ AllowFreeThreshold(), in which case they are relayed subject to the rate limiter
 BIP 66: strict DER encoding for signatures
 ------------------------------------------

-Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
+NYC3 0.10 implements BIP 66, which introduces block version 3, and a new
 consensus rule, which prohibits non-DER signatures. Such transactions have been
 non-standard since Bitcoin v0.8.0 (released in February 2013), but were
 technically still permitted inside blocks.
@@ -522,7 +522,7 @@ Wallet:
 GUI:
 - `c21c74b` osx: Fix missing dock menu with qt5
 - `b90711c` Fix Transaction details shows wrong To:
- `516053c` Make links in 'About Bitcoin Core' clickable
+- `516053c` Make links in 'About NYC3' clickable
 - `bdc83e8` Ensure payment request network matches client network
 - `65f78a1` Add GUI view of peer information
 - `06a91d9` VerifyDB progress reporting
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.10.1 is now available from:
+NYC3 version 0.10.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.10.1/>

@@ -25,7 +25,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.10.2 is now available from:
+NYC3 version 0.10.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.10.2/>

@@ -25,7 +25,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.10.3 is now available from:
+NYC3 version 0.10.3 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.10.3/>

@@ -25,7 +25,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -82,7 +82,7 @@ permitted. Even BIP62 did not propose applying this rule to
 old version transactions, but conforming implementations have become
 much more common since BIP62 was initially written.

-Bitcoin Core has produced compatible signatures since a28fb70e in
+NYC3 has produced compatible signatures since a28fb70e in
 September 2013, but this didn't make it into a release until 0.9
 in March 2014; Bitcoinj has done so for a similar span of time.
 Bitcoinjs and electrum have been more recently updated.
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.10.4 is now available from:
+NYC3 version 0.10.4 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.10.4/>

@@ -26,7 +26,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -79,13 +79,13 @@ found at the URLs below:
 - Block versions over the last 2,000 blocks showing the days to the
  earliest possible BIP65 consensus-enforced block: <http://bitcoin.sipa.be/ver-2k.png>

-**Notice to miners:** Bitcoin Core’s block templates are now for
+**Notice to miners:** NYC3’s block templates are now for
 version 4 blocks only, and any mining software relying on its
 getblocktemplate must be updated in parallel to use libblkmaker either
 version FIXME or any version from FIXME onward.

 - If you are solo mining, this will affect you the moment you upgrade
-  Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
+  NYC3, which must be done prior to BIP65 achieving its 951/1001
  status.

 - If you are mining with the stratum mining protocol: this does not
@@ -101,7 +101,7 @@ Windows bug fix for corrupted UTXO database on unclean shutdowns
 ----------------------------------------------------------------

 Several Windows users reported that they often need to reindex the
-entire blockchain after an unclean shutdown of Bitcoin Core on Windows
+entire blockchain after an unclean shutdown of NYC3 on Windows
 (or an unclean shutdown of Windows itself). Although unclean shutdowns
 remain unsafe, this release no longer relies on memory-mapped files for
 the UTXO database, which significantly reduced the frequency of unclean
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.11.0 is now available from:
+NYC3 version 0.11.0 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.11.0/>

@@ -25,7 +25,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -86,7 +86,7 @@ related to the blockchain in the bitcoin system: the raw blocks as received over
 the network (blk???.dat), the undo data (rev???.dat), the block index and the 
 UTXO set (both LevelDB databases). The databases are built from the raw data.

-Block pruning allows Bitcoin Core to delete the raw block and undo data once 
+Block pruning allows NYC3 to delete the raw block and undo data once 
 it's been validated and used to build the databases. At that point, the raw data 
 is used only to relay blocks to other nodes, to handle reorganizations, to look 
 up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or 
@@ -95,7 +95,7 @@ all blocks in the blockchain.

 The user specifies how much space to allot for block & undo files. The minimum 
 allowed is 550MB. Note that this is in addition to whatever is required for the 
-block index and UTXO databases. The minimum was chosen so that Bitcoin Core will 
+block index and UTXO databases. The minimum was chosen so that NYC3 will 
 be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 
 minutes per block). In rare instances it is possible that the amount of space 
 used will exceed the pruning target in order to keep the required last 288 
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.11.1 is now available from:
+NYC3 version 0.11.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.11.1/>

@@ -25,7 +25,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -83,7 +83,7 @@ permitted. Even BIP62 did not propose applying this rule to
 old version transactions, but conforming implementations have become
 much more common since BIP62 was initially written.

-Bitcoin Core has produced compatible signatures since a28fb70e in
+NYC3 has produced compatible signatures since a28fb70e in
 September 2013, but this didn't make it into a release until 0.9
 in March 2014; Bitcoinj has done so for a similar span of time.
 Bitcoinjs and electrum have been more recently updated.
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.11.2 is now available from:
+NYC3 version 0.11.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.11.2/>

@@ -26,7 +26,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -79,13 +79,13 @@ found at the URLs below:
 - Block versions over the last 2,000 blocks showing the days to the
  earliest possible BIP65 consensus-enforced block: <http://bitcoin.sipa.be/ver-2k.png>

-**Notice to miners:** Bitcoin Core’s block templates are now for
+**Notice to miners:** NYC3’s block templates are now for
 version 4 blocks only, and any mining software relying on its
 getblocktemplate must be updated in parallel to use libblkmaker either
 version 0.4.3 or any version from 0.5.2 onward.

 - If you are solo mining, this will affect you the moment you upgrade
-  Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
+  NYC3, which must be done prior to BIP65 achieving its 951/1001
  status.

 - If you are mining with the stratum mining protocol: this does not
@@ -149,7 +149,7 @@ Windows bug fix for corrupted UTXO database on unclean shutdowns
 ----------------------------------------------------------------

 Several Windows users reported that they often need to reindex the
-entire blockchain after an unclean shutdown of Bitcoin Core on Windows
+entire blockchain after an unclean shutdown of NYC3 on Windows
 (or an unclean shutdown of Windows itself). Although unclean shutdowns
 remain unsafe, this release no longer relies on memory-mapped files for
 the UTXO database, which significantly reduced the frequency of unclean
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.12.0 is now available from:
+NYC3 version 0.12.0 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.12.0/>

@@ -26,7 +26,7 @@ Downgrade warning

 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
-backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+backwards-compatible with pre-0.10 versions of NYC3 or other software:

 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
@@ -48,10 +48,10 @@ This does not affect wallet forward or backward compatibility.

 Because release 0.12.0 and later will obfuscate the chainstate on every
 fresh sync or reindex, the chainstate is not backwards-compatible with
-pre-0.12 versions of Bitcoin Core or other software.
+pre-0.12 versions of NYC3 or other software.

 If you want to downgrade after you have done a reindex with 0.12.0 or later,
-you will need to reindex when you first start Bitcoin Core version 0.11 or
+you will need to reindex when you first start NYC3 version 0.11 or
 earlier.

 Notable changes
@@ -107,15 +107,15 @@ can often prevent an extra roundtrip before the actual block is downloaded.
 Memory pool limiting
 --------------------

-Previous versions of Bitcoin Core had their mempool limited by checking
+Previous versions of NYC3 had their mempool limited by checking
 a transaction's fees against the node's minimum relay fee. There was no
 upper bound on the size of the mempool and attackers could send a large
 number of transactions paying just slighly more than the default minimum
 relay fee to crash nodes with relatively low RAM. A temporary workaround
-for previous versions of Bitcoin Core was to raise the default minimum
+for previous versions of NYC3 was to raise the default minimum
 relay fee.

-Bitcoin Core 0.12 will have a strict maximum size on the mempool. The
+NYC3 0.12 will have a strict maximum size on the mempool. The
 default value is 300 MB and can be configured with the `-maxmempool`
 parameter. Whenever a transaction would cause the mempool to exceed
 its maximum size, the transaction that (along with in-mempool descendants) has
@@ -124,7 +124,7 @@ minimum relay feerate will be increased to match this feerate plus the initial
 minimum relay feerate. The initial minimum relay feerate is set to
 1000 satoshis per kB.

-Bitcoin Core 0.12 also introduces new default policy limits on the length and
+NYC3 0.12 also introduces new default policy limits on the length and
 size of unconfirmed transaction chains that are allowed in the mempool
 (generally limiting the length of unconfirmed chains to 25 transactions, with a
 total size of 101 KB).  These limits can be overriden using command line
@@ -134,7 +134,7 @@ Opt-in Replace-by-fee transactions
 ----------------------------------

 It is now possible to replace transactions in the transaction memory pool of
-Bitcoin Core 0.12 nodes. Bitcoin Core will only allow replacement of
+NYC3 0.12 nodes. NYC3 will only allow replacement of
 transactions which have any of their inputs' `nSequence` number set to less
 than `0xffffffff - 1`.  Moreover, a replacement transaction may only be
 accepted when it pays sufficient fee, as described in [BIP 125]
@@ -156,7 +156,7 @@ updated RPC calls `gettransaction` and `listtransactions`, which now have an
 additional field in the output indicating if a transaction is replaceable under
 BIP125 ("bip125-replaceable").

-Note that the wallet in Bitcoin Core 0.12 does not yet have support for
+Note that the wallet in NYC3 0.12 does not yet have support for
 creating transactions that would be replaceable under BIP 125.


@@ -196,14 +196,14 @@ returned (previously all relevant hashes were returned).
 Relay and Mining: Priority transactions
 ---------------------------------------

-Bitcoin Core has a heuristic 'priority' based on coin value and age. This
+NYC3 has a heuristic 'priority' based on coin value and age. This
 calculation is used for relaying of transactions which do not pay the
 minimum relay fee, and can be used as an alternative way of sorting
-transactions for mined blocks. Bitcoin Core will relay transactions with
+transactions for mined blocks. NYC3 will relay transactions with
 insufficient fees depending on the setting of `-limitfreerelay=<r>` (default:
 `r=15` kB per minute) and `-blockprioritysize=<s>`.

-In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum
+In NYC3 0.12, when mempool limit has been reached a higher minimum
 relay fee takes effect to limit memory usage. Transactions which do not meet
 this higher effective minimum relay fee will not be relayed or mined even if
 they rank highly according to the priority heuristic.
@@ -224,7 +224,7 @@ Note, however, that if mining priority transactions is left disabled, the
 priority delta will be ignored and only the fee metric will be effective.

 This internal automatic prioritization handling is being considered for removal
-entirely in Bitcoin Core 0.13, and it is at this time undecided whether the
+entirely in NYC3 0.13, and it is at this time undecided whether the
 more accurate priority calculation for chained unconfirmed transactions will be
 restored. Community direction on this topic is particularly requested to help
 set project priorities.
@@ -234,15 +234,15 @@ Automatically use Tor hidden services

 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.
+NYC3 has been updated to make use of this.

 This means that if Tor is running (and proper authorization is available),
-Bitcoin Core automatically creates a hidden service to listen on, without
-manual configuration. Bitcoin Core will also use Tor automatically to connect
+NYC3 automatically creates a hidden service to listen on, without
+manual configuration. NYC3 will also use Tor automatically to connect
 to other .onion nodes if the control socket can be successfully opened. This
 will positively affect the number of available .onion nodes and their usage.

-This new feature is enabled by default if Bitcoin Core is listening, and
+This new feature is enabled by default if NYC3 is listening, and
 a connection to Tor can be made. It can be configured with the `-listenonion`,
 `-torcontrol` and `-torpassword` settings. To show verbose debugging
 information, pass `-debug=tor`.
@@ -264,7 +264,7 @@ transaction fees.

 Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`
 (or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin
-Core to use floating fees. By default, Bitcoin Core will use floating
+Core to use floating fees. By default, NYC3 will use floating
 fees.

 Based on past transaction data, floating fees approximate the fees
@@ -275,9 +275,9 @@ Sometimes, it is not possible to give good estimates, or an estimate
 at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`
 (default: `0.0002` BTC/kB).

-At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default:
+At all times, NYC3 will cap fees at `-maxtxfee=<x>` (default:
 0.10) BTC.
-Furthermore, Bitcoin Core will never create transactions paying less than
+Furthermore, NYC3 will never create transactions paying less than
 the current minimum relay fee.
 Finally, a user can set the minimum fee rate for all transactions with
 `-mintxfee=<i>`, which defaults to 1000 satoshis per kB.
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.12.1 is now available from:
+NYC3 version 0.12.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.12.1/>

@@ -27,10 +27,10 @@ Downgrade warning

 Because release 0.12.0 and later will obfuscate the chainstate on every
 fresh sync or reindex, the chainstate is not backwards-compatible with
-pre-0.12 versions of Bitcoin Core or other software.
+pre-0.12 versions of NYC3 or other software.

 If you want to downgrade after you have done a reindex with 0.12.0 or later,
-you will need to reindex when you first start Bitcoin Core version 0.11 or
+you will need to reindex when you first start NYC3 version 0.11 or
 earlier.

 Notable changes
@@ -84,7 +84,7 @@ For more information about the implementation, see
 BIP113 locktime enforcement soft fork
 -------------------------------------

-Bitcoin Core 0.11.2 previously introduced mempool-only locktime
+NYC3 0.11.2 previously introduced mempool-only locktime
 enforcement using GetMedianTimePast(). This release seeks to
 consensus enforce the rule.

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.13.0 is now available from:
+NYC3 version 0.13.0 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.0/>

@@ -21,7 +21,7 @@ an OS initially released in 2001. This means that not even critical security
 updates will be released anymore. Without security updates, using a bitcoin
 wallet on a XP machine is irresponsible at least.

-In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
+In addition to that, with 0.12.x there have been varied reports of NYC3
 randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
 what the source of these crashes is, but it is likely that upstream
 libraries such as Qt are no longer being tested on XP.
@@ -76,7 +76,7 @@ table by any user on the system.
 C++11 and Python 3
 ------------------

-Various code modernizations have been done. The Bitcoin Core code base has
+Various code modernizations have been done. The NYC3 code base has
 started using C++11. This means that a C++11-capable compiler is now needed for
 building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.

@@ -156,7 +156,7 @@ You can't disable HD key generation once you have created a HD wallet.

 There is no distinction between internal (change) and external keys.

-HD wallets are incompatible with older versions of Bitcoin Core.
+HD wallets are incompatible with older versions of NYC3.

 [Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

@@ -172,7 +172,7 @@ The code preparations for Segregated Witness ("segwit"), as described in [BIP
 finished and included in this release.  However, BIP 141 does not yet specify
 activation parameters on mainnet, and so this release does not support segwit
 use on mainnet.  Testnet use is supported, and after BIP 141 is updated with
-proposed parameters, a future release of Bitcoin Core is expected that
+proposed parameters, a future release of NYC3 is expected that
 implements those parameters for mainnet.

 Furthermore, because segwit activation is not yet specified for mainnet,
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.13.1 is now available from:
+NYC3 version 0.13.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.1/>

@@ -22,7 +22,7 @@ an OS initially released in 2001. This means that not even critical security
 updates will be released anymore. Without security updates, using a bitcoin
 wallet on a XP machine is irresponsible at least.

-In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
+In addition to that, with 0.12.x there have been varied reports of NYC3
 randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
 what the source of these crashes is, but it is likely that upstream
 libraries such as Qt are no longer being tested on XP.
@@ -131,13 +131,13 @@ covered by the txid. This provides several immediate benefits:
  (specifically, the segregated witnesses) while still ensuring that the node
  can build an accurate copy of the UTXO set for the block chain with the most
  proof of work.  Segwit enables this capability at the consensus layer, but
-  note that Bitcoin Core does not provide an option to use this capability as
+  note that NYC3 does not provide an option to use this capability as
  of this 0.13.1 release.

 - **Script versioning:** Segwit makes it easy for future soft forks to allow
  Bitcoin users to individually opt-in to almost any change in the Bitcoin
  Script language when those users receive new transactions.  Features
-  currently being researched by Bitcoin Core contributors that may use this
+  currently being researched by NYC3 contributors that may use this
  capability include support for Schnorr signatures, which can improve the
  privacy and efficiency of multisig transactions (or transactions with
  multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
@@ -183,7 +183,7 @@ a third-party to insert data into other people's transactions, changing
 the transaction's txid (called transaction malleability) and possibly
 causing other problems.

-Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and
+Since NYC3 0.10.0, nodes have defaulted to only relaying and
 mining transactions whose dummy element was a null value (0x00, also
 called OP_0).  The null dummy soft fork turns this relay rule into a
 consensus rule both for non-segwit transactions and segwit transactions,
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.13.2 is now available from:
+NYC3 version 0.13.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.2/>

@@ -21,7 +21,7 @@ an OS initially released in 2001. This means that not even critical security
 updates will be released anymore. Without security updates, using a bitcoin
 wallet on a XP machine is irresponsible at least.

-In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
+In addition to that, with 0.12.x there have been varied reports of NYC3
 randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
 what the source of these crashes is, but it is likely that upstream
 libraries such as Qt are no longer being tested on XP.
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.14.0 is now available from:
+NYC3 version 0.14.0 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.14.0/>

@@ -16,7 +16,7 @@ To receive security and update notifications, please subscribe to:
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later.

 Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
@@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
 can still do so at your own risk but be aware that there are known instabilities and issues.
 Please do not report issues about Windows XP to the issue tracker.

-Bitcoin Core should also work on most other Unix-like systems but is not
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -55,7 +55,7 @@ improved, leading to much shorter sync and initial block download times.
 Manual Pruning
 --------------

-Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning
+NYC3 has supported automatically pruning the blockchain since 0.11. Pruning
 the blockchain allows for significant storage space savings as the vast majority of
 the downloaded data can be discarded after processing so very little of it remains
 on the disk.
@@ -129,7 +129,7 @@ the same thing as the GUI icon. The command takes one boolean parameter,
 Out-of-sync Modal Info Layer
 ----------------------------

-When Bitcoin Core is out-of-sync on startup, a semi-transparent information
+When NYC3 is out-of-sync on startup, a semi-transparent information
 layer will be shown over top of the normal display. This layer contains
 details about the current sync progress and estimates the amount of time
 remaining to finish syncing. This layer can also be hidden and subsequently
@@ -189,7 +189,7 @@ commands such as `prioritisetransaction` so that those changes will not be lost.
 Final Alert
 -----------

-The Alert System was [disabled and deprecated](https://bitcoin.org/en/alert/2016-11-01-alert-retirement) in Bitcoin Core 0.12.1 and removed in 0.13.0. 
+The Alert System was [disabled and deprecated](https://bitcoin.org/en/alert/2016-11-01-alert-retirement) in NYC3 0.12.1 and removed in 0.13.0. 
 The Alert System was retired with a maximum sequence final alert which causes any nodes
 supporting the Alert System to display a static hard-coded "Alert Key Compromised" message which also
 prevents any other alerts from overriding it. This final alert is hard-coded into this release
@@ -241,7 +241,7 @@ Low-level RPC changes
   the mempool or if `txindex` is enabled.

 - A new RPC command `getmemoryinfo` has been added which will return information
-   about the memory usage of Bitcoin Core. This was added in conjunction with
+   about the memory usage of NYC3. This was added in conjunction with
   optimizations to memory management. See [Pull #8753](https://github.com/bitcoin/bitcoin/pull/8753)
   for more information.

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.14.1 is now available from:
+NYC3 version 0.14.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.14.1/>

@@ -16,7 +16,7 @@ To receive security and update notifications, please subscribe to:
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later.

 Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
@@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
 can still do so at your own risk but be aware that there are known instabilities and issues.
 Please do not report issues about Windows XP to the issue tracker.

-Bitcoin Core should also work on most other Unix-like systems but is not
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.14.2 is now available from:
+NYC3 version 0.14.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.14.2/>

@@ -16,7 +16,7 @@ To receive security and update notifications, please subscribe to:
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later.

 Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
@@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
 can still do so at your own risk but be aware that there are known instabilities and issues.
 Please do not report issues about Windows XP to the issue tracker.

-Bitcoin Core should also work on most other Unix-like systems but is not
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -40,7 +40,7 @@ other impact.

 This only affects users that have explicitly enabled UPnP through the GUI
 setting or through the `-upnp` option, as since the last UPnP vulnerability
-(in Bitcoin Core 0.10.3) it has been disabled by default.
+(in NYC3 0.10.3) it has been disabled by default.

 If you use this option, it is recommended to upgrade to this version as soon as
 possible.
@@ -1,4 +1,4 @@
-Bitcoin Core version *0.14.3* is now available from:
+NYC3 version *0.14.3* is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.14.3/>

@@ -16,7 +16,7 @@ To receive security and update notifications, please subscribe to:
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later.

 Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
@@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
 can still do so at your own risk but be aware that there are known instabilities and issues.
 Please do not report issues about Windows XP to the issue tracker.

-Bitcoin Core should also work on most other Unix-like systems but is not
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -34,7 +34,7 @@ Denial-of-Service vulnerability CVE-2018-17144
 -------------------------------

 A denial-of-service vulnerability exploitable by miners has been discovered in
-Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
+NYC3 versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
 the vulnerable versions to 0.14.3, 0.15.2 or 0.16.3 as soon as possible.

 Known Bugs
@@ -1,4 +1,4 @@
-Bitcoin Core version *0.15.0.1* is now available from:
+NYC3 version *0.15.0.1* is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.15.0.1/>

@@ -51,10 +51,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -1,4 +1,4 @@
-Bitcoin Core version *0.15.0* is now available from:
+NYC3 version *0.15.0* is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.15.0/>

@@ -48,10 +48,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notes for 0.15.0
@@ -136,23 +136,23 @@ Fee estimation has been significantly improved in version 0.15, with more accura
    - The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods).
    - An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to `CONSERVATIVE`).
    - The RPC return object now contains an `errors` member, which returns errors encountered during processing.
-    - If Bitcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
+    - If NYC3 has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
 - A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.

 Multi-wallet support
 --------------------

-Bitcoin Core now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/10849)). The wallets are completely separated, with individual balances, keys and received transactions.
+NYC3 now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/10849)). The wallets are completely separated, with individual balances, keys and received transactions.

 Multi-wallet is enabled by using more than one `-wallet` argument when starting Bitcoin, either on the command line or in the Bitcoin config file.

 **In Bitcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions.** GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem.

-Bitcoin Core 0.15.0 contains the following changes to the RPC interface and `bitcoin-cli` for multi-wallet:
+NYC3 0.15.0 contains the following changes to the RPC interface and `bitcoin-cli` for multi-wallet:

-* When running Bitcoin Core with a single wallet, there are **no** changes to the RPC interface or `bitcoin-cli`. All RPC calls and `bitcoin-cli` commands continue to work as before.
-* When running Bitcoin Core with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>` endpoint, and `bitcoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet.
-* When running Bitcoin Core with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>` endpoint, for example `127.0.0.1:8332/wallet/wallet1.dat`. `bitcoin-cli` commands should be run with a `-rpcwallet` option, for example `bitcoin-cli -rpcwallet=wallet1.dat getbalance`.
+* When running NYC3 with a single wallet, there are **no** changes to the RPC interface or `bitcoin-cli`. All RPC calls and `bitcoin-cli` commands continue to work as before.
+* When running NYC3 with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>` endpoint, and `bitcoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet.
+* When running NYC3 with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>` endpoint, for example `127.0.0.1:8332/wallet/wallet1.dat`. `bitcoin-cli` commands should be run with a `-rpcwallet` option, for example `bitcoin-cli -rpcwallet=wallet1.dat getbalance`.
 * A new *node-level* `listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument.

 Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.
@@ -160,7 +160,7 @@ Note that while multi-wallet is now fully supported, the RPC multi-wallet interf
 Replace-by-fee control in the GUI
 ---------------------------------

-Bitcoin Core has supported creating opt-in replace-by-fee (RBF) transactions
+NYC3 has supported creating opt-in replace-by-fee (RBF) transactions
 since version 0.12.0, and since version 0.14.0 has included a `bumpfee` RPC method to
 replace unconfirmed opt-in RBF transactions with a new transaction that pays
 a higher fee.
@@ -171,7 +171,7 @@ transaction with a higher-fee transaction are both supported in the GUI (See [PR
 Removal of Coin Age Priority
 ----------------------------

-In previous versions of Bitcoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Bitcoin Core 0.15 removes all remaining support for Coin Age Priority (See [PR 9602](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications:
+In previous versions of NYC3, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. NYC3 0.15 removes all remaining support for Coin Age Priority (See [PR 9602](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications:

 - The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed.
 - The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
@@ -204,7 +204,7 @@ Version 0.15 introduces several new RPC methods:
 Low-level RPC changes
 ---------------------

- When using Bitcoin Core in multi-wallet mode, RPC requests for wallet methods must specify
+- When using NYC3 in multi-wallet mode, RPC requests for wallet methods must specify
  the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details.

 - The new database model no longer stores information about transaction
@@ -246,7 +246,7 @@ Low-level RPC changes

 - The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument (See [PR 10143](https://github.com/bitcoin/bitcoin/pull/10143)).

- The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Bitcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
+- The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since NYC3 no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).

 - The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false (See [PR 10995](https://github.com/bitcoin/bitcoin/pull/10995)).

@@ -1,4 +1,4 @@
-Bitcoin Core version *0.15.1* is now available from:
+NYC3 version *0.15.1* is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.15.1/>

@@ -52,10 +52,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.


@@ -65,7 +65,7 @@ Notable changes
 Network fork safety enhancements
 --------------------------------

-A number of changes to the way Bitcoin Core deals with peer connections and invalid blocks
+A number of changes to the way NYC3 deals with peer connections and invalid blocks
 have been made, as a safety precaution against blockchain forks and misbehaving peers.

 - Unrequested blocks with less work than the minimum-chain-work are now no longer processed even
@@ -1,4 +1,4 @@
-Bitcoin Core version *0.15.2* is now available from:
+NYC3 version *0.15.2* is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.15.2/>

@@ -48,10 +48,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.


@@ -62,7 +62,7 @@ Denial-of-Service vulnerability CVE-2018-17144
 -------------------------------

 A denial-of-service vulnerability exploitable by miners has been discovered in
-Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
+NYC3 versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
 the vulnerable versions to 0.15.2 or 0.16.3 as soon as possible.

 0.15.2 Change log
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.16.0 is now available from:
+NYC3 version 0.16.0 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.16.0/>

@@ -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
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -54,7 +54,7 @@ Wallet changes

 ### Segwit Wallet

-Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.
+NYC3 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.

 A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate.
 A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions.
@@ -92,7 +92,7 @@ use the `replaceable` argument for individual transactions.

 ### Wallets directory configuration (`-walletdir`)

-Bitcoin Core now has more flexibility in where the wallets directory can be
+NYC3 now has more flexibility in where the wallets directory can be
 located. Previously wallet database files were stored at the top level of the
 bitcoin data directory. The behavior is now:

@@ -112,7 +112,7 @@ becomes unavailable during operation, funds may be lost.

 Build: Minimum GCC bumped to 4.8.x
 ------------------------------------
-The minimum version of the GCC compiler required to compile Bitcoin Core is now 4.8. No effort will be
+The minimum version of the GCC compiler required to compile NYC3 is now 4.8. No effort will be
 made to support older versions of GCC. See discussion in issue #11732 for more information.
 The minimum version for the Clang compiler is still 3.3. Other minimum dependency versions can be found in `doc/dependencies.md` in the repository.

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.16.1 is now available from:
+NYC3 version 0.16.1 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.16.1/>

@@ -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
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.16.2 is now available from:
+NYC3 version 0.16.2 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.16.2/>

@@ -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
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 0.16.2 change log
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.16.3 is now available from:
+NYC3 version 0.16.3 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.16.3/>

@@ -39,10 +39,10 @@ wallets that were created with older versions are not affected by this.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 should also work on most other Unix-like systems but is not
 frequently tested on them.

 Notable changes
@@ -52,7 +52,7 @@ Denial-of-Service vulnerability
 -------------------------------

 A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
-been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
+been discovered in NYC3 versions 0.14.0 up to 0.16.2. It is recommended
 to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

 0.16.3 change log
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.17.0.1 is now available from:
+NYC3 version 0.17.0.1 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.17.0.1/>

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.17.0 is now available from:
+NYC3 version 0.17.0 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.17.0/>

@@ -46,10 +46,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 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
@@ -256,7 +256,7 @@ hardware implementations will typically implement multiple roles simultaneously.
 Upgrading non-HD wallets to HD wallets
 --------------------------------------

-Since Bitcoin Core 0.13.0, creating new BIP 32 Hierarchical Deterministic wallets has been supported by Bitcoin Core but old non-HD wallets could not be upgraded to HD. Now non-HD wallets can be upgraded to HD using the `-upgradewallet` command line option. This upgrade will result in the all keys in the keypool being marked as used and a new keypool generated. **A new backup must be made when this upgrade is performed.**
+Since NYC3 0.13.0, creating new BIP 32 Hierarchical Deterministic wallets has been supported by NYC3 but old non-HD wallets could not be upgraded to HD. Now non-HD wallets can be upgraded to HD using the `-upgradewallet` command line option. This upgrade will result in the all keys in the keypool being marked as used and a new keypool generated. **A new backup must be made when this upgrade is performed.**

 Additionally, `-upgradewallet` can be used to upgraded from a non-split HD chain (all keys generated with `m/0'/0'/i'`) to a split HD chain (receiving keys generated with `'m/0'/0'/i'` and change keys generated with `m'/0'/1'/i'`). When this upgrade occurs, all keys already in the keypool will remain in the keypool to be used until all keys from before the upgrade are exhausted. This is to avoid issues with backups and downgrades when some keys may come from the change key keypool. Users can begin using the new split HD chain keypools by using the `newkeypool` RPC to mark all keys in the keypool as used and begin using a new keypool generated from the split HD chain.

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.17.1 is now available from:
+NYC3 version 0.17.1 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.17.1/>

@@ -50,10 +50,10 @@ processing the entire blockchain.
 Compatibility
 ==============

-Bitcoin Core is extensively tested on multiple operating systems using
+NYC3 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
+NYC3 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
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.0 is now available from:
+NYC3 version 0.9.0 is now available from:

  https://bitcoin.org/bin/0.9.0/

@@ -59,11 +59,11 @@ Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
 the blockchain for missing spent coins, which will take a long time (tens
 of minutes on a typical machine).

-Rebranding to Bitcoin Core
+Rebranding to NYC3
 ---------------------------

 To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we
-have renamed the reference client to Bitcoin Core.
+have renamed the reference client to NYC3.


 OP_RETURN and data in the block chain
@@ -295,7 +295,7 @@ GUI:
 - Add Coin Control Features
 - Improve receive coins workflow: make the 'Receive' tab into a form to request
  payments, and move historical address list functionality to File menu.
- Rebrand to `Bitcoin Core`
+- Rebrand to `NYC3`
 - Move initialization/shutdown to a thread. This prevents "Not responding"
  messages during startup. Also show a window during shutdown.
 - Don't regenerate autostart link on every client startup
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.1 is now available from:
+NYC3 version 0.9.1 is now available from:

  https://bitcoin.org/bin/0.9.1/

@@ -33,7 +33,7 @@ If you are upgrading from version 0.7.2 or earlier, the first time you run
 No code changes were made between 0.9.0 and 0.9.1. Only the dependencies were changed.

 - Upgrade OpenSSL to 1.0.1g. This release fixes the following vulnerabilities which can
-  affect the Bitcoin Core software:
+  affect the NYC3 software:

  - CVE-2014-0160 ("heartbleed")
    A missing bounds check in the handling of the TLS heartbeat extension can
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.2.1 is now available from:
+NYC3 version 0.9.2.1 is now available from:

  https://bitcoin.org/bin/0.9.2.1/

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.2 is now available from:
+NYC3 version 0.9.2 is now available from:

  https://bitcoin.org/bin/0.9.2/

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.3 is now available from:
+NYC3 version 0.9.3 is now available from:

  https://bitcoin.org/bin/0.9.3/

@@ -70,7 +70,7 @@ GUI:
 Miscellaneous:
 - key.cpp: fail with a friendlier message on missing ssl EC support
 - Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core)
+- Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for NYC3)
 - Upgrade miniupnpc to 1.9.20140701
 - Fix boost detection in build system on some platforms

@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.4 is now available from:
+NYC3 version 0.9.4 is now available from:

  https://bitcoin.org/bin/0.9.4/

@@ -25,15 +25,15 @@ various operating system maintainers. Review by Gregory Maxwell determined that
 this update is incompatible with the Bitcoin system and could lead to consensus
 forks.

-Bitcoin Core released binaries from https://bitcoin.org are unaffected,
+NYC3 released binaries from https://bitcoin.org are unaffected,
 as are any built with the gitian deterministic build system.

 However, if you are running either

 - The Ubuntu PPA from https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
- A third-party or self-compiled Bitcoin Core
+- A third-party or self-compiled NYC3

-upgrade to Bitcoin Core 0.9.4, which includes a workaround, **before** updating
+upgrade to NYC3 0.9.4, which includes a workaround, **before** updating
 OpenSSL.

 The incompatibility is due to the OpenSSL update changing the
@@ -1,4 +1,4 @@
-Bitcoin Core version 0.9.5 is now available from:
+NYC3 version 0.9.5 is now available from:

  https://bitcoin.org/bin/0.9.5/

@@ -24,7 +24,7 @@ Notable changes
 Mining and relay policy enhancements
 ------------------------------------

-Bitcoin Core's block templates are now for version 3 blocks only, and any mining
+NYC3's block templates are now for version 3 blocks only, and any mining
 software relying on its `getblocktemplate` must be updated in parallel to use
 libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
 If you are solo mining, this will affect you the moment you upgrade Bitcoin
@@ -114,7 +114,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 macOS:
+### Build and sign NYC3 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
@@ -329,7 +329,7 @@ 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/
+  - NYC3 announcements list https://bitcoincore.org/en/list/announcements/join/

  - Update title of #bitcoin on Freenode IRC

@@ -1,14 +1,14 @@
 # TOR SUPPORT IN BITCOIN

-It is possible to run Bitcoin Core as a Tor hidden service, and connect to such services.
+It is possible to run NYC3 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 NYC3 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 NYC3 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
@@ -37,7 +37,7 @@ In a typical situation, this suffices to run behind a Tor proxy:
 	./bitcoind -proxy=127.0.0.1:9050


-## 2. Run a Bitcoin Core hidden server
+## 2. Run a NYC3 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
@@ -95,13 +95,13 @@ for normal IPv4/IPv6 communication, use:

 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.
+NYC3 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
+NYC3 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 NYC3 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`.
@@ -124,7 +124,7 @@ in the tor configuration file. The hashed password can be obtained with the comm

 ## 4. Privacy recommendations

- Do not add anything but Bitcoin Core ports to the hidden service created in section 2.
+- Do not add anything but NYC3 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
@@ -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 NYC3 software.

 How to translate?
 ------------------
@@ -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.
+NYC3 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:
@@ -5,7 +5,7 @@ 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
+The NYC3 daemon can be configured to act as a trusted "border
 router", implementing the bitcoin wire protocol and relay, making
 consensus decisions, maintaining the local blockchain database,
 broadcasting locally generated transactions into the network, and
@@ -33,7 +33,7 @@ buffering or reassembly.

 ## Prerequisites

-The ZeroMQ feature in Bitcoin Core requires the ZeroMQ API >= 4.0.0
+The ZeroMQ feature in NYC3 requires the ZeroMQ API >= 4.0.0
 [libzmq](https://github.com/zeromq/libzmq/releases).
 For version information, see [dependencies.md](dependencies.md).
 Typically, it is packaged by distributions as something like
@@ -556,14 +556,12 @@ void SetupServerArgs()

 std::string LicenseInfo()
 {
-    const std::string URL_SOURCE_CODE = "<https://github.com/bitcoin/bitcoin>";
-    const std::string URL_WEBSITE = "<https://bitcoincore.org>";
+    const std::string URL_SOURCE_CODE = "<https://github.com/nyc3coin/nyc3>";

    return CopyrightHolders(strprintf(_("Copyright (C) %i-%i"), 2009, COPYRIGHT_YEAR) + " ") + "\n" +
           "\n" +
-           strprintf(_("Please contribute if you find %s useful. "
-                       "Visit %s for further information about the software."),
-               PACKAGE_NAME, URL_WEBSITE) +
+           strprintf(_("Please contribute if you find %s useful. "),
+               PACKAGE_NAME) +
           "\n" +
           strprintf(_("The source code is available from %s."),
               URL_SOURCE_CODE) +
@@ -42,7 +42,7 @@ static bool WalletAppInit(int argc, char* argv[])
    }
    if (argc < 2 || HelpRequested(gArgs)) {
        std::string usage = strprintf("%s bitcoin-wallet version", PACKAGE_NAME) + " " + FormatFullVersion() + "\n\n" +
-                                      "wallet-tool is an offline tool for creating and interacting with Bitcoin Core wallet files.\n" +
+                                      "wallet-tool is an offline tool for creating and interacting with NYC3 wallet files.\n" +
                                      "By default wallet-tool will act on wallets in the default mainnet wallet directory in the datadir.\n" +
                                      "To change the target wallet, use the -datadir, -wallet and -testnet/-regtest arguments.\n\n" +
                                      "Usage:\n" +
@@ -47,74 +47,13 @@ unsigned int Lwma3CalculateNextWorkRequired(const CBlockIndex* pindexLast, const
    return nextTarget.GetCompact();
 }

-unsigned int GetNextWorkBuffer(const CBlockIndex* pindexLast, const CBlockHeader *pblock, const Consensus::Params& params)
-{
-    assert(pindexLast != nullptr);
-    unsigned int nProofOfWorkLimit = UintToArith256(params.powLimit).GetCompact();
-
-    // Only change once per difficulty adjustment interval
-    if ((pindexLast->nHeight+1) % params.DifficultyAdjustmentInterval() != 0)
-    {
-        if (params.fPowAllowMinDifficultyBlocks)
-        {
-            // Special difficulty rule for testnet:
-            // If the new block's timestamp is more than 2* 10 minutes
-            // then allow mining of a min-difficulty block.
-            if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)
-                return nProofOfWorkLimit;
-            else
-            {
-                // Return the last non-special-min-difficulty-rules-block
-                const CBlockIndex* pindex = pindexLast;
-                while (pindex->pprev && pindex->nHeight % params.DifficultyAdjustmentInterval() != 0 && pindex->nBits == nProofOfWorkLimit)
-                    pindex = pindex->pprev;
-                return pindex->nBits;
-            }
-        }
-        return pindexLast->nBits;
-    }
-
-    // Go back by what we want to be 14 days worth of blocks
-    int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);
-    assert(nHeightFirst >= 0);
-    const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);
-    assert(pindexFirst);
-
-    return CalculateNextWorkRequired(pindexLast, pindexFirst->GetBlockTime(), params);
-}
-
 unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock, const Consensus::Params& params)
 {
    if (pindexLast->nHeight+1 <= 150)
-        return GetNextWorkBuffer(pindexLast, pblock, params);
+        return UintToArith256(params.powLimit).GetCompact();
    return Lwma3CalculateNextWorkRequired(pindexLast, params);
 }

-unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
-{
-    if (params.fPowNoRetargeting)
-        return pindexLast->nBits;
-
-    // Limit adjustment step
-    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
-    if (nActualTimespan < params.nPowTargetTimespan/4)
-        nActualTimespan = params.nPowTargetTimespan/4;
-    if (nActualTimespan > params.nPowTargetTimespan*4)
-        nActualTimespan = params.nPowTargetTimespan*4;
-
-    // Retarget
-    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
-    arith_uint256 bnNew;
-    bnNew.SetCompact(pindexLast->nBits);
-    bnNew *= nActualTimespan;
-    bnNew /= params.nPowTargetTimespan;
-
-    if (bnNew > bnPowLimit)
-        bnNew = bnPowLimit;
-
-    return bnNew.GetCompact();
-}
-
 bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params)
 {
    bool fNegative;
@@ -248,14 +248,14 @@ enum ServiceFlags : uint64_t {
    // Nothing
    NODE_NONE = 0,
    // NODE_NETWORK means that the node is capable of serving the complete block chain. It is currently
-    // set by all Bitcoin Core non pruned nodes, and is unset by SPV clients or other light clients.
+    // set by all NYC3 non pruned nodes, and is unset by SPV clients or other light clients.
    NODE_NETWORK = (1 << 0),
    // NODE_GETUTXO means the node is capable of responding to the getutxo protocol request.
-    // Bitcoin Core does not support this but a patch set called Bitcoin XT does.
+    // NYC3 does not support this but a patch set called Bitcoin XT does.
    // See BIP 64 for details on how this is implemented.
    NODE_GETUTXO = (1 << 1),
    // NODE_BLOOM means the node is capable and willing to handle bloom-filtered connections.
-    // Bitcoin Core nodes used to support this by default, without advertising this bit,
+    // NYC3 nodes used to support this by default, without advertising this bit,
    // but no longer do as of protocol version 70011 (= NO_BLOOM_VERSION)
    NODE_BLOOM = (1 << 2),
    // NODE_WITNESS indicates that a node can be asked for blocks and transactions including
@@ -30,7 +30,7 @@ public:

    enum ColumnIndex {
        Label = 0,   /**< User specified label */
-        Address = 1  /**< Bitcoin address */
+        Address = 1  /**< NYC3 address */
    };

    enum RoleIndex {
@@ -108,7 +108,7 @@ void EditAddressDialog::accept()
            break;
        case AddressTableModel::INVALID_ADDRESS:
            QMessageBox::warning(this, windowTitle(),
-                tr("The entered address \"%1\" is not a valid Bitcoin address.").arg(ui->addressEdit->text()),
+                tr("The entered address \"%1\" is not a valid NYC3 address.").arg(ui->addressEdit->text()),
                QMessageBox::Ok, QMessageBox::Ok);
            break;
        case AddressTableModel::DUPLICATE_ADDRESS:
@@ -57,7 +57,7 @@
      <item>
       <widget class="QValidatedLineEdit" name="payTo">
        <property name="toolTip">
-         <string>The Bitcoin address to send the payment to</string>
+         <string>The NYC3 address to send the payment to</string>
        </property>
       </widget>
      </item>
@@ -48,7 +48,7 @@
         <item>
          <widget class="QValidatedLineEdit" name="addressIn_SM">
           <property name="toolTip">
-            <string>The Bitcoin address to sign the message with</string>
+            <string>The NYC3 address to sign the message with</string>
           </property>
          </widget>
         </item>
@@ -152,7 +152,7 @@
         <item>
          <widget class="QPushButton" name="signMessageButton_SM">
           <property name="toolTip">
-            <string>Sign the message to prove you own this Bitcoin address</string>
+            <string>Sign the message to prove you own this NYC3 address</string>
           </property>
           <property name="text">
            <string>Sign &amp;Message</string>
@@ -258,7 +258,7 @@
         <item>
          <widget class="QValidatedLineEdit" name="addressIn_VM">
           <property name="toolTip">
-            <string>The Bitcoin address the message was signed with</string>
+            <string>The NYC3 address the message was signed with</string>
           </property>
          </widget>
         </item>
@@ -295,7 +295,7 @@
         <item>
          <widget class="QPushButton" name="verifyMessageButton_VM">
           <property name="toolTip">
-            <string>Verify the message to ensure it was signed with the specified Bitcoin address</string>
+            <string>Verify the message to ensure it was signed with the specified NYC3 address</string>
           </property>
           <property name="text">
            <string>Verify &amp;Message</string>
@@ -104,7 +104,7 @@ void setupAddressWidget(QValidatedLineEdit *widget, QWidget *parent)
    widget->setFont(fixedPitchFont());
    // We don't want translators to use own addresses in translations
    // and this is the only place, where this address is supplied.
-    widget->setPlaceholderText(QObject::tr("Enter a Bitcoin address (e.g. %1)").arg(
+    widget->setPlaceholderText(QObject::tr("Enter a NYC3 address (e.g. %1)").arg(
        QString::fromStdString(DummyAddress(Params()))));
    widget->setValidator(new BitcoinAddressEntryValidator(parent));
    widget->setCheckValidator(new BitcoinAddressCheckValidator(parent));
@@ -322,7 +322,7 @@
        <translation>Besig met herindeksering van blokke op hardeskyf...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Stuur munte na 'n Bitcoin adres</translation>
    </message>
    <message>
@@ -694,7 +694,7 @@
        <translation>Wysig stuur adres</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>Die ingevoerde adres "%1" is nie 'n geldige Bitcoin adres nie.</translation>
    </message>
    <message>
@@ -1120,7 +1120,7 @@
        <translation>Bedrag</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>Voer in 'n Bitcoin adres (bv. %1)</translation>
    </message>
    <message>
@@ -1697,7 +1697,7 @@ transaksievertragingsrisiko.</translation>
        <translation>Betalings versoek verstryk.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>Waarskuwing: Ongeldige Bitcoinadres</translation>
    </message>
    <message>
@@ -1730,7 +1730,7 @@ Is u seker?</translation>
        <translation>Hierdie is 'n gewone betaling</translation>
    </message>
    <message>
-        <source>The Bitcoin address to send the payment to</source>
+        <source>The NYC3 address to send the payment to</source>
        <translation>Die Bitcoinadres waarheen die betaling gestuur word</translation>
    </message>
    <message>
@@ -2039,7 +2039,7 @@ word die fooi eweredig verdeel.</translation>
 <context>
    <name>bitcoin-core</name>
    <message>
-        <source>Bitcoin Core</source>
+        <source>NYC3</source>
        <translation>Bitcoin Kern</translation>
    </message>
    <message>
@@ -326,7 +326,7 @@
        <translation>Herindekseer blokke op skyf...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Stuur muntstukke na 'n Bitcoin adres</translation>
    </message>
    <message>
@@ -718,7 +718,7 @@
        <translation>Wysig stuurende adres</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>Die ingeskrewe adres "%1" is nie 'n geldige Bitcoin adres nie.</translation>
    </message>
    <message>
@@ -334,7 +334,7 @@
        <translation>إعادة فهرسة الكتل على القرص ...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>ارسل عملات الى عنوان بيتكوين</translation>
    </message>
    <message>
@@ -744,7 +744,7 @@
        <translation>تعديل عنوان الارسال</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>العنوان المدخل "%1" ليس عنوان بيت كوين صحيح.</translation>
    </message>
    <message>
@@ -1248,7 +1248,7 @@
        <translation>عنوان الدفع غير صالح %1</translation>
    </message>
    <message>
-        <source>URI cannot be parsed! This can be caused by an invalid Bitcoin address or malformed URI parameters.</source>
+        <source>URI cannot be parsed! This can be caused by an invalid NYC3 address or malformed URI parameters.</source>
        <translation>لا يمكن تحليل العنوان (URI)! يمكن أن يحدث هذا بسبب عنوان بتكوين غير صالح أو معلمات عنوان (URI) غير صحيحة.</translation>
    </message>
    <message>
@@ -1350,7 +1350,7 @@
        <translation>مبلغ</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>ادخل عنوان محفطة البتكوين (مثال %1)</translation>
    </message>
    <message>
@@ -2127,7 +2127,7 @@
        <translation>انتهاء صلاحية طلب الدفع.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>تحذير: عنوان بتكوين غير صالح</translation>
    </message>
    <message>
@@ -2166,7 +2166,7 @@
        <translation>هذا دفع اعتيادي</translation>
    </message>
    <message>
-        <source>The Bitcoin address to send the payment to</source>
+        <source>The NYC3 address to send the payment to</source>
        <translation>عنوان البت كوين المرسل اليه الدفع</translation>
    </message>
    <message>
@@ -2259,7 +2259,7 @@
        <translation>&amp;توقيع الرسالة</translation>
    </message>
    <message>
-        <source>The Bitcoin address to sign the message with</source>
+        <source>The NYC3 address to sign the message with</source>
        <translation>عنوان البتكوين لتوقيع الرسالة به</translation>
    </message>
    <message>
@@ -2291,7 +2291,7 @@
        <translation>نسخ التوقيع الحالي إلى حافظة النظام</translation>
    </message>
    <message>
-        <source>Sign the message to prove you own this Bitcoin address</source>
+        <source>Sign the message to prove you own this NYC3 address</source>
        <translation>وقع الرسالة لتثبت انك تمتلك عنوان البت كوين هذا</translation>
    </message>
    <message>
@@ -2311,11 +2311,11 @@
        <translation>&amp;تحقق رسالة</translation>
    </message>
    <message>
-        <source>The Bitcoin address the message was signed with</source>
+        <source>The NYC3 address the message was signed with</source>
        <translation>عنوان البتكوين الذي تم توقيع الرسالة به</translation>
    </message>
    <message>
-        <source>Verify the message to ensure it was signed with the specified Bitcoin address</source>
+        <source>Verify the message to ensure it was signed with the specified NYC3 address</source>
        <translation>تحقق من الرسالة للتأكد من توقيعها مع عنوان البتكوين المحدد</translation>
    </message>
    <message>
@@ -2911,7 +2911,7 @@
        <translation>غير قادر على بدء خادم ال HTTP. راجع سجل تصحيح الأخطاء للحصول على التفاصيل.</translation>
    </message>
    <message>
-        <source>Bitcoin Core</source>
+        <source>NYC3</source>
        <translation>جوهر بيتكوين</translation>
    </message>
    <message>
@@ -290,7 +290,7 @@
        <translation>Пераіндэксацыя блокаў на дыску...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Даслаць манеты на Біткойн-адрас</translation>
    </message>
    <message>
@@ -1209,8 +1209,8 @@
 <context>
    <name>bitcoin-core</name>
    <message>
-        <source>Bitcoin Core</source>
-        <translation>Bitcoin Core</translation>
+        <source>NYC3</source>
+        <translation>NYC3</translation>
    </message>
    <message>
        <source>Do you want to rebuild the block database now?</source>
@@ -334,7 +334,7 @@
        <translation>Повторно индексиране на блоковете на диска...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Изпращане към Биткоин адрес</translation>
    </message>
    <message>
@@ -718,7 +718,7 @@
        <translation>Редактиране на адрес за изпращане</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>"%1" не е валиден Биткоин адрес.</translation>
    </message>
    <message>
@@ -1160,7 +1160,7 @@
        <translation>Сума</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>Въведете Биткойн адрес (например: %1)</translation>
    </message>
    <message>
@@ -1701,7 +1701,7 @@
        <translation>Заявката за плащане е изтекла.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>Внимание: Невалиден Биткойн адрес</translation>
    </message>
    <message>
@@ -1821,7 +1821,7 @@
        <translation>Копиране на текущия подпис</translation>
    </message>
    <message>
-        <source>Sign the message to prove you own this Bitcoin address</source>
+        <source>Sign the message to prove you own this NYC3 address</source>
        <translation>Подпишете съобщение като доказателство, че притежавате определен адрес</translation>
    </message>
    <message>
@@ -1837,7 +1837,7 @@
        <translation>&amp;Провери</translation>
    </message>
    <message>
-        <source>Verify the message to ensure it was signed with the specified Bitcoin address</source>
+        <source>Verify the message to ensure it was signed with the specified NYC3 address</source>
        <translation>Проверете съобщение, за да сте сигурни че е подписано с определен Биткоин адрес</translation>
    </message>
    <message>
@@ -2329,7 +2329,7 @@
 <context>
    <name>bitcoin-core</name>
    <message>
-        <source>Bitcoin Core</source>
+        <source>NYC3</source>
        <translation>Биткойн ядро</translation>
    </message>
    <message>
@@ -881,7 +881,7 @@
 <context>
    <name>bitcoin-core</name>
    <message>
-        <source>Bitcoin Core</source>
+        <source>NYC3</source>
        <translation>Биткойн ядро</translation>
    </message>
    <message>
@@ -338,7 +338,7 @@
        <translation>El servidor proxy està &lt;b&gt;activat&lt;/b&gt;: %1</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Envia monedes a una adreça Bitcoin</translation>
    </message>
    <message>
@@ -744,7 +744,7 @@
        <translation>Edita l'adreça d'enviament</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>L'adreça introduïda «%1» no és una adreça de Bitcoin vàlida.</translation>
    </message>
    <message>
@@ -1308,7 +1308,7 @@
        <translation>Adreça de pagament no vàlida %1</translation>
    </message>
    <message>
-        <source>URI cannot be parsed! This can be caused by an invalid Bitcoin address or malformed URI parameters.</source>
+        <source>URI cannot be parsed! This can be caused by an invalid NYC3 address or malformed URI parameters.</source>
        <translation>L'URI no pot ser analitzat! Això pot ser a causa d'una adreça de Bitcoin no vàlida o per paràmetres URI amb mal format.</translation>
    </message>
    <message>
@@ -1410,7 +1410,7 @@
        <translation>Import</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>Introduïu una adreça de Bitcoin (p. ex. %1)</translation>
    </message>
    <message>
@@ -2231,7 +2231,7 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>La sol·licitud de pagament ha vençut.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>Avís: adreça Bitcoin no vàlida</translation>
    </message>
    <message>
@@ -2274,7 +2274,7 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>Això és un pagament normal.</translation>
    </message>
    <message>
-        <source>The Bitcoin address to send the payment to</source>
+        <source>The NYC3 address to send the payment to</source>
        <translation>L'adreça Bitcoin on enviar el pagament</translation>
    </message>
    <message>
@@ -2367,7 +2367,7 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>Podeu signar missatges/acords amb les vostres adreces per provar que rebeu les bitcoins que s'hi envien. Aneu amb compte no signar res que sigui vague o aleatori, perquè en alguns atacs de suplantació es pot provar que hi signeu la vostra identitat. Només signeu aquelles declaracions completament detallades en què hi esteu d'acord. </translation>
    </message>
    <message>
-        <source>The Bitcoin address to sign the message with</source>
+        <source>The NYC3 address to sign the message with</source>
        <translation>L'adreça Bitcoin amb què signar el missatge</translation>
    </message>
    <message>
@@ -2399,7 +2399,7 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>Copia la signatura actual al porta-retalls del sistema</translation>
    </message>
    <message>
-        <source>Sign the message to prove you own this Bitcoin address</source>
+        <source>Sign the message to prove you own this NYC3 address</source>
        <translation>Signa el missatge per provar que ets propietari d'aquesta adreça Bitcoin</translation>
    </message>
    <message>
@@ -2423,11 +2423,11 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>Introduïu l'adreça del receptor, el missatge (assegureu-vos de copiar els salts de línia, espais, tabuladors, etc. exactament) i signatura de sota per verificar el missatge. Tingueu cura de no llegir més en la signatura del que està al missatge signat, per evitar ser enganyat per un atac d'home-en-el-mig. Tingueu en compte que això només demostra que la part que signa rep amb l'adreça, i no es pot provar l'enviament de qualsevol transacció!</translation>
    </message>
    <message>
-        <source>The Bitcoin address the message was signed with</source>
+        <source>The NYC3 address the message was signed with</source>
        <translation>L'adreça Bitcoin amb què va ser signat el missatge</translation>
    </message>
    <message>
-        <source>Verify the message to ensure it was signed with the specified Bitcoin address</source>
+        <source>Verify the message to ensure it was signed with the specified NYC3 address</source>
        <translation>Verificar el missatge per assegurar-se que ha estat signat amb una adreça Bitcoin específica</translation>
    </message>
    <message>
@@ -3059,8 +3059,8 @@ Nota: Com que la comissió es calcula en funció dels bytes, una comissió de "1
        <translation>No s'ha pogut iniciar el servidor HTTP. Vegeu debug.log per a més detalls.</translation>
    </message>
    <message>
-        <source>Bitcoin Core</source>
-        <translation>Bitcoin Core</translation>
+        <source>NYC3</source>
+        <translation>NYC3</translation>
    </message>
    <message>
        <source>The %s developers</source>
@@ -290,7 +290,7 @@
        <translation>S'estan reindexant els blocs al disc...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Envia monedes a una adreça Bitcoin</translation>
    </message>
    <message>
@@ -650,7 +650,7 @@
        <translation>Edita les adreces d'enviament</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>L'adreça introduïda «%1» no és una adreça de Bitcoin vàlida.</translation>
    </message>
    <message>
@@ -1034,7 +1034,7 @@
        <translation>Adreça de pagament no vàlida %1</translation>
    </message>
    <message>
-        <source>URI cannot be parsed! This can be caused by an invalid Bitcoin address or malformed URI parameters.</source>
+        <source>URI cannot be parsed! This can be caused by an invalid NYC3 address or malformed URI parameters.</source>
        <translation>L'URI no pot ser analitzat! Això pot ser a causa d'una adreça de Bitcoin no vàlida o per paràmetres URI amb mal format.</translation>
    </message>
    <message>
@@ -1128,7 +1128,7 @@
        <translation>Import</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>Introduïu una adreça de Bitcoin (p. ex. %1)</translation>
    </message>
    <message>
@@ -1737,7 +1737,7 @@
        <translation>La sol·licitud de pagament ha vençut.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>Avís: adreça Bitcoin no vàlida</translation>
    </message>
    <message>
@@ -1772,7 +1772,7 @@
        <translation>Això és un pagament normal.</translation>
    </message>
    <message>
-        <source>The Bitcoin address to send the payment to</source>
+        <source>The NYC3 address to send the payment to</source>
        <translation>L'adreça Bitcoin on enviar el pagament</translation>
    </message>
    <message>
@@ -1861,7 +1861,7 @@
        <translation>Podeu signar missatges/acords amb les vostres adreces per provar que rebeu les bitcoins que s'hi envien. Aneu amb compte no signar res que siga vague o aleatori, perquè en alguns atacs de suplantació es pot provar que hi signeu la vostra identitat. Només signeu aquelles declaracions completament detallades en què hi esteu d'acord. </translation>
    </message>
    <message>
-        <source>The Bitcoin address to sign the message with</source>
+        <source>The NYC3 address to sign the message with</source>
        <translation>L'adreça Bitcoin amb què signar el missatge</translation>
    </message>
    <message>
@@ -1893,7 +1893,7 @@
        <translation>Copia la signatura actual al porta-retalls del sistema</translation>
    </message>
    <message>
-        <source>Sign the message to prove you own this Bitcoin address</source>
+        <source>Sign the message to prove you own this NYC3 address</source>
        <translation>Signa el missatge per provar que ets propietari d'esta adreça Bitcoin</translation>
    </message>
    <message>
@@ -1917,11 +1917,11 @@
        <translation>Introduïu l'adreça del receptor, el missatge (assegureu-vos de copiar els salts de línia, espais, tabuladors, etc. exactament) i signatura de sota per verificar el missatge. Tingueu cura de no llegir més en la signatura del que està al missatge signat, per evitar ser enganyat per un atac d'home-en-el-mig. Tingueu en compte que això només demostra que la part que signa rep amb l'adreça, i no es pot provar l'enviament de qualsevol transacció!</translation>
    </message>
    <message>
-        <source>The Bitcoin address the message was signed with</source>
+        <source>The NYC3 address the message was signed with</source>
        <translation>L'adreça Bitcoin amb què va ser signat el missatge</translation>
    </message>
    <message>
-        <source>Verify the message to ensure it was signed with the specified Bitcoin address</source>
+        <source>Verify the message to ensure it was signed with the specified NYC3 address</source>
        <translation>Verificar el missatge per assegurar-se que ha estat signat amb una adreça Bitcoin específica</translation>
    </message>
    <message>
@@ -2441,8 +2441,8 @@
        <translation>S'està podant l'emmagatzemament de blocs...</translation>
    </message>
    <message>
-        <source>Bitcoin Core</source>
-        <translation>Bitcoin Core</translation>
+        <source>NYC3</source>
+        <translation>NYC3</translation>
    </message>
    <message>
        <source>This is a pre-release test build - use at your own risk - do not use for mining or merchant applications</source>
@@ -326,7 +326,7 @@
        <translation>S'estan reindexant els blocs al disc...</translation>
    </message>
    <message>
-        <source>Send coins to a Bitcoin address</source>
+        <source>Send coins to a NYC3 address</source>
        <translation>Envia monedes a una adreça Bitcoin</translation>
    </message>
    <message>
@@ -722,7 +722,7 @@
        <translation>Edita l'adreça d'enviament</translation>
    </message>
    <message>
-        <source>The entered address "%1" is not a valid Bitcoin address.</source>
+        <source>The entered address "%1" is not a valid NYC3 address.</source>
        <translation>L'adreça introduïda «%1» no és una adreça de Bitcoin vàlida.</translation>
    </message>
    <message>
@@ -1186,7 +1186,7 @@
        <translation>Adreça de pagament no vàlida %1</translation>
    </message>
    <message>
-        <source>URI cannot be parsed! This can be caused by an invalid Bitcoin address or malformed URI parameters.</source>
+        <source>URI cannot be parsed! This can be caused by an invalid NYC3 address or malformed URI parameters.</source>
        <translation>L'URI no pot ser analitzat! Això pot ser a causa d'una adreça de Bitcoin no vàlida o per paràmetres URI amb mal format.</translation>
    </message>
    <message>
@@ -1280,7 +1280,7 @@
        <translation>Import</translation>
    </message>
    <message>
-        <source>Enter a Bitcoin address (e.g. %1)</source>
+        <source>Enter a NYC3 address (e.g. %1)</source>
        <translation>Introduïu una adreça de Bitcoin (p. ex. %1)</translation>
    </message>
    <message>
@@ -1969,7 +1969,7 @@
        <translation>La sol·licitud de pagament ha vençut.</translation>
    </message>
    <message>
-        <source>Warning: Invalid Bitcoin address</source>
+        <source>Warning: Invalid NYC3 address</source>
        <translation>Avís: adreça Bitcoin no vàlida</translation>
    </message>
    <message>
@@ -2004,7 +2004,7 @@
        <translation>Això és un pagament normal.</translation>
    </message>
    <message>
-        <source>The Bitcoin address to send the payment to</source>
+        <source>The NYC3 address to send the payment to</source>
        <translation>L'adreça Bitcoin on enviar el pagament</translation>
    </message>
    <message>
@@ -2093,7 +2093,7 @@
        <translation>Podeu signar missatges/acords amb les vostres adreces per provar que rebeu les bitcoins que s'hi envien. Aneu amb compte no signar res que sigui vague o aleatori, perquè en alguns atacs de suplantació es pot provar que hi signeu la vostra identitat. Només signeu aquelles declaracions completament detallades en què hi esteu d'acord. </translation>
    </message>
    <message>
-        <source>The Bitcoin address to sign the message with</source>
+        <source>The NYC3 address to sign the message with</source>
        <translation>L'adreça Bitcoin amb què signar el missatge</translation>
    </message>
    <message>
@@ -2125,7 +2125,7 @@
        <translation>Copia la signatura actual al porta-retalls del sistema</translation>
    </message>
    <message>
-        <source>Sign the message to prove you own this Bitcoin address</source>
+        <source>Sign the message to prove you own this NYC3 address</source>
        <translation>Signa el missatge per provar que ets propietari d'aquesta adreça Bitcoin</translation>
    </message>
    <message>
@@ -2149,11 +2149,11 @@
        <translation>Introduïu l'adreça del receptor, el missatge (assegureu-vos de copiar els salts de línia, espais, tabuladors, etc. exactament) i signatura de sota per verificar el missatge. Tingueu cura de no llegir més en la signatura del que està al missatge signat, per evitar ser enganyat per un atac d'home-en-el-mig. Tingueu en compte que això només demostra que la part que signa rep amb l'adreça, i no es pot provar l'enviament de qualsevol transacció!</translation>
    </message>
    <message>
-        <source>The Bitcoin address the message was signed with</source>
+        <source>The NYC3 address the message was signed with</source>
        <translation>L'adreça Bitcoin amb què va ser signat el missatge</translation>
    </message>
    <message>
-        <source>Verify the message to ensure it was signed with the specified Bitcoin address</source>
+        <source>Verify the message to ensure it was signed with the specified NYC3 address</source>
        <translation>Verificar el missatge per assegurar-se que ha estat signat amb una adreça Bitcoin específica</translation>
    </message>
    <message>
@@ -2709,8 +2709,8 @@
        <translation>No s'ha pogut iniciar el servidor HTTP. Vegeu debug.log per a més detalls.</translation>
    </message>
    <message>
-        <source>Bitcoin Core</source>
-        <translation>Bitcoin Core</translation>
+        <source>NYC3</source>
+        <translation>NYC3</translation>
    </message>
    <message>
        <source>This is a pre-release test build - use at your own risk - do not use for mining or merchant applications</source>
--- a/Show More
+++ b/Show More