From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 063C2B88 for ; 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 ; Fri, 10 Jul 2015 16:28:03 +0000 (UTC) Received: by qkdv3 with SMTP id v3so14962571qkd.3 for ; 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: From: Tier Nolan 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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


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 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.

It should b= e whatever gives the highest fee.=C2=A0 In effect, child pays for parent cr= eates 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 fe= e for 250 bytes =3D 0 per byte
A&B: 0.0005 fee for 550 by= tes =3D 0.91 uBTC per byte
A&B&C: 0.0006 fee for 950 = bytes =3D 0.63uBTC per byte

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)= .

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

C: 0.0001 for 400 bytes =3D 0.25 BTC per b= yte

If that is above the threshold, then C should be adde= d.

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.

A 2 pass system could get a = reasonably efficient result.

B is 0.0005 fee for 300 byte= s =3D 1.67 uBTC per byte and is assumed to be a high value transaction.
=
The algorithm would be

Pass 1:<= br>
Process all 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.

Pass 1:
Process all non-included transactions in o= rder of BTC per byte, until block is full
=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.

=C2=A0=C2=A0=C2=A0 Otherwise, conside= r the transaction plus all non-included ancestors as a single transaction
=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),
=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
=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)

--001a113a7d021c53a7051a87db6a--