From: "David A. Harding" <dave@dtrt•org>
To: "Johan Torås Halseth" <johanth@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Date: Sun, 27 Oct 2019 12:54:02 -1000 [thread overview]
Message-ID: <20191027225402.rfajp4j6itujq5av@ganymede> (raw)
In-Reply-To: <CAD3i26AjhQ9VkCo_5y8aqZ_8YvSqKP2MCkdRv8YunjAhmmXz=Q@mail.gmail.com>
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize these limits are there for a reason though, but I'm wondering if
> we could relax them.
Johan,
I'm not sure any of the other replies to this thread addressed your
request for a reason behind the limits related to your proposal, so I
thought I'd point out that---subsequent to your posting here---a
document[1] was added to the Bitcoin Core developer wiki that I think
describes the risk of the approach you proposed:
> Free relay attack:
>
> - Create a low feerate transaction T.
>
> - Send zillions of child transactions that are slightly higher feerate
> than T until mempool is full.
>
> - Create one small transaction with feerate just higher than T’s, and
> watch T and all its children get evicted. Total fees in mempool drops
> dramatically!
>
> - Attacker just relayed (say) 300MB of data across the whole network
> but only pays small feerate on one small transaction.
The document goes on to describe at a high level how Bitcoin Core
attempts to mitigate this problem as well as other ways it tries to
optimize the mempool in order to maximize miner profit (and so ensure
that miners continue to use public transaction relay).
I hope that's helpful to you and to others in both understanding the
current state and in thinking about ways in which it might be improved.
-Dave
[1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining
Content adapted from slides by Suhas Daftuar, uploaded and formatted
by Gregory Sanders and Marco Falke.
prev parent reply other threads:[~2019-10-27 23:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 19:37 [bitcoin-dev] " Matt Corallo
2018-11-30 17:38 ` Russell O'Connor
2018-11-30 19:33 ` Matt Corallo
2018-12-02 15:08 ` Bob McElrath
2018-12-03 4:16 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-12-04 3:33 ` Rusty Russell
2019-01-07 15:18 ` Matt Corallo
2019-01-08 5:50 ` Rusty Russell
2019-01-08 14:46 ` Matt Corallo
2019-02-13 4:22 ` Rusty Russell
2019-10-24 13:49 ` Johan Torås Halseth
2019-10-24 21:25 ` Matt Corallo
2019-10-25 7:05 ` Johan Torås Halseth
2019-10-25 17:30 ` Matt Corallo
2019-10-27 19:13 ` Jeremy
2019-10-28 9:45 ` Johan Torås Halseth
2019-10-28 17:14 ` David A. Harding
2019-10-30 7:22 ` Johan Torås Halseth
2019-10-27 22:54 ` David A. Harding [this message]
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=20191027225402.rfajp4j6itujq5av@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=johanth@gmail$(echo .)com \
--cc=lightning-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