From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 00C16B2F; Wed, 30 Oct 2019 07:23:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 287BA8A; Wed, 30 Oct 2019 07:23:06 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id m7so1462167lji.2; Wed, 30 Oct 2019 00:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cbJ0gJacAV3wrKjYZQX+uGPiH+AnIrGK/8EcfIXBgjM=; b=CMgvQr0zKFP7PpaMK8XEPFbh8x8JUR0FjdRNMlcZSh7y/bT2cWtIGQTzurGo4fBE7P +duu7ubRNjYcWfEoYnZgrNJ885QvsmSiLJFv1QOJJFn6qd9TVMd5/Yb3GHY0vgUJnM56 HqsYHYiBiAyB/CGAnErFEqkiwdsJ4BGzmn5xpN1LSGbusA3PzKFXwcPRCfMx0zbbmPDq itEgyRZR+OpaPUhE7gB7HKrHONg87Ri8vT0/DEI3KL6wPKz2p5RYD3BsyTSvb//ilN3C 6suVByOTgWpWF5vZIzoiG1vwVDTijWHbPGloMSKSbn180iUCC6zUqucMyjN40YYQAZlS JeFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cbJ0gJacAV3wrKjYZQX+uGPiH+AnIrGK/8EcfIXBgjM=; b=FXfSg7kLDx1wZWa/FtBpq4o2LfgmatwDPvcGad8ofvXv2oYZlll9jrXr4bilvg9QyJ 4v3sTZP9BOdMUPCOltvJkQvIk/y5/WyyZUtTjk/wfU53XrO/KBKgkFg7o5VqhNFOhDhD Ea+TyD5DKmmZlIsa+/Bb28ujIcWWhyOPa+GJtX7krfat+iKm/qoqeTXzPIkWTtBYLCq8 DGpRoFFRl3vIvEYxW3BXZ8QauYbIfpt+cRhor9QpuVaNkeMSLLRW5DkJAN02fKOhUCK4 qrCpIvzng5aZm2y77EMSPoiyWA60StlT6zFE4ztS64idMSgNQqhhLI4GNTCOwaEqvPbx Yo0Q== X-Gm-Message-State: APjAAAXHA+Oo/QBSzHk4cI3KNrrfYmAjNWNqIdtabiWVK7FRdKHf5kw5 c58xncxEk+VtUjlF+8Ty84laW2jyQaq2qMcGAP0= X-Google-Smtp-Source: APXvYqxmDBSCuOmbr7RKPPHNKtNmX97FmXGh9/3j0FBjDTUY4R5/CiANxePdieMhRWLIBP87j72JvlHjxSG/LSGTV/c= X-Received: by 2002:a2e:3612:: with SMTP id d18mr5702976lja.222.1572420184308; Wed, 30 Oct 2019 00:23:04 -0700 (PDT) MIME-Version: 1.0 References: <6728FF51-E378-4AED-99BA-ECB83688AA9C@mattcorallo.com> <20191028171416.7owxqblz3ttsvw5r@ganymede> In-Reply-To: <20191028171416.7owxqblz3ttsvw5r@ganymede> From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= Date: Wed, 30 Oct 2019 08:22:53 +0100 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="0000000000008602be05961b9a29" X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 02 Nov 2019 15:20:10 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 07:23:09 -0000 --0000000000008602be05961b9a29 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 28, 2019 at 6:16 PM David A. Harding 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 --0000000000008602be05961b9a29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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).=C2=A0 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 th= is many outputs. And as your calculation shows, this opens up the potential= for free relay of large amounts of data.=C2=A0

We= could start special casing to only allow this for "LN commitment-like= " transactions, but this would be application specific changes, and yo= ur calculation shows that even with the BOLT2 numbers there still exists ca= ses 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 i= n "[PATCH] First draft of option_simplfied_commitment"
=
- Johan
--0000000000008602be05961b9a29--