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 DC384B88 for ; Fri, 10 Jul 2015 16:25:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 399FB158 for ; Fri, 10 Jul 2015 16:25:28 +0000 (UTC) Received: by iecvh10 with SMTP id vh10so199934645iec.3 for ; Fri, 10 Jul 2015 09:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5Z62284FBiAxAgZkyXsaWys+ZHc9265iqO5Cuas6PlU=; b=AXomgl5Bg2lKrkPIvIZSB5FM6Mv4cY22znFYg7qMh+gXCCzgoYGZ0bBR+8WZTeuvgs FqgCdaD8ntjdCvgw17MtARABLLbRKRZd9qSSPV82Ad2aRoM/yM7c3f271YBd1H3PKJT0 E2k8ufDJPDl6RjyA6zdwyRGNNRiiVv0bnJ7JM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5Z62284FBiAxAgZkyXsaWys+ZHc9265iqO5Cuas6PlU=; b=ZQYXBM/UYEROyH9eRIDln67Se98XjO5dsTuKdRxlnesarnJ6T8OS9bH/TNX/ehDFRT rjhe/mSHKRJeCXMKNv6YymPVypBu+TrAPAaTdnrHPnsvz3qkSGHEear1A+Pc7hLt6Ym+ J3eHZkhGyEsQ943oKPdQ/aJ2aqViyrdD1yvvJQjois6rH4gIxBdCLdSs2XHLfVx+esKf Sql3cMA7r9cTUUpNz9yccS9rke2Y8vNKK/sJQKekuQ+cyOS0Uh0vBPsacBnRvdssRwdF fdsxYFPrVnNUSMv9lBWUuO7Rb7IsRGNvzcWm0+7LUIGS2OGnaPs2aRKlpGSNY3HGfRQi ZFVg== X-Gm-Message-State: ALoCoQmKjIFUYJBCkjgCHP/nAHeQKLMp237u+OyqzWqt9ZnnA3BlH8JEqiB0QVFEL87nFkV5bwZC X-Received: by 10.50.136.134 with SMTP id qa6mr4338788igb.26.1436545527675; Fri, 10 Jul 2015 09:25:27 -0700 (PDT) Received: from [192.168.2.79] (69-196-189-7.dsl.teksavvy.com. [69.196.189.7]) by smtp.gmail.com with ESMTPSA id g12sm6766746ioe.28.2015.07.10.09.25.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jul 2015 09:25:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Richard Moore In-Reply-To: Date: Fri, 10 Jul 2015 12:25:20 -0400 Message-Id: <837A1D9C-FD4E-4DF7-BE6B-4C90EB07C0A7@ricmoo.com> References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> To: Jeff Garzik X-Mailer: Apple Mail (2.2102) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, MIME_QP_LONG_LINE, 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:25:30 -0000 --Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By ignored, do you mean the nodes/miners didn=E2=80=99t even include the = low fee transaction in their memory pools, so would no longer have = access to it? If a node decides to not include it in its memory pool for = this reason, I guess it won=E2=80=99t send out any INV messages either? Could the broadcaster of TX_b rebroadcast TX_a? Then I guess any node = that did add it to its memory pool would realize it=E2=80=99s not new = and not rebroadcast it to those who didn=E2=80=99t, so it won=E2=80=99t = propagate=E2=80=A6 Although, after receiving the orphan transaction = TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish = time to prevent further DoS vectors)? Assuming the sender of TX_b has a = copy of TX_a=E2=80=A6 > On Jul 10, 2015, at 12:13 PM, Jeff Garzik wrote: >=20 > CPFP is interesting, but it does not fully cover the case it is trying = to address: If TX_a goes out without sufficient fee, sending out a new = TX_b will not help TX_a suddenly reach nodes/miners that ignored TX_a. >=20 >=20 > On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore > wrote: > Hey guys, >=20 > With all the recent congestion and discussion regarding FSS-RBF, I was = wondering if there good reasons not to have CPFP as a default policy? Or = is it? >=20 > 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 = required 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. >=20 > I tried to test it out a few days ago, sending 0.0008 btc without any = fee, then that utxo into another transaction w/ 0.0001 btc. It still = hasn=E2=80=99t confirmed, which could be any of: a) CPFP doesn=E2=80=99t = have enough hash power, b) the amounts are too small, c) the coins are = too new, d) the fee should have actually been 0.0002 btc, e) the = congestion is just too great; or some combination. >=20 > Just curious as whatnot=E2=80=A6 >=20 > Thanks, > RicMoo >=20 > = .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2= =B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8= =C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA> >=20 > Richard Moore ~ Founder > Genetic Mistakes Software inc. > phone: (778) 882-6125 > email: ricmoo@geneticmistakes.com > www: http://GeneticMistakes.com >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 >=20 = .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2= =B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8= =C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes.com www: http://GeneticMistakes.com --Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 By ignored, do you mean the nodes/miners didn=E2=80=99t even = include the low fee transaction in their memory pools, so would no = longer have access to it? If a node decides to not include it in its = memory pool for this reason, I guess it won=E2=80=99t send out any INV = messages either?

Could= the broadcaster of TX_b rebroadcast TX_a? Then I guess any node that = did add it to its memory pool would realize it=E2=80=99s not new and not = rebroadcast it to those who didn=E2=80=99t, so it won=E2=80=99t = propagate=E2=80=A6 Although, after receiving the orphan transaction = TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish = time to prevent further DoS vectors)? Assuming the sender of TX_b has a = copy of TX_a=E2=80=A6


On Jul 10, 2015, at 12:13 PM, Jeff Garzik <jgarzik@gmail.com> = wrote:

CPFP is interesting, but it does not fully cover = the case it is trying to address:   If TX_a goes out without = sufficient fee, sending out a new TX_b will not help TX_a suddenly reach = nodes/miners that ignored TX_a.


On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore = <me@ricmoo.com> wrote:
Hey = guys,

With all = the recent congestion and discussion regarding FSS-RBF, I was wondering = if there good reasons not to have CPFP as a default policy? Or is = it?

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

I tried to test it out a few days ago, sending 0.0008 btc = without any fee, then that utxo into another transaction w/ 0.0001 btc. = It still hasn=E2=80=99t confirmed, which could be any of: a) CPFP = doesn=E2=80=99t have enough hash power, b) the amounts are too small, c) = the coins are too new, d) the fee should have actually been 0.0002 btc, = e) the congestion is just too great; or some combination.

Just curious as = whatnot=E2=80=A6

Thanks,
RicMoo

.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7= .=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2= =B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>

Richard Moore ~ Founder
Genetic = Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2= =B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7= .=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>

Richard Moore ~ Founder
Genetic = Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com

= --Apple-Mail=_D04FDE35-E388-4A7A-BCB0-90716FC08DEE--