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 9F439BA2 for ; Mon, 6 Jul 2015 04:14:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD88B1FD for ; Mon, 6 Jul 2015 04:14:14 +0000 (UTC) Received: by oiaf66 with SMTP id f66so77886417oia.3 for ; Sun, 05 Jul 2015 21:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=h+Q82bsShOgOq1FNW1tRoUPX5G3hQfyfmXq57AFyf+U=; b=Sz4/F+HggEqrdI/V8/6qj/CowAxDpSNhl9Zz5mZcWTH7P+gqqjqIWvFYkU+Z3+cmF5 AXUyRf2CCPOh92AESzz6xccQ5k3ora8WSxm5q+3ZnHW5XOXZpUDVQsdGOvsLpx0U6bBP b1KKVQndZ0cvmG6Sc20iT356JNAzRJ5ycJzskLX6oYvQ6rHYpR+wbhmV9c0djDEzJOP+ Pxvx4JVdZ7TlF5KdqcUPwNj6Y68sddzWvndSD27XynsEQXrW7L9ZMwNbIBSKxhls/WMq IhRSU8sIWu88RV1YbXDnpQ6cFDdYTOyX6BbGPvBcFi0gtrGirOMDLS4Qxt4wubN+JjNJ G86g== MIME-Version: 1.0 X-Received: by 10.182.134.130 with SMTP id pk2mr47572365obb.4.1436156054123; Sun, 05 Jul 2015 21:14:14 -0700 (PDT) Received: by 10.76.69.229 with HTTP; Sun, 5 Jul 2015 21:14:14 -0700 (PDT) In-Reply-To: <20150703215658.GC5916@muck> References: <20150703215658.GC5916@muck> Date: Sun, 5 Jul 2015 23:14:14 -0500 Message-ID: From: Dan Bryant To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: DKBryant@gmail.com List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 04:14:15 -0000 On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: > This is called child pays for parent and there is a three year old pull > request implementing it: > > https://github.com/bitcoin/bitcoin/pull/1647 Understood... When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX selection was already being done by miners, but I see now that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. Perhaps the BIP66 orphan block chain shows that some miners may not always be counted on to ensure that all TX stuffed in a block have dependencies met. Certainly not until the PR1647 is fully merged and deployed. On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock wrote: > PR#1647 only addresses miner policy, though, right? I believe the BIP is > addressing the user-facing side of this functionality. CPFP mining policy > does very little good if wallets don't offer any way for users to goose up > incoming transactions. On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: > The points regarding sweep transaction UI is out of scope for a BIP I'm > afraid. I suggest talking with wallet authors, and if agreement can be > found writing a pull request. Yes... although I certainly admit, I didn't know about CPFP or I would have called it out as a requirement for this UI enhancement request. I'll see if I can't get some wallet authors interested in this as a feature enhancement when PR1647 commits. Perhaps there are risks raised if CPFP is not enabled but these sweep tx enter the mempool. If miners take the high fee "children" but ignore the low fee "parents" then the child might enter the blockchain without the parent. If miners were light on block validation, wouldn't it be possible that the child may go forward with many confirmations, while the parent patiently waits in the mempool? This could be bad since spending the child may look good, as it might have many confirmations, while its parent has few. On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd wrote: > "Replace-by-fee scorched-earth without child-pays-for-parent", > Peter Todd, Bitcoin-development mailing list, Apr 28th 2014 > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html Very good! So if I follow, RPF can work one of two ways: In the "countermeasure" form, spender gives receiver a partially signed "countermeasure" transactions with juiced up fees. In the "anyonecanpay" form, spender signs the transaction with ANYONECANPAY bit allowing the reviver to add fees at will. One question I did have about RBF is this.. Is it correct to presume that the spender doesn't send the incomplete "countermeasure" transaction to the network? If they did, wouldn't they get flagged on DoS code banning them from peers? Corollary question. If the "countermeasure" transaction is not broadcast, is it sent to the receiver via back channel (email, etc) I'll try to clean up the draft BIP to include CPFP dependencies and RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc to outline my thoughts at this point. Not burning a whole in my head, so may take some time. Thx.