📅 Original date posted:2019-10-16
📝 Original message:Following discussion on this mailing list, support for BIP 61 REJECT
messages was not removed from Bitcoin Core in V0.19. The behaviour in that
upcoming release is that REJECT messages are disabled by default and can be
enabled using the `-enablebip61` command line option.
Support for REJECT messages will be removed entirely in Bitcoin Core V0.20,
expected for release in mid 2020. The PR to remove support was merged into
Bitcoin Core's master branch this week.
Adoption of new Bitcoin Core versions across reachable nodes generally
takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows
that although v0.18 was released in May 2019, there are still several
hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.
Software that currently use REJECT messages from public nodes for
troubleshooting issues therefore have plenty of time to transition to one
of the methods listed by Marco in the email above.
John
On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191016/4664e5b3/attachment.html>;
John Newbery [ARCHIVE] /
npub1ap…608ff
2023-06-07 18:21:13
in reply to nevent1q…a9d3
Author Public Key
npub1aprq807up25mkugnhlr9nc2jkqqxd3wyrct3uj0kzhsdunaj7q8s7608ffPublished at
2023-06-07 18:21:13Event JSON
{
"id": "cf75aa082fa63b541f2cd02f52ef96e0cce30e6d73ee5c409ebc07134a01292d",
"pubkey": "e84603bfdc0aa9bb7113bfc659e152b00066c5c41e171e49f615e0de4fb2f00f",
"created_at": 1686162073,
"kind": 1,
"tags": [
[
"e",
"fc240d6737eec3e3732c71a02d6bd551346f2bcb2e039d48bf20d899e18045d3",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2019-10-16\n📝 Original message:Following discussion on this mailing list, support for BIP 61 REJECT\nmessages was not removed from Bitcoin Core in V0.19. The behaviour in that\nupcoming release is that REJECT messages are disabled by default and can be\nenabled using the `-enablebip61` command line option.\n\nSupport for REJECT messages will be removed entirely in Bitcoin Core V0.20,\nexpected for release in mid 2020. The PR to remove support was merged into\nBitcoin Core's master branch this week.\n\nAdoption of new Bitcoin Core versions across reachable nodes generally\ntakes several months. https://bitnodes.earn.com/dashboard/?days=365 shows\nthat although v0.18 was released in May 2019, there are still several\nhundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.\nSoftware that currently use REJECT messages from public nodes for\ntroubleshooting issues therefore have plenty of time to transition to one\nof the methods listed by Marco in the email above.\n\nJohn\n\nOn Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Bitcoin Core may send \"reject\" messages as response to \"tx\", \"block\" or\n\u003e \"version\" messages from a network peer when the message could not be\n\u003e accepted.\n\u003e\n\u003e This feature is toggled by the `-enablebip61` command line option and has\n\u003e been\n\u003e disabled by default since Bitcoin Core version 0.18.0 (not yet released as\n\u003e of\n\u003e time of writing). Nodes on the network can not generally be trusted to send\n\u003e valid (\"reject\") messages, so this should only ever be used when connected\n\u003e to a\n\u003e trusted node. At this time, I am not aware of any software that requires\n\u003e this\n\u003e feature, and I would like to remove if from Bitcoin Core to make the\n\u003e codebase\n\u003e slimmer, easier to understand and maintain. Let us know if your application\n\u003e relies on this feature and you can not use any of the recommended\n\u003e alternatives:\n\u003e\n\u003e * Testing or debugging of implementations of the Bitcoin P2P network\n\u003e protocol\n\u003e should be done by inspecting the log messages that are produced by a\n\u003e recent\n\u003e version of Bitcoin Core. Bitcoin Core logs debug messages\n\u003e (`-debug=\u003ccategory\u003e`) to a stream (`-printtoconsole`) or to a file\n\u003e (`-debuglogfile=\u003cdebug.log\u003e`).\n\u003e\n\u003e * Testing the validity of a block can be achieved by specific RPCs:\n\u003e - `submitblock`\n\u003e - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with\n\u003e potentially invalid POW\n\u003e\n\u003e * Testing the validity of a transaction can be achieved by specific RPCs:\n\u003e - `sendrawtransaction`\n\u003e - `testmempoolaccept`\n\u003e\n\u003e * Wallets should not use the absence of \"reject\" messages to indicate a\n\u003e transaction has propagated the network, nor should wallets use \"reject\"\n\u003e messages to set transaction fees. Wallets should rather use fee\n\u003e estimation\n\u003e to determine transaction fees and set replace-by-fee if desired. Thus,\n\u003e they\n\u003e could wait until the transaction has confirmed (taking into account the\n\u003e fee\n\u003e target they set (compare the RPC `estimatesmartfee`)) or listen for the\n\u003e transaction announcement by other network peers to check for propagation.\n\u003e\n\u003e I propose to remove \"reject\" messages from Bitcoin Core 0.19.0 unless\n\u003e there are\n\u003e valid concerns about its removal.\n\u003e\n\u003e Marco\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191016/4664e5b3/attachment.html\u003e",
"sig": "c2ca3dc4a982dca46ea1fed37ed70be9047d0e5325510b0293fe15eff46e6b7184d679b847f1f9885e7914b1585bb78b833073fde27c3f618e3e0eb823f9edab"
}