* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
@ 2015-07-10 1:18 Raystonn
0 siblings, 0 replies; 7+ messages in thread
From: Raystonn @ 2015-07-10 1:18 UTC (permalink / raw)
To: Matt Whitlock; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/html, Size: 2491 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
@ 2015-07-10 0:42 Raystonn
2015-07-10 1:12 ` Matt Whitlock
0 siblings, 1 reply; 7+ messages in thread
From: Raystonn @ 2015-07-10 0:42 UTC (permalink / raw)
To: Matt Whitlock; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/html, Size: 1787 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
2015-07-10 0:42 Raystonn
@ 2015-07-10 1:12 ` Matt Whitlock
0 siblings, 0 replies; 7+ messages in thread
From: Matt Whitlock @ 2015-07-10 1:12 UTC (permalink / raw)
To: Raystonn; +Cc: bitcoin-dev
Um, it's called "replace-by-fee" for a reason. The transaction [set] paying the highest fee [rate] is always the one that will be accepted. You can't use the order in which transactions were received to determine which one is the "replacing" transaction and which is/are the "replaced" transaction(s) because order is not defined for transactions in the mempool. (Ordering transactions is precisely why we must have a block chain.)
On Thursday, 9 July 2015, at 5:42 pm, Raystonn wrote:
> It is a mistake for RBF to assume a transaction with lower fee is invalid. If I paid a higher fee to get a one hour confirmation in the current congestion, I might want to drop back to a lower fee if I see the spam stop.
>
> On 9 Jul 2015 4:55 pm, Matt Whitlock <bip@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
@ 2015-07-09 23:55 Matt Whitlock
[not found] ` <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
2015-07-10 1:57 ` Tom Harding
0 siblings, 2 replies; 7+ messages in thread
From: Matt Whitlock @ 2015-07-09 23:55 UTC (permalink / raw)
To: Peter Todd, bitcoin-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>]
* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
[not found] ` <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
@ 2015-07-10 1:36 ` Matt Whitlock
0 siblings, 0 replies; 7+ messages in thread
From: Matt Whitlock @ 2015-07-10 1:36 UTC (permalink / raw)
To: Patrick Strateman; +Cc: bitcoin-dev
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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
2015-07-09 23:55 Matt Whitlock
[not found] ` <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
@ 2015-07-10 1:57 ` Tom Harding
2015-07-10 2:00 ` Matt Whitlock
1 sibling, 1 reply; 7+ messages in thread
From: Tom Harding @ 2015-07-10 1:57 UTC (permalink / raw)
To: bitcoin-dev
Replace-by-anything can only work if conflicts are relayed, so the
solution is not to act against the peer.
Alex Morcos offered a suggestion on IRC -- track recently-rejected
txid's and don't getdata them. The idea sounds good to me.
On 7/9/2015 4:55 PM, Matt Whitlock 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Can we penalize peers who relay rejected replacement txs?
2015-07-10 1:57 ` Tom Harding
@ 2015-07-10 2:00 ` Matt Whitlock
0 siblings, 0 replies; 7+ messages in thread
From: Matt Whitlock @ 2015-07-10 2:00 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
On Thursday, 9 July 2015, at 6:57 pm, Tom Harding wrote:
> Replace-by-anything can only work if conflicts are relayed, so the
> solution is not to act against the peer.
>
> Alex Morcos offered a suggestion on IRC -- track recently-rejected
> txid's and don't getdata them. The idea sounds good to me.
While that's probably a good idea, it wouldn't do much to reduce the load. I am not seeing many repeated transaction hashes among the "rejected replacement" messages in my log.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-07-10 2:08 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-10 1:18 [bitcoin-dev] Can we penalize peers who relay rejected replacement txs? Raystonn
-- strict thread matches above, loose matches on Subject: below --
2015-07-10 0:42 Raystonn
2015-07-10 1:12 ` Matt Whitlock
2015-07-09 23:55 Matt Whitlock
[not found] ` <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
2015-07-10 1:36 ` Matt Whitlock
2015-07-10 1:57 ` Tom Harding
2015-07-10 2:00 ` Matt Whitlock
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox