path: root/1d/b2caa77722b03e38ab5d12465877dbc38cb72b

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 58924C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jul 2023 20:18:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 2081240524
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jul 2023 20:18:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2081240524
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=JkDeSwRO
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 oxgxOQCi7l5v
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jul 2023 20:18:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A3EB14014E
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
 [IPv6:2607:f8b0:4864:20::d31])
 by smtp2.osuosl.org (Postfix) with ESMTPS id A3EB14014E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jul 2023 20:18:35 +0000 (UTC)
Received: by mail-io1-xd31.google.com with SMTP id
 ca18e2360f4ac-78625caa702so229174239f.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 04 Jul 2023 13:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1688501914; x=1691093914;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=eJKqLQ5E3tlnLDy1xCOpsVCIPghNDMqCzxby8qiK8aM=;
 b=JkDeSwRO7wyhAoF9a/jHcHx6nCauo4xpuxDlIJK83IZYge1PuD4HivBO6yulelHjm+
 wfekNxAzKgTnHprPLxk5cHo5DTuWrMy+NYnyqeLviTLjUPosSZJ/UzxJeaEHkWv5APQc
 sxPHzv5Z4SMCVJsd/JpnTmx/uPQIdLALMatyLG5H7eamOK7q9f6udRHg0MhbqiuRoXKR
 9arBy4xPOQlKdBlyCoK8G0xlAOeoBzpo7YWIv9UehFFjVPd8bdO2pOQ48dw9wr1x0n2k
 Fiu1VtERuA+vHJKnQlSu8YTjI18wWS5lENvzul8kIvktp/Wk4/VfpZghY95Yo8XZ0xn/
 u88A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1688501914; x=1691093914;
 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=eJKqLQ5E3tlnLDy1xCOpsVCIPghNDMqCzxby8qiK8aM=;
 b=ioBic/RlQswfJGRWy/4aNukTDe4N7ww2uQCTRmfYu8EPrROVTj/rUQPwDzVP5w4rro
 fKI7QRWadGGA4ZRemf5AnLEplp6vhLi0q3DXvgtIQ3OzT+ZKg+RU/dl1IAvrtvNNjnln
 ou2ZtTO1UjljKDK4pNOyNC4T8ycQDYQdeNZbQa/+nkaF/NGfw7+dJx9DDiESxRVP+yGG
 nk0xK6Uf++G3UADXd71NR6slkOzlRNXSdcns4lFskhyH+87XiFOB94yWezJD87rTGzJt
 CzVOeZEUiaGa2MGblQox00hZsKXUafeh3P84DS8ksSCkUjulK2KRo2eAxP3Drt6OjBOh
 a9pw==
X-Gm-Message-State: AC+VfDxc7/jjGfQ2vODXtq6mqSCoqaGhdu6TiTigEIeHR3lCR9Sz64Ky
 iugj8Nw54ZdrRjQoBi23Aw2SVJkIvHnLcNesvD0=
X-Google-Smtp-Source: ACHHUZ64dZEk9Zuva2gqzue/LIOJBz/zWea8le2/UUKC+IbumiOcJdZ1LH86dM4X9/oZmtmwmm5oLSTfA3ivSOHS9iI=
X-Received: by 2002:a5d:930b:0:b0:783:4590:e40e with SMTP id
 l11-20020a5d930b000000b007834590e40emr14605351ion.12.1688501914600; Tue, 04
 Jul 2023 13:18:34 -0700 (PDT)
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>
 <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
In-Reply-To: <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 4 Jul 2023 21:18:23 +0100
Message-ID: <CALZpt+GZd8kv4Nq-ANR26GPeT_6+0U8zRnsQM1_OLOuhxD7QFg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d28d8305ffaefc8e"
X-Mailman-Approved-At: Tue, 04 Jul 2023 22:13:18 +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: Tue, 04 Jul 2023 20:18:37 -0000

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

Hi Joost,

> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.

From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex standard.

There is the observation that other critical elements of vault's
application state could be backed up in this way (e.g pubkeys and amounts
of the destination output) to rebuild from scratch a pre-signed withdrawal.
The unstructured data could be even marked by an application-level "tag" or
"signaling" to identify all the backup annexes composing your vault
application state.

Of course, such backing up of more critical elements comes with its own
drawbacks in terms of confidentiality, as you would leak your vault policy
on-chain, so they would need to be ciphered first, I think.

It sounds to me another economically rational set of use-cases can be to
simplify protocols using the chain as a publication space for collectibles.
Using the annex as a publication space enables a clear chain of collectible
ownership thanks to the key signing the annex, which is not permissible
with op_return outputs today.

Best,
Antoine


Le mar. 20 juin 2023 =C3=A0 13:30, Joost Jager <joost.jager@gmail.com> a =
=C3=A9crit :

