path: root/4b/0fe084eaac6cae7d4569bcd9d2f8e0f027a928

Return-Path: <joost.jager@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 88981C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 07:44:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5C663401B7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 07:44:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5C663401B7
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=FjdX4V6J
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
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 toeUQ8z7L4ss
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 07:44:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DFDC1400DD
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DFDC1400DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 07:44:30 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-51491b87565so4329311a12.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 00:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686383069; x=1688975069;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=c9XQJL0/Fw04QEUZATUrZckNoKDX/5rB7DD5HTKllDE=;
 b=FjdX4V6JWBMx/RkJh9N+zmkiPHBiGiNIoY6klG8N5zEHHmmDdQMl2gQG+EWXtyEagu
 FJcMYGjuStdfFvLkVoDPimpf6/IH5d9xfudWhdlukvgtzTRbZ6OGZ91yf3MdpoDmHVMS
 A1RsAhcbFknf1kYsX1zjcxgtjrjDVgAm7fhLOeOyCqgcbBWuw2a+8J4P0dH8As/JkT0J
 Oh8vjzyO01t7wdNbGvserl+MAu8rHBPBTn6LdBlnNbZgXR2fnhO96/szqREWaLIxXwq4
 aC9s+JZK8gocb1lQdbGEuatUNyn43Dt6ktofZlZ73lTbCHmISTI2v/uEiCyaoaKk8Dlz
 WenA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686383069; x=1688975069;
 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=c9XQJL0/Fw04QEUZATUrZckNoKDX/5rB7DD5HTKllDE=;
 b=Yg6LPtDyjLPAHUh8t/Bu/USWxDK4Y40ofnffnZ3Pa9hLH8O9rl6v+sBUpbGfdN+Aww
 g39ndULXENHe5gv1PVhLe+UGEdJ/gkgUZhaXuK+Ok5W1F3Q6oFTnFJNs8BMRGjBa19vl
 DWAXxKdRQQfi14W1naEuLXmy5JnsIMkLbXz/ZWUrJKSUQFhgrdRI+0ZK/qs6GYWuQASU
 7u2kjsx1Oidn4A40epyAdJDccvjeSX8Z0joCR69AjivWmUoSrBmRpPttseDQ72osclz4
 xvzO+RP+DXilYSyk8RTWlfoxkPflevgHr0kWmyz3wRzH165riLYa1JRiH75Q9VdoZKdT
 09FQ==
X-Gm-Message-State: AC+VfDyTSgXxmPbD8cFwjvvE2DgMXIUXoGih/bRDDsFwa3ZQmRILelWq
 0/1Fy/llvVb6Sy/CnVFSJ/1bfmp5TnNvVvL12f0CxZQxNq4=
X-Google-Smtp-Source: ACHHUZ4HCTufyI+Q9mTnF5thQiZutv6s5TdFCebeWeHiJmZkkEgqn1gLY3YGA452Vn2Ml5X/bpkhKHT+eBuGt/T7jBA=
X-Received: by 2002:a17:907:7e8b:b0:966:471c:2565 with SMTP id
 qb11-20020a1709077e8b00b00966471c2565mr4017239ejc.48.1686383068510; Sat, 10
 Jun 2023 00:44:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
In-Reply-To: <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 10 Jun 2023 09:43:52 +0200
Message-ID: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c0fde905fdc1a79e"
X-Mailman-Approved-At: Sat, 10 Jun 2023 09:02:36 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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, 10 Jun 2023 07:44:32 -0000

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

Hi Antoine,

On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM Antoine Riard <antoine.riard@gmail.=
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 thinkin=
g
> 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 ideally
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 probably
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 and
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 the
vault itself can be confirmed independently and the backup may never
confirm. If you create a vault and lose the ephemeral signatures, the funds
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 one
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 us=
e
> annex tags with the benefit to combine multiple "types" of unstructured
> data in a single annex payload. As you're raising smaller bits of
> unstructured data might not afford the overhead though my answer with thi=
s
> observation would be to move this traffic towards some L2 systems ? In my
> mind, the default of adding a version byte for the usage of unstructured
> data comes with the downside of having future consensus enabled use-cases
> encumbering by the extended witness economic cost.
>

When it comes to the trade-offs associated with various encodings, I fully
acknowledge their existence. The primary motivation behind my proposal to
adopt a simple approach to the Taproot annex is to avoid a potentially long
standardization process. While I am not entirely familiar with the
decision-making process of Bitcoin Core, my experience with other projects
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 correct=
,
> 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 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 could benefit unstructured
> 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.ht=
ml
[2] https://github.com/bitcoin/bips/pull/1421
[3] https://github.com/bitcoin/bitcoin/pull/24007

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

<div dir=3D"ltr"><div>Hi Antoine,</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM An=
toine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gm=
ail.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-lef=
t:1ex"><div dir=3D"ltr"><div>From a taproot annex design perspective, I thi=
nk this could 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 annex&#39;s list of unstructured data use-cases includes existing d=
ata storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,=
 timestamps, and any other data already stored on the chain. These applicat=
ions would immediately benefit from the annex&#39;s improved space efficien=
cy.</div><div class=3D"gmail_quote"><br>However, the primary advantage I se=
e in the annex is that its data isn&#39;t included in the calculation of th=
e txid or a potential parent commit transaction&#39;s txid (for inscription=
s). I&#39;ve explained this at [1]. This feature makes the annex a powerful=
 tool for applications that would ideally use covenants.<br><br>The most cr=
itical application in this category, for me, involves time-locked vaults. G=
iven the positive 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-signed transactions signed using an ephemeral key can fill the gap=
 and improve the safeguarding of Bitcoin in the short term.<br><br>Backing =
up the ephemeral signatures of the pre-signed transactions on the blockchai=
n itself is an excellent way to ensure that the vault can always be &#39;op=
ened&#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 sig=
nature backup can&#39;t be executed in one atomic operation. For example, y=
ou can store the backup in a child commit/reveal transaction set, but the v=
ault itself can be confirmed independently and the backup may never confirm=
. If you create a vault and lose the ephemeral signatures, the funds will b=
e lost.<br><br>This use case for the annex has been labeled &#39;speculativ=
e&#39; elsewhere. To me, every use case appears speculative at this point b=
ecause the annex isn&#39;t available. However, if you believe that time-loc=
ked 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 that 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.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=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;t=
ypes&quot; of unstructured data in a single annex payload. As you&#39;re ra=
ising smaller bits of unstructured data might not afford the overhead thoug=
h my answer with this observation would be to move this traffic towards som=
e L2 systems ? In my mind, the default of adding a version byte for the usa=
ge of unstructured data comes with the downside of having future consensus =
enabled use-cases encumbering by the extended witness economic cost.</div><=
/div></blockquote><div><br></div><div>When it comes to the trade-offs assoc=
iated with various encodings, I fully acknowledge their existence.=C2=A0The=
 primary motivation behind my proposal to adopt a simple approach to the Ta=
proot annex is to avoid a potentially long standardization process. While I=
 am not entirely familiar with the decision-making process of Bitcoin Core,=
 my experience with other projects suggests that simpler changes often enco=
unter less resistance and can be implemented more swiftly. Perhaps I am bei=
ng overly cautious here, though.<br></div><div>=C2=A0</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"ltr"><div>About=C2=A0the anne=
x payload extension attack described by Greg. If my understanding of this t=
ransaction-relay jamming griefing issue is correct, we can have an annex ta=
g in the future where the signer is committing to the total weight of the t=
ransaction, or even the max per-input annex size ? This should prevent a co=
injoin or aggregated commitment transaction counterparty to inflate its ann=
ex space to downgrade the overall transaction feerate, I guess. And I think=
 this could benefit unstructured data use-cases too.</div></div></blockquot=
e><div><br></div>Regarding the potential payload extension attack, I believ=
e that the changes proposed in the [3] to allow tx replacement by smaller w=
itness would provide a viable solution?=C2=A0<br><div>=C2=A0</div><div>Joos=
t</div><div><br></div><div>[1] <a href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2023-June/021737.html">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2023-June/021737.html</a></div><div>[2]=C2=A0<a =
href=3D"https://github.com/bitcoin/bips/pull/1421">https://github.com/bitco=
in/bips/pull/1421</a></div><div>[3]=C2=A0<a href=3D"https://github.com/bitc=
oin/bitcoin/pull/24007">https://github.com/bitcoin/bitcoin/pull/24007</a></=
div></div></div>

--000000000000c0fde905fdc1a79e--