Bitcoin Forum

I've seen some reasons here and there but looking for full arguments against this BIP.

Discussion about this can be found in the PR: https://github.com/bitcoin/bitcoin/pull/15437 and on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016701.html

The primary reasons are that reject messages are used for debugging purposes but the p2p network shouldn't be used to debug software and that reject messages are not necessarily reliable so they don't do anything useful except for debugging, which, as mentioned previously, shouldn't happen via p2p.

Thanks for the links.

Shouldn't the protocol version be bumped also since there is no code to handle reject messages anymore? It is still the same 70015 as before:
https://github.com/bitcoin/bitcoin/blob/b1b173994406158e5faa3c83b113da9d971ac104/src/version.h#L12

Practically, it doesn't need to be. Maybe for documentation clarity, but that's already pretty unclear. As a practical matter, usually removing a message does not require peers to alter their behavior.

If a message type is removed, then nodes that have upgraded will not send out those messages. Unless that message is a response to another one or is a fixed part of the handshake (i.e. version), the peer will not care if it doesn't receive that message anymore. Reject messages were not a requirement and other nodes do not expect to receive reject messages. Then, for forwards compatibility, existing nodes do not disconnect, ban, or otherwise take action (except logging) when an unknown message is received. So if a peer sends a reject message to a node that has removed it. it will do nothing with that message and just log that it received it.

Thus nothing in the protocol breaks by removing the reject message so the version doesn't need to be bumped.

Reject messages were never a 'stable interface' and couldn't really be-- the issue is that which reason for rejecting you provide depends critically on the exact construction of the software.  So random, seemingly unrelated changes could stir them around.


Say, for example that you send a transaction that was already confirmed a few blocks ago.   Is that a inputs-already-spent rejection, or is that an inputs-don't-exist rejection?   The former is only even possible to return if you have a pretty expensive index of every confirmed transaction-- something that isn't required for consensus operation but which Bitcoin originally had.

Essentially rejections make for a bad interface because they inherently expose otherwise irrelevant internals.  They also result in privacy leaks, dos attacks, etc...  and searching showed zero (I believe absolutely zero, but it might have been just nearly zero) usage outside of test harnesses / debugging output.

The protocol didn't need to be bumped because there never was any guarantee that reject messages would be generated, and unknown messages are just ignored in the protocol. I'm pretty sure the protocol version wasn't bumped for their introduction either-- at least a bump is not mentioned in the BIP.


Good protocol design:

1. Be strict in what you accept. Otherwise it becomes impossible to change anything without accidentally breaking compatibility with broken inputs.
2. Liberal in the kinds of things you send, within the strict allowance of the spec so that all corner cases get tested.
3. Silence is golden. Information you don't send usually can't cause interop problems or compromise the user's privacy.

:)