public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2015-07-06  4:20 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
2015-07-06  4:20       ` Micha Bailey [this message]
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=CAAmoQf3g_3p-+JU2bjFzv+4wAD1Y7bvQ7WAX4u8B4MdeXtmpSw@mail.gmail.com \
    --to=michabailey@gmail.com \
    --cc=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