From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6ADCFC000B for ; Mon, 14 Feb 2022 19:51:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5358C81763 for ; Mon, 14 Feb 2022 19:51:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRPnu4heNDwj for ; Mon, 14 Feb 2022 19:51:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6D0D7813BE for ; Mon, 14 Feb 2022 19:51:39 +0000 (UTC) Received: by mail-yb1-xb2e.google.com with SMTP id o19so49238389ybc.12 for ; Mon, 14 Feb 2022 11:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UBJPVvre5aDrM4+jPfxWX8DwPyAkDA3vFP4twqr9skw=; b=htrmfK6etL/GmBHB/aZwh/Gbw7UAW020/3HhZUCe+owaaEwTxxXD1avEqpJYZpUdIa g9SgbLyW3eMaY/bRyBIK6QlRdMK+6JiTkHWOV+vwtVC7XzNh7Age0eISQ+7Tpu3H9LEF hC+sODcTA9x3LLUNkBJivwCHlaHr3xMRgFmI4q6kKs/t3LV+vEiydCPZNIEMB4Pv1bQX JAdxMklHGOLuxrUr/GurjlmrVtsDE8JvgdidrcHRDa/5ZL+Dld4oRz2rQj8AgRNFUNcB IT/9sACm3MmaqDimrpk6xD326xHKk1bnslUAOALQaTxV/Of8aeEITMyjnn3Hj45wRzNi MNMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UBJPVvre5aDrM4+jPfxWX8DwPyAkDA3vFP4twqr9skw=; b=7OFtpS4sd8Umy65kxoItAEWEJYJbemLaxIygslHyhEYPRYNwSep7YjyRxBmW68Il4s 9Os2Igw268fVNj+53J6BsZ6mL1207Hu7L+W6CsmW/ZRLJk28tkHJWKPIKFvjcREbFWkF kJbjn3oSO7fRDkMmWA5uii626SI00mZ7pBw5u/ZIKgV3SfZMVxHKCPli5xU+Vp80zBRJ /sIxkAgrGcNd8p3YZLsa1cho56LMtybu0Wt3h+k6xPgwPGCJL2Bd8joMPQWHg3ujqYJX rFu7NrHHDBGrBhscczlQhlF7l32aXIy/pHWLMHefy2JVcspuKSgyU4ZnI92S6g4wS67C 7c8A== X-Gm-Message-State: AOAM5316233sAr1zXf6PBx+GlpkKRPBbdn59EB86wB2VQiW9mB9Gsd/1 j9OfTugQMUCDHBQA4NVT0AFPYsOwhy3KD9J0lE0qxuScKXueZw== X-Google-Smtp-Source: ABdhPJyCAsSFEFdDIWhL534e2yzXMuY76XhAkLWu0gdE6G18WUknrk0V0SRv2/liI+stmuZ/UZ8ab93lChGHcfI81Tw= X-Received: by 2002:a81:4528:: with SMTP id s40mr386953ywa.188.1644868297905; Mon, 14 Feb 2022 11:51:37 -0800 (PST) MIME-Version: 1.0 References: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com> In-Reply-To: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com> From: "James O'Beirne" Date: Mon, 14 Feb 2022 14:51:26 -0500 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="0000000000009958d205d7ffbe7b" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Thoughts on fee bumping X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 19:51:40 -0000 --0000000000009958d205d7ffbe7b Content-Type: text/plain; charset="UTF-8" > This entirely misses the network cost. Yes, sure, we can send > "diffs", but if you send enough diffs eventually you send a lot of data. The whole point of that section of the email was to consider the network cost. There are many cases for which transmitting a supplementary 1-in-1-out transaction (i.e. a sponsorship txn) is going to be more efficient from a bandwidth standpoint than rebroadcasting a potentially large txn during RBF. > > In an ideal design, special structural foresight would not be > > needed in order for a txn's feerate to be improved after broadcast. > > > > Anchor outputs specified solely for CPFP, which amount to many > > bytes of wasted chainspace, are a hack. > It's probably > > uncontroversial at this > > This has nothing to do with fee bumping, though, this is only solved > with covenants or something in that direction, not different relay > policy. My post isn't only about relay policy; it's that txn sponsors allows for fee-bumping in cases where RBF isn't possible and CPFP would be wasteful, e.g. for a tree of precomputed vault transactions or - maybe more generally - certain kinds of covenants. > How does this not also fail your above criteria of not wasting block > space? In certain cases (e.g. vault structures), using sponsorship txns to bump fees as-needed is more blockspace-efficient than including mostly-unused CPFP "anchor" outputs that pay to fee-management wallets. I'm betting there are other similar cases where CPFP anchors are included but not necessarily used, and amount to wasted blockspace. > Further, this doesn't solve pinning attacks at all. In lightning we > want to be able to *replace* something in the mempool (or see it > confirm soon, but that assumes we know exactly what transaction is in > "the" mempool). Just being able to sponsor something doesn't help if > you don't know what that thing is. When would you be trying to bump the fee on a transaction without knowing what it is? Seeing a specific transaction "stuck" in the mempool seems to be a prerequisite to bumping fees. I'm not sure what you're getting at here. --0000000000009958d205d7ffbe7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This entirely misses the network cost. Yes, sure, we = can send
> "diffs", but if you send enough diffs eventually= you send a lot of data.

The whole point of that section of the emai= l was to consider the
network cost. There are many cases for which trans= mitting a
supplementary 1-in-1-out transaction (i.e. a sponsorship txn) = is going
to be more efficient from a bandwidth standpoint than rebroadca= sting a
potentially large txn during RBF.

> > In an ideal = design, special structural foresight would not be
> > needed in or= der for a txn's feerate to be improved after broadcast.
> > > > Anchor outputs specified solely for CPFP, which amount to many<= br>> > bytes of wasted chainspace, are a hack. > It's probably=
> > uncontroversial at this
>
> This has nothing to d= o with fee bumping, though, this is only solved
> with covenants or s= omething in that direction, not different relay
> policy.

My p= ost isn't only about relay policy; it's that txn
sponsors allows= for fee-bumping in cases where RBF isn't possible and
CPFP would be= wasteful, e.g. for a tree of precomputed vault
transactions or - m= aybe more generally - certain kinds of
covenants.

> H= ow does this not also fail your above criteria of not wasting block
>= space?

In certain cases (e.g. vault structures), using sponsorship = txns to
bump fees as-needed is more blockspace-efficient than including<= br>mostly-unused CPFP "anchor" outputs that pay to fee-management= wallets.
I'm betting there are other similar cases where CPFP ancho= rs are
included but not necessarily used, and amount to wasted blockspac= e.

> Further, this doesn't solve pinning attacks at all. In l= ightning we
> want to be able to *replace* something in the mempool (= or see it
> confirm soon, but that assumes we know exactly what trans= action is in
> "the" mempool). Just being able to sponsor s= omething doesn't help if
> you don't know what that thing is.=

When would you be trying to bump the fee on a transaction withoutknowing what it is? Seeing a specific transaction "stuck" in th= e
mempool seems to be a prerequisite to bumping fees. I'm not sure w= hat
you're getting at here.
--0000000000009958d205d7ffbe7b--