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
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BEC34BD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 17:51:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3EC115B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 17:51:01 +0000 (UTC)
Received: by wgjx7 with SMTP id x7so254933491wgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 10:51:00 -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=409L2nX6H7pzUzFm/yUlfLk4urEi+ktfAE54Yn5/Z8E=;
b=rf9nWCeTrFRM6e2For5S+OVISdDyChEUqDW8lmOE0OdnLqpg4KfT5ilv+gT4fQNMPR
P+m4PFmMC41+U8XWZXtRlK/nlPCVCv6xTChywx6APQEV9fH+DBz4Vka17n9TvlZfogMZ
2zf7Crh2MM0/Kb6ta85KhhfbAT0vSi7vyWT6z64iDiAIMEfQSFlmtT2MHrPIBlu8xg0E
awY8oyb+0ynqruofkbTn51Z6xVDuPkw/0FvUB65rxxvBTYW+Kv5xlsdCrk/bo7WBxMQS
LUrtlGGkvaM5KrmP3S35J3cwyUbD3AoJSnv6lMDA7gwtb9Jk4axseU/ORqOkWhDjKq/P
y6TA==
MIME-Version: 1.0
X-Received: by 10.194.121.100 with SMTP id lj4mr42321854wjb.104.1436550660229;
Fri, 10 Jul 2015 10:51:00 -0700 (PDT)
Received: by 10.180.168.34 with HTTP; Fri, 10 Jul 2015 10:51:00 -0700 (PDT)
In-Reply-To: <559FFAB3.2010309@openbitcoinprivacyproject.org>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
<CAE-z3OV+-18VLbOfWzDnE5HWJ4436HGtC_qDFFVkFQTGyjGOVw@mail.gmail.com>
<CADm_WcYQLzqQLY-Dspd1jUtF9Z=_721TReoc_eKYk5JCQ4fejg@mail.gmail.com>
<559FFAB3.2010309@openbitcoinprivacyproject.org>
Date: Fri, 10 Jul 2015 13:51:00 -0400
Message-ID: <CAPWm=eWH9rZpwJeK2tTdHH8+BWDU_Vam8oBtG0u49v2yZuYVfw@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Content-Type: multipart/alternative; boundary=089e011777b5ce0f12051a8903b7
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 17:51:02 -0000
--089e011777b5ce0f12051a8903b7
Content-Type: text/plain; charset=UTF-8
I think the biggest problem with merging CPFP right now is that at least in
its current implementation it is not efficient enough in certain
situations,.
On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier <
justus@openbitcoinprivacyproject.org> wrote:
> On 07/10/2015 11:31 AM, Jeff Garzik wrote:
> > This is a good explanation but it does not address reachability. TX_a,
> the
> > first tx sent out on the network, presumably has insufficient fee to get
> > mined - which also means it did not necessarily even reach all miners.
> >
> > Simply sending out TX_b with added fee does not guarantee that nodes
> > suddenly have TX_a, which they may have ignored/dropped before.
>
> I'm not sure why that's actually a problem.
>
> CPFP is initiated by the recipient of the parent transaction, and so if
> the recipient is creating this transaction in the first place they must
> have a copy of the parent transaction which can/should broadcast at the
> same time.
>
> If the child reaches a CPFP miner, then presumably the parents made it
> as well (any path between the sender and the miner that doesn't relay
> the parent should reject the child as trying to spend non-existent
> coins), so both of the transactions can be mined at the same time.
>
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus@openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e011777b5ce0f12051a8903b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think the biggest problem with merging CPFP right now is=
that at least in its current implementation it is not efficient enough in =
certain situations,.</div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier <span dir=3D"ltr">=
<<a href=3D"mailto:justus@openbitcoinprivacyproject.org" target=3D"_blan=
k">justus@openbitcoinprivacyproject.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">On 07/10/2015 11:31 AM, Jeff Garzik w=
rote:<br>
> This is a good explanation but it does not address reachability.=C2=A0=
TX_a, the<br>
> first tx sent out on the network, presumably has insufficient fee to g=
et<br>
> mined - which also means it did not necessarily even reach all miners.=
<br>
><br>
> Simply sending out TX_b with added fee does not guarantee that nodes<b=
r>
> suddenly have TX_a, which they may have ignored/dropped before.<br>
<br>
</span>I'm not sure why that's actually a problem.<br>
<br>
CPFP is initiated by the recipient of the parent transaction, and so if<br>
the recipient is creating this transaction in the first place they must<br>
have a copy of the parent transaction which can/should broadcast at the<br>
same time.<br>
<br>
If the child reaches a CPFP miner, then presumably the parents made it<br>
as well (any path between the sender and the miner that doesn't relay<b=
r>
the parent should reject the child as trying to spend non-existent<br>
coins), so both of the transactions can be mined at the same time.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Justus Ranvier<br>
Open Bitcoin Privacy Project<br>
<a href=3D"http://www.openbitcoinprivacyproject.org/" rel=3D"noreferrer" ta=
rget=3D"_blank">http://www.openbitcoinprivacyproject.org/</a><br>
<a href=3D"mailto:justus@openbitcoinprivacyproject.org">justus@openbitcoinp=
rivacyproject.org</a><br>
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623<br>
</font></span><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>
--089e011777b5ce0f12051a8903b7--
|
