public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dan Bryant <dkbryant@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
Date: Sun, 5 Jul 2015 23:14:14 -0500	[thread overview]
Message-ID: <CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com> (raw)
In-Reply-To: <20150703215658.GC5916@muck>

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.


  reply	other threads:[~2015-07-06  4:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02  4:44 [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty Dan Bryant
2015-07-02  4:52 ` Mark Friedenbach
2015-07-02  4:57   ` Matt Whitlock
2015-07-02 13:13     ` Tier Nolan
2015-07-03 21:56   ` Peter Todd
2015-07-06  4:14     ` Dan Bryant [this message]
2015-07-06  4:20       ` Micha Bailey
2015-07-06  4:24       ` Luke Dashjr
2015-07-09  6:17         ` Aaron Voisine
2015-07-09  6:22           ` Luke Dashjr
2015-07-09  7:19             ` Dan Bryant
2015-07-15  8:26       ` Dan Bryant
2015-08-26 15:28         ` Aaron Voisine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com' \
    --to=dkbryant@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox