MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
In-Reply-To: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 12 Jun 2023 09:03:47 -0400
Message-ID: <CAB3F3Ds4aZ7fqqNUBGW3vzvUhsJ7ABvbGaAaEhWimyLosxwVmg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000b182c05fdee5aaa"
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?

The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or scriptpath spends, ala
https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 .
It's much easier to think about one-off replacements from an anti-DoS
perspective.

We would have to think a lot harder if that actually solves the problem and
maintains the prospective use-cases before diving into analysis, regardless=
.

Cheers,
Greg


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

> Hi Antoine,
>
> On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM Antoine Riard <antoine.riard@gmai=
l.com>
> wrote:
>
>> From a taproot annex design perspective, I think this could be very
>> valuable if you have a list of unstructured data use-cases you're thinki=
ng
>> about ?
>>
>
> The annex's list of unstructured data use-cases includes existing data
> storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,
> timestamps, and any other data already stored on the chain. These
> applications would immediately benefit from the annex's improved space
> efficiency.
>
> However, the primary advantage I see in the annex is that its data isn't
> included in the calculation of the txid or a potential parent commit
> transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would ideal=
ly
> use covenants.
>
> The most critical application in this category, for me, involves
> time-locked vaults. Given the positive reception to proposals such as
> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probabl=
y
> a bit further out, but pre-signed transactions signed using an ephemeral
> key can fill the gap and improve the safeguarding of Bitcoin in the short
> term.
>
> Backing up the ephemeral signatures of the pre-signed transactions on the
> blockchain itself is an excellent way to ensure that the vault can always
> be 'opened'. However, without the annex, this is not as safe as it could
> be. Due to the described circular reference problem, the vault creation a=
nd
> signature backup can't be executed in one atomic operation. For example,
> you can store the backup in a child commit/reveal transaction set, but th=
e
> vault itself can be confirmed independently and the backup may never
> confirm. If you create a vault and lose the ephemeral signatures, the fun=
ds
> will be lost.
>
> This use case for the annex has been labeled 'speculative' elsewhere. To
> me, every use case appears speculative at this point because the annex
> isn't available. However, if you believe that time-locked vaults are
> important for Bitcoin and also acknowledge that soft forks, such as the o=
ne
> required for OP_VAULT, aren't easy to implement, I'd argue that the
> intermediate solution described above is very relevant.
>
>
>> As raised on the BIP proposal, those unstructured data use-cases could
>> use annex tags with the benefit to combine multiple "types" of unstructu=
red
>> data in a single annex payload. As you're raising smaller bits of
>> unstructured data might not afford the overhead though my answer with th=
is
>> observation would be to move this traffic towards some L2 systems ? In m=
y
>> mind, the default of adding a version byte for the usage of unstructured
>> data comes with the downside of having future consensus enabled use-case=
s
>> encumbering by the extended witness economic cost.
>>
>
> When it comes to the trade-offs associated with various encodings, I full=
y
> acknowledge their existence. The primary motivation behind my proposal to
> adopt a simple approach to the Taproot annex is to avoid a potentially lo=
ng
> standardization process. While I am not entirely familiar with the
> decision-making process of Bitcoin Core, my experience with other project=
s
> suggests that simpler changes often encounter less resistance and can be
> implemented more swiftly. Perhaps I am being overly cautious here, though=
.
>
>
>> About the annex payload extension attack described by Greg. If my
>> understanding of this transaction-relay jamming griefing issue is correc=
t,
>> we can have an annex tag in the future where the signer is committing to
>> the total weight of the transaction, or even the max per-input annex siz=
e ?
>> This should prevent a coinjoin or aggregated commitment transaction
>> counterparty to inflate its annex space to downgrade the overall
>> transaction feerate, I guess. And I think this could benefit unstructure=
d
>> data use-cases too.
>>
>
> Regarding the potential payload extension attack, I believe that the
> changes proposed in the [3] to allow tx replacement by smaller witness
> would provide a viable solution?
>
> Joost
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.=
html
> [2] https://github.com/bitcoin/bips/pull/1421
> [3] https://github.com/bitcoin/bitcoin/pull/24007
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; Regarding the potential payload extension attack, I b=
elieve that the changes proposed in the [3] to allow tx replacement by smal=
ler witness would provide a viable solution?=C2=A0<div><br></div><div>The o=
nly plausible case I could see moving forward is replacing the transaction =
to a form that has *no* annex or scriptpath spends, ala <a href=3D"https://=
github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119">https://gith=
ub.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119</a> . It&#39;s mu=
ch easier to think about one-off replacements from an anti-DoS perspective.=
=C2=A0</div><div><br></div><div>We would have to think a lot harder if that=
 actually solves the problem and maintains the prospective use-cases before=
 diving into analysis, regardless.</div><div><br></div><div>Cheers,</div><d=
