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
|
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 17660F74
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Feb 2018 16:26:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
[209.85.214.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BDD95C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Feb 2018 16:26:20 +0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id v186so15950184itc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Feb 2018 08:26:20 -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=mQNpPNuFx+ZQJcflsyF3IN+fUZ2MpzR9nZjNaJroGI0=;
b=G2HIu4eXleDwCV+e/Sxs1hY8ZDhFF4/kD0VGuSG9tx2pkolqjK/1NaD4uXGEkXs+ox
BdWLtvAUfQqmx5JqH52wvGrwOPR/Hbk1pQMfDZfK+9wQ1bvrQvyRuR3A2RdlmODIt1u0
cMbo8qV41GXqQUwtKHWmReb7Weeimt87Lu/mU=
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=mQNpPNuFx+ZQJcflsyF3IN+fUZ2MpzR9nZjNaJroGI0=;
b=nr3Au2NtI6TwOWpIcBZOE0vOCSe7/i4L5X4WOaXD8n+FTuJaII7h+wAdJmISCGNAwY
T7XhqNWtBoUFHGCDk8ytOxwnbI46mV8EAAUzVFBHCFrK2u4E7PmOfrTiRpJ8d03wjKd+
C8CocFIslRDo7j2kMkCFQqpX1kp7diZWh2aH0bYRYOCKWOrZ/FR0i2bmKb7cN8jQkTkI
4N27Fnbw0jrE/h0yZRk/9MOfnb9mzAN3jNfdL8ghkkL7Koa7op+/QFY2CCx1mznpwVDX
yvuD3NLk6kX21mYD93BIpBua0nevo2p+d8U3EGLwcdv/SUJWxdMCWfDyjw1HAxEYJPzg
qWiw==
X-Gm-Message-State: APf1xPBfEBjrcoGO5ZFsVjFhbMrOV/XA1gNzw4FHa5/lY8b6s/AKqAt7
zbvCFP2YkwbB/dgE8GuRecQmFN+1YZ6RDmBBTX1JDpSs
X-Google-Smtp-Source: AG47ELs+YCUGT2uRk3+QFiNbA/lLF0tkADFPkfRa2p4E187OtLVo+7Q8xKVVl1lRwVqZRWoA9+iA6/yBVfJWxMUKRuw=
X-Received: by 10.36.17.77 with SMTP id 74mr6166535itf.74.1519748779706; Tue,
27 Feb 2018 08:26:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.166.10 with HTTP; Tue, 27 Feb 2018 08:25:59 -0800 (PST)
In-Reply-To: <20180212234225.GA9131@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>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 27 Feb 2018 11:25:59 -0500
Message-ID: <CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11441194299e150566341668"
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: Tue, 27 Feb 2018 16:26:21 -0000
--001a11441194299e150566341668
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd.org> wrote:
>
> Ah ok, I misunderstood and didn't realise you were talking about the case
> where
> Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> case
> is possible to solve without putting some kind of restriction on spending
> unconfirmed outputs; with a restriction it's fairly simple to solve.
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?
--001a11441194299e150566341668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <span dir=3D"ltr"><<a hr=
ef=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
<br>
</span>Ah ok, I misunderstood and didn't realise you were talking about=
the case where<br>
Alice re-spends her unconfirmed payment. Unfortunately I don't think th=
at case<br>
is possible to solve without putting some kind of restriction on spending<b=
r>
unconfirmed outputs; with a restriction it's fairly simple to solve.</b=
lockquote><div><br></div><div>When you say that you don't think it is p=
ossible to solve, do you mean that there is a specific problem with this pr=
oposal of replacing transactions when offered a new transaction whose fee r=
ate exceeds the package fee rate of the original transaction (and ensuring =
that the fee increase covers the size of the transactions being ejected)?=
=C2=A0 Is your concern only about the ability to computing and track the pa=
ckage fee rate for transactions within the mempool or is there some other i=
ssue you foresee?<br></div><div>=C2=A0</div></div></div></div>
--001a11441194299e150566341668--
|
