📅 Original date posted:2015-07-09
📝 Original message:My reasons for wanting this are two-fold:
1.) To reduce the CPU load due to Bitcoind. Presently I am seeing periods of time in which Bitcoind is pegging a CPU core. Given that the flood of spam transactions appears mostly to be invalid under RBF rules, I would like to cut off the flood coming into my node by temp-banning the peers who are relaying invalid replacement transactions.
2.) If enough other nodes also implement this banning rule, then we could potentially cut off the flood of spam right at the source. Then the spammer would be forced to build and publish *non-conflicting* transactions to continue the attack, and this would be much costlier to maintain, as then *all* of the spam transactions could eventually have their fees collected by miners, not just some non-conflicting subset of the spam.
On Thursday, 9 July 2015, at 6:27 pm, Patrick Strateman wrote:
> What do you gain by banning peers doing this?
>
> I'm thinking practically nothing.
>
> On Jul 9, 2015 4:55 PM, "Matt Whitlock" <bip at mattwhitlock.name> wrote:
>
> > I'm presently running my full node with Peter Todd's full replace-by-fee
> > patch set [1]. I am seeing a LOT of messages in the log about replacement
> > transactions being rejected due to their paying less in fees than the
> > transactions they would replace. I understand that this could happen
> > legitimately from time to time, due to my node's receiving a replacing
> > transaction prior to receiving the replaced transaction; however, due to
> > the ongoing spam attack, I am seeing a steady stream of these rejection
> > messages, dozens per second at times. I am wondering if 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, similar to how other "misbehaving" peers are treated.
> >
> > [1] https://github.com/petertodd/bitcoin/commits/replace-by-fee-v0.10.2
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:41:50
in reply to nevent1q…x3fs
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:41:50Event JSON
{
"id": "81a86b2d638e15ac7d740ceedc5aa2f5a2ddf47bf00bec34837c83532e35daf6",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686152510,
"kind": 1,
"tags": [
[
"e",
"b3856dc84fad9e3da113cb809110ffcebdf01e349fe2ffc93e81d06232da1b52",
"",
"root"
],
[
"e",
"f1f5f9c3d6861ef8e7ffffe7a607502ab6c99a49f2b682f4181879fca1f22e6f",
"",
"reply"
],
[
"p",
"fbac73d2413d23d5b6e60bc431152069981e56a94cd5d626c9e88b6c0a18cbd5"
]
],
"content": "📅 Original date posted:2015-07-09\n📝 Original message:My reasons for wanting this are two-fold:\n\n1.) To reduce the CPU load due to Bitcoind. Presently I am seeing periods of time in which Bitcoind is pegging a CPU core. Given that the flood of spam transactions appears mostly to be invalid under RBF rules, I would like to cut off the flood coming into my node by temp-banning the peers who are relaying invalid replacement transactions.\n\n2.) If enough other nodes also implement this banning rule, then we could potentially cut off the flood of spam right at the source. Then the spammer would be forced to build and publish *non-conflicting* transactions to continue the attack, and this would be much costlier to maintain, as then *all* of the spam transactions could eventually have their fees collected by miners, not just some non-conflicting subset of the spam.\n\n\nOn Thursday, 9 July 2015, at 6:27 pm, Patrick Strateman wrote:\n\u003e What do you gain by banning peers doing this?\n\u003e \n\u003e I'm thinking practically nothing.\n\u003e \n\u003e On Jul 9, 2015 4:55 PM, \"Matt Whitlock\" \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e \n\u003e \u003e I'm presently running my full node with Peter Todd's full replace-by-fee\n\u003e \u003e patch set [1]. I am seeing a LOT of messages in the log about replacement\n\u003e \u003e transactions being rejected due to their paying less in fees than the\n\u003e \u003e transactions they would replace. I understand that this could happen\n\u003e \u003e legitimately from time to time, due to my node's receiving a replacing\n\u003e \u003e transaction prior to receiving the replaced transaction; however, due to\n\u003e \u003e the ongoing spam attack, I am seeing a steady stream of these rejection\n\u003e \u003e messages, dozens per second at times. I am wondering if each replacement\n\u003e \u003e rejection ought to penalize the peer who relayed the offending transaction,\n\u003e \u003e and if the penalty builds up enough, then the peer could be temporarily\n\u003e \u003e banned, similar to how other \"misbehaving\" peers are treated.\n\u003e \u003e\n\u003e \u003e [1] https://github.com/petertodd/bitcoin/commits/replace-by-fee-v0.10.2",
"sig": "8e62474d2eee9f34e346002a8f9bdd8f89f24bea98e1d73f7fb83b49f091343e2ae17df31d045046267e0ffc0ff564e35245ee5ff994d8e6cf0d88eda1c4f889"
}