MIME-Version: 1.0
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
Precedence: list

--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">&lt;<a href=3D"mailto:tier.nolan@gmail.com" =
target=3D"_blank">tier.nolan@gmail.com</a>&gt;</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">&lt;<a href=3D"mailto:me@ricmoo.com" target=
=3D"_blank">me@ricmoo.com</a>&gt;</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&amp;B: 0.0005 fee for 550 bytes =3D 0.91 uBTC per byte<br></=
div><div>A&amp;B&amp;C: 0.0006 fee for 950 bytes =3D 0.63uBTC per byte<br><=
/div><div><br></div><div>This means that the A&amp;B combination has the be=
st fee per byte value.=C2=A0 A&amp;B should be added to the memory pool (if=
 0.91 uBTC per byte is above the threshold).<br><br></div><div>Once A&amp;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&#39;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&#39;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&#39;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--