Proposal: disconnect clients sending unrequested txs. #4338

I am not sure if this is the correct place for new proposals, so I apologize in advance if this is the wrong place.

<a href="https://github.com/conformal/btcd">btcd</a> currently disconnects peers that sending unrequested txs:

<pre> 18:36:03 2014-06-13 [INF] BMGR: New valid peer 173.228.29.187:58881 (inbound) (/BitCoinJ:0.10.3/) 18:36:04 2014-06-13 [WRN] BMGR: Got unrequested transaction ae238ff036467cf3f6fd83bb4987e287109e2423b702da319146cd8e4bf2eae8 from 173.228.29.187:58881 -- disconnecting </pre>

I believe bitcoinj does this to avoid a roundtrip.

However, I see a few issues with accepting unrequested txs. A peer can easily cause bitcoind to waste time processing TXs, fill and max out the orphan tx database dropping random txs from the orphan tx database, wasting bandwidth, etc. A potential DoS target.

There is no requirement that a client must send an inv, wait for a getdata, than send a tx. Currently, bitcoind will accept unrequested txs.

I am proposing bitcoind not accepted unrequested txs, forcing peers to send an inv first and respond to getdata requests.

I'd like to hear thoughts from others.

So, in some cases it makes sense from an efficiency point of view to broadcast transactions (or blocks!) directly without advertising them first, if you know the peer does not have them yet. If you just created the transaction yourself or mined the block yourself, this is an obvious truth.

So, alternative proposal: trigger DoS scoring when receiving an unadvertized tx/block that you do already have.

Pros:

• Optimizes propagation latency slightly.
• Is conpatible with all existing behavior in clients afaik.

Cons:

• More complex network rule.
• Assumes that every peer (or at least every NODE_NETWORK peer) will be interested in the actual tx/block (which is currently likely the case, but we don't know the future variety of network nodes).

If we accept your premise that there are DoS attacks here... ... then I don't see how forcing attackers to jump through one extra hoop (send an 'inv' first) fixes them.

Attackers will just send 'inv' messages first.

Gavin: the idea is not to just require them to just send an inv first. The idea is to only allow an incoming tx message when it was getdata'd before. If an attack sends an inv for something we already have, we never getdata.

There are several cases where the receiver of an inv message might not actual want the data. Here are two cases:

• The data has already been requested from another peer and it's currently in-flight. There is no need to process the same data again, so it's possible to ignore the inv message, or add it to a list of peers known to have the data so it can be requested from them should the in-flight request fail.
• The data is already available in a local cache or in the local db.

By giving nodes the chance to choose whether or not to send a getdata through first sending it an inv, the decision is left up to the receiver whether or not it needs the data.

My point is that this will not fix any of the DoS attacks that hypothesized, because attackers will never send something you already have.

If the DoS attack is incoming bandwidth: attacker can just send an endless stream of orphan-and-will-never-have-inputs-satisfied transactions.

If the DoS attack is disk or memory thrashing looking up transaction previous inputs: same.

If the proposal really isn't about DoS attacks but is about optimizing the networking p2p protocol, then okey dokey; I'll let networking protocol experts argue over what the Most Optimal Behavior is.

On a somewhat related note, I'm seeing many peers sending many block invs (not just the latest block) without any getblocks having been sent first. This was contributing to the very high orphan block count that some people were seeing. My pull request #4431 makes it so that blocks aren't requested from any node other than the syncnode (which is also changed after every 500 blocks, or sooner).

To me it seems to late to change this, too much software relies on this.

But if you still think this is worth the trouble, the place for protocol-level change proposals such as this would be a BIP, which can be proposed and discussed on the -dev mailing list (see https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki ).