summaryrefslogtreecommitdiff
path: root/67/07d026fc4ad309e53830b9911accf5db5f3ddb
blob: e36992d16aab4071a5e695aac94fe622aea2230f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
Return-Path: <joost.jager@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 63C17C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 07:50:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3E6F3844B4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 07:50:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3E6F3844B4
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=sIcbOkHQ
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HdyipzRSzhhQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 07:50:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F2E70844AC
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [IPv6:2a00:1450:4864:20::634])
 by smtp1.osuosl.org (Postfix) with ESMTPS id F2E70844AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 07:50:14 +0000 (UTC)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-9768fd99c0cso164653466b.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Jun 2023 00:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685778612; x=1688370612;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=p+PNlPBs9GTQ2LTa+q4SamwEYydRRQboImkOTMl9Hxs=;
 b=sIcbOkHQSSEiGIWRdpFz8AUXTs+wsj0xob70gMGGzXhKaJiBi4/ZPKQRvsJT8e1Yrr
 sYAb0fN/SaSUdE5iO7/Yk+gifxonkuqDEadQe9ahD6GUTakzQ6oKaEn9YwrgG5Gr5xNF
 IGDEHdBLOsMLmBNQmdUeZK1i9OuXKMz8b37DFDYH3g1BiKA6WZhDLpEl3fjeoyqpF6z3
 crcgvRV0xZppwfmBwRYh62prJb/DXn2UChFaBUCPjBxbpEhV5xUe4dsoemhvrEspYgIe
 LjnxLST9xMTjV9zXTTQ75Nw8u7szae8TwA/orgNmei82ouEr/ri074odGczWrjPo3rYe
 wMHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685778612; x=1688370612;
 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=p+PNlPBs9GTQ2LTa+q4SamwEYydRRQboImkOTMl9Hxs=;
 b=fzDCJ8aqIMKHIkqWsxCSdUlLeFrHYZ7x+3gvr+a0s0IwJngQswvwQdDKcOpK2VdX88
 e3lBlxcMqy9PUNHItkMN06H6Zj7ifN4NV5bL5VQyzr7ldsYtWE+HBE5BzdjV/FXpFYsT
 RKG3brSzUQLcMmapFLErSzN2UHOn5zA5e+SHr7As1v/KtKzYhobT8m6iLSmlDjfx2xRJ
 hJ9aKr+Eko6j3fUPDf6XKOXNEQ09bXWH4wlKR4Ooud1DjFNRyJ2a2Lix7ct95OWVmZRY
 etz+akO2B+nNeeNG3+62sFYlq/1hGH2TM6zOQufgaycQJs8iOEILoUeXtSqjq+fOJaOi
 UC2Q==
X-Gm-Message-State: AC+VfDzsx3V06CHki5kho6kVQBDjmw8dmiyNQSAsjIZu6rGXdHQoCzf1
 Sy27o5XKkUryAdyyNJCFel6/N+rN+h8Rxvs09+I=
X-Google-Smtp-Source: ACHHUZ607kz2bNKJjMhviOOEiRILEjzZbPvkSSYEbtG5j6iebQ+VSstSXVJzn31O9wV//6itucXtwEqeI25SSPH/qk0=
X-Received: by 2002:a17:907:9623:b0:96f:7636:65ca with SMTP id
 gb35-20020a170907962300b0096f763665camr833769ejc.3.1685778612402; Sat, 03 Jun
 2023 00:50:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
In-Reply-To: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 09:49:36 +0200
Message-ID: <CAJBJmV9JYYOSJXbzhrGTrv3jf_qGoLRbq9COgbBmuinpNAOhDg@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000005cc11b05fd34ebfd"
X-Mailman-Approved-At: Sat, 03 Jun 2023 07:53:59 +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, 03 Jun 2023 07:50:16 -0000

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

Hi David,

On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David A. Harding <dave@dtrt.org> wro=
te:

> Out of curiosity, what features and benefits are available today?  I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>

Indeed, there's a minor efficiency gain in the reveal transaction witness,
but I think the real advantage is that it eliminates the need to publish
and pay for the commit transaction in the first place. Any spend of a
taproot UTXO can be supplemented with arbitrary data in just a single
transaction.


> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?


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 housed.
This feature can be beneficial in scenarios that require the emulation of
covenants through the use of presigned transactions involving an ephemeral
signer.

For instance, one can establish a time-locked vault using 2-of-2 multisig
presigned transactions in which one of the signers is ephemeral [1]. After
signing, the private key is discarded, leaving only the signature. To
ensure the signature is never lost, it can be stored as a backup in the
annex of the transaction that the presigned transaction spends. Such an
operation would not be possible with a commit/reveal inscription.

[1] https://github.com/LedgerHQ/app-bitcoin-new/issues/153

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

<div dir=3D"ltr"><div>Hi David,</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David=
 A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wrot=
e:</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">
Out of curiosity, what features and benefits are available today?=C2=A0 I <=
br>
know Greg Sanders wants to use annex data with LN-Symmetry[1], but <br>
that&#39;s dependent on a soft fork of SIGHASH_ANYPREVOUT.=C2=A0 I also hea=
rd you <br>
mention that it could allow putting arbitrary data into a witness <br>
without having to commit to that data beforehand, but that would only <br>
increase the efficiency of witness stuffing like ordinal inscriptions by <b=
r>
only 0.4% (~2 bytes saved per 520 bytes pushed) and it&#39;d still be <br>
required to create an output in order to spend it.<br></blockquote><div><br=
></div><div>Indeed, there&#39;s a minor efficiency gain in the reveal trans=
action witness, but I think the real advantage is that it eliminates the ne=
ed to publish and pay for the commit transaction in the first place. Any sp=
end of a taproot UTXO can be supplemented with arbitrary data in just a sin=
gle transaction.<br></div><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">
Is there some other way to use the annex today that would be beneficial <br=
>
to users of Bitcoin?</blockquote><div><br></div><div>The removal of the nee=
d for a commitment transaction also enables the inclusion of data within a =
single transaction that relies on its own transaction identifier (txid). Th=
is is possible because the txid calculation does not incorporate the annex,=
 where the data would be housed. This feature can be beneficial in scenario=
s that require the emulation of covenants through the use of presigned tran=
sactions involving an ephemeral signer.<br><br>For instance, one can establ=
ish a time-locked vault using 2-of-2 multisig presigned transactions in whi=
ch one of the signers is ephemeral=C2=A0[1]. After signing, the private key=
 is discarded, leaving only the signature. To ensure the signature is never=
 lost, it can be stored as a backup in the annex of the transaction that th=
e presigned transaction spends. Such an operation would not be possible wit=
h a commit/reveal inscription.<br></div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"https://github.com/LedgerHQ/app-bitcoin-new/issues/153">https://github=
.com/LedgerHQ/app-bitcoin-new/issues/153</a></div></div></div>

--0000000000005cc11b05fd34ebfd--