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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
|
Return-Path: <michabailey@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 74F45BA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Jul 2015 04:20:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08A8A21E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Jul 2015 04:20:31 +0000 (UTC)
Received: by wgjx7 with SMTP id x7so128913576wgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 21:20:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=S7QYYhV9Y1mPrQsDcSw7lXeRzcDjuOQXZjkvbEBGpNU=;
b=Q0/cHnk0VzjzLncY4TAe/6RyF4Qkh54M3vL2MYwYNCPdtZoSXF8rWTONo78glYCmle
mUUsINiANmFEsI+v93h7gs83GVA1UzAsqfm/rg1SyCe419VnX9ZV9dd1U0HkBh7RIYU5
gxND3Czr9AGTrWdhNu/bt4fBrrNFcfIc5+9CibY44Lwjtnr/K0fCwnCla8uPF4LYSqOV
2yOhrxrxsi9HH4gMGU3Bt6VBp16LWPkbour9pnGEuSUfbIp2a588Cpwq5gAq2lAXxG1C
UvNwiDaMEX8U8oB4s5cEkYA/nWBHhMX4bYikFP4mABBp/Un5hlGWDmMVteI/Gsnp47YE
vuxg==
MIME-Version: 1.0
X-Received: by 10.180.20.198 with SMTP id p6mr50087043wie.38.1436156430643;
Sun, 05 Jul 2015 21:20:30 -0700 (PDT)
Received: by 10.28.32.132 with HTTP; Sun, 5 Jul 2015 21:20:30 -0700 (PDT)
In-Reply-To: <CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com>
References: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
<CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com>
<20150703215658.GC5916@muck>
<CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com>
Date: Mon, 6 Jul 2015 07:20:30 +0300
Message-ID: <CAAmoQf3g_3p-+JU2bjFzv+4wAD1Y7bvQ7WAX4u8B4MdeXtmpSw@mail.gmail.com>
From: Micha Bailey <michabailey@gmail.com>
To: "DKBryant@gmail.com" <DKBryant@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec53f397de3f7fc051a2d39e1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed
transactions with a bounty.
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: Mon, 06 Jul 2015 04:20:33 -0000
--bcaec53f397de3f7fc051a2d39e1
Content-Type: text/plain; charset=UTF-8
On Monday, July 6, 2015, Dan Bryant <dkbryant@gmail.com> wrote:
> On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> > This is called child pays for parent and there is a three year old pull
> > request implementing it:
> >
> > https://github.com/bitcoin/bitcoin/pull/1647
>
> Understood... When I wrote the BIP proposal I was assuming
> (incorrectly) that CPFP TX selection was already being done by miners,
> but I see now that certain trees could bloom the TX selection latency
> as miners would need to be more dependency aware. Perhaps the BIP66
> orphan block chain shows that some miners may not always be counted on
> to ensure that all TX stuffed in a block have dependencies met.
> Certainly not until the PR1647 is fully merged and deployed.
>
> On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip@mattwhitlock.name
> <javascript:;>> wrote:
> > PR#1647 only addresses miner policy, though, right? I believe the BIP is
> > addressing the user-facing side of this functionality. CPFP mining policy
> > does very little good if wallets don't offer any way for users to goose
> up
> > incoming transactions.
>
> On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> > The points regarding sweep transaction UI is out of scope for a BIP I'm
> > afraid. I suggest talking with wallet authors, and if agreement can be
> > found writing a pull request.
>
> Yes... although I certainly admit, I didn't know about CPFP or I would
> have called it out as a requirement for this UI enhancement request.
> I'll see if I can't get some wallet authors interested in this as a
> feature enhancement when PR1647 commits.
>
> Perhaps there are risks raised if CPFP is not enabled but these sweep
> tx enter the mempool. If miners take the high fee "children" but
> ignore the low fee "parents" then the child might enter the blockchain
> without the parent. If miners were light on block validation,
> wouldn't it be possible that the child may go forward with many
> confirmations, while the parent patiently waits in the mempool? This
> could be bad since spending the child may look good, as it might have
> many confirmations, while its parent has few.
A child is a transaction that spends outputs of another transaction, the
parent. The child cannot be confirmed before the parent, because the
outputs being spent do not yet exist.
>
> On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete@petertodd.org
> <javascript:;>> wrote:
> > "Replace-by-fee scorched-earth without child-pays-for-parent",
> > Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
>
> Very good! So if I follow, RPF can work one of two ways:
>
> In the "countermeasure" form, spender gives receiver a partially
> signed "countermeasure" transactions with juiced up fees.
>
> In the "anyonecanpay" form, spender signs the transaction with
> ANYONECANPAY bit allowing the reviver to add fees at will.
>
> One question I did have about RBF is this.. Is it correct to presume
> that the spender doesn't send the incomplete "countermeasure"
> transaction to the network? If they did, wouldn't they get flagged on
> DoS code banning them from peers?
A transaction that is not completely signed won't be relayed, correct, and
it cannot be mined.
> Corollary question. If the "countermeasure" transaction is not
> broadcast, is it sent to the receiver via back channel (email, etc)
>
> I'll try to clean up the draft BIP to include CPFP dependencies and
> RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc
> to outline my thoughts at this point. Not burning a whole in my head,
> so may take some time.
>
> Thx.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <javascript:;>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--bcaec53f397de3f7fc051a2d39e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, July 6, 2015, Dan Bryant <<a href=3D"mailto:dkbryant@=
gmail.com">dkbryant@gmail.com</a>> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:<br>
> This is called child pays for parent and there is a three year old pul=
l<br>
> request implementing it:<br>
><br>
> <a href=3D"https://github.com/bitcoin/bitcoin/pull/1647" target=3D"_bl=
ank">https://github.com/bitcoin/bitcoin/pull/1647</a><br>
<br>
Understood... When I wrote the BIP proposal I was assuming<br>
(incorrectly) that CPFP TX selection was already being done by miners,<br>
but I see now that certain trees could bloom the TX selection latency<br>
as miners would need to be more dependency aware.=C2=A0 Perhaps the BIP66<b=
r>
orphan block chain shows that some miners may not always be counted on<br>
to ensure that all TX stuffed in a block have dependencies met.<br>
Certainly not until the PR1647 is fully merged and deployed.<br>
<br>
On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <<a href=3D"javascript:;"=
onclick=3D"_e(event, 'cvml', 'bip@mattwhitlock.name')">bip=
@mattwhitlock.name</a>> wrote:<br>
> PR#1647 only addresses miner policy, though, right? I believe the BIP =
is<br>
> addressing the user-facing side of this functionality. CPFP mining pol=
icy<br>
> does very little good if wallets don't offer any way for users to =
goose up<br>
> incoming transactions.<br>
<br>
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:<br>
> The points regarding sweep transaction UI is out of scope for a BIP I&=
#39;m<br>
> afraid. I suggest talking with wallet authors, and if agreement can be=
<br>
> found writing a pull request.<br>
<br>
Yes... although I certainly admit, I didn't know about CPFP or I would<=
br>
have called it out as a requirement for this UI enhancement request.<br>
I'll see if I can't get some wallet authors interested in this as a=
<br>
feature enhancement when PR1647 commits.<br>
<br>
Perhaps there are risks raised if CPFP is not enabled but these sweep<br>
tx enter the mempool.=C2=A0 If miners take the high fee "children"=
; but<br>
ignore the low fee "parents" then the child might enter the block=
chain<br>
without the parent.=C2=A0 If miners were light on block validation,<br>
wouldn't it be possible that the child may go forward with many<br>
confirmations, while the parent patiently waits in the mempool?=C2=A0 This<=
br>
could be bad since spending the child may look good, as it might have<br>
many confirmations, while its parent has few.</blockquote><div><br></div><d=
iv>A child is a transaction that spends outputs of another transaction, the=
parent. The child cannot be confirmed before the parent, because the outpu=
ts being spent do not yet exist.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>
On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <<a href=3D"javascript:;" onc=
lick=3D"_e(event, 'cvml', 'pete@petertodd.org')">pete@peter=
todd.org</a>> wrote:<br>
> "Replace-by-fee scorched-earth without child-pays-for-parent"=
;,<br>
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014<br>
> <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014=
-April/005620.html" target=3D"_blank">http://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2014-April/005620.html</a><br>
<br>
Very good!=C2=A0 So if I follow, RPF can work one of two ways:<br>
<br>
In the "countermeasure" form, spender gives receiver a partially<=
br>
signed "countermeasure" transactions with juiced up fees.<br>
<br>
In the "anyonecanpay" form, spender signs the transaction with<br=
>
ANYONECANPAY bit allowing the reviver to add fees at will.<br>
<br>
One question I did have about RBF is this.. Is it correct to presume<br>
that the spender doesn't send the incomplete "countermeasure"=
<br>
transaction to the network?=C2=A0 If they did, wouldn't they get flagge=
d on<br>
DoS code banning them from peers?</blockquote><div><br></div><div>A transac=
tion that is not completely signed won't be relayed, correct, and it ca=
nnot be mined.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Corollary question.=C2=A0 If the "countermeasure" transaction is =
not<br>
broadcast, is it sent to the receiver via back channel (email, etc)<br>
<br>
I'll try to clean up the draft BIP to include CPFP dependencies and<br>
RBF capabilities.=C2=A0 Whether it belongs in a BIP or a PR, its just a doc=
<br>
to outline my thoughts at this point.=C2=A0 Not burning a whole in my head,=
<br>
so may take some time.<br>
<br>
Thx.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"javascript:;" onclick=3D"_e(event, 'cvml', 'bitcoin-=
dev@lists.linuxfoundation.org')">bitcoin-dev@lists.linuxfoundation.org<=
/a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
</blockquote>
--bcaec53f397de3f7fc051a2d39e1--
|