> Hi all,
>
> On Sat, Jun 10, 2023 at 9:43=E2=80=AFAM Joost Jager <joost.jager@gmail.co=
m> wrote:
>
>> 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 idea=
lly
>> 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 probab=
ly
>> 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 shor=
t
>> term.
>>
>> Backing up the ephemeral signatures of the pre-signed transactions on th=
e
>> blockchain itself is an excellent way to ensure that the vault can alway=
s
>> 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 t=
he
>> vault itself can be confirmed independently and the backup may never
>> confirm. If you create a vault and lose the ephemeral signatures, the fu=
nds
>> 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.
>>
>
> To support this use case of the taproot annex, I've create a simple demo
> application here: https://github.com/joostjager/annex-covenants
>
> This demo shows how a coin can be spent to a special address from which i=
t
> can - at a later stage - only move to a pre-defined final destination. It
> makes use of the annex to store the ephemeral signature for the presigned
> transaction so that the coin cannot get lost. This is assuming that nodes
> do not prune witness data en masse and also that the destination address
> itself is known.
>
> The application may not be the most practically useful, but more advanced
> covenants such as time-locked vaults can be implemented similarly.
>
> Hopefully this further raises awareness of the on-chain ephemeral
> signature backup functionality that the annex uniquely enables.
>
> Joost
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>&gt; Hopefully this further r=
aises awareness of the on-chain ephemeral signature backup functionality th=
at the annex uniquely enables.</div><div><br></div><div>From my perspective=
, if vault applications can be made more robust by on-chain backing up of e=
phemeral signatures, this can be rational to make the annex standard.</div>=
<div><br></div><div>There is the observation that other critical elements=
=C2=A0of vault&#39;s application state could be backed up in this way (e.g =
pubkeys and amounts of the=C2=A0destination output) to rebuild from scratch=
 a pre-signed withdrawal. The unstructured data could be even marked by an =
application-level &quot;tag&quot; or &quot;signaling&quot; to identify all =
the backup annexes composing your vault application state.</div><div><br></=
div><div>Of course, such backing up of more critical elements comes with it=
s own drawbacks in terms of confidentiality, as you=C2=A0would leak your va=
ult policy on-chain, so they would need to be ciphered first, I think.</div=
><div><br></div><div>It sounds to me another economically rational set of u=
se-cases can be to simplify protocols using the chain as a publication spac=
e for collectibles. Using the annex as a publication space enables a clear =
chain of collectible ownership thanks to the key signing the annex, which i=
s not permissible with op_return outputs today.</div><div><br></div><div>Be=
st,</div><div>Antoine</div><div><br></div><font color=3D"#888888"></font></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 20 juin 2023 =C3=A0=C2=A013:30, Joost Jager &lt;<a href=3D"mailt=
o:joost.jager@gmail.com">joost.jager@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 10, 2023=
 at 9:43=E2=80=AFAM Joost Jager &lt;<a href=3D"mailto:joost.jager@gmail.com=
" target=3D"_blank">joost.jager@gmail.com</a>&gt; wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_quote">However, the primary advant=
age I see in the annex is that its data isn&#39;t included in the calculati=
on of the txid or a potential parent commit transaction&#39;s txid (for ins=
criptions). 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 critical application in this category, for me, involves time-locked v=
aults. Given the positive reception to proposals such as OP_VAULT [2], I do=
n&#39;t think I&#39;m alone in this belief. OP_VAULT is probably a bit furt=
her 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 b=
lockchain 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 co=
uld be. Due to the described circular reference problem, the vault creation=
 and signature backup can&#39;t be executed in one atomic operation. For ex=
ample, you can store the backup in a child commit/reveal transaction set, b=
ut the vault itself can be confirmed independently and the backup may never=
 confirm. If you create a vault and lose the ephemeral signatures, the fund=
s will be lost.<br><br>This use case for the annex has been labeled &#39;sp=
eculative&#39; elsewhere. 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 that the intermediate solution described above is very rele=
vant.</div></div></blockquote><div><br></div><div>To support this use case =
of the taproot annex, I&#39;ve create a simple demo application here:=C2=A0=
<a href=3D"https://github.com/joostjager/annex-covenants" target=3D"_blank"=
>https://github.com/joostjager/annex-covenants</a></div><div><br></div><div=
>This demo shows how a coin can be spent to a special address from which it=
 can - at a later stage - only move to a pre-defined final destination. It =
makes use of the annex to store the ephemeral signature for the presigned t=
ransaction so that the coin cannot get lost. This is assuming that nodes do=
 not prune witness data en masse and also that the destination address itse=
lf is known.</div><div><br></div><div>The application may not be the most p=
ractically useful, but more advanced covenants such as time-locked vaults c=
an be implemented similarly.</div><div><br></div><div>Hopefully this furthe=
r raises awareness of the on-chain ephemeral signature backup functionality=
 that the annex uniquely enables.</div><div><br></div><div>Joost</div></div=
></div>
</blockquote></div>

--000000000000d28d8305ffaefc8e--