From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4CFBEC000B for ; Tue, 15 Jun 2021 03:09:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 269E560746 for ; Tue, 15 Jun 2021 03:09:08 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNWWORg3PHKn for ; Tue, 15 Jun 2021 03:09:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by smtp3.osuosl.org (Postfix) with ESMTPS id A1FD8600CA for ; Tue, 15 Jun 2021 03:09:06 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id x24so18846108lfr.10 for ; Mon, 14 Jun 2021 20:09:06 -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=h359UEd3KkDeu01cvx91+IUKUTK+Rni6Gm31WDbX7Go=; b=TtHQ++wUTKAU6vuFX4uhYaDYy3Id6t5RpgmHvJ6w5K+s/RcI+R49Ax0E9ZEcihqCK8 rGds7sxTfCllYfbBQTZxZMzvaK9qGCkg9t38s/aW7Ficn9MZZrItwmYSWQ7K6xD81NMS L0lyp/i9I5Tq1GclETcVTT8JvJUL9tlf7uWsk2y5+Al/uR8b2kiwWeVSndBiLkMKcS2Z KCewAHpibFfYCfo07CQlqGAqHA7JyVlfPtR5CW8Yr1RXY+sFSubYOVKD4/Gnr4/wTNnY FXhaSs0MlUtEQ4V7w33ZRLuMbd0ulzzmy+oGI6v7Fa/hnEwPd9f8PPH7BkJEHu9yxKE8 T0Fg== 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=h359UEd3KkDeu01cvx91+IUKUTK+Rni6Gm31WDbX7Go=; b=RwFzkj9BReaCvN61MjyRF3Lt3AJO4xuupJc3XarDppiM0xQ6p4nWfHQJBJL2dMktR1 OWsK0kB7uu68musE33mKNBZfMmwU5EBAaduZbuYDpoc+7SAUOys/AYRWbbVrhUhyn79y by1tLiJtSvMktkMczGKSavgYJNHiVet+ETx3hQYZCL4su+Jsr8O4Py+8ak3XkDbDXSFh MYGl3pXqbeZNZgqVzIX9aOgF5moNUIdcPVWRXlUvwtog6NdFvowk22ssIA6tuQRjRSQj CgqwZ3o+amltm4ekDEpUPX0bOvZ83ip3v545CRUyxFb5Z4ZvtK4UqJQrBmFdDzmAjjQI LOPg== X-Gm-Message-State: AOAM532l7wbsQ2x3dUjFcV0aJYxOYcCjG/iF33h6FlQ7bxZezjqJzh9e M4viJGKNHe+c6luejPBnpFmpFi6mgm4X3eZ19SA= X-Google-Smtp-Source: ABdhPJxiplaaLzWkDhjoozEhUTkroPT2ZGbCV1ukTGLOmhHiy4TegZlaGaciWCEuxmxp2BhqUIUb1JD6w4VHfYDPvVk= X-Received: by 2002:a05:6512:332c:: with SMTP id l12mr15183014lfe.454.1623726544271; Mon, 14 Jun 2021 20:09:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Tue, 15 Jun 2021 13:08:37 +1000 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="000000000000e23df205c4c54b23" X-Mailman-Approved-At: Tue, 15 Jun 2021 07:33:23 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent 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: Tue, 15 Jun 2021 03:09:08 -0000 --000000000000e23df205c4c54b23 Content-Type: text/plain; charset="UTF-8" On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier wrote: > > > On Tue, 15 Jun 2021 at 02:47, Antoine Riard > wrote: > >> > This makes a lot of sense as it matches the semantics of what we are >> trying >> to achieve: allow the owner of an output (whether an individual or group) >> to reduce that output's value to pay a higher fee. >> >> Note, I think you're still struggling with some trust issue that anchor >> upgrade is at least eliminating for LN, namely the pre-agreement among a >> group of signers about the effective feerate to use at some unknown time >> point in the future. If you authorize your counterparty for a broadcast at >> feerate X, how do you prevent a broadcast at feerate Y, where Y is far >> under X, thus maliciously burning a lot of your fee-bumping reserve ? >> >> Of course, one mitigation is to make a contribution to a common >> fee-bumping output reserve proportional to what has been contributed as a >> funding collateral. Thus disincentivizing misuse of the common fee-bumping >> reserve in a game-theoretical way. But if you take the example of a LN >> channel, you're now running into another issue. Off-chain balances might >> fluctuate in a way that most of the time, your fee-bumping reserve >> contribution is out-of-proportion with your balance amounts to protect ? >> And as such enduring some significant timevalue bleeding on your >> fee-bumping reserve. >> >> Single-party managed fee-bumping reserve doesn't seem to suffer from this >> drawback ? >> > > I claim that what I am suggesting is a single-party managed fee-bumping > system that solves all fee-bumping requirements of lightning without > needing external utxos and without additional interaction or fee > pre-agreement between parties. On the commit tx you have your balance going > exclusively towards you which you can unilaterally reduce to increase the > fee up to whatever threshold you want. With a HTLC or PTLC you also always > have a tx with an output that you can unilaterally drain to bump fee > (either the hltc-success or htlc-timeout). Are you saying that there are > protocols where this would require pre-arrangement or are you saying that > it would require pre-arrangement in lightning for some reason I don't see? > Ok now I see what I am missing: We don't really know who owns certain outputs in lightning until the most-recent-state-enforcement mechanism has done its job. i.e. the outputs are 2-of-2s up until that has been resolved. I was operating on some simplified imaginary lightning. Indeed this makes the proposal far less attractive and does require interaction and pre-agreement. This complexity here makes it worse than just keeping external fee-bumping utxos around (as undesirable as this is). Thanks for helping me figure this out. LL --000000000000e23df205c4c54b23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 15 Jun 2021 at 10:59, Lloyd F= ournier <lloyd.fourn@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, 15 Jun 2021 at 02:47, Antoine = Riard <anto= ine.riard@gmail.com> wrote:
> This makes a lot of sense as it ma= tches the semantics of what we are trying
to achieve: allow the owner of= an output (whether an individual or group)
to reduce that output's = value to pay a higher fee.

