diff options
author | MarcoFalke <falke.marco@gmail.com> | 2018-09-10 13:59:20 -0400 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2019-10-02 10:39:14 -0400 |
commit | fa25f43ac5692082dba3f90456c501eb08f1b75c (patch) | |
tree | dfd75d76811bfa032b7d511eb96ebbf99124bf5b /doc/release-notes-15437.md | |
parent | ddc4e3c2d6857336a38cee49c47bce3ca49ab224 (diff) | |
download | bitcoin-fa25f43ac5692082dba3f90456c501eb08f1b75c.tar.xz |
p2p: Remove BIP61 reject messages
Diffstat (limited to 'doc/release-notes-15437.md')
-rw-r--r-- | doc/release-notes-15437.md | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/release-notes-15437.md b/doc/release-notes-15437.md new file mode 100644 index 0000000000..031e90ccd2 --- /dev/null +++ b/doc/release-notes-15437.md @@ -0,0 +1,34 @@ +P2P and network changes +----------------------- + +#### Removal of reject network messages from Bitcoin Core (BIP61) + +The command line option to enable BIP61 (`-enablebip61`) has been removed. + +This feature has been disabled by default since Bitcoin Core version 0.18.0. +Nodes on the network can not generally be trusted to send valid ("reject") +messages, so this should only ever be used when connected to a trusted node. +Please use the recommended alternatives if you rely on this deprecated feature: + +* Testing or debugging of implementations of the Bitcoin P2P network protocol + should be done by inspecting the log messages that are produced by a recent + version of Bitcoin Core. Bitcoin Core logs debug messages + (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file + (`-debuglogfile=<debug.log>`). + +* Testing the validity of a block can be achieved by specific RPCs: + - `submitblock` + - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with + potentially invalid POW + +* Testing the validity of a transaction can be achieved by specific RPCs: + - `sendrawtransaction` + - `testmempoolaccept` + +* Wallets should not use the absence of "reject" messages to indicate a + transaction has propagated the network, nor should wallets use "reject" + messages to set transaction fees. Wallets should rather use fee estimation + to determine transaction fees and set replace-by-fee if desired. Thus, they + could wait until the transaction has confirmed (taking into account the fee + target they set (compare the RPC `estimatesmartfee`)) or listen for the + transaction announcement by other network peers to check for propagation. |