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.
next prev parent 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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