📅 Original date posted:2019-10-21
📝 Original message:I guess then the best way to discover nodes that have reject messages
enabled is connecting/disconnecting to random nodes and send them
invalid transactions and keep the ones which reply with a reject message.
On 18/10/2019 22.53, John Newbery via bitcoin-dev wrote:
>> Is there a NODE_* bit we can use to pick peers that support this
> (useful!) feature?
>
> No. BIP 61 has no mechanism for advertising that a node will send REJECT
> messages.
>
> On Wed, Oct 16, 2019 at 12:43 PM John Newbery <john at johnnewbery.com
> <mailto:john at johnnewbery.com>> wrote:
>
> 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
> <mailto: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
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 18:21:14
in reply to nevent1q…034y
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 18:21:14Event JSON
{
"id": "f05931f33a99f029bb90a67b03d410b9811175e52ac28bf523d8b21ce66d8c7a",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686162074,
"kind": 1,
"tags": [
[
"e",
"fc240d6737eec3e3732c71a02d6bd551346f2bcb2e039d48bf20d899e18045d3",
"",
"root"
],
[
"e",
"0e6302f6e3c0bd0c8c0bf4e8f02f34e4d943f6bcdc181e71607bd7882df495ab",
"",
"reply"
],
[
"p",
"e84603bfdc0aa9bb7113bfc659e152b00066c5c41e171e49f615e0de4fb2f00f"
]
],
"content": "📅 Original date posted:2019-10-21\n📝 Original message:I guess then the best way to discover nodes that have reject messages\nenabled is connecting/disconnecting to random nodes and send them\ninvalid transactions and keep the ones which reply with a reject message.\n\n\nOn 18/10/2019 22.53, John Newbery via bitcoin-dev wrote:\n\u003e\u003e Is there a NODE_* bit we can use to pick peers that support this\n\u003e (useful!) feature?\n\u003e \n\u003e No. BIP 61 has no mechanism for advertising that a node will send REJECT\n\u003e messages.\n\u003e \n\u003e On Wed, Oct 16, 2019 at 12:43 PM John Newbery \u003cjohn at johnnewbery.com\n\u003e \u003cmailto:john at johnnewbery.com\u003e\u003e wrote:\n\u003e \n\u003e Following discussion on this mailing list, support for BIP 61 REJECT\n\u003e messages was not removed from Bitcoin Core in V0.19. The behaviour\n\u003e in that upcoming release is that REJECT messages are disabled by\n\u003e default and can be enabled using the `-enablebip61` command line option.\n\u003e \n\u003e Support for REJECT messages will be removed entirely in Bitcoin Core\n\u003e V0.20, expected for release in mid 2020. The PR to remove support\n\u003e was merged into Bitcoin Core's master branch this week.\n\u003e \n\u003e Adoption of new Bitcoin Core versions across reachable nodes\n\u003e generally takes several months.\n\u003e https://bitnodes.earn.com/dashboard/?days=365 shows that although\n\u003e v0.18 was released in May 2019, there are still several hundred\n\u003e reachable nodes on V0.17, V0.16, V0.15 and earlier software.\n\u003e Software that currently use REJECT messages from public nodes for\n\u003e troubleshooting issues therefore have plenty of time to transition\n\u003e to one of the methods listed by Marco in the email above.\n\u003e \n\u003e John\n\u003e \n\u003e On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Bitcoin Core may send \"reject\" messages as response to \"tx\",\n\u003e \"block\" or\n\u003e \"version\" messages from a network peer when the message could\n\u003e not be accepted.\n\u003e \n\u003e This feature is toggled by the `-enablebip61` command line\n\u003e option and has been\n\u003e disabled by default since Bitcoin Core version 0.18.0 (not yet\n\u003e released as of\n\u003e time of writing). Nodes on the network can not generally be\n\u003e trusted to send\n\u003e valid (\"reject\") messages, so this should only ever be used when\n\u003e connected to a\n\u003e trusted node. At this time, I am not aware of any software that\n\u003e requires this\n\u003e feature, and I would like to remove if from Bitcoin Core to make\n\u003e the codebase\n\u003e slimmer, easier to understand and maintain. Let us know if your\n\u003e application\n\u003e relies on this feature and you can not use any of the\n\u003e recommended alternatives:\n\u003e \n\u003e * Testing or debugging of implementations of the Bitcoin P2P\n\u003e network protocol\n\u003e should be done by inspecting the log messages that are\n\u003e produced by a 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\n\u003e blocks with\n\u003e potentially invalid POW\n\u003e \n\u003e * Testing the validity of a transaction can be achieved by\n\u003e specific RPCs:\n\u003e - `sendrawtransaction`\n\u003e - `testmempoolaccept`\n\u003e \n\u003e * Wallets should not use the absence of \"reject\" messages to\n\u003e indicate a\n\u003e transaction has propagated the network, nor should wallets use\n\u003e \"reject\"\n\u003e messages to set transaction fees. Wallets should rather use\n\u003e fee estimation\n\u003e to determine transaction fees and set replace-by-fee if\n\u003e desired. Thus, they\n\u003e could wait until the transaction has confirmed (taking into\n\u003e account the fee\n\u003e target they set (compare the RPC `estimatesmartfee`)) or\n\u003e listen for the\n\u003e transaction announcement by other network peers to check for\n\u003e propagation.\n\u003e \n\u003e I propose to remove \"reject\" messages from Bitcoin Core 0.19.0\n\u003e unless 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 \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \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",
"sig": "6908f435183794fd00f7668689c2b0a8013c0a38b1d71f7334e4b3df8543aa94504b9b219861646870632632590235f0dd165a0a911a0d4eb3132cddd8603688"
}