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 DF95F8B4 for ; Fri, 10 Jul 2015 16:09:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B045EE for ; Fri, 10 Jul 2015 16:09:47 +0000 (UTC) Received: by igrv9 with SMTP id v9so16086184igr.1 for ; Fri, 10 Jul 2015 09:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google; h=from:content-type:subject:message-id:date:to:mime-version; bh=UNj5/vRFEMW+7IqxVq2HkTuE3zKthvaXb5gfJnpueR4=; b=Ew5/39ihm4mTWbUcOfZ1aAoHulVx4R76DVg0Y69C/piESYLZf5hUywI/KNAjwVPLdl 0qCuI40wwJsafstOyTpAnQXIW7sZpFVxunbfDxUd/CQGZdSYyaP6L493EIEUIQMRYeUv khy0Gl7IM8js2qPkp7vR/DnOFOcU7aEGRm3J8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=UNj5/vRFEMW+7IqxVq2HkTuE3zKthvaXb5gfJnpueR4=; b=eIjxx3kRLupTCH0Xc4IAcELZlhVVmGX5plUg6r1KFmRzE7xlr3MXYRBWV+AaG5da8B 630jAkd3GGKs+u1JVGQnM0NS3uKvljAiMc4HnHdCa7WnHbdsaZrSukTz/eVusr+4+USx Phtxj/DF/BfOXj8VnLwAVjhRPjaCbFyyksifzWbNlF8IrzQtGqY7ugfdHjQy4R/jvXBS 7cR2xnceecDx43ZmXuOrpaaP3mmErfycDKa/pbFR3wx+tubsfw2m7KBTfrSCm6hdnSuX 8F3Ev3qV0PwTJv7oHhk2AvjK7bpNGcufoHxnKwtNp9gNunDigmRJoa4bOiKyIvs8Y5u0 5HpQ== X-Gm-Message-State: ALoCoQnL81lXM4c9H9dmisG6T3NsX5teVwiOplogvw5Gplx39rN41tSVqCgIFqqAcIpbDo9XMhTK X-Received: by 10.107.18.10 with SMTP id a10mr6497175ioj.98.1436544587102; Fri, 10 Jul 2015 09:09:47 -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 191sm3002300iof.18.2015.07.10.09.09.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jul 2015 09:09:45 -0700 (PDT) From: Richard Moore Content-Type: multipart/alternative; boundary="Apple-Mail=_DB4351EE-A1B0-4353-9640-142F6388066D" Message-Id: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> Date: Fri, 10 Jul 2015 12:09:43 -0400 To: bitcoin-dev@lists.linuxfoundation.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) 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,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 Subject: [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:09:49 -0000 --Apple-Mail=_DB4351EE-A1B0-4353-9640-142F6388066D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 --Apple-Mail=_DB4351EE-A1B0-4353-9640-142F6388066D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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


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

= --Apple-Mail=_DB4351EE-A1B0-4353-9640-142F6388066D--