Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.

From: Micha Bailey <michabailey@gmail•com>
To: "DKBryant@gmail•com" <DKBryant@gmail•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
Date: Mon, 6 Jul 2015 07:20:30 +0300	[thread overview]
Message-ID: <CAAmoQf3g_3p-+JU2bjFzv+4wAD1Y7bvQ7WAX4u8B4MdeXtmpSw@mail.gmail.com> (raw)
In-Reply-To: <CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

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 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 <bip@mattwhitlock•name
> <javascript:;>> 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 <pete@petertodd•org
> <javascript:;>> 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 <javascript:;>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5323 bytes --]