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 74F45BA6 for ; Mon, 6 Jul 2015 04:20:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08A8A21E for ; Mon, 6 Jul 2015 04:20:31 +0000 (UTC) Received: by wgjx7 with SMTP id x7so128913576wgj.2 for ; Sun, 05 Jul 2015 21:20:30 -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=S7QYYhV9Y1mPrQsDcSw7lXeRzcDjuOQXZjkvbEBGpNU=; b=Q0/cHnk0VzjzLncY4TAe/6RyF4Qkh54M3vL2MYwYNCPdtZoSXF8rWTONo78glYCmle mUUsINiANmFEsI+v93h7gs83GVA1UzAsqfm/rg1SyCe419VnX9ZV9dd1U0HkBh7RIYU5 gxND3Czr9AGTrWdhNu/bt4fBrrNFcfIc5+9CibY44Lwjtnr/K0fCwnCla8uPF4LYSqOV 2yOhrxrxsi9HH4gMGU3Bt6VBp16LWPkbour9pnGEuSUfbIp2a588Cpwq5gAq2lAXxG1C UvNwiDaMEX8U8oB4s5cEkYA/nWBHhMX4bYikFP4mABBp/Un5hlGWDmMVteI/Gsnp47YE vuxg== MIME-Version: 1.0 X-Received: by 10.180.20.198 with SMTP id p6mr50087043wie.38.1436156430643; Sun, 05 Jul 2015 21:20:30 -0700 (PDT) Received: by 10.28.32.132 with HTTP; Sun, 5 Jul 2015 21:20:30 -0700 (PDT) In-Reply-To: References: <20150703215658.GC5916@muck> Date: Mon, 6 Jul 2015 07:20:30 +0300 Message-ID: From: Micha Bailey To: "DKBryant@gmail.com" Content-Type: multipart/alternative; boundary=bcaec53f397de3f7fc051a2d39e1 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] 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 List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 04:20:33 -0000 --bcaec53f397de3f7fc051a2d39e1 Content-Type: text/plain; charset=UTF-8 On Monday, July 6, 2015, Dan Bryant wrote: > 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. A child is a transaction that spends outputs of another transaction, the parent. The child cannot be confirmed before the parent, because the outputs being spent do not yet exist. > > 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? A transaction that is not completely signed won't be relayed, correct, and it cannot be mined. > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --bcaec53f397de3f7fc051a2d39e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, July 6, 2015, Dan Bryant <dkbryant@gmail.com> wrote:
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 pul= l
> 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.=C2=A0 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 <bip= @mattwhitlock.name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP = is
> addressing the user-facing side of this functionality. CPFP mining pol= icy
> 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&= #39;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<= br> 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.=C2=A0 If miners take the high fee "children"= ; but
ignore the low fee "parents" then the child might enter the block= chain
without the parent.=C2=A0 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?=C2=A0 This<= br> could be bad since spending the child may look good, as it might have
many confirmations, while its parent has few.

A child is a transaction that spends outputs of another transaction, the= parent. The child cannot be confirmed before the parent, because the outpu= ts being spent do not yet exist.
=C2=A0

On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete@peter= todd.org> wrote:
> "Replace-by-fee scorched-earth without child-pays-for-parent"= ;,
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> http://lists.linuxfoundation.org/pipe= rmail/bitcoin-dev/2014-April/005620.html

Very good!=C2=A0 So if I follow, RPF can work one of two ways:

In the "countermeasure" form, spender gives receiver a partially<= br> 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?=C2=A0 If they did, wouldn't they get flagge= d on
DoS code banning them from peers?

A transac= tion that is not completely signed won't be relayed, correct, and it ca= nnot be mined.


Corollary question.=C2=A0 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.=C2=A0 Whether it belongs in a BIP or a PR, its just a doc=
to outline my thoughts at this point.=C2=A0 Not burning a whole in my head,=
so may take some time.

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