path: root/0b/54faa7098ccdb9b85779ecbb79326bc208a3ab

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 51928C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 17:18:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 22E3D401D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 17:18:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kd3jkZgD_Wtf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 17:18:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [IPv6:2a00:1450:4864:20::333])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B8CA640191
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 17:18:52 +0000 (UTC)
Received: by mail-wm1-x333.google.com with SMTP id
 s70-20020a1ca9490000b02901a589651424so299882wme.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 10:18:52 -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;
 bh=TMfySYtnVz69eMLDw6eDxrWznCY7xMtMsWhJDUY37xQ=;
 b=Enjdqyv1E+3z8MAtoH/XzmjRwj40gsLPX6MLlCvt1Ug6bW8MKDhQVD4jRAL51iYaGv
 mAvh6mlaPr05peoqWJAmpwgq9NtXS1uo/BZRqWFN+Itz0YZBsbdU/rx1PmALBLxCEjbJ
 Oc7dCCxO0dgwuBowWRH9+vb3JUrOQRyNmvwwdsTZCqguAK/QL6qWkzUfiJd9SQJZRj2J
 V1SQgdmKBW9NkqLIy6Onu4/QeqQCZkvLjXrMkaO6gnoBgDLOaf727eqBjQrnOhTLT0qH
 dzo6JuIH5UU/B8jQcQYlQ4VqNsgUvGdmYV9qarhhK4NjiQM/R/de4cbYB8UoEsPYCGXQ
 o+5w==
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;
 bh=TMfySYtnVz69eMLDw6eDxrWznCY7xMtMsWhJDUY37xQ=;
 b=IbgSa3wxVgmm3maonozhkE55AXHSmo2SRaxuE4reA9ybRzytbX+B4p+vYoTF3i3Ve4
 o8nNqAYueGQPy+s+b6lkXS1CJTFTOOMzbJq6R2m5766oNLIKSKxgpCX2Fx9j7pH42a3j
 g2QFx2uGgDFO1pcJUOU7uzc9TORj1EpYZNyDjN1tg+ximlZol2fu5pSjWYBdQUjPJqoz
 GfrWacZ+wUkJRca1dvKCvXNc1BsqofEFce+qvYG93QoX7ASN8bU2PMZYCXfMKnJVWv8B
 UXJXQiEf0lVud2x54YaIyWi2kR7pFqhTXB76JgMhCSqNuvOECGy9RNaBffVqyKjNUptG
 OinA==
X-Gm-Message-State: AOAM531P+1NzauhWylBIg2d5FG5/WmDWENkptdohY4VTWfj6thMHA8l3
 wgvzKqsi+aCm9GXJIzgieCXBAbHavIUtkP7oGWQ=
X-Google-Smtp-Source: ABdhPJz3OPbMuXNmm93bcSDjTKjm8JyOad8JjQQ/LlNs3SSD4QMtOU7HGW5uV1e/rKwAjhx14mX44aEm9TVCR8zVE4o=
X-Received: by 2002:a1c:5f86:: with SMTP id t128mr129274wmb.165.1623691130707; 
 Mon, 14 Jun 2021 10:18:50 -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>
 <CAD5xwhjSN1LX_8L90UYy-r=sMPCRTonHetxKY4C0f1ghw548SA@mail.gmail.com>
In-Reply-To: <CAD5xwhjSN1LX_8L90UYy-r=sMPCRTonHetxKY4C0f1ghw548SA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 14 Jun 2021 13:18:38 -0400
Message-ID: <CALZpt+HEzEvNY4O3TWR_LkPydzGdJFz-=NZ3Qd7mEHL6A=y5_g@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000012209605c4bd0d0a"
X-Mailman-Approved-At: Mon, 14 Jun 2021 17:41:08 +0000
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: Mon, 14 Jun 2021 17:18:54 -0000

--00000000000012209605c4bd0d0a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for this analysis of a sponsor-like mechanism.

For sure, "watchtower friendly" and "post hoc" are really good point
towards sponsorship, at least other proposals are struggling with
watchtower support, at least in way where your watchtower policy doesn't
leak to your counterparties (which is really gross from a security
standpoint when you think about it!)

