Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-21 📝 Original message:I guess then the best way ...
📅 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
>
📝 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
>