iv>Greg</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Jun 10, 2023 at 5:02=E2=80=AFAM Joost=
 Jager via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote 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>Hi Anto=
ine,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM Antoine Riard &lt;<a href=3D"ma=
ilto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>=
&gt; wrote:<br></div><blockquote 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>From a taproot annex design perspective, I think this cou=
ld be very valuable if you have a list of unstructured=C2=A0data use-cases =
you&#39;re thinking about ? </div></div></blockquote><div><br></div>The ann=
ex&#39;s list of unstructured data use-cases includes existing data storage=
 uses that utilize OP_RETURN or inscriptions. Consider ordinals, timestamps=
, and any other data already stored on the chain. These applications would =
immediately benefit from the annex&#39;s improved space efficiency.</div><d=
iv class=3D"gmail_quote"><br>However, the primary advantage I see in the an=
nex is that its data isn&#39;t included in the calculation of the txid or a=
 potential parent commit transaction&#39;s txid (for inscriptions). I&#39;v=
e explained this at [1]. This feature makes the annex a powerful tool for a=
pplications that would ideally use covenants.<br><br>The most critical appl=
ication in this category, for me, involves time-locked vaults. Given the po=
sitive reception to proposals such as OP_VAULT [2], I don&#39;t think I&#39=
;m alone in this belief. OP_VAULT is probably a bit further out, but pre-si=
gned transactions signed using an ephemeral key can fill the gap and improv=
e the safeguarding of Bitcoin in the short term.<br><br>Backing up the ephe=
meral signatures of the pre-signed transactions on the blockchain itself is=
 an excellent way to ensure that the vault can always be &#39;opened&#39;. =
However, without the annex, this is not as safe as it could be. Due to the =
described circular reference problem, the vault creation and signature back=
up can&#39;t be executed in one atomic operation. For example, you can stor=
e the backup in a child commit/reveal transaction set, but the vault itself=
 can be confirmed independently and the backup may never confirm. If you cr=
eate a vault and lose the ephemeral signatures, the funds will be lost.<br>=
<br>This use case for the annex has been labeled &#39;speculative&#39; else=
where. To me, every use case appears speculative at this point because the =
annex isn&#39;t available. However, if you believe that time-locked vaults =
are important for Bitcoin and also acknowledge that soft forks, such as the=
 one required for OP_VAULT, aren&#39;t easy to implement, I&#39;d argue tha=
t the intermediate solution described above is very relevant.<br><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>As raised on the BIP proposal, those unstructured=C2=A0data use-cases=
 could use annex tags with the benefit to combine multiple &quot;types&quot=
; of unstructured data in a single annex payload. As you&#39;re raising sma=
ller bits of unstructured data might not afford the overhead though my answ=
er with this observation would be to move this traffic towards some L2 syst=
ems ? In my mind, the default of adding a version byte for the usage of uns=
tructured data comes with the downside of having future consensus enabled u=
se-cases encumbering by the extended witness economic cost.</div></div></bl=
ockquote><div><br></div><div>When it comes to the trade-offs associated wit=
h various encodings, I fully acknowledge their existence.=C2=A0The primary =
motivation behind my proposal to adopt a simple approach to the Taproot ann=
ex is to avoid a potentially long standardization process. While I am not e=
ntirely familiar with the decision-making process of Bitcoin Core, my exper=
ience with other projects suggests that simpler changes often encounter les=
s resistance and can be implemented more swiftly. Perhaps I am being overly=
 cautious here, though.<br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>About=C2=A0the annex payload=
 extension attack described by Greg. If my understanding of this transactio=
n-relay jamming griefing issue is correct, we can have an annex tag in the =
future where the signer is committing to the total weight of the transactio=
n, or even the max per-input annex size ? This should prevent a coinjoin or=
 aggregated commitment transaction counterparty to inflate its annex space =
to downgrade the overall transaction feerate, I guess. And I think this cou=
ld benefit unstructured data use-cases too.</div></div></blockquote><div><b=
r></div>Regarding the potential payload extension attack, I believe that th=
e changes proposed in the [3] to allow tx replacement by smaller witness wo=
uld provide a viable solution?=C2=A0<br><div>=C2=A0</div><div>Joost</div><d=
iv><br></div><div>[1] <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2023-June/021737.html" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-June/021737.html</a></div><div>[2]=
=C2=A0<a href=3D"https://github.com/bitcoin/bips/pull/1421" target=3D"_blan=
k">https://github.com/bitcoin/bips/pull/1421</a></div><div>[3]=C2=A0<a href=
=3D"https://github.com/bitcoin/bitcoin/pull/24007" target=3D"_blank">https:=
//github.com/bitcoin/bitcoin/pull/24007</a></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>

--0000000000000b182c05fdee5aaa--