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
|
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 063C2B88
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 16:28:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 58BE015A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 16:28:03 +0000 (UTC)
Received: by qkdv3 with SMTP id v3so14962571qkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 09:28:02 -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=I0l5ZB0tg6dte0v5HAedAyJGRJ3vDy+IqRG53j0aY3A=;
b=Vs1pQ+OLV4eDVi8bPFlb3SD/I0QfzVuaEVXGKgsSVKdcKP8Pg0NqceEdJSL+8rkqO8
EiFgSenf2IoBMQGbT3LY22FZRJKBsjj8yW0sOpaH3w2/QtL/+MiysLX0eVjHmo0zzZ+q
wZNtaeGFfpsqAVHItazKHiIeCifZoZ7btXRlG0+76K0cjgRf/vhck1roNOvU0KAXQuI4
s7XphHUaNeteq1LTLYRymqpbNOCGJLlFUdmn15Z44v6yuLmXZoLVo1pXjd5YkrmUFLXc
Oqz+RZ92VlD4J+rukkGXxRdHewD0x/3OcVfwZ8Pubr95/Yr+FE4eHPTTqXOzY2Q5NCj8
1W3w==
MIME-Version: 1.0
X-Received: by 10.140.33.227 with SMTP id j90mr34040600qgj.6.1436545682521;
Fri, 10 Jul 2015 09:28:02 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Fri, 10 Jul 2015 09:28:02 -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 17:28:02 +0100
Message-ID: <CAE-z3OV+-18VLbOfWzDnE5HWJ4436HGtC_qDFFVkFQTGyjGOVw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113a7d021c53a7051a87db6a
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 16:28:04 -0000
--001a113a7d021c53a7051a87db6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 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.
>
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 as
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)
--001a113a7d021c53a7051a87db6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <span dir=3D"ltr"><<a=
href=3D"mailto:me@ricmoo.com" target=3D"_blank">me@ricmoo.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"word-wrap:break-word"><div>I was also wondering, with CPFP, should the =
transaction fee be based on total transactions size, or the sum of each tra=
nsaction=E2=80=99s required fee? For example, a third transaction C whose u=
nconfirmed 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 ~300=
bytes, 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></blockquote><div><br></div><div>It should b=
e whatever gives the highest fee.=C2=A0 In effect, child pays for parent cr=
eates compound transactions.<br><br></div><div>A: 250 bytes, 0 fee<br></div=
><div>B: 300 bytes: 0.0005 fee<br></div><div>C: 400 bytes: 0.0001 fee<br><b=
r></div><div>There are 3 combinations to consider<br><br></div><div>A: 0 fe=
e for 250 bytes =3D 0 per byte<br></div><div>A&B: 0.0005 fee for 550 by=
tes =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 th=
e A&B combination has the best 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 i=
ts own.=C2=A0 <br><br></div><div>C: 0.0001 for 400 bytes =3D 0.25 BTC per b=
yte<br><br></div><div>If that is above the threshold, then C should be adde=
d.<br><br></div><div>In practice, it isn't possible to check every comb=
ination.=C2=A0 If there are N transactions, then checking all triple combin=
ations 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 byte=
s =3D 1.67 uBTC per byte and is assumed to be a high value transaction.<br>=
<br></div><div>The algorithm would be<br><br></div><div></div><div>Pass 1:<=
br></div><div>Process all 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></div><di=
v><br><div>Pass 1:<br></div><div>Process all non-included transactions in o=
rder of BTC per byte, until block is full<br>=C2=A0=C2=A0=C2=A0 If the tran=
saction's parents are either already in the pool or a previous block, a=
dd the transaction.<br><br></div><div>=C2=A0=C2=A0=C2=A0 Otherwise, conside=
r the transaction plus all non-included ancestors as a single transaction<b=
r></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If this combined tr=
ansaction 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 com=
bined transaction<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 drop the other transaction(s)<br></div><div><br><b=
r></div></div></div></div></div>
--001a113a7d021c53a7051a87db6a--
|
