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
Precedence: list

--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--