W.r.t to sponsorship chain/fee overhead (at least compared to
ANYPREVOUT+IOMAP), I think it's ultimately a question of how many contracts
are closed cooperatively-vs-non-coop on the long-term. Even if we can hope
for emergency closure for security reasons to be pretty rare in practice,
we might still have significant non-coop closing when counterparties can't
agree on the economic opportunity of pursuing the contract or not. E.g, a
big LN hub unilaterally closes small channels, either because it doesn't
earn routing fees or those mobile nodes have been offline for too long.

Still, I think the next step of the discussion would be to come up with a
consistent simulation against which we can all agree on and score all the
proposals against it.

Le dim. 13 juin 2021 =C3=A0 10:16, Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> The API of a sponsor-like mechanism is close to ideal in my opinion:
>
> - compatible with non malleable transactions
> - 0 overhead if fees accurately estimated
> - watchtower friendly
> - post hoc, requires minimal 'protocol awareness'
> - friendly with most mempool eviction policies, not much new required
> - can work to atomically bump multiple txns
> - can be bumped cooperatively by multiple sponsors w/o coordination
> - 0 'rebroadcast overhead' (e.g., for a large batch) leasing to cascading
> retransmission fees for replacement
> - can be piggy backed with other future transactions or protocols (e.g.
> coinjoin)
> - compatible with change being in cold storage
>
> The main drawback is it is chain space - wise less efficient, as an
> additional transaction gets made. However, I think the API benefits
> 'product market fit' over alternative solutions outweigh other concerns,
> and if the 'sponsorship efficiency hypothesis' holds true, then most
> transactions will not require sponsors and therefore the savings of not
> needing to preplan a few bumping mechanism will be more efficient overall
> (efficient market will drive accuracy in estimating fees rather than
> needing to sponsor).
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Thanks for this analysis of a sponsor-like mechanism.<br><=
div><br>For sure, &quot;watchtower friendly&quot; and &quot;post hoc&quot; =
are really good point towards sponsorship, at least other proposals are str=
uggling with watchtower support, at least in way where your watchtower poli=
cy doesn&#39;t leak to your counterparties (which is really gross from a se=
curity standpoint when you think about it!)<br><br>W.r.t to sponsorship cha=
in/fee overhead (at least compared to ANYPREVOUT+IOMAP), I think it&#39;s u=
ltimately a question of how many contracts are closed cooperatively-vs-non-=
coop on the long-term. Even if we can hope for emergency closure for securi=
ty reasons to be pretty rare in practice, we might still have significant n=
on-coop closing when counterparties can&#39;t agree on the economic opportu=
nity of pursuing the contract or not. E.g, a big LN hub unilaterally closes=
 small channels, either because it doesn&#39;t earn routing fees or those m=
obile nodes have been offline for too long.<br><br>Still, I think the next =
step of the discussion would be to come up with a consistent simulation aga=
inst which we can all agree on and score all the proposals against it.<br><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">Le=C2=A0dim. 13 juin 2021 =C3=A0=C2=A010:16, Jeremy via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"auto">The API of a sponsor-li=
ke mechanism is close to ideal in my opinion:<div dir=3D"auto"><br></div><d=
iv dir=3D"auto">- compatible with non malleable transactions</div><div dir=
=3D"auto">- 0 overhead if fees accurately estimated</div><div dir=3D"auto">=
- watchtower friendly</div><div dir=3D"auto">- post hoc, requires minimal &=
#39;protocol awareness&#39;</div><div dir=3D"auto">- friendly with most mem=
pool eviction policies, not much new required</div><div dir=3D"auto">- can =
work to atomically bump multiple txns</div><div dir=3D"auto">- can be bumpe=
d cooperatively by multiple sponsors w/o coordination</div><div dir=3D"auto=
">- 0 &#39;rebroadcast overhead&#39; (e.g., for a large batch) leasing to c=
ascading retransmission fees for replacement</div><div dir=3D"auto">- can b=
e piggy backed with other future transactions or protocols (e.g. coinjoin)<=
/div><div dir=3D"auto">- compatible with change being in cold storage</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">The main drawback is it is ch=
ain space - wise less efficient, as an additional transaction gets made. Ho=
wever, I think the API benefits &#39;product market fit&#39; over alternati=
ve solutions outweigh other concerns, and if the &#39;sponsorship efficienc=
y hypothesis&#39; holds=C2=A0true, then most transactions will not require =
sponsors and therefore the savings of not needing to preplan a few bumping =
mechanism will be more efficient overall (efficient market will drive accur=
acy in estimating fees rather than needing to sponsor).</div><div dir=3D"au=
to"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div=
>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000012209605c4bd0d0a--