path: root/99/8d4e8e6f3569a3f27ea41569ac44a6449deb52

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 92DB5C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 12:06:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 568F3843AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 12:06:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 568F3843AF
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=P4dDiX2P
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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
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 5D_pLeCq9oWi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 12:06:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1086284380
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [IPv6:2a00:1450:4864:20::62d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 1086284380
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 12:06:12 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-9745ba45cd1so320174466b.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Jun 2023 05:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685793971; x=1688385971;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=xgnzTrBGthKO9HGcGZQbz+n370iZ89bh2132Z81NqvU=;
 b=P4dDiX2PCyQFWjZjahFZTWUcEWfAGGu5UBrMoa8fNEc5xoU7jigLuFVJe26FNlDwDc
 Lo1zVQUOXZ3ElEIOILyfzB1xXfYe+vbh8TvAHPcDfXDKDR64rju5lFMOrAGkdkh8ICPr
 e1vsiHKqyRqM65cB8+lUKcN4I+TqxQfT6nz8P7qVhQCgezysDu6KqBk4BNPWo9gYj7h1
 iT7BEY+VLe/ptFmYIeOZMWRT+FAYgocHgQrKbnn8arn71d3Akx+LKWdkZN87bOg3Rl8h
 UCoEVP2Q2wUkIArJkzg4PkCxP9sxhWgVUL4R7/fV2hMGbaZKDV+wjU1W1fYOH2zrpjBr
 SLuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685793971; x=1688385971;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=xgnzTrBGthKO9HGcGZQbz+n370iZ89bh2132Z81NqvU=;
 b=YVzMkpUsGCukTti0nMpGBcSfmgSolaI/0aRY3HyHxreA6ZUmBVFiAunvGnKzV7pdMx
 k5CI9+VYFsWtkDUJLj7XP3gBGVNXUolcWzkxO5nPG5umRdI8PMd9W3v0sQhgRV1qisvG
 zWz+4pFlmtm4kZMwtucebQd3Wcswf5+aEXuuyFZd8iBA+J6peaPkUD4sLvTLB7TnMIT/
 N4gTJjQYrNGbLfe/OZCsetK8LuP3v4NgoDEafZGpH5mavl5YUD852B18xWd+eIoD77KK
 vKXe5jhapzTbPZEBLihXNOoZULLWTT/mPP8lrb8wmFC+7cnniYdXAQsHnnta6mdgM3+O
 tI7g==
X-Gm-Message-State: AC+VfDweGpigvq8FqZTQQs/pM5uM5Zg/rlP7D7GpxUYqA5EnoT8ELyos
 nEhMdQ2r8K4V7k8w5EOThac8r6GXYHsUGO2sdKmib0N4vLs=
X-Google-Smtp-Source: ACHHUZ6ouEl0vw2BgDAVBBgZflVxCE6y0pigSOQX9FK9G0HiUEpdXT+bvcs6IbfwPLXRdEe6DYhgdhFZXU/LOgLFnqg=
X-Received: by 2002:a17:907:6e20:b0:92b:6b6d:2daf with SMTP id
 sd32-20020a1709076e2000b0092b6b6d2dafmr1306076ejc.77.1685793970706; Sat, 03
 Jun 2023 05:06:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAJBJmV9JYYOSJXbzhrGTrv3jf_qGoLRbq9COgbBmuinpNAOhDg@mail.gmail.com>
 <CAJBJmV_UR9ND2vK1+BVeKQ==xdsamJ_7U-X4LH67J9g57UrkTw@mail.gmail.com>
In-Reply-To: <CAJBJmV_UR9ND2vK1+BVeKQ==xdsamJ_7U-X4LH67J9g57UrkTw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sat, 3 Jun 2023 08:05:59 -0400
Message-ID: <CAB3F3Dugso9MUqr5hMMorL7FargPPspiof+0-qkYGnP_SLyELg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c9dcdf05fd387e1e"
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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: Sat, 03 Jun 2023 12:06:14 -0000

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

> I think this avoidance of a circular reference is also why LN-Symmetry
uses the annex?

The annex trick specifically is used to force the publication of the
missing piece of the control block corresponding to the new taproot output.
This is to maintain the node's O(1) state while also keeping 0.5RTT channel
updates. Could have also been done with a dangling OP_RETURN, with the
associated restrictions on which sighashes you can use since you now have
to commit to multiple outputs(disallows SIGHASH_SINGLE).

There's also a fair exchange protocol that obviates the need for it using
signature adapters, but the requisite APIs don't exist yet, and doesn't
lend itself naturally to 3+ party scenarios.

> Depending on policy to mitigate this annex malleability vector could
mislead developers into believing their transactions are immune to
replacement, when in fact they might not be.

The issue I'm talking about is where someone's transaction is denied entry
into the mempool entirely because a counter-party decided to put in a
strictly worse transaction for miners by bloating the weight of it, not
adding fees. A strictly worse "API" for paying miners for no gain seems
like a bad trade to me, especially when there are reasonable methods for
mitigating this.

> It may thus be more prudent to permit the utilization of the annex
without restrictions, inform developers of its inherent risks, and
acknowledge that Bitcoin, in its present state, might not be ideally suited
for certain types of applications?

Mempool policy should be an attempt to bridge the gap between node anti-DoS
and an entity's ability to pay miners more via feerate-ordered queue. I
don't think the answer to this problem is to zero out all ability to limit
the sizes of multi-party, multi-input transactions for speculative use
cases.

Greg



On Sat, Jun 3, 2023 at 7:31=E2=80=AFAM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Jun 3, 2023 at 9:49=E2=80=AFAM Joost Jager <joost.jager@gmail.com=
> wrote:
>
>> The removal of the need for a commitment transaction also enables the
>> inclusion of data within a single transaction that relies on its own
>> transaction identifier (txid). This is possible because the txid
>> calculation does not incorporate the annex, where the data would be hous=
ed.
>> This feature can be beneficial in scenarios that require the emulation o=
f
>> covenants through the use of presigned transactions involving an ephemer=
al
>> signer.
>>
>
> I think this avoidance of a circular reference is also why LN-Symmetry
> uses the annex?
>
> Joost
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>&gt; I think this avoidance of a circular reference i=
s also why LN-Symmetry uses the annex?</div><div><br></div>The annex trick =
specifically is used to force the=C2=A0publication of the missing piece of =
the control block=C2=A0corresponding to the new taproot output. This is to =
maintain the node&#39;s O(1) state while also keeping 0.5RTT channel update=
s. Could have also been done with a dangling OP_RETURN, with the associated=
 restrictions on which sighashes you can use since you now have to commit t=
o multiple outputs(disallows SIGHASH_SINGLE).<div><br></div><div>There&#39;=
s also a fair exchange protocol that obviates the need for it using signatu=
re adapters, but the requisite APIs don&#39;t exist yet, and doesn&#39;t le=
nd itself naturally=C2=A0to 3+ party scenarios.</div><div><br></div><div>&g=
t; Depending on policy to mitigate this annex malleability vector could mis=
lead developers into believing their transactions are immune to replacement=
, when in fact they might not be.=C2=A0</div><div><br></div><div>The issue =
I&#39;m talking about=C2=A0is where someone&#39;s transaction is denied ent=
ry into the mempool entirely because a counter-party decided to put in a st=
rictly worse transaction for miners by bloating the weight of it, not addin=
g fees. A strictly worse &quot;API&quot; for paying miners for no gain seem=
s like a bad trade to me,=C2=A0especially when there are reasonable methods=
 for mitigating this.</div><div><br></div><div>&gt; It may thus be more pru=
dent to permit the utilization of the annex without restrictions, inform de=
velopers of its inherent risks, and acknowledge that Bitcoin, in its presen=
t state, might not be ideally suited for certain types of applications?</di=
v><div><br></div><div>Mempool policy should be an attempt to bridge the gap=
 between node anti-DoS and an entity&#39;s ability to pay miners more via f=
eerate-ordered queue. I don&#39;t think the answer to this problem is to ze=
ro out all ability to limit the sizes of multi-party, multi-input transacti=
ons for speculative=C2=A0use cases.</div><div><br></div><div>Greg<br><div><=
br></div><div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Jun 3, 2023 at 7:31=E2=80=AFAM Joost =
Jager via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"l=
tr">On Sat, Jun 3, 2023 at 9:49=E2=80=AFAM Joost Jager &lt;<a href=3D"mailt=
o:joost.jager@gmail.com" target=3D"_blank">joost.jager@gmail.com</a>&gt; wr=
ote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>The removal of the need for a commitm=
ent transaction also enables the inclusion of data within a single transact=
ion that relies on its own transaction identifier (txid). This is possible =
because the txid calculation does not incorporate the annex, where the data=
 would be housed. This feature can be beneficial in scenarios that require =
the emulation of covenants through the use of presigned transactions involv=
ing an ephemeral signer.</div></div></blockquote><div><br></div><div>I thin=
k this avoidance of a circular reference is also why LN-Symmetry uses the a=
nnex?</div><div><br></div><div>Joost</div></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>

--000000000000c9dcdf05fd387e1e--