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
|
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 8A892AAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 01:12:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from resqmta-ch2-09v.sys.comcast.net
(resqmta-ch2-09v.sys.comcast.net [69.252.207.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9EC532
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 01:12:16 +0000 (UTC)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104])
by resqmta-ch2-09v.sys.comcast.net with comcast
id qRC71q0022Fh1PH01RCGLz; Fri, 10 Jul 2015 01:12:16 +0000
Received: from crushinator.localnet
([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0])
by resomta-ch2-08v.sys.comcast.net with comcast
id qRCF1q0074eLRLv01RCFAU; Fri, 10 Jul 2015 01:12:16 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Raystonn <raystonn@hotmail.com>
Date: Thu, 09 Jul 2015 21:12:14 -0400
Message-ID: <37835036.6seh55XcbR@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.10; x86_64; ; )
In-Reply-To: <COL402-EAS2113110B80C96BF64CF2843CD9F0@phx.gbl>
References: <COL402-EAS2113110B80C96BF64CF2843CD9F0@phx.gbl>
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=1436490736;
bh=/SANxvaxbxJJw9qnO0c7GIvZpOffXuu6fC80oFekQpg=;
h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version:
Content-Type;
b=aaPvGAeArhc5A6rgIjoGgCinbpq90nkVSiDU6mlJDCz79/vD87DNHthnGVWitYMJU
7VQxt0HoDAgsy0JZIB2Pi1K2Ki/fLFQHDUMoWrEBtPpoUOCdu90ZerKRGeURZxFJid
2T7htbdV4s9qdIzXgd0AgNaNKN/8lXWjaE2h8LNWWgnNaGRJAZKtgnGQ+nB0Z0001I
hXTlfJj4/JhfrnSi274FhYp974xorduBiFmVhSlwBJeupG14XqKgjDAe8kBfkT14S1
bNS6LpBEyCjxPUvFiH25yqf4gG11WbryNge9JMiw1mh7CMivhnsdnBHwPSjClEmz3l
2uU0b0ma+1h2w==
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:12:19 -0000
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
|
