summaryrefslogtreecommitdiff
path: root/d5/0c4d9fb770717e0e5b296d03934a16f8c93604
blob: 4638cd8e0fb3b96fdcee8854b9ade67cbb8a994c (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
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1048AB13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 16:13:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
	[209.85.212.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B51CE3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 16:13:31 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so17824957wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Jul 2015 09:13:29 -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=Jn9Ikj0C+SriwpRSThme5YaReoExmbvKLI0OcAILeng=;
	b=Smj3Ebc8w2gztkK+TWVU5LuGGA9PZ9EajlJ/dsQvCXsX0nbBwYgEU3C4cZ2GNESiUB
	yX2Y2RUg6OQqnBoYBTa5X0ESqtH7S4x7jTfx/RP/W4Te0qevRCQWGiPJPhHjKF+jaB21
	kPbfuAwBoJMgBMMz5uR82iA1tFl/O+eO40medLJnNMbVQGaihDN6rn3tnLXbxCk2V2e6
	/Hn6WpOVp5HaeD5qs+X15nYTLW6vEnxKMx1/Or0mixpIbQo2cxsQSeo9kgl7TH/P/jtL
	OllXiVsh+1f66I2unqKmEL9cYX3OOLc8+OiQyCzhDIyLCVqtgebi0vSacDsRXiqhXnLV
	5DYA==
MIME-Version: 1.0
X-Received: by 10.180.79.162 with SMTP id k2mr7690284wix.46.1436544809664;
	Fri, 10 Jul 2015 09:13:29 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Fri, 10 Jul 2015 09:13:29 -0700 (PDT)
In-Reply-To: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
Date: Fri, 10 Jul 2015 12:13:29 -0400
Message-ID: <CADm_WcZkH9fZD23MH8m4wXEnqqjmMg1mPFjeME+uHbMgPNViEw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Richard Moore <me@ricmoo.com>
Content-Type: multipart/alternative; boundary=f46d043745111587e3051a87a7db
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
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:13:32 -0000

--f46d043745111587e3051a87a7db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.


On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me@ricmoo.com> wrote:

> Hey guys,
>
> 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?
>
> 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 require=
d 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 c=
onfirmed),
> 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 f=
or
> the 3 transactions it is going to commit.
>
> 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 has=
h 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 so=
me
> combination.
>
> Just curious as whatnot=E2=80=A6
>
> Thanks,
> RicMoo
>
> .=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
> www: http://GeneticMistakes.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--f46d043745111587e3051a87a7db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">CPFP is interesting, but it does not fully cover the case =
it is trying to address: =C2=A0 If TX_a goes out without sufficient fee, se=
nding out a new TX_b will not help TX_a suddenly reach nodes/miners that ig=
nored TX_a.<div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <span dir=
=3D"ltr">&lt;<a href=3D"mailto:me@ricmoo.com" target=3D"_blank">me@ricmoo.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word"><div>Hey guys,</div><div><br></div><div>With all the re=
cent 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><br>=
</div><div>I was also wondering, with CPFP, should the transaction fee be b=
ased on total transactions size, or the sum of each transaction=E2=80=99s r=
equired 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><br></div><div>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.000=
1 btc. It still hasn=E2=80=99t confirmed, which could be any of: a) CPFP do=
esn=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><br></div><div=
>Just curious as whatnot=E2=80=A6</div><div><br></div><div>Thanks,</div><di=
v>RicMoo</div><div><br></div><div>
<span style=3D"border-collapse:separate;color:rgb(0,0,0);font-family:Helvet=
ica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing=
:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:n=
one;white-space:normal;word-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><br>Richard Moore ~ Founder<br>Genetic Mista=
kes Software inc.<br>phone: <a href=3D"tel:%28778%29%20882-6125" value=3D"+=
17788826125" target=3D"_blank">(778) 882-6125</a><br>email:=C2=A0<a href=3D=
"mailto:ricmoo@geneticmistakes.com" target=3D"_blank">ricmoo@geneticmistake=
s.com</a><br>www:=C2=A0<a href=3D"http://GeneticMistakes.com/" target=3D"_b=
lank">http://GeneticMistakes.com</a></span>
</div>
<br></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--f46d043745111587e3051a87a7db--