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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B2F19F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 17:28:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com
[209.85.192.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1794C12D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 17:28:15 +0000 (UTC)
Received: by qgef3 with SMTP id f3so82530588qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 10:28:14 -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:cc
:content-type; bh=mAjhP69wYouLdZ4/Zd/Cmt7rHSh79Z+LhEn34d4zi/w=;
b=nsVl/sT4TbcE0+Bii8BMqdVyDpAgMh27ETjcvecDaJPayW0q6kcP4deHuPuEQP7zcq
M13YJKM7PLb0MVLNQ/kH0CKMvmYDTR/MjONTHCq3fZoXK42+DXwAIcHerPB9+gGKv3B9
/OgNBXSK22D+pyRwQsDR2zPSYIc/Y9KoTP3fu2t9gRvw81ua93cq48pNVQbGwt0OCVKG
xXkLiNGALtm8f1qPkYaj6B5aNERSQ3AXluT+4S8ud158LXCz9MZ5ieylH1hywQoZcD7f
dVTpEig4BCDZTlvsrdW4tThEOv5ElRkEUid7arbwZUK09Y7hFFOqeLAYmK2WIHOp1amn
VdwQ==
MIME-Version: 1.0
X-Received: by 10.140.237.147 with SMTP id i141mr36969440qhc.25.1436549294292;
Fri, 10 Jul 2015 10:28:14 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Fri, 10 Jul 2015 10:28:14 -0700 (PDT)
In-Reply-To: <CADm_WcYQLzqQLY-Dspd1jUtF9Z=_721TReoc_eKYk5JCQ4fejg@mail.gmail.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
<CAE-z3OV+-18VLbOfWzDnE5HWJ4436HGtC_qDFFVkFQTGyjGOVw@mail.gmail.com>
<CADm_WcYQLzqQLY-Dspd1jUtF9Z=_721TReoc_eKYk5JCQ4fejg@mail.gmail.com>
Date: Fri, 10 Jul 2015 18:28:14 +0100
Message-ID: <CAE-z3OWvrhXzE907Ano+KPV28obDL3PdFCUCs7KzD09qNsFfAw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135ad28638669051a88b2e2
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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:28:15 -0000
--001a1135ad28638669051a88b2e2
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <jgarzik@gmail.com> 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.
>
When the peer adds both parent and child to the memory pool, it should
forward both of them.
CPFP inherently requires that nodes keep transactions that they have
rejected due to low fees.
If peers requested parents, then it would be possible to forward them
onwards.
If a node receives a high-fee transaction and doesn't have the parent, it
could request the parent.
Spam protection could be handled by banning nodes which send lots of
"children" and then never having the parent to the transaction.
The rule would be that forwarding a transaction means that you have all its
parents back to transactions contained in blocks.
--001a1135ad28638669051a88b2e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <span dir=3D"=
ltr"><<a href=3D"mailto:jgarzik@gmail.com" target=3D"_blank">jgarzik@gma=
il.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"><div class=
=3D"gmail_quote">This is a good explanation but it does not address reachab=
ility.=C2=A0 TX_a, the first tx sent out on the network, presumably has ins=
ufficient fee to get mined - which also means it did not necessarily even r=
each all miners.<div><br></div><div>Simply sending out TX_b with added fee =
does not guarantee that nodes suddenly have TX_a, which they may have ignor=
ed/dropped before.<br></div></div></blockquote></div><br>When the peer adds=
both parent and child to the memory pool, it should forward both of them.<=
br><br></div><div class=3D"gmail_extra">CPFP inherently requires that nodes=
keep transactions that they have rejected due to low fees.<br><br></div><d=
iv class=3D"gmail_extra">If peers requested parents, then it would be possi=
ble to forward them onwards.<br><br></div><div class=3D"gmail_extra">If a n=
ode receives a high-fee transaction and doesn't have the parent, it cou=
ld request the parent.<br></div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">Spam protection could be handled by banning nodes whic=
h send lots of "children" and then never having the parent to the=
transaction.<br><br></div><div class=3D"gmail_extra">The rule would be tha=
t forwarding a transaction means that you have all its parents back to tran=
sactions contained in blocks.<br></div></div></div></div></div></div>
--001a1135ad28638669051a88b2e2--
|
