1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
Return-Path: <bip@mattwhitlock.name>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E89FCBD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 01:36:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from resqmta-ch2-12v.sys.comcast.net
(resqmta-ch2-12v.sys.comcast.net [69.252.207.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 866A61A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 01:36:40 +0000 (UTC)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106])
by resqmta-ch2-12v.sys.comcast.net with comcast
id qRcL1q0062JGN3p01Rcf2a; Fri, 10 Jul 2015 01:36:39 +0000
Received: from crushinator.localnet
([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0])
by resomta-ch2-10v.sys.comcast.net with comcast
id qRce1q00P4eLRLv01Rcf9J; Fri, 10 Jul 2015 01:36:39 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Patrick Strateman <patrick.strateman@gmail.com>
Date: Thu, 09 Jul 2015 21:36:38 -0400
Message-ID: <3260721.l4JVm1ozWG@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.10; x86_64; ; )
In-Reply-To: <CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
References: <1828256.77UID9hUjK@crushinator>
<CADPq5bkyhdGocJncJfG5xkes6Qx-oHyeAsw0CUugqdqJZeubSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20140121; t=1436492199;
bh=XQXNZ7SHFe+cXC2hyK/vwgpXX/vKz2JoDA0fl7mPNms=;
h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version:
Content-Type;
b=s74h3Y9mSUk9rKc7fIiHg6hYE1QyStGJV0LeKwsdSZrRtZygQKFk8XscF8JH/jIMn
Zre7keiHVoHcrgyS9KEF6Cx+9yeaZy0nzl0IJhseGRk0npwfS3Niq2XDbCVefYHkew
UWxaVUbuKBh4u93FKSaUoHSACHoo5xMnlfEalxnDoRFEC2b8f18jRJarBlbWODW6NK
hpr47gp53BSXQPGKxCXTreloUg32txiN/yaISwGc2MGw/bB1L9ssxw0DU+wJimXOGW
QtFPQi+p6sRaA/1/6U96ADCjcia0hOFfegesJrAz4yWDmVTvld3cM6ZSDTkihMpwob
nv32mg4Z6lO9w==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Can we penalize peers who relay rejected
replacement txs?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2015 01:36:41 -0000
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
|
