From: "Johan Torås Halseth" <johanth@gmail•com>
To: "David A. Harding" <dave@dtrt•org>
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: Wed, 30 Oct 2019 08:22:53 +0100 [thread overview]
Message-ID: <CAD3i26BkuxMyazGsQ1+ij25f3xhXUBpUTcOfgYKnY4fur5rGBw@mail.gmail.com> (raw)
In-Reply-To: <20191028171416.7owxqblz3ttsvw5r@ganymede>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
On Mon, Oct 28, 2019 at 6:16 PM David A. Harding <dave@dtrt•org> wrote:
> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
> than the default maximum mempool size in Bitcoin Core).
>
Thanks, Dave, I wasn't aware the limits would allow this many outputs. And
as your calculation shows, this opens up the potential for free relay of
large amounts of data.
We could start special casing to only allow this for "LN commitment-like"
transactions, but this would be application specific changes, and your
calculation shows that even with the BOLT2 numbers there still exists cases
with a large number of children.
We are moving forward with adding a 1 block delay to all outputs to utilize
the current carve-out rule, and the changes aren't that bad. See Joost's
post in "[PATCH] First draft of option_simplfied_commitment"
- Johan
[-- Attachment #2: Type: text/html, Size: 1549 bytes --]
next prev parent reply other threads:[~2019-10-30 7:23 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 [this message]
2019-10-27 22:54 ` David A. Harding
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=CAD3i26BkuxMyazGsQ1+ij25f3xhXUBpUTcOfgYKnY4fur5rGBw@mail.gmail.com \
--to=johanth@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
--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