Merge bitcoin#13134: net: Add option -enablebip61 to configure sending of BIP61 notifications#3414
Conversation
9b01e14 to
6745df4
Compare
UdjinM6
left a comment
There was a problem hiding this comment.
See inline comments + should apply the same logic to NetMsgType::REJECT messages in governance.cpp and privatesend-client/server.cpp
src/net_processing.h
Outdated
There was a problem hiding this comment.
General comment regarding future BIP61-related backports. IIRC, Bitcoin eventually sets this to false and then entirely removes BIP61 support. The removal of BIP61 from Bitcoin Core was extremely controversial from the standpoint of mobile wallets.
Not sure what our plan is for when we get to that point, but wanted to bring it up so we do not blindly follow Bitcoin. I imagine @HashEngineering and @QuantumExplorer will want to provide input on that.
There was a problem hiding this comment.
Correct, I've seen this, but these backports at this point are needed for resolving conflicts. Also, I do think their reasoning for removing it made senes
There was a problem hiding this comment.
Yeah I strongly encourage the continued use of BIP61, the reasoning to remove it was too weak in Bitcoin.
|
Needs rebase |
a46483e to
9d4423b
Compare
|
rebased on develop |
…ing of BIP61 notifications 87fe292 doc: Mention disabling BIP61 in bips.md (Wladimir J. van der Laan) fe16dd8 net: Add option `-enablebip61` to configure sending of BIP61 notifications (Wladimir J. van der Laan) Pull request description: This commit adds a boolean option `-peersendreject`, defaulting to `1`, that can be used to disable the sending of [BIP61](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki) `reject` messages. This functionality has been requested for various reasons: - security (DoS): reject messages can reveal internal state that can be used to target certain resources such as the mempool more easily. - bandwidth: a typical node sends lots of reject messages; this counts against upstream bandwidth. Also the reject messages tend to be larger than the message that was rejected. On the other hand, reject messages can be useful while developing client software (I found them indispensable while creating bitcoin-submittx), as well as for our own test cases, so whatever the default becomes on the long run, IMO the functionality should be retained as option. But that's a discussion for later, for now it's simply a node operator decision. Also adds a RPC test that checks the functionality. Tree-SHA512: 9488cc53e13cd8e5c6f8eb472a44309572673405c1d1438c3488f627fae622c95e2198bde5ed7d29e56b948e2918bf1920239e9f865889f4c37c097c37a4d7a9
Signed-off-by: Pasta <pasta@dashboost.org>
Signed-off-by: Pasta <pasta@dashboost.org>
Signed-off-by: Pasta <pasta@dashboost.org>
Signed-off-by: Pasta <pasta@dashboost.org>
9d4423b to
eb76a92
Compare
|
rebased again to (hopefully) resolve tests |
eb76a92 to
7ab99df
Compare
7ab99df to
3c491ab
Compare
…ding of BIP61 notifications (dashpay#3414) * Merge bitcoin#13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications 87fe292 doc: Mention disabling BIP61 in bips.md (Wladimir J. van der Laan) fe16dd8 net: Add option `-enablebip61` to configure sending of BIP61 notifications (Wladimir J. van der Laan) Pull request description: This commit adds a boolean option `-peersendreject`, defaulting to `1`, that can be used to disable the sending of [BIP61](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki) `reject` messages. This functionality has been requested for various reasons: - security (DoS): reject messages can reveal internal state that can be used to target certain resources such as the mempool more easily. - bandwidth: a typical node sends lots of reject messages; this counts against upstream bandwidth. Also the reject messages tend to be larger than the message that was rejected. On the other hand, reject messages can be useful while developing client software (I found them indispensable while creating bitcoin-submittx), as well as for our own test cases, so whatever the default becomes on the long run, IMO the functionality should be retained as option. But that's a discussion for later, for now it's simply a node operator decision. Also adds a RPC test that checks the functionality. Tree-SHA512: 9488cc53e13cd8e5c6f8eb472a44309572673405c1d1438c3488f627fae622c95e2198bde5ed7d29e56b948e2918bf1920239e9f865889f4c37c097c37a4d7a9 * 0.17 -> 0.16 Signed-off-by: Pasta <pasta@dashboost.org> * tx1 -> base_ tx fixing 13134 Signed-off-by: Pasta <pasta@dashboost.org> * move added bip61 message checking up Signed-off-by: Pasta <pasta@dashboost.org> * Dash specific code, only send reject messages if bip61 is enabled Signed-off-by: Pasta <pasta@dashboost.org> * Fix invalidtxrequest.py Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com> Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Tests currently fail. I did my best to fix them, this is a dependency for further p2p refactoring and changes I have done.