MIME-Version: 1.0
In-Reply-To: <20150703215658.GC5916@muck>
References: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
	<CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com>
	<20150703215658.GC5916@muck>
Date: Sun, 5 Jul 2015 23:14:14 -0500
Message-ID: <CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com>
From: Dan Bryant <dkbryant@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed
 transactions with a bounty.
Precedence: list
Reply-To: DKBryant@gmail.com

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> 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 <pete@petertodd.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/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.