path: root/61/7de02974264d309009c9c7e43bdfa115c23fba

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 31A6BC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 00:59:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 205F383CA6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 00:59:42 +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 yXTSEklr2BP0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 00:59:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [IPv6:2a00:1450:4864:20::12e])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 1647483C9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 00:59:41 +0000 (UTC)
Received: by mail-lf1-x12e.google.com with SMTP id j2so23905107lfg.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 17:59:40 -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=d1K1ZfWSloP6/xgwzBpbV8RKB1W4BFvyq2+iTZAkxA4=;
 b=p5N6DrM6I8FiIZDspBYmQp2ZfU8B523aA2fYgqRESymTLcv6O+RgmihxqdJ94rnjmY
 6lcmpi+317q/Wldc/LWune0wZW1Mqnza7dJbxKifQP4T6+dOb7xsA7ytshApenhGMuNe
 YZwh7C+HkH0P/oKrFX02oqFa8uJxpsfGbe3hlUQzJoMmKwKAXORUh6ESrJXdZaEnzomu
 lxdYFdImFOdCMbgDK1xSUXkhTTKDTaPvxtreSRkXddsxH0EGQNTj+b5rVOvJag6UA8w9
 FHMXa7SCXpXifDXoIc34+c3nqUT2eLu2728Sz+Gm+P0/PK1s6P5QmbpzfKLRFxokcYtW
 7dgQ==
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=d1K1ZfWSloP6/xgwzBpbV8RKB1W4BFvyq2+iTZAkxA4=;
 b=Q+QZ+a/wmqgjuj7btEk/Deg6AzOdT3coT7qEI9aUlPeLWWzDmRecyI4yPLGjiWSGvT
 22iHm0GT/ApXZ+OwCsM3VH6gSevhQSDO9PFQmLv1CxARli50xJrZA0v2d9Oy7eqRmHiN
 qb+BDrBU8/XzbtZQDOjD5FCekEQi8yaThcMrBjA69mhs1YzQ1O+4RT7R4h3RXOiz6D52
 LAM8DTmvrumawWeiVm6a4VRB4fSGPDBcfSGaQyAfSf8ar0N+gIoE+GR+ulkQ/GOJYytX
 x7RPVSRxklOGrzaeEdDkRA1lsEQY+tsTslM7wi18ZOicOjt8rXeOg2ofOak1agm2r/z1
 XLJQ==
X-Gm-Message-State: AOAM533n8FRrU1Xpxk/SxwpWJSP3DnIMrvnjFBPwWfqXv5JgT0pENJI4
 JApe2TTeS8u9ttqaTec6ZcQRWV9t2Nqf+SAJEw8=
X-Google-Smtp-Source: ABdhPJymRvqluYv/Jjsr5jyzW2/WWuKYT6weAEuroYFVgv9rVUqW1QrQ5qCoBicLArd05azbf02zFKgVnYtFU5rBKL0=
X-Received: by 2002:a19:c50c:: with SMTP id w12mr227766lfe.461.1623718778960; 
 Mon, 14 Jun 2021 17:59:38 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FvLb=N5Qygs+dPmh1o9QCwXj8RoznF5n47opOq7CG_0g@mail.gmail.com>
 <CAH5Bsr2gmqqS1LWuT679vzOEywo=gCdNdOX-Jb9aFFb=EPZcHg@mail.gmail.com>
 <CALZpt+Hj-KdiuQueAhkeTwzJvu5Wo9zdBQ39aZGrSmjJvgbkDQ@mail.gmail.com>
 <CAH5Bsr0V6r3+GsDg=CbDshj=QnpAr+saXftG_pazkWvL=m-W3g@mail.gmail.com>
 <CALZpt+E09jViG0owWpSWBoG5rjk_=HdMgQisp_1DsBEKBq-D2w@mail.gmail.com>
In-Reply-To: <CALZpt+E09jViG0owWpSWBoG5rjk_=HdMgQisp_1DsBEKBq-D2w@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 15 Jun 2021 10:59:12 +1000
Message-ID: <CAH5Bsr1NxM6WcpagwpmFC=Nn3tzK+H8n-Vx1_ObMGEejnD4SjA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000009019105c4c37d55"
X-Mailman-Approved-At: Tue, 15 Jun 2021 01:44:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2021 00:59:42 -0000

--00000000000009019105c4c37d55
Content-Type: text/plain; charset="UTF-8"

On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard@gmail.com> 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?

To further emphasise the generality of this idea you can easily imagine a
world where this is enabled on all Bitcoin transactions (of course you have
to stomach tx malleability -- a bit more palatable with ANYPREVOUT
everywhere). Even for a normal wallet-to-wallet payment the receiver could
efficiently increase the tx fee by making a signature under the key of
their output and replacing the original tx without interacting with the
sender who actually provided the funds for the payment.

Cheers,

LL

--00000000000009019105c4c37d55
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, 15 Jun 2021 at 02:47, Antoine=
 Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">ant=
oine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">&gt; This makes a lot of sense as it m=
atches the semantics of what we are trying<br>to achieve: allow the owner o=
f an output (whether an individual or group)<br>to reduce that output&#39;s=
 value to pay a higher fee.<br><br>Note, I think you&#39;re still strugglin=
g 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 feer=
ate 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 a=
t feerate Y, where Y is far under X, thus maliciously burning a lot of your=
 fee-bumping reserve ?<br><br>Of course, one mitigation is to make a contri=
bution to a common fee-bumping output reserve proportional to what has been=
 contributed as a funding collateral. Thus disincentivizing misuse of the c=
ommon fee-bumping reserve in a game-theoretical way. But if you take the ex=
ample of a LN channel, you&#39;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 prot=
ect ? And as such enduring some significant timevalue bleeding on your fee-=
bumping reserve.<br><br>Single-party managed fee-bumping reserve doesn&#39;=
t seem to suffer from this drawback ?<br></div></blockquote><br></div><div =
class=3D"gmail_quote">I claim that what I am suggesting is a single-party m=
anaged 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&#39;t see?<div><div><br></div><div>To f=
urther emphasise the generality of this idea you can easily imagine a world=
 where this is enabled on all Bitcoin transactions (of course you have to s=
tomach tx malleability -- a bit more palatable with ANYPREVOUT everywhere).=
 Even for a normal wallet-to-wallet payment the receiver could efficiently =
increase the tx fee by making a signature under the key of their output and=
 replacing the original tx without interacting with the sender who actually=
 provided the funds for the payment.<br></div><div><br></div><div>Cheers,</=
div><div><br></div><div>LL</div>

</div><div>=C2=A0</div></div></div>

--00000000000009019105c4c37d55--