Commit e7f0b7bf authored by freetrader's avatar freetrader
Browse files

Merge branch 'master' into 'master'

Various Markdown fixes for proper display on docs.bitcoincashnode.org

See merge request !688
parents 9e52e168 9070d42f
Pipeline #170611848 passed with stages
in 52 minutes and 55 seconds
......@@ -15,7 +15,7 @@ of resources.
Our main development repository is currently located at
https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node
[https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node](https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node)
This features the project code, an issue tracker and facilities to see
project progress and activities, even in detailed form such as individual
......@@ -34,7 +34,7 @@ our main development and interactive support for users of our node.
Other social media resources such as our Telegram and Twitter are linked
from the project website at
https://bitcoincashnode.org
[https://bitcoincashnode.org](https://bitcoincashnode.org)
On all our channels, we seek to facilitate development of Bitcoin Cash Node,
and to welcome and support people who wish to participate.
......@@ -103,11 +103,11 @@ Here are some handy links for development practices aligned with Bitcoin Cash No
Getting set up with the Bitcoin Cash Node Repository
----------------------------------------------
1. Create an account at https://gitlab.com/ if you don't have one yet
1. Create an account at [https://gitlab.com](https://gitlab.com) if you don't have one yet
2. Install Git on your machine
Git documentation can be found at: https://git-scm.com/
Git documentation can be found at: [https://git-scm.com](https://git-scm.com)
To install these packages on Debian or Ubuntu, type: `sudo apt-get install git`
......@@ -121,7 +121,7 @@ Enter a file in which to save the key (/home/*username*/.ssh/id_rsa): [Press ent
4. Upload your SSH public key to GitLab
- Go to: `https://gitlab.com, log in
- Go to: [https://gitlab.com](https://gitlab.com), log in
- Under "User Settings", "SSH Keys", add your public key
......@@ -129,7 +129,7 @@ Paste contents from: `$HOME/.ssh/id_rsa.pub`
5. Create a personal fork of the Bitcoin Cash Node repository for your work
- Sign into GitLab under your account, then visit the project at https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node
- Sign into GitLab under your account, then visit the project at [https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node](https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node)
- Click the 'Fork' button on the top right, and choose to fork the project to your personal GitLab space.
......@@ -182,7 +182,7 @@ sudo apt-get install clang-format-8 clang-tidy-8 clang-tools-8
If not available in the distribution, `clang-format-8` and `clang-tidy` can be
installed from https://releases.llvm.org/download.html or https://apt.llvm.org.
installed from [https://releases.llvm.org/download.html](https://releases.llvm.org/download.html) or [https://apt.llvm.org](https://apt.llvm.org).
For example, for macOS:
```
......@@ -246,7 +246,7 @@ What to work on
---------------
If you are looking for a useful task to contribute to the project, a good place
to start is the list of issues at https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/issues
to start is the list of issues at [https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/issues](https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/issues)
Look for issues marked with a label 'good-first-issue'.
......
......@@ -81,23 +81,23 @@ contact at imaginary dot username dot btc at gmail dot com
Neighboring projects that may be affected by bugs, potential exploits, or other security vulnerabilities that are disclosed to Bitcoin Cash Node will be passed along information regarding disclosures that we believe could impact them. As per the standard referenced above, we are disclosing these relationships here:
* [Bitcoin Unlimited](https://www.bitcoinunlimited.info)
* Security Contacts: security at bitcoinunlimited dot info
* Disclosure Policy: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/SECURITY.md
* Security Contacts: security at bitcoinunlimited dot info
* Disclosure Policy: [https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/SECURITY.md](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/SECURITY.md)
* [BCHD](https://bchd.cash)
* Security Contacts: Chris Pacia (ctpacia at gmail dot com) and Josh Ellithorpe (quest at mac dot com)
* Disclosure Policy: see README information at https://github.com/gcash/bchd/
* Security Contacts: Chris Pacia (ctpacia at gmail dot com) and Josh Ellithorpe (quest at mac dot com)
* Disclosure Policy: see README information at [https://github.com/gcash/bchd/](https://github.com/gcash/bchd/)
* [Flowee](https://flowee.org)
* Security Contact: tomz at freedommail dot ch
* Disclosure Policy: see https://gitlab.com/FloweeTheHub/thehub
* Security Contact: tomz at freedommail dot ch
* Disclosure Policy: see [https://gitlab.com/FloweeTheHub/thehub](https://gitlab.com/FloweeTheHub/thehub)
* [Knuth](https://github.com/k-nuth/kth/)
* Security Contact: fpelliccioni at gmail dot com
* Disclosure Policy: see https://github.com/k-nuth/kth/blob/master/README.md#security-disclosures
* Security Contact: fpelliccioni at gmail dot com
* Disclosure Policy: see [https://github.com/k-nuth/kth/blob/master/README.md#security-disclosures](https://github.com/k-nuth/kth/blob/master/README.md#security-disclosures)
* [Bitcoin Verde](https://github.com/SoftwareVerde/bitcoin-verde/)
* Security Contact: josh at softwareverde dot com
* Security Contact: josh at softwareverde dot com
We have approached several other projects and are waiting for responses from them.
......
......@@ -2,7 +2,7 @@
This document describes the working rules, workflow, terminology and guidelines that developers and testers should be familiar with while working on the Bitcoin Cash Node repository and issue tracker at
https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/
[https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/](https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/)
## BCHN GitLab workflow
......@@ -102,7 +102,6 @@ Committers can add prefix tags to their commit messages and MR titles to provide
These tags have no special meaning to GitLab (at least not yet) and are simply for human consumption at this stage.They are not well standardized, but below you will find a section documenting some better known commit tags.
**WIP**
When a merge requested is prefixed by "WIP:", GitLab blocks merging of the MR.
......
......@@ -3,7 +3,7 @@
(updated for Fedora 31)
# Preparation
## Preparation
Minimal build requirements:
......
This diff is collapsed.
......@@ -11,7 +11,7 @@ to connect to BCH compatible peers.
General expectations for DNS Seed operators
===========================================
-------------------------------------------
Bitcoin attempts to minimize the level of trust in DNS seeds,
but DNS seeds still pose a small amount of risk for the network.
......
......@@ -16,7 +16,7 @@ The util tests are run as part of `make check` target. The functional
tests are run by the Teamcity continuous build process whenever a diff is
created or updated on Phabricator. Both sets of tests can also be run locally.
# Running functional tests locally
## Running functional tests locally
Build for your system first. Be sure to enable wallet, utils and daemon when
you configure. Tests will not run otherwise.
......@@ -195,7 +195,7 @@ The warning message will now be printed to the `sys.stderr` output.
Util tests can be run locally by running `test/util/bitcoin-util-test.py`.
Use the `-v` option for verbose output.
# Writing functional tests
## Writing functional tests
#### Example test
......
......@@ -13,6 +13,8 @@ Comments-URI: https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_req
Comments-Summary: BCHN internal review comments.
```
# getblocktemplatelight
## Abstract
......@@ -309,17 +311,17 @@ merkle_root = hashes[0]
## References
- [1] BIP 22: getblocktemplate - Fundamentals
- [2] BIP 23: getblocktemplate - Pooled Mining
- [3] https://github.com/btccom/bitcoin-abc-1/commit/e87774c8ee724a0e9ecbc289236920ea1aa04a83
- [4] src/rpc/mining.cpp, see `MakeMerkleBranch` function
- [5] https://reference.cash/protocol/blockchain/block/block-header
- [6] https://reference.cash/protocol/p2p/compact__int/
- [7] https://reference.cash/protocol/blockchain/block/#coinbase-transaction
- [8] https://reference.cash/protocol/blockchain/transaction/
- [9] https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/doc/miner.md#getminingcandidate-and-submitminingsolution
- [1] [BIP22: getblocktemplate - Fundamentals](https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki/)
- [2] [BIP23: getblocktemplate - Pooled Mining](https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki/)
- [3] [https://github.com/btccom/bitcoin-abc-1/commit/e87774c8ee724a0e9ecbc289236920ea1aa04a83](https://github.com/btccom/bitcoin-abc-1/commit/e87774c8ee724a0e9ecbc289236920ea1aa04a83)
- [4] [src/rpc/mining.cpp](../src/rpc/mining.cpp), see `MakeMerkleBranch` function
- [5] [https://reference.cash/protocol/blockchain/block/block-header](https://reference.cash/protocol/blockchain/block/block-header)
- [6] [https://reference.cash/protocol/p2p/compact__int/](https://reference.cash/protocol/p2p/compact__int/)
- [7] [https://reference.cash/protocol/blockchain/block/#coinbase-transaction](https://reference.cash/protocol/blockchain/block/#coinbase-transaction)
- [8] [https://reference.cash/protocol/blockchain/transaction/](https://reference.cash/protocol/blockchain/transaction/)
- [9] [https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/doc/miner.md#getminingcandidate-and-submitminingsolution](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/doc/miner.md#getminingcandidate-and-submitminingsolution)
# Copyright
## Copyright
This document is licensed under the Creative Commons CC0 1.0 Universal license.
......@@ -18,15 +18,6 @@ VM image to avoid 'contaminating' the build.
The instructions below use the automated script [gitian-build.py](https://github.com/bitcoin-cash-node/bitcoin-cash-node/blob/master/contrib/gitian-build.py) which only works in Debian/Ubuntu. For manual steps and instructions for fully offline signing, see [this guide](./gitian-building/gitian-building-manual.md).
## Table of Contents
* [Gitian building](gitian-building.md#gitian-building)
* [Table of Contents](gitian-building.md#table-of-contents)
* [Preparing the Gitian builder host](gitian-building.md#preparing-the-gitian-builder-host)
* [MacOS code signing](gitian-building.md#macos-code-signing)
* [Initial Gitian Setup](gitian-building.md#initial-gitian-setup)
* [Build binaries](gitian-building.md#build-binaries)
## Preparing the Gitian builder host
The first step is to prepare the host environment that will be used to perform the Gitian builds.
......
# Setup Debian virtual machine on VirtualBox
Table of Contents
-----------------
- [Create a new VirtualBox VM](#create-a-new-virtualbox-vm)
- [Connecting to the VM](#connecting-to-the-vm)
Create a new VirtualBox VM
--------------------------
In the VirtualBox GUI click "New" and choose the following parameters in the wizard:
......
Getting and building the inputs
-------------------------------
At this point you have two options, you can either use the automated script (found in [https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/contrib/gitian-build.py](https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/contrib/gitian-build.py), only works in Debian/Ubuntu) or you could manually do everything by following this guide.
At this point you have two options, you can either use the automated script (found in [contrib/gitian-build.py](../../contrib/gitian-build.py), only works in Debian/Ubuntu) or you could manually do everything by following this guide.
If you are using the automated script, then run it with the `--setup` command. Afterwards, run it with the `--build` command (example: `contrib/gitian-build.py -b signer 0.15.0`). Otherwise ignore this.
Follow the instructions in [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change)
......@@ -10,10 +10,10 @@ manual intervention. Also optionally follow the next step: 'Seed the Gitian sour
and offline git repositories' which will fetch the remaining files required for building
offline.
Building Bitcoin ABC
--------------------
Building Bitcoin Cash Node
--------------------------
To build Bitcoin ABC (for Linux, OS X and Windows) just follow the steps under 'perform
To build Bitcoin Cash Node (for Linux, OS X and Windows) just follow the steps under 'perform
Gitian builds' in [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#setup-and-perform-gitian-builds) in the bitcoin repository.
This may take some time as it will build all the dependencies needed for each descriptor.
......@@ -33,7 +33,7 @@ Output from `gbuild` will look something like
remote: Total 57959 (delta 0), reused 0 (delta 0), pack-reused 57958
Receiving objects: 100% (57959/57959), 53.76 MiB | 484.00 KiB/s, done.
Resolving deltas: 100% (41590/41590), done.
From https://github.com/Bitcoin-ABC/bitcoin-abc.git
From https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node.git
... (new tags, new branch etc)
--- Building for trusty amd64 ---
Stopping target if it is up
......@@ -59,11 +59,11 @@ and inputs.
For example:
```bash
URL=https://github.com/Bitcoin-ABC/bitcoin-abc.git
URL=https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node.git
COMMIT=v0.18.5
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-abc/contrib/gitian-descriptors/gitian-linux.yml
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-abc/contrib/gitian-descriptors/gitian-win.yml
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-abc/contrib/gitian-descriptors/gitian-osx.yml
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-cash-node/contrib/gitian-descriptors/gitian-linux.yml
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-cash-node/contrib/gitian-descriptors/gitian-win.yml
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin-cash-node/contrib/gitian-descriptors/gitian-osx.yml
```
Building fully offline
......@@ -90,7 +90,7 @@ LXC_ARCH=amd64 LXC_SUITE=buster on-target -u root dpkg --add-architecture i386
LXC_ARCH=amd64 LXC_SUITE=buster on-target -u root apt-get update
LXC_ARCH=amd64 LXC_SUITE=buster on-target -u root \
-e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install \
$( sed -ne '/^packages:/,/^[^-]/ {/^- .*/{s/"//g;s/- //;p}}' ../bitcoin-abc/contrib/gitian-descriptors/*|sort|uniq )
$( sed -ne '/^packages:/,/^[^-]/ {/^- .*/{s/"//g;s/- //;p}}' ../bitcoin-cash-node/contrib/gitian-descriptors/*|sort|uniq )
LXC_ARCH=amd64 LXC_SUITE=buster on-target -u root apt-get -q -y purge grub
LXC_ARCH=amd64 LXC_SUITE=buster on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade
```
......@@ -109,7 +109,7 @@ sudo service apt-cacher-ng restart
Then when building, override the remote URLs that gbuild would otherwise pull from the Gitian descriptors::
```bash
cd ~
export URL=${HOME}/bitcoin-abc
export URL=${HOME}/bitcoin-cash-node
export COMMIT=<commmit hash or tag>
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ${URL}/contrib/gitian-descriptors/gitian-win.yml
......
# Setting up Debian for Gitian building
** Table of Contents **
* [Setting up Debian for Gitian building](gitian-building-setup-gitian-debian.md#setting-up-debian-for-gitian-building)
* [Installing Gitian](gitian-building-setup-gitian-debian.md#installing-gitian)
* [Setting up the Gitian image](gitian-building-setup-gitian-debian.md#setting-up-the-gitian-image)
* [Downloading dependencies](gitian-building-setup-gitian-debian.md#downloading-dependencies)
In this section we will be setting up the Debian installation for Gitian building.
We assume that a user `gitianuser` with sudo privileges was previously added.
......
......@@ -119,6 +119,9 @@ to 0.21.2.
Known Issues
------------
...
Configuration
------------
......@@ -160,98 +163,98 @@ all of them on our GitLab repository.
Changes since Bitcoin Cash Node 0.21.2
--------------------------------------
**New documents:**
### New documents
...
**Removed documents:**
### Removed documents
...
**Notable commits grouped by functionality:**
### Notable commits grouped by functionality
Security or consensus relevant fixes
#### Security or consensus relevant fixes
...
Interfaces / RPC
#### Interfaces / RPC
...
Peformance optimizations
#### Peformance optimizations
...
GUI
#### GUI
...
Code quality
#### Code quality
...
Documentation updates
#### Documentation updates
...
Build / general
#### Build / general
...
Build / Linux
#### Build / Linux
...
Build / MacOSX
#### Build / MacOSX
...
Tests / test framework
#### Tests / test framework
...
Benchmarks
#### Benchmarks
...
Seeds / seeder software
#### Seeds / seeder software
...
Maintainer tools
#### Maintainer tools
...
Infrastructure
#### Infrastructure
...
Cleanup
#### Cleanup
...
Continuous Integration (GitLab CI)
#### Continuous Integration (GitLab CI)
...
Backports
#### Backports
...
Bitcoin Core 0.10.0
===================
Bitcoin Core version 0.10.0 is now available from:
https://bitcoin.org/bin/0.10.0/
<https://bitcoin.org/bin/0.10.0/>
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
<https://github.com/bitcoin/bitcoin/issues>
Upgrading and downgrading
=========================
-------------------------
How to Upgrade
--------------
### How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
---------------------
### 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
......@@ -45,10 +46,9 @@ This does not affect wallet forward or backward compatibility.
Notable changes
===============
---------------
Faster synchronization
----------------------
### Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
......@@ -63,6 +63,7 @@ very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
- `getblockchaininfo` now returns the number of validated headers in addition to
the number of validated blocks.
- `getpeerinfo` lists both the number of blocks and headers we know we have in
......@@ -72,8 +73,7 @@ have requested from peers (but haven't received yet) are also listed as
- A new RPC `getchaintips` lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
-----------------------
### Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
......@@ -90,6 +90,7 @@ data directory in the `fee_estimates.dat` file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
- `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
......@@ -97,6 +98,7 @@ is over-ridden by the -paytxfee option.
(default: 0)
New RPC commands for fee estimation:
- `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
......@@ -105,8 +107,7 @@ a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.
RPC access control changes
--------------------------
### RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
......@@ -133,8 +134,7 @@ Using wildcards will result in the rule being rejected with the following error
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
REST interface
--------------
### REST interface
A new HTTP API is exposed when running with the `-rest` flag, which allows
unauthenticated access to public node data.
......@@ -143,6 +143,7 @@ It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
- Blocks: http://localhost:8332/rest/block/*HASH*.*EXT*
- Blocks without transactions: http://localhost:8332/rest/block/notxdetails/*HASH*.*EXT*
- Transactions (requires `-txindex`): http://localhost:8332/rest/tx/*HASH*.*EXT*
......@@ -152,8 +153,7 @@ binary) or `json`.
For more details, see the `doc/REST-interface.md` document in the repository.
RPC Server "Warm-Up" Mode
-------------------------
### RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
......@@ -164,8 +164,7 @@ This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
-------------------------
### Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
......@@ -191,10 +190,9 @@ the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
[1] <https://eprint.iacr.org/2014/161.pdf>
Watch-only wallet support
-------------------------
### Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
......@@ -219,8 +217,7 @@ Compared to using `getrawtransaction`, this mechanism does not require
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
-----------------
### Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
......@@ -241,8 +238,7 @@ correctly spends the passed scriptPubKey under additional constraints indicated
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
------------------------------------------------
### Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
......@@ -252,8 +248,7 @@ actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
bitcoin-tx
----------
### bitcoin-tx
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
......@@ -276,8 +271,7 @@ server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
------------------------------------
### Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its `getblocktemplate` must be updated in parallel to use
......@@ -301,6 +295,7 @@ their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
- `-datacarrier=0/1` : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
- `-datacarriersize=n` : Maximum size, in bytes, we consider acceptable for
......@@ -310,8 +305,7 @@ The relay policy has changed to more properly implement the desired behavior of
relaying free (or very low fee) transactions unless they have a priority above the