š
Original date posted:2019-03-05
š Original message:Bitcoin Core may send "reject" messages as response to "tx", "block" or
"version" messages from a network peer when the message could not be accepted.
This feature is toggled by the `-enablebip61` command line option and has been
disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
time of writing). 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. At this time, I am not aware of any software that requires this
feature, and I would like to remove if from Bitcoin Core to make the codebase
slimmer, easier to understand and maintain. Let us know if your application
relies on this feature and you can not use any of the recommended alternatives:
* 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.
I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
valid concerns about its removal.
Marco
Marco Falke [ARCHIVE] /
npub1qsā¦9jjz5
2023-06-07 18:16:34
in reply to nevent1qā¦d9e6
Author Public Key
npub1qspcss06rhl7lwrhzrnv5k7w7er32htkgds2d50802eguajx4p5sp9jjz5Published at
2023-06-07 18:16:34Event JSON
{
"id": "9e7d5b971c93a5f11c9f7ccdcc71a6054811f82b9bbc3c746ce148f1b25c96fa",
"pubkey": "04038841fa1dffefb87710e6ca5bcef647155d764360a6d1e77ab28e7646a869",
"created_at": 1686161794,
"kind": 1,
"tags": [
[
"e",
"d23d84909ded4e86934b4199a32650fb490f51617593613544f6edda083d91e3",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2019-03-05\nš Original message:Bitcoin Core may send \"reject\" messages as response to \"tx\", \"block\" or\n\"version\" messages from a network peer when the message could not be accepted.\n\nThis feature is toggled by the `-enablebip61` command line option and has been\ndisabled by default since Bitcoin Core version 0.18.0 (not yet released as of\ntime of writing). Nodes on the network can not generally be trusted to send\nvalid (\"reject\") messages, so this should only ever be used when connected to a\ntrusted node. At this time, I am not aware of any software that requires this\nfeature, and I would like to remove if from Bitcoin Core to make the codebase\nslimmer, easier to understand and maintain. Let us know if your application\nrelies on this feature and you can not use any of the recommended alternatives:\n\n* Testing or debugging of implementations of the Bitcoin P2P network protocol\n should be done by inspecting the log messages that are produced by a recent\n version of Bitcoin Core. Bitcoin Core logs debug messages\n (`-debug=\u003ccategory\u003e`) to a stream (`-printtoconsole`) or to a file\n (`-debuglogfile=\u003cdebug.log\u003e`).\n\n* Testing the validity of a block can be achieved by specific RPCs:\n - `submitblock`\n - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with\n potentially invalid POW\n\n* Testing the validity of a transaction can be achieved by specific RPCs:\n - `sendrawtransaction`\n - `testmempoolaccept`\n\n* Wallets should not use the absence of \"reject\" messages to indicate a\n transaction has propagated the network, nor should wallets use \"reject\"\n messages to set transaction fees. Wallets should rather use fee estimation\n to determine transaction fees and set replace-by-fee if desired. Thus, they\n could wait until the transaction has confirmed (taking into account the fee\n target they set (compare the RPC `estimatesmartfee`)) or listen for the\n transaction announcement by other network peers to check for propagation.\n\nI propose to remove \"reject\" messages from Bitcoin Core 0.19.0 unless there are\nvalid concerns about its removal.\n\nMarco",
"sig": "b52c1ebe7754ca316c2a31e1a0d3edb5a93760ba98b1b284686f0009618018f617631bf398981e6c6baebb85688ff546687f7d88835b5776ebd264c1adfb0bd9"
}