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 7B2F19F2 for ; Fri, 10 Jul 2015 17:28:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1794C12D for ; Fri, 10 Jul 2015 17:28:15 +0000 (UTC) Received: by qgef3 with SMTP id f3so82530588qge.0 for ; Fri, 10 Jul 2015 10:28:14 -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=mAjhP69wYouLdZ4/Zd/Cmt7rHSh79Z+LhEn34d4zi/w=; b=nsVl/sT4TbcE0+Bii8BMqdVyDpAgMh27ETjcvecDaJPayW0q6kcP4deHuPuEQP7zcq M13YJKM7PLb0MVLNQ/kH0CKMvmYDTR/MjONTHCq3fZoXK42+DXwAIcHerPB9+gGKv3B9 /OgNBXSK22D+pyRwQsDR2zPSYIc/Y9KoTP3fu2t9gRvw81ua93cq48pNVQbGwt0OCVKG xXkLiNGALtm8f1qPkYaj6B5aNERSQ3AXluT+4S8ud158LXCz9MZ5ieylH1hywQoZcD7f dVTpEig4BCDZTlvsrdW4tThEOv5ElRkEUid7arbwZUK09Y7hFFOqeLAYmK2WIHOp1amn VdwQ== MIME-Version: 1.0 X-Received: by 10.140.237.147 with SMTP id i141mr36969440qhc.25.1436549294292; Fri, 10 Jul 2015 10:28:14 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Fri, 10 Jul 2015 10:28:14 -0700 (PDT) In-Reply-To: References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> Date: Fri, 10 Jul 2015 18:28:14 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1135ad28638669051a88b2e2 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 17:28:15 -0000 --001a1135ad28638669051a88b2e2 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik wrote: > 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. > When the peer adds both parent and child to the memory pool, it should forward both of them. CPFP inherently requires that nodes keep transactions that they have rejected due to low fees. If peers requested parents, then it would be possible to forward them onwards. If a node receives a high-fee transaction and doesn't have the parent, it could request the parent. Spam protection could be handled by banning nodes which send lots of "children" and then never having the parent to the transaction. The rule would be that forwarding a transaction means that you have all its parents back to transactions contained in blocks. --001a1135ad28638669051a88b2e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <jgarzik@gma= il.com> wrote:
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.

When the peer adds= both parent and child to the memory pool, it should forward both of them.<= br>
CPFP inherently requires that nodes= keep transactions that they have rejected due to low fees.

If peers requested parents, then it would be possi= ble to forward them onwards.

If a n= ode receives a high-fee transaction and doesn't have the parent, it cou= ld request the parent.

Spam protection could be handled by banning nodes whic= h send lots of "children" and then never having the parent to the= transaction.

The rule would be tha= t forwarding a transaction means that you have all its parents back to tran= sactions contained in blocks.
--001a1135ad28638669051a88b2e2--