path: root/3f/e9ce8e0d2335c3dd6ee1536da7deccde3340af

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 20C42C000B;
 Thu, 10 Feb 2022 08:09:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E5D7440465;
 Thu, 10 Feb 2022 08:09:14 +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: 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 B5FPiGPk8WQn; Thu, 10 Feb 2022 08:09:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [IPv6:2a00:1450:4864:20::135])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 038D340127;
 Thu, 10 Feb 2022 08:09:12 +0000 (UTC)
Received: by mail-lf1-x135.google.com with SMTP id 13so8881339lfp.7;
 Thu, 10 Feb 2022 00:09:12 -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=gHa/1ROYLNoTB+IyAJBEPt2gQ+sKNt8Ckf4U4TUSIsc=;
 b=ISnLBcbMrUl2HZC75rrpQXB8I6sLpUhmu8dvhjQCD4Lo6QiuOOkPyCFuQJN+wbXOHB
 btnox6HhV4ieH+GasvGy6u0t7qhlVGUZxo1qjeRo5xGR12FIdt73Akgna2y3z+L+Qn93
 Zn67lNnkqtkqZyYDdESEP89TebP8fIC7oP7aKVon9JxFu7JI9UOGj9Y6fbK58+AodgnH
 BXaUrT7VBugOaO0iXLRT9DunVW0vDg0ttUn/yX/JbECRybCr4E0AY7JX6WaZq1QrL6V6
 xMjNU0JC/y1HULU7LsRye4RMTLByy/1asKX7QEcc0qLSzS56X1f8A3DtaX0CvUWLc+7o
 /8jQ==
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=gHa/1ROYLNoTB+IyAJBEPt2gQ+sKNt8Ckf4U4TUSIsc=;
 b=Ij2q1M4ok6Km8pvynrhUz4uXwjHgDp00mH6MQkniGJsLtXvhKW/oR98cMqJut++eo4
 Q2VnxKO6Uxz5qUO4Rml2f1LLq0lgwfE+GjnXd+ukJ4TKhvH/Srjyj3U8Q8RwlxDR8QZO
 dd6yxXoITMCq2VeRi2BIVeRJHYJfqvNmJcm9qA2htlUvE4zDgnTN/j/PRUtVgBvbNNZP
 nhO9wgwP1cmIcHSea/QiAzn/T6z2Hpk7LgZ7YhIvQz6TzRusNcvDbWO8LnrNLVG1hExi
 Gi1Q5ifYvXIkQYNy9liaPA3Nq52Ih34iwVzNwv+FFQAbQ1A7bZ2yeY5FCZvQZ1w2kj50
 xDUQ==
X-Gm-Message-State: AOAM5333stiGDjPvrQXyijncgwNIY4zuSs1O+u1WM1jSSo2bW1e8F0SO
 zN/uy79R7DqTaAvjAb+ifsxsXKNdh86+M7WqmIM=
X-Google-Smtp-Source: ABdhPJzgaHWgufgBP1eRcnf3kaoNK06yx5VAA/TOXeKX9dknjCDDwXLtIL5qHooTxgQ4sN5EajxPNQuM11yVtONld4o=
X-Received: by 2002:a05:6512:3e1a:: with SMTP id
 i26mr4426430lfv.175.1644480550514; 
 Thu, 10 Feb 2022 00:09:10 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <YgS3sJvg6kG3WnVJ@petertodd.org>
In-Reply-To: <YgS3sJvg6kG3WnVJ@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Thu, 10 Feb 2022 00:08:59 -0800
Message-ID: <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000db2e105d7a577e4"
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Thu, 10 Feb 2022 08:09:15 -0000

--0000000000000db2e105d7a577e4
Content-Type: text/plain; charset="UTF-8"

That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.

Often times in these protocols "the call is coming inside the house". It's
not a third party adding fees we are scared of, it's a direct party to the
protocol!

Sponsors or fee accounts would enable you to ensure the protocol you're
working on makes forward progress. For things like Eltoo the internal
ratchet makes this work well.

Protocols which depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.

Cheers,

Jeremy

