summaryrefslogtreecommitdiff
path: root/74/36b73192fcf01a88b5871f3bb2d75692729bda
blob: 7b517e802073c125653662c48cceaa6c250d5538 (plain)
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
Return-Path: <me@ricmoo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DC384B88
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 16:25:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com
	[209.85.223.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 399FB158
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 16:25:28 +0000 (UTC)
Received: by iecvh10 with SMTP id vh10so199934645iec.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 09:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=5Z62284FBiAxAgZkyXsaWys+ZHc9265iqO5Cuas6PlU=;
	b=AXomgl5Bg2lKrkPIvIZSB5FM6Mv4cY22znFYg7qMh+gXCCzgoYGZ0bBR+8WZTeuvgs
	FqgCdaD8ntjdCvgw17MtARABLLbRKRZd9qSSPV82Ad2aRoM/yM7c3f271YBd1H3PKJT0
	E2k8ufDJPDl6RjyA6zdwyRGNNRiiVv0bnJ7JM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:message-id:references:to;
	bh=5Z62284FBiAxAgZkyXsaWys+ZHc9265iqO5Cuas6PlU=;
	b=ZQYXBM/UYEROyH9eRIDln67Se98XjO5dsTuKdRxlnesarnJ6T8OS9bH/TNX/ehDFRT
	rjhe/mSHKRJeCXMKNv6YymPVypBu+TrAPAaTdnrHPnsvz3qkSGHEear1A+Pc7hLt6Ym+
	J3eHZkhGyEsQ943oKPdQ/aJ2aqViyrdD1yvvJQjois6rH4gIxBdCLdSs2XHLfVx+esKf
	Sql3cMA7r9cTUUpNz9yccS9rke2Y8vNKK/sJQKekuQ+cyOS0Uh0vBPsacBnRvdssRwdF
	fdsxYFPrVnNUSMv9lBWUuO7Rb7IsRGNvzcWm0+7LUIGS2OGnaPs2aRKlpGSNY3HGfRQi
	ZFVg==
X-Gm-Message-State: ALoCoQmKjIFUYJBCkjgCHP/nAHeQKLMp237u+OyqzWqt9ZnnA3BlH8JEqiB0QVFEL87nFkV5bwZC
X-Received: by 10.50.136.134 with SMTP id qa6mr4338788igb.26.1436545527675;
	Fri, 10 Jul 2015 09:25:27 -0700 (PDT)
Received: from [192.168.2.79] (69-196-189-7.dsl.teksavvy.com. [69.196.189.7])
	by smtp.gmail.com with ESMTPSA id
	g12sm6766746ioe.28.2015.07.10.09.25.25
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 10 Jul 2015 09:25:26 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Richard Moore <me@ricmoo.com>
In-Reply-To: <CADm_WcZkH9fZD23MH8m4wXEnqqjmMg1mPFjeME+uHbMgPNViEw@mail.gmail.com>
Date: Fri, 10 Jul 2015 12:25:20 -0400
Message-Id: <837A1D9C-FD4E-4DF7-BE6B-4C90EB07C0A7@ricmoo.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
	<CADm_WcZkH9fZD23MH8m4wXEnqqjmMg1mPFjeME+uHbMgPNViEw@mail.gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
X-Mailer: Apple Mail (2.2102)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, MIME_QP_LONG_LINE,
	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
Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
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 16:25:30 -0000


--Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

By ignored, do you mean the nodes/miners didn=E2=80=99t even include the =
low fee transaction in their memory pools, so would no longer have =
access to it? If a node decides to not include it in its memory pool for =
this reason, I guess it won=E2=80=99t send out any INV messages either?

Could the broadcaster of TX_b rebroadcast TX_a? Then I guess any node =
that did add it to its memory pool would realize it=E2=80=99s not new =
and not rebroadcast it to those who didn=E2=80=99t, so it won=E2=80=99t =
propagate=E2=80=A6 Although, after receiving the orphan transaction =
TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish =
time to prevent further DoS vectors)? Assuming the sender of TX_b has a =
copy of TX_a=E2=80=A6


> On Jul 10, 2015, at 12:13 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
>=20
> CPFP is interesting, but it does not fully cover the case it is trying =
to address:   If TX_a goes out without sufficient fee, sending out a new =
TX_b will not help TX_a suddenly reach nodes/miners that ignored TX_a.
>=20
>=20
> On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me@ricmoo.com =
<mailto:me@ricmoo.com>> wrote:
> Hey guys,
>=20
> With all the recent congestion and discussion regarding FSS-RBF, I was =
wondering if there good reasons not to have CPFP as a default policy? Or =
is it?
>=20
> I was also wondering, with CPFP, should the transaction fee be based =
on total transactions size, or the sum of each transaction=E2=80=99s =
required fee? For example, a third transaction C whose unconfirmed utxo =
from transaction B has an unconfirmed utxo in transaction A (all of =
A=E2=80=99s inputs are confirmed), with each A, B and C being ~300bytes, =
should C=E2=80=99s transaction fee be 0.0001 btc for the ~1kb it is =
about to commit to the blockchain, or 0.0003 btc for the 3 transactions =
it is going to commit.
>=20
> I tried to test it out a few days ago, sending 0.0008 btc without any =
fee, then that utxo into another transaction w/ 0.0001 btc. It still =
hasn=E2=80=99t confirmed, which could be any of: a) CPFP doesn=E2=80=99t =
have enough hash power, b) the amounts are too small, c) the coins are =
too new, d) the fee should have actually been 0.0002 btc, e) the =
congestion is just too great; or some combination.
>=20
> Just curious as whatnot=E2=80=A6
>=20
> Thanks,
> RicMoo
>=20
> =
.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=
=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=
=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>
>=20
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125 <tel:%28778%29%20882-6125>
> email: ricmoo@geneticmistakes.com <mailto:ricmoo@geneticmistakes.com>
> www: http://GeneticMistakes.com <http://geneticmistakes.com/>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20