Note, I think you're still struggling= with some trust issue that anchor upgrade is at least eliminating for LN, = namely the pre-agreement among a group of signers about the effective feera= te to use at some unknown time point in the future. If you authorize your c= ounterparty for a broadcast at feerate X, how do you prevent a broadcast at= feerate Y, where Y is far under X, thus maliciously burning a lot of your = fee-bumping reserve ?

Of course, one mitigation is to make a contrib= ution to a common fee-bumping output reserve proportional to what has been = contributed as a funding collateral. Thus disincentivizing misuse of the co= mmon fee-bumping reserve in a game-theoretical way. But if you take the exa= mple of a LN channel, you're now running into another issue. Off-chain = balances might fluctuate in a way that most of the time, your fee-bumping r= eserve contribution is out-of-proportion with your balance amounts to prote= ct ? And as such enduring some significant timevalue bleeding on your fee-b= umping reserve.

Single-party managed fee-bumping reserve doesn't= seem to suffer from this drawback ?

I claim that what I am suggesting is a single-party ma= naged fee-bumping system=20 that solves all fee-bumping requirements of lightning without needing exter= nal utxos and without additional interaction or fee pre-agreement between p= arties. On the commit tx you have your balance going exclusively towards yo= u which you can unilaterally reduce to increase the fee up to whatever thre= shold you want. With a HTLC or PTLC you also always have a tx with an outpu= t that you can unilaterally drain to bump fee (either the hltc-success or h= tlc-timeout). Are you saying that there are protocols where this would requ= ire pre-arrangement or are you saying that it would require pre-arrangement= in lightning for some reason I don't see?

Ok now I see what I am missing: We don't really know wh= o owns certain outputs in lightning until the most-recent-state-enforcement= mechanism has done its job. i.e. the outputs are 2-of-2s up until that has= been resolved. I was operating on some simplified imaginary lightning. In= deed this makes the proposal far less attractive and does require interacti= on and pre-agreement. This complexity here makes it worse than just keeping= external fee-bumping utxos around (as undesirable as this is).=20 Thanks for helping me figure this out.

LL
<= /div>

--000000000000e23df205c4c54b23--