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 BEC34BD1 for ; Fri, 10 Jul 2015 17:51:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3EC115B for ; Fri, 10 Jul 2015 17:51:01 +0000 (UTC) Received: by wgjx7 with SMTP id x7so254933491wgj.2 for ; Fri, 10 Jul 2015 10:51:00 -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=409L2nX6H7pzUzFm/yUlfLk4urEi+ktfAE54Yn5/Z8E=; b=rf9nWCeTrFRM6e2For5S+OVISdDyChEUqDW8lmOE0OdnLqpg4KfT5ilv+gT4fQNMPR P+m4PFmMC41+U8XWZXtRlK/nlPCVCv6xTChywx6APQEV9fH+DBz4Vka17n9TvlZfogMZ 2zf7Crh2MM0/Kb6ta85KhhfbAT0vSi7vyWT6z64iDiAIMEfQSFlmtT2MHrPIBlu8xg0E awY8oyb+0ynqruofkbTn51Z6xVDuPkw/0FvUB65rxxvBTYW+Kv5xlsdCrk/bo7WBxMQS LUrtlGGkvaM5KrmP3S35J3cwyUbD3AoJSnv6lMDA7gwtb9Jk4axseU/ORqOkWhDjKq/P y6TA== MIME-Version: 1.0 X-Received: by 10.194.121.100 with SMTP id lj4mr42321854wjb.104.1436550660229; Fri, 10 Jul 2015 10:51:00 -0700 (PDT) Received: by 10.180.168.34 with HTTP; Fri, 10 Jul 2015 10:51:00 -0700 (PDT) In-Reply-To: <559FFAB3.2010309@openbitcoinprivacyproject.org> References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> <559FFAB3.2010309@openbitcoinprivacyproject.org> Date: Fri, 10 Jul 2015 13:51:00 -0400 Message-ID: From: Alex Morcos To: Justus Ranvier Content-Type: multipart/alternative; boundary=089e011777b5ce0f12051a8903b7 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 17:51:02 -0000 --089e011777b5ce0f12051a8903b7 Content-Type: text/plain; charset=UTF-8 I think the biggest problem with merging CPFP right now is that at least in its current implementation it is not efficient enough in certain situations,. On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier < justus@openbitcoinprivacyproject.org> wrote: > On 07/10/2015 11:31 AM, 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. > > I'm not sure why that's actually a problem. > > CPFP is initiated by the recipient of the parent transaction, and so if > the recipient is creating this transaction in the first place they must > have a copy of the parent transaction which can/should broadcast at the > same time. > > If the child reaches a CPFP miner, then presumably the parents made it > as well (any path between the sender and the miner that doesn't relay > the parent should reject the child as trying to spend non-existent > coins), so both of the transactions can be mined at the same time. > > -- > Justus Ranvier > Open Bitcoin Privacy Project > http://www.openbitcoinprivacyproject.org/ > justus@openbitcoinprivacyproject.org > E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e011777b5ce0f12051a8903b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the biggest problem with merging CPFP right now is= that at least in its current implementation it is not efficient enough in = certain situations,.

On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier = <justus@openbitcoinprivacyproject.org> wrote:
On 07/10/2015 11:31 AM, Jeff Garzik w= rote:
> This is a good explanation but it does not address reachability.=C2=A0= TX_a, the
> first tx sent out on the network, presumably has insufficient fee to g= et
> 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.

I'm not sure why that's actually a problem.

CPFP is initiated by the recipient of the parent transaction, and so if
the recipient is creating this transaction in the first place they must
have a copy of the parent transaction which can/should broadcast at the
same time.

If the child reaches a CPFP miner, then presumably the parents made it
as well (any path between the sender and the miner that doesn't relay the parent should reject the child as trying to spend non-existent
coins), so both of the transactions can be mined at the same time.

--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinp= rivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623

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


--089e011777b5ce0f12051a8903b7--