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

[Micha Bailey]

On Monday, July 6, 2015, Dan Bryant <dkbryant at 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 at 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 at 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 at lists.linuxfoundation.org <javascript:;>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150706/8c82606a/attachment.html>