On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> > Happy new years devs,
> >
> > I figured I would share some thoughts for conceptual review that have
> been
> > bouncing around my head as an opportunity to clean up the fee paying
> > semantics in bitcoin "for good". The design space is very wide on the
> > approach I'll share, so below is just a sketch of how it could work which
> > I'm sure could be improved greatly.
> >
> > Transaction fees are an integral part of bitcoin.
> >
> > However, due to quirks of Bitcoin's transaction design, fees are a part
> of
> > the transactions that they occur in.
> >
> > While this works in a "Bitcoin 1.0" world, where all transactions are
> > simple on-chain transfers, real world use of Bitcoin requires support for
> > things like Fee Bumping stuck transactions, DoS resistant Payment
> Channels,
> > and other long lived Smart Contracts that can't predict future fee rates.
> > Having the fees paid in band makes writing these contracts much more
> > difficult as you can't merely express the logic you want for the
> > transaction, but also the fees.
> >
> > Previously, I proposed a special type of transaction called a "Sponsor"
> > which has some special consensus + mempool rules to allow arbitrarily
> > appending fees to a transaction to bump it up in the mempool.
> >
> > As an alternative, we could establish an account system in Bitcoin as an
> > "extension block".
>
> <snip>
>
> > This type of design works really well for channels because the addition
> of
> > fees to e.g. a channel state does not require any sort of pre-planning
> > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> > design is naturally immune to pinning issues since you could offer to
> pay a
> > fee for any TXID and the number of fee adding offers does not need to be
> > restricted in the same way the descendant transactions would need to be.
>
> So it's important to recognize that fee accounts introduce their own kind
> of
> transaction pinning attacks: third parties would be able to attach
> arbitrary
> fees to any transaction without permission. This isn't necessarily a good
> thing: I don't want third parties to be able to grief my transaction
> engines by
> getting obsolete transactions confirmed in liu of the replacments I
> actually
> want confirmed. Eg a third party could mess up OpenTimestamps calendars at
> relatively low cost by delaying the mining of timestamp txs.
>
> Of course, there's an obvious way to fix this: allow transactions to
> designate
> a pubkey allowed to add further transaction fees if required. Which Bitcoin
> already has in two forms: Replace-by-Fee and Child Pays for Parent.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">That&#39;s not really pinning; painning usually refers to=
 pinning something to the bottom of the mempool whereas these mechanisms ma=
ke it easier to guarantee that progress can be made on confirming the trans=
actions you&#39;re interested in.<div dir=3D"auto"><br></div><div dir=3D"au=
to">Often times in these protocols &quot;the call is coming inside the hous=
e&quot;. It&#39;s not a third party adding fees we are scared of, it&#39;s =
a direct party to the protocol!</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Sponsors or fee accounts would enable you to ensure the protocol =
you&#39;re working on makes forward progress. For things like Eltoo the int=
ernal ratchet makes this work well.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Protocols which depend on in mempool replacements before confir=
mation already must be happy (should they be secure) with any prior state b=
eing mined. If a third party pays the fee you might even be happier since t=
he execution wasn&#39;t on your dime.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Jeremy</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:<b=
r>
&gt; Happy new years devs,<br>
&gt; <br>
&gt; I figured I would share some thoughts for conceptual review that have =
been<br>
&gt; bouncing around my head as an opportunity to clean up the fee paying<b=
r>
&gt; semantics in bitcoin &quot;for good&quot;. The design space is very wi=
de on the<br>
&gt; approach I&#39;ll share, so below is just a sketch of how it could wor=
k which<br>
&gt; I&#39;m sure could be improved greatly.<br>
&gt; <br>
&gt; Transaction fees are an integral part of bitcoin.<br>
&gt; <br>
&gt; However, due to quirks of Bitcoin&#39;s transaction design, fees are a=
 part of<br>
&gt; the transactions that they occur in.<br>
&gt; <br>
&gt; While this works in a &quot;Bitcoin 1.0&quot; world, where all transac=
tions are<br>
&gt; simple on-chain transfers, real world use of Bitcoin requires support =
for<br>
&gt; things like Fee Bumping stuck transactions, DoS resistant Payment Chan=
nels,<br>
&gt; and other long lived Smart Contracts that can&#39;t predict future fee=
 rates.<br>
&gt; Having the fees paid in band makes writing these contracts much more<b=
r>
&gt; difficult as you can&#39;t merely express the logic you want for the<b=
r>
&gt; transaction, but also the fees.<br>
&gt; <br>
&gt; Previously, I proposed a special type of transaction called a &quot;Sp=
onsor&quot;<br>
&gt; which has some special consensus + mempool rules to allow arbitrarily<=
br>
&gt; appending fees to a transaction to bump it up in the mempool.<br>
&gt; <br>
&gt; As an alternative, we could establish an account system in Bitcoin as =
an<br>
&gt; &quot;extension block&quot;.<br>
<br>
&lt;snip&gt;<br>
<br>
&gt; This type of design works really well for channels because the additio=
n of<br>
&gt; fees to e.g. a channel state does not require any sort of pre-planning=
<br>
&gt; (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort o=
f<br>
&gt; design is naturally immune to pinning issues since you could offer to =
pay a<br>
&gt; fee for any TXID and the number of fee adding offers does not need to =
be<br>
&gt; restricted in the same way the descendant transactions would need to b=
e.<br>
<br>
So it&#39;s important to recognize that fee accounts introduce their own ki=
nd of<br>
transaction pinning attacks: third parties would be able to attach arbitrar=
y<br>
fees to any transaction without permission. This isn&#39;t necessarily a go=
od<br>
thing: I don&#39;t want third parties to be able to grief my transaction en=
gines by<br>
getting obsolete transactions confirmed in liu of the replacments I actuall=
y<br>
want confirmed. Eg a third party could mess up OpenTimestamps calendars at<=
br>
relatively low cost by delaying the mining of timestamp txs.<br>
<br>
Of course, there&#39;s an obvious way to fix this: allow transactions to de=
signate<br>
a pubkey allowed to add further transaction fees if required. Which Bitcoin=
<br>
already has in two forms: Replace-by-Fee and Child Pays for Parent.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://pet=
ertodd.org" rel=3D"noreferrer noreferrer" target=3D"_blank">petertodd.org</=
a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000db2e105d7a577e4--