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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D9C7E43
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Mar 2018 15:40:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f67.google.com (mail-it0-f67.google.com
[209.85.214.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02AFB5CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Mar 2018 15:40:07 +0000 (UTC)
Received: by mail-it0-f67.google.com with SMTP id c11so8100025ith.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Mar 2018 07:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=GU7bU9UuIpQGH7fh8kX11CgT+PMjnaIGFNiAWXvboAo=;
b=1JzrAD+brGdNStRB2ED2E141wR5UIopDwK0gsEA2hLD5aRoMUjfD0H6LzMKIF7jSSM
ra6XMNSaMfdMoo+YS4528bvIk4y8yWTs5o14TQC0E1OLz9keqNMvUBuk2+IIJvEYqb8p
KsFVYIjGPGNn+zXrkmWzo5PWuA0tJIsfh52Cc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=GU7bU9UuIpQGH7fh8kX11CgT+PMjnaIGFNiAWXvboAo=;
b=NPf3YVjoU1lDt+qTwGcclZaxPFKUn2ezHgfyc8aqZMjNyMMZbkfXeUh4B41tJDjlth
mh3oW3IiqHiotKeYRrfyTcPtqoDSydzFzdX7yrlmWWIX+dTLZG5AW0JjQV7LxvLejWyM
eUuWOCGhJnBSNdtNn0GkTfKvPKRR+Mk35vhJIyER71e8GeqRuE06zl56sCAQ+V8I52aC
FigH1w92u/waTnk4duk6Ie3GwkGEiE4DHNfpVLb9JHmfDmamZa80XyQixNxAuVIA52on
tAa/LDMLB2W01r7znhGUGKKo5VPc+z/FCyDuriYEKLpn35T/Dw5v0cQUSZ8NjpJ7FBSK
NmZA==
X-Gm-Message-State: AElRT7ErHZB71vFBueO+4GWgXDmdzMuxSIdRV6HYPgUk7wvfzfsJUN87
28GMU0Nkfgj8Lup2O7YQ36S6jTzjiVoGZjexz/Pt0oGQ
X-Google-Smtp-Source: AG47ELuGrShpOsOQbHYIjP9b1PN/SiFhYWA/dZACmYTD2pLCBoRBl9H11UVi7L29AgqCkqLGS+MYoyatsTfrqoGx0xM=
X-Received: by 10.36.67.1 with SMTP id s1mr14432686itb.145.1520523607278; Thu,
08 Mar 2018 07:40:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.166.10 with HTTP; Thu, 8 Mar 2018 07:39:46 -0800 (PST)
In-Reply-To: <20180301151129.GA9373@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
<20180212234225.GA9131@fedora-23-dvm>
<CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
<20180301151129.GA9373@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 8 Mar 2018 10:39:46 -0500
Message-ID: <CAMZUoKkG8tbdb+6tGmpvgXb-=3Tu4JsTWXz77o3EC+4Bcbd17A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11441cf27c61180566e87d69"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 08 Mar 2018 15:40:09 -0000
--001a11441cf27c61180566e87d69
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete@petertodd.org> wrote:
> On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> > When you say that you don't think it is possible to solve, do you mean
> that
> > there is a specific problem with this proposal of replacing transactions
> > when offered a new transaction whose fee rate exceeds the package fee
> rate
> > of the original transaction (and ensuring that the fee increase covers
> the
> > size of the transactions being ejected)? Is your concern only about the
> > ability to computing and track the package fee rate for transactions
> within
> > the mempool or is there some other issue you foresee?
>
> I mean, I think in general solving this problem is probably not possible.
> Basically, the fundamental problem is someone else has consumed network
> bandwidth that should be paid for with fees. What you're trying to do is
> replace a transaction without paying those fees, which is identical to
> what an
> attacker is trying to do, and thus any such scheme will be as vulnerable to
> attack as not having that protection in the first place.
>
> ...which does give you an out: maybe the attack isn't important enough to
> matter. :)
>
Thanks, that makes sense.
I still think it is worthwhile pursuing this proposed change in RBF policy
as it would seem that the current policy is problematic in practice today
where participants are just performing normal transactions and are not
trying to attack each other.
--001a11441cf27c61180566e87d69
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
>On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <span dir=3D"ltr"><<a href=
=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div=
class=3D"h5">On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Conno=
r wrote:<br>
> When you say that you don't think it is possible to solve, do you =
mean that<br>
> there is a specific problem with this proposal of replacing transactio=
ns<br>
> when offered a new transaction whose fee rate exceeds the package fee =
rate<br>
> of the original transaction (and ensuring that the fee increase covers=
the<br>
> size of the transactions being ejected)?=C2=A0 Is your concern only ab=
out the<br>
> ability to computing and track the package fee rate for transactions w=
ithin<br>
> the mempool or is there some other issue you foresee?<br>
<br>
</div></div>I mean, I think in general solving this problem is probably not=
possible.<br>
Basically, the fundamental problem is someone else has consumed network<br>
bandwidth that should be paid for with fees. What you're trying to do i=
s<br>
replace a transaction without paying those fees, which is identical to what=
an<br>
attacker is trying to do, and thus any such scheme will be as vulnerable to=
<br>
attack as not having that protection in the first place.<br>
<br>
...which does give you an out: maybe the attack isn't important enough =
to<br>
matter. :)<br>
</blockquote><div><br></div><div>Thanks, that makes sense.<br><br></div><di=
v>I still think it is worthwhile pursuing this proposed change in RBF polic=
y as it would seem that the current policy is problematic in practice today=
where participants are just performing normal transactions and are not try=
ing to attack each other.<br></div></div></div></div></div>
--001a11441cf27c61180566e87d69--
|
