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
|
Return-Path: <joost.jager@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2435CC0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Jun 2023 09:37:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EC8AF60BAD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Jun 2023 09:36:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EC8AF60BAD
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=seSPHc0W
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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id VW4Fb6Wt5XV9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Jun 2023 09:36:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 93F6860BAB
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
[IPv6:2a00:1450:4864:20::62a])
by smtp3.osuosl.org (Postfix) with ESMTPS id 93F6860BAB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Jun 2023 09:36:58 +0000 (UTC)
Received: by mail-ej1-x62a.google.com with SMTP id
a640c23a62f3a-9827bd8e0afso197581766b.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Jun 2023 02:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1686821816; x=1689413816;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=sgjDY86AqC1nn+a1WwYP71J0Sscqrwk0dDdfnDlS5BY=;
b=seSPHc0WYrMipfBrgPmhwFB4As19aBcbKUwDbOmKFwJkEpiY+rhqYBqZXaKgUME0Yj
+u43KgTZvelpcKTG+Ost2j7PvUgv6xyLAaRQwpZEWoX41F/wwXW9KlMMEbI3IAj83o91
NoNoEyUseY02szoy3XoxPB17DzV9oBNf2y8NWidZOr/RqWIb6DWhHAa8LsoszYbo6bMF
Eu01rU0l3ulTWUjkv+4BNQ1IAJA5eTa/ulWjzO2p9ApucaFeEfupeBvP94sPO4jI3fUY
oX+OxBj0dNvcOH+BwcbfuQcTp1JDeWTJtwBbBFr3plbT63msru51tF5U8GHaO4Z9zckq
P9gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1686821816; x=1689413816;
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=sgjDY86AqC1nn+a1WwYP71J0Sscqrwk0dDdfnDlS5BY=;
b=kIUPUHqy7OpXiHYSQ97swkTw7kdZOiO8n9uUAv/QmHJkZ/cRhAAzVAjY9WITfyzp4/
PHxQ8L0W5u/3LBwn9iFb8CdrEmjMvTh3XrlawNzUkbP7Ms3pWZ+0EOsMherT5zZ5xyNz
3N1rSKuN5mDYtTb6wFCM2vuoM8/t3OEv2GRyFBwSpWfrn8azNeLULc1nsGqjjZq88LWK
DNm2V/GyVeb1iuFfAP2ujbZ2bdzw+ilpd6Pk02cpCL3uX78QV7/Za/k3NbNTTRYwDCAT
ruCXCYx1PhSyWNb6eSqZaZacr9cRzW2Fv3QWaEgpbrY7qCLYi/a51bpiuQ81Ukm1Xrjx
btng==
X-Gm-Message-State: AC+VfDzQc7dxGsaF7zr/VINH/3J7Ke4U1+4RHarRB40s3UeCXee9gEOo
qF6yUJ0Xu9RO1do/3yFXdMk+eFIbUK1DgNRRzDA=
X-Google-Smtp-Source: ACHHUZ5pZIlV7o4xLc5aff0KwV5BAyTOv183HYtL9MoibRRDwdKzNTnGqUSpidUIt/R2+NXmDrmB/N4KkMA63Q3knZQ=
X-Received: by 2002:a17:906:9b8d:b0:973:df9c:b1aa with SMTP id
dd13-20020a1709069b8d00b00973df9cb1aamr20009434ejc.71.1686821816403; Thu, 15
Jun 2023 02:36:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
<29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
<CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
In-Reply-To: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Thu, 15 Jun 2023 11:36:19 +0200
Message-ID: <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002a902e05fe27cfef"
X-Mailman-Approved-At: Thu, 15 Jun 2023 10:40:58 +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: Thu, 15 Jun 2023 09:37:00 -0000
--0000000000002a902e05fe27cfef
Content-Type: text/plain; charset="UTF-8"
Hi Greg,
Getting back to this:
Another solution could be to make annex usage "opt-in"
> by requiring all inputs to commit to an annex to be relay-standard. In
> this case, you've opted into a possible
> vector, but at least current usage patterns wouldn't be unduly affected.
>
Ignoring the argument that policy may provide a false sense of security, I
think this is an interesting idea. Opt-in would enable convenants through
presigned txes with atomic on-chain signature backup, without needing to
worry about non-annex multi-party protocols (coinjoin and dual funded
lightning mentioned previously) that may suffer from annex inflation or the
last signer presenting an unexpected annex. The downside is just that extra
empty annex byte per input, if there are other inputs involved. To me that
would be a reasonable trade-off.
Would it then still be necessary to restrict the annex to a maximum size?
Perhaps not opting into annex for multi-party protocols is sufficient. Or
otherwise, #24007 may be helpful. It is hard to pick a constant usually.
Joost.
--0000000000002a902e05fe27cfef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Greg,</div><div><br></div><div>Getting back to thi=
s:</div><div><br></div><div class=3D"gmail_quote"><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 id=3D"m_-3252546504006912555=
gmail-:3hl" aria-label=3D"Message Body" role=3D"textbox" aria-multiline=3D"=
true" style=3D"direction:ltr;min-height:85px" aria-controls=3D":3k2"><div>A=
nother solution could be to make annex usage "opt-in"</div><div>b=
y requiring all inputs to commit to an annex to be relay-standard. In this =
case, you've opted into a possible</div><div>vector, but at least curre=
nt usage patterns wouldn't be unduly affected.=C2=A0</div></div></div><=
/blockquote><div>=C2=A0</div><div>Ignoring the argument that policy may pro=
vide a false sense of security, I think this is an interesting idea. Opt-in=
would enable convenants through presigned txes with atomic on-chain signat=
ure backup, without needing to worry about non-annex multi-party protocols =
(coinjoin and dual funded lightning mentioned previously) that may suffer f=
rom annex inflation or the last signer presenting an unexpected annex. The =
downside is just that extra empty annex byte per input, if there are other =
inputs involved. To me that would be a reasonable trade-off.</div><div><br>=
</div><div>Would it then still be necessary to restrict the annex to a maxi=
mum size? Perhaps not opting into annex for multi-party protocols is suffic=
ient. Or otherwise, #24007 may be helpful. It is hard to pick a constant us=
ually.</div><div><br></div><div>Joost.</div></div></div>
--0000000000002a902e05fe27cfef--
|