=
.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=
=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=
=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com <mailto:ricmoo@geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>

--Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">By ignored, do you mean the nodes/miners didn=E2=80=99t even =
include the low fee transaction in their memory pools, so would no =
longer have access to it? If a node decides to not include it in its =
memory pool for this reason, I guess it won=E2=80=99t send out any INV =
messages either?<div class=3D""><br class=3D""></div><div class=3D"">Could=
 the broadcaster of TX_b rebroadcast TX_a? Then I guess any node that =
did add it to its memory pool would realize it=E2=80=99s not new and not =
rebroadcast it to those who didn=E2=80=99t, so it won=E2=80=99t =
propagate=E2=80=A6 Although, after receiving the orphan transaction =
TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish =
time to prevent further DoS vectors)? Assuming the sender of TX_b has a =
copy of TX_a=E2=80=A6<div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 10, 2015, at 12:13 PM, Jeff Garzik &lt;<a =
href=3D"mailto:jgarzik@gmail.com" class=3D"">jgarzik@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">CPFP is interesting, but it does not fully cover =
the case it is trying to address: &nbsp; If TX_a goes out without =
sufficient fee, sending out a new TX_b will not help TX_a suddenly reach =
nodes/miners that ignored TX_a.<div class=3D""><br =
class=3D""></div></div><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore =
<span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:me@ricmoo.com" =
target=3D"_blank" class=3D"">me@ricmoo.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D"">Hey =
guys,</div><div class=3D""><br class=3D""></div><div class=3D"">With all =
the recent congestion and discussion regarding FSS-RBF, I was wondering =
if there good reasons not to have CPFP as a default policy? Or is =
it?</div><div class=3D""><br class=3D""></div><div class=3D"">I was also =
wondering, with CPFP, should the transaction fee be based on total =
transactions size, or the sum of each transaction=E2=80=99s required =
fee? For example, a third transaction C whose unconfirmed utxo from =
transaction B has an unconfirmed utxo in transaction A (all of A=E2=80=99s=
 inputs are confirmed), with each A, B and C being ~300bytes, should =
C=E2=80=99s transaction fee be 0.0001 btc for the ~1kb it is about to =
commit to the blockchain, or 0.0003 btc for the 3 transactions it is =
going to commit.</div><div class=3D""><br class=3D""></div><div =
class=3D"">I tried to test it out a few days ago, sending 0.0008 btc =
without any fee, then that utxo into another transaction w/ 0.0001 btc. =
It still hasn=E2=80=99t confirmed, which could be any of: a) CPFP =
doesn=E2=80=99t have enough hash power, b) the amounts are too small, c) =
the coins are too new, d) the fee should have actually been 0.0002 btc, =
e) the congestion is just too great; or some combination.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Just curious as =
whatnot=E2=80=A6</div><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks,</div><div class=3D"">RicMoo</div><div class=3D""><br =
class=3D""></div><div class=3D"">
<span style=3D"border-collapse: separate; font-family: Helvetica; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px;" =
class=3D"">.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7=
.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=
=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8&gt;&lt;(((=C2=BA&gt;<br =
class=3D""><br class=3D"">Richard Moore ~ Founder<br class=3D"">Genetic =
Mistakes Software inc.<br class=3D"">phone: <a =
href=3D"tel:%28778%29%20882-6125" value=3D"+17788826125" target=3D"_blank"=
 class=3D"">(778) 882-6125</a><br class=3D"">email:&nbsp;<a =
href=3D"mailto:ricmoo@geneticmistakes.com" target=3D"_blank" =
class=3D"">ricmoo@geneticmistakes.com</a><br class=3D"">www:&nbsp;<a =
href=3D"http://geneticmistakes.com/" target=3D"_blank" =
class=3D"">http://GeneticMistakes.com</a></span>
</div>
<br class=3D""></div><br =
class=3D"">_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
<br class=3D""></blockquote></div><br class=3D""></div>
</div></blockquote></div><br class=3D""><div apple-content-edited=3D"true"=
 class=3D"">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: =
0px;">.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=
=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7=
.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8&gt;&lt;(((=C2=BA&gt;<br =
class=3D""><br class=3D"">Richard Moore ~ Founder<br class=3D"">Genetic =
Mistakes Software inc.<br class=3D"">phone: (778) 882-6125<br =
class=3D"">email:&nbsp;<a href=3D"mailto:ricmoo@geneticmistakes.com" =
class=3D"">ricmoo@geneticmistakes.com</a><br class=3D"">www:&nbsp;<a =
href=3D"http://GeneticMistakes.com/" =
class=3D"">http://GeneticMistakes.com</a></span>
</div>
<br class=3D""></div></div></body></html>=

--Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE--