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
|
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 89797BC8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 16:31:03 +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 6D76E16B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 16:31:02 +0000 (UTC)
Received: by wgjx7 with SMTP id x7so253452721wgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 09:31:01 -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=UIcqIo1ivje+/C1Hi38gyhv7f7YeCogNHfvTSxML78Y=;
b=GQSj23Q78f7xfgG5DrrR65qibv51QKukEtVT/VmPn2GO5gqGZjeDxo1+hQ9nc/AmOj
6GA2dlUWAwXlE4DJ/q0qZAgD8wBQOEKWGM2gU5LiQKdvYojBEDNBXLSN68Z55ezoUxYY
ImYTO4pPEhj7dOmmfRFiML8AgZWetZGghZrY0I8r6j+sku8tvpoHzIye6uEac8eCsY5A
GfR9BSlF/AAyBEYcCO9n1LGVSTVuV/cf7ftYZnagBAnR7LOvjpD6XVE0FAtpgEOT8L+1
s0TtaXmKb8DlkhnxWkBhe/8T2ESdGDFv30XPzxRwxdCzMTcaIcPQnXccVPF/4KCq3ymi
FvXw==
MIME-Version: 1.0
X-Received: by 10.180.37.105 with SMTP id x9mr7511965wij.33.1436545861213;
Fri, 10 Jul 2015 09:31:01 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Fri, 10 Jul 2015 09:31:01 -0700 (PDT)
In-Reply-To: <CAE-z3OV+-18VLbOfWzDnE5HWJ4436HGtC_qDFFVkFQTGyjGOVw@mail.gmail.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
<CAE-z3OV+-18VLbOfWzDnE5HWJ4436HGtC_qDFFVkFQTGyjGOVw@mail.gmail.com>
Date: Fri, 10 Jul 2015 12:31:01 -0400
Message-ID: <CADm_WcYQLzqQLY-Dspd1jUtF9Z=_721TReoc_eKYk5JCQ4fejg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f642beec2e470051a87e591
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:31:03 -0000
--e89a8f642beec2e470051a87e591
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.
On Fri, Jul 10, 2015 at 12:28 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>
> On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me@ricmoo.com> wrote:
>
>> 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 requir=
ed 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.
>>
>
> It should be whatever gives the highest fee. In effect, child pays for
> parent creates compound transactions.
>
> A: 250 bytes, 0 fee
> B: 300 bytes: 0.0005 fee
> C: 400 bytes: 0.0001 fee
>
> There are 3 combinations to consider
>
> A: 0 fee for 250 bytes =3D 0 per byte
> A&B: 0.0005 fee for 550 bytes =3D 0.91 uBTC per byte
> A&B&C: 0.0006 fee for 950 bytes =3D 0.63uBTC per byte
>
> This means that the A&B combination has the best fee per byte value. A&B
> should be added to the memory pool (if 0.91 uBTC per byte is above the
> threshold).
>
> Once A&B are added, then C can be reconsidered on its own.
>
> C: 0.0001 for 400 bytes =3D 0.25 BTC per byte
>
> If that is above the threshold, then C should be added.
>
> In practice, it isn't possible to check every combination. If there are =
N
> transactions, then checking all triple combinations costs around N cubed.
>
> A 2 pass system could get a reasonably efficient result.
>
> B is 0.0005 fee for 300 bytes =3D 1.67 uBTC per byte and is assumed to be=
a
> high value transaction.
>
> The algorithm would be
>
> Pass 1:
> Process all transactions in order of BTC per byte, until block is full
> If the transaction's parents are either already in the pool or a
> previous block, add the transaction.
>
> Pass 1:
> Process all non-included transactions in order of BTC per byte, until
> block is full
> If the transaction's parents are either already in the pool or a
> previous block, add the transaction.
>
> Otherwise, consider the transaction plus all non-included ancestors a=
s
> a single transaction
> If this combined transaction has a higher BTC per byte than the
> lowest transaction(s),
> add the combined transaction
> drop the other transaction(s)
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--e89a8f642beec2e470051a87e591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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.</div><div><br></div><div><br></div></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 10, 2015 at 12:28 PM=
, Tier Nolan <span dir=3D"ltr"><<a href=3D"mailto:tier.nolan@gmail.com" =
target=3D"_blank">tier.nolan@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote"><span class=3D"">On Fri, Jul 10, 2015 at 5:09 PM, R=
ichard Moore <span dir=3D"ltr"><<a href=3D"mailto:me@ricmoo.com" target=
=3D"_blank">me@ricmoo.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div>I was al=
so wondering, with CPFP, should the transaction fee be based on total trans=
actions size, or the sum of each transaction=E2=80=99s required fee? For ex=
ample, 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 confirm=
ed), with each A, B and C being ~300bytes, should C=E2=80=99s transaction f=
ee 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></blockq=
uote><div><br></div></span><div>It should be whatever gives the highest fee=
.=C2=A0 In effect, child pays for parent creates compound transactions.<br>=
<br></div><div>A: 250 bytes, 0 fee<br></div><div>B: 300 bytes: 0.0005 fee<b=
r></div><div>C: 400 bytes: 0.0001 fee<br><br></div><div>There are 3 combina=
tions to consider<br><br></div><div>A: 0 fee for 250 bytes =3D 0 per byte<b=
r></div><div>A&B: 0.0005 fee for 550 bytes =3D 0.91 uBTC per byte<br></=
div><div>A&B&C: 0.0006 fee for 950 bytes =3D 0.63uBTC per byte<br><=
/div><div><br></div><div>This means that the A&B combination has the be=
st fee per byte value.=C2=A0 A&B should be added to the memory pool (if=
0.91 uBTC per byte is above the threshold).<br><br></div><div>Once A&B=
are added, then C can be reconsidered on its own.=C2=A0 <br><br></div><div=
>C: 0.0001 for 400 bytes =3D 0.25 BTC per byte<br><br></div><div>If that is=
above the threshold, then C should be added.<br><br></div><div>In practice=
, it isn't possible to check every combination.=C2=A0 If there are N tr=
ansactions, then checking all triple combinations costs around N cubed.<br>=
<br></div><div>A 2 pass system could get a reasonably efficient result.<br>=
<br></div><div>B is 0.0005 fee for 300 bytes =3D 1.67 uBTC per byte and is =
assumed to be a high value transaction.<br><br></div><div>The algorithm wou=
ld be<br><br></div><div></div><div>Pass 1:<br></div><div>Process all transa=
ctions in order of BTC per byte, until block is full<br>=C2=A0=C2=A0=C2=A0 =
If the transaction's parents are either already in the pool or a previo=
us block, add the transaction.<br></div><div><br><div>Pass 1:<br></div><div=
>Process all non-included transactions in order of BTC per byte, until bloc=
k is full<br>=C2=A0=C2=A0=C2=A0 If the transaction's parents are either=
already in the pool or a previous block, add the transaction.<br><br></div=
><div>=C2=A0=C2=A0=C2=A0 Otherwise, consider the transaction plus all non-i=
ncluded ancestors as a single transaction<br></div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 If this combined transaction has a higher BTC per =
byte than the lowest transaction(s), <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add the combined transaction<br></div><di=
v>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 drop t=
he other transaction(s)<br></div><div><br><br></div></div></div></div></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>
--e89a8f642beec2e470051a87e591--
|
