Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 89797BC8 for ; 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 ; Fri, 10 Jul 2015 16:31:02 +0000 (UTC) Received: by wgjx7 with SMTP id x7so253452721wgj.2 for ; 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: References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> Date: Fri, 10 Jul 2015 12:31:01 -0400 Message-ID: From: Jeff Garzik To: Tier Nolan 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > > On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore 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
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.

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.



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, R= ichard Moore <me@ricmoo.com> wrote:
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.

It should be whatever gives the highest fee= .=C2=A0 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 combina= tions 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
<= /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).

Once A&B= are added, then C can be reconsidered on its own.=C2=A0

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.=C2=A0 If there are N tr= ansactions, 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 wou= ld be

Pass 1:
Process all transa= ctions in order of BTC per byte, until block is full
=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.

Pass 1:
Process all non-included transactions in order of BTC per byte, until bloc= k is full
=C2=A0=C2=A0=C2=A0 If the transaction's parents are either= already in the pool or a previous block, add the transaction.

=C2=A0=C2=A0=C2=A0 Otherwise, consider the transaction plus all non-i= ncluded ancestors as a single transaction
=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),
=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
=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)



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--e89a8f642beec2e470051a87e591--