path: root/17/eb911656169b05679e068bea263c3e87ef8c7d

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 DA635C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:30:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A1F80403AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:30:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A1F80403AA
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=mnf4UB0i
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 PChHJW9Kcw31
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:30:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 65002416A2
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [IPv6:2a00:1450:4864:20::635])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 65002416A2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:30:58 +0000 (UTC)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-988a076a7d3so342408666b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 05:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1687264256; x=1689856256;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=cIGu6kCxZdjslUIM1QvFKD4GpSG0zfdSHJDmjREv0cQ=;
 b=mnf4UB0imKTJDnChwa2ta9oKrUo8q7MNCgtQ/6vfFXPsuCk+u/7qzvAmfDtDU6/LfB
 zeAyWwq+Z2r5cOgWvuzxNpa3tQQlWe9IUY3AN9kDCugNXHVmP5feki3lrULfMAWsVQnh
 eLcI6nyuDNSCyW6hzfRuftooOC77SXbykKu8gRPmNghNzXsx8YNHPMlttglfqNY7JkeW
 6klI51T3L3wLzb+2gGtRFAv6h0ekn0C1EMJzOcqr1OJza+w1jFaSevbxa63iG/LPJtwc
 KYmv7KFPwMPnw+7PfPTbPplsQnUAhHcITQlSFH2FGtYP+YhzOWMPmotH/h+ve+uBf7k2
 4mgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1687264256; x=1689856256;
 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=cIGu6kCxZdjslUIM1QvFKD4GpSG0zfdSHJDmjREv0cQ=;
 b=gaOmMIlqRIRH1/C/TXC0XgUZozRyHHfKJFSd4Y30yQn1GQHNISz+pWhKzcvQgOTn2V
 JWBobMCx+98GY/yjFzs4UUdUDPInfsZb4MTyDGRO9IMvoxVh4JDdF5TRAlFGnlqQvuIK
 js3uYgfLy/DX8J/CNejN0fIe3hydrjDKvzLBWp8CjLpquUJi4P9buPBe2EHvBPEyk/pz
 2r+xAIrBMxi+wIpmzovmXGoJgFUJIyLFHXl1TiVPs3JH8a0Z95CXfwuO+e61qwv+qYlK
 Y1LmuUyUMrAIFO4mAusy7U0BGoI5mws9MHTOmLMBCZ4MBicO5TvPU5UshGJzS92xTPlt
 4rRg==
X-Gm-Message-State: AC+VfDw8TAdLlNmU3ho8VWEVz2i1+kMNDEbiKzJF48Q1zHKorRFfYaRs
 rHLgHJDvmK45HR4krz02R2qdHxzKx6gMEV17FtOfbsv2uBM=
X-Google-Smtp-Source: ACHHUZ4UfKB8h6/4yxo2tnCegvzdqrDNaeNyWtEb3H+E1eCEAObmsGL6/6BqJCLqfSWdbt4bGRCM1RtGlHJzkBfXwqI=
X-Received: by 2002:a17:907:320d:b0:974:1c90:b3d3 with SMTP id
 xg13-20020a170907320d00b009741c90b3d3mr11469891ejb.12.1687264256161; Tue, 20
 Jun 2023 05:30:56 -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>
In-Reply-To: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 20 Jun 2023 14:30:19 +0200
Message-ID: <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a17bad05fe8ed2e0"
X-Mailman-Approved-At: Tue, 20 Jun 2023 12:59:53 +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, 20 Jun 2023 12:31:00 -0000

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

Hi all,

On Sat, Jun 10, 2023 at 9:43=E2=80=AFAM Joost Jager <joost.jager@gmail.com>=
 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 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.
>

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

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

<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">joost.jager@gmail.com</=
a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote">However, the primary advantage I see =
in the annex 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;ve explained this at [1]. This feature makes the annex a powerful t=
ool for applications that would ideally use covenants.<br><br>The most crit=
ical application in this category, for me, involves time-locked vaults. Giv=
en the positive reception to proposals such as OP_VAULT [2], I don&#39;t th=
ink I&#39;m alone in this belief. OP_VAULT is probably a bit further out, b=
ut pre-signed transactions signed using an ephemeral key can fill the gap a=
nd improve the safeguarding of Bitcoin in the short term.<br><br>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 &#39;open=
ed&#39;. However, without the annex, this is not as safe as it could be. Du=
e to the described circular reference problem, the vault creation and signa=
ture backup can&#39;t be executed in one atomic operation. For example, you=
 can store the backup in a child commit/reveal transaction set, but the vau=
lt 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.<br><br>This use case for the annex has been labeled &#39;speculative&=
#39; elsewhere. To me, every use case appears speculative at this point bec=
ause the annex isn&#39;t available. However, if you believe that time-locke=
d vaults are important for Bitcoin and also acknowledge that soft forks, su=
ch 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.</div=
></div></blockquote><div><br></div><div>To support this use case of the tap=
root annex, I&#39;ve create a simple demo application here:=C2=A0<a href=3D=
"https://github.com/joostjager/annex-covenants">https://github.com/joostjag=
er/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 - on=
ly move to a pre-defined final destination. It makes use of the annex to st=
ore 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 m=
asse and also that the destination address itself is known.</div><div><br><=
/div><div>The application may not be the most practically useful, but more =
advanced covenants such as time-locked vaults can be implemented similarly.=
</div><div><br></div><div>Hopefully this further raises awareness of the on=
-chain ephemeral signature backup functionality that the annex uniquely ena=
bles.</div><div><br></div><div>Joost</div></div></div>

--000000000000a17bad05fe8ed2e0--