Published on: 2015-07-10T02:00:45+00:00
In a message sent on July 9, 2015 at 6:57 pm, Tom Harding discussed the issue of replacing transactions and how conflicts should be relayed in order for the replace-by-anything feature to work. He suggests that acting against the peer is not the solution. In response, Alex Morcos suggested tracking recently-rejected transaction IDs and not getting data from them, which Harding agreed was a good idea. However, he also noted that this approach may not necessarily reduce the load, as there are not many repeated transaction hashes among rejected replacement messages in his log.Matt Whitlock, a Bitcoin developer, reported on the bitcoin-dev mailing list that he was seeing a lot of messages in his log about replacement transactions being rejected due to their paying less in fees than the transactions they would replace. He suggested that each replacement rejection ought to penalize the peer who relayed the offending transaction and if the penalty builds up enough, then the peer could be temporarily banned. However, Alex Morcos offered a suggestion on IRC -- track recently-rejected txid's and don't getdata them. This solution is not to act against the peer.Matt Whitlock is presently running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, he is seeing a steady stream of these rejection messages, dozens per second at times. The link for the patch set is provided in the email. The idea proposed by Alex Morcos on IRC is to track recently-rejected txid's and don't getdata them. This can only work if conflicts are relayed, so the solution is not to act against the peer.Matt Whitlock is running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, Matt is seeing a steady stream of replacement transaction rejection messages which could happen legitimately from time to time. However, due to the flood of spam transactions being mostly invalid under RBF rules, he wants to cut off the flood coming into his node by temp-banning the peers who are relaying such invalid replacement transactions. By doing so, the CPU load due to Bitcoind could be reduced as presently there are periods of time in which Bitcoind is pegging a CPU core.Moreover, if enough other nodes also implement this banning rule, then we could potentially cut off the flood of spam right at the source. This would force the spammer to build and publish non-conflicting transactions to continue the attack which could eventually have their fees collected by miners, not just some non-conflicting subset of the spam. Patrick Strateman questioned the practicality of banning peers doing this but Matt did not respond to that. The link to Peter Todd's full replace-by-fee patch set has been provided in the context.
Updated on: 2023-08-01T14:15:33.442392+00:00