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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <danny.thorpe@gmail.com>) id 1YxN2b-0004F4-Av
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 22:09:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.42 as permitted sender)
client-ip=209.85.218.42; envelope-from=danny.thorpe@gmail.com;
helo=mail-oi0-f42.google.com;
Received: from mail-oi0-f42.google.com ([209.85.218.42])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxN2a-0004fg-GX
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 22:09:41 +0000
Received: by oiww2 with SMTP id w2so89055888oiw.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 15:09:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.68.10 with SMTP id r10mr23372422oet.21.1432678175079;
Tue, 26 May 2015 15:09:35 -0700 (PDT)
Received: by 10.60.2.105 with HTTP; Tue, 26 May 2015 15:09:35 -0700 (PDT)
In-Reply-To: <CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
References: <20150526051305.GA23502@savin.petertodd.org>
<CAJN5wHXRMfZigtgJ4JTKqRMkoQgkZ-d8sZ5rkpspqySwFEQEKg@mail.gmail.com>
<CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
Date: Tue, 26 May 2015 15:09:35 -0700
Message-ID: <CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11331258b402e705170361b4
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(danny.thorpe[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YxN2a-0004fg-GX
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 22:09:41 -0000
--001a11331258b402e705170361b4
Content-Type: text/plain; charset=UTF-8
Thanks for the clarification.
So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.
The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.
So an implementation that wishes to take advantage of RBF will still need
to have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.
Is this correct?
I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.
Thanks,
-Danny
On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> It's just a mempool policy rule.
>
> Allowing the contents of blocks to change (other than by mining a
> competing chain) would be pretty much the largest possible change to
> Bitcoin's design....
>
--001a11331258b402e705170361b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for the clarification.<div><br></div><div>So, since=
RBF applies only to pending transactions in the mempool awaiting incorpora=
tion into a block, there is a window of opportunity in which the pending tx=
is incorporated into a block at the same time that the spender is construc=
ting and publishing a replacement for that pending tx.=C2=A0</div><div><br>=
</div><div>The replacement transaction would be rejected by the peer networ=
k as a double spend because it conflicts with the now confirmed original tx=
, and the spender will have to go back and create a new stand-alone transac=
tion to accomplish what they hoped to do with an RBF replacement.</div><div=
><br></div><div>So an implementation that wishes to take advantage of RBF w=
ill still need to have a "plan B" implementation path to handle t=
he corner case of a replacement tx being rejected as a double spend.</div><=
div><br></div><div>Is this correct? =C2=A0</div><div><br></div><div>I'm=
just trying to get my head around the implementation cost vs benefit of RB=
F in the context of my applications.</div><div><br></div><div>Thanks,</div>=
<div>-Danny</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <span dir=3D"ltr"><=
<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@=
gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">It's just a mempool policy rule.</p>
<p dir=3D"ltr">Allowing the contents of blocks to change (other than by min=
ing a competing chain) would be pretty much the largest possible change to =
Bitcoin's design....</p>
</blockquote></div><br></div>
--001a11331258b402e705170361b4--
|
