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
|
Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 88E50C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Jun 2021 10:03:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 6A79F605F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Jun 2021 10:03:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level:
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
tests=[BAYES_50=0.8, 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
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 JgOXH4v5un7c
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Jun 2021 10:03:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
[IPv6:2a00:1450:4864:20::12d])
by smtp3.osuosl.org (Postfix) with ESMTPS id 32F45600CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Jun 2021 10:03:56 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id u13so31641644lfk.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Jun 2021 03:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=ALeCQRjJLt1Okov2vXrMpVK6EzM9kGKSDWaHQX6dHdA=;
b=m8IHh29V3aAS3/TquwNQhmoGDWdw01+EINkLNdKaRtH10y9gggJxP28s+JqG39v9a2
LUdiIBdMRuAYu1jb/AGLd1x1EGYZBLL4f5CuQ2N/xYTiDtRGJcb2AAsJWyVtwBn4tHhP
LdOUi9EbLVVR4gTxW86ywtZvVvgHUg/AnnnV8uMg+wGQPYR0615C8yALlyKSV5khxBny
+IEMRpoSXF1LU+nKzf9ojxsvr66pNA/ASssCJ9jG8LhDvAFzBj4ICxaBY3lrXRgRnffD
MmBdQqDIW2ut94tt966kCyNRgG5u0KVf3iYDqjq5MBeMkZitp8hbZKrS3dKCAlrTg2MD
9TSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=ALeCQRjJLt1Okov2vXrMpVK6EzM9kGKSDWaHQX6dHdA=;
b=rfBvQNFtX2EqqZeL3andTR91030hbbE0Ie+DrRBdzUHReO+EYnHZjYoShqTG3CYeG4
SwZhuOnyDO7mCL8OuYXNPybYxDBL0vrmbElkehsWRXs1ayDHNAIuHIu9R5W9Qx4iNRXY
Uw+bvfFPZoMU9GbHtplhmIlKcFQM3rt6Ul6y8qIrHC0W1OlyUhPR8/JhBmLz9LwYF9cH
y6sDETOtjv012jhPwA6d2XzFuSFgBh49LyacbfD/BeIsbjUUbEGg0eNZwxk2XKBFLFRL
/cbXAnyHjmJ3ZTNC4FWJgBaGFwNrom4iTEoGnpOwEkNJXS/lehYiVTFREFZHyJ6tLFwl
WDIw==
X-Gm-Message-State: AOAM532cfARBywIdW44ZcnaVkiu7gjWcvdKftpm/nElUyFldN554JbHz
stsi110LF19z39dWrJAQ6zqHfaQekDQnmXJ9DHA=
X-Google-Smtp-Source: ABdhPJw0i4DVMcjAVRqfsEnV0+s4qOvkpFlf4p6zEhevXFx0bU5CzY7UQEeq+aN0WVIrBcbVIWiw1sbq7ORmLxPTpWM=
X-Received: by 2002:a05:6512:344d:: with SMTP id
j13mr17685925lfr.19.1624874633762;
Mon, 28 Jun 2021 03:03:53 -0700 (PDT)
MIME-Version: 1.0
References: <795f917b-3883-1827-f39b-35123b500f36@achow101.com>
In-Reply-To: <795f917b-3883-1827-f39b-35123b500f36@achow101.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Mon, 28 Jun 2021 12:03:42 +0200
Message-ID: <CAMhCMoF7N4BuXDz1cSDBLi5zH8c06uZ3T3gc750azFH3JagcNw@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000599c7d05c5d09b60"
X-Mailman-Approved-At: Mon, 28 Jun 2021 10:05:59 +0000
Subject: Re: [bitcoin-dev] Taproot Fields for PSBT
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: Mon, 28 Jun 2021 10:03:58 -0000
--000000000000599c7d05c5d09b60
Content-Type: text/plain; charset="UTF-8"
Hi Andrew,
I just have a small suggestion on this proposal.
On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> | Taproot Leaf Script
> | <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt>
> | <tt><control block></tt>
> | The control block for this leaf as specified in BIP 341. The control
> block contains the merkle tree path to this leaf.
> | <tt><script> <8-bit uint></tt>
> | The script for this leaf as would be provided in the witness stack
> followed by the single byte leaf version.
>
So far, all the defined PSBT types had a relatively short keydata (not much
bigger than a couple of pubkeys).
I think that is a desirable property to keep, as it is often a reasonable
assumption that dictionary keys are not very large.
The control block as per BIP 341 can be up to 33 + 32*128 = 4129 bytes long.
Perhaps it would be better to split this into PSBT_IN_TAP_LEAF_SCRIPT
and PSBT_IN_TAP_LEAF_CONTROL_BLOCK (both with no keydata)?
Best,
Salvatore Ingala
--000000000000599c7d05c5d09b60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hi Andrew,<div><br></div><div>I just have=
a small suggestion on this proposal.</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 22 Jun 2021 at 23:29, An=
drew Chow via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">| Taproot Leaf Script<br>
| <tt>PSBT_IN_TAP_LEAF_SCRIPT =3D 0x15</tt><br>
| <tt><control block></tt><br>
| The control block for this leaf as specified in BIP 341. The control<br>
block contains the merkle tree path to this leaf.<br>
| <tt><script> <8-bit uint></tt><br>
| The script for this leaf as would be provided in the witness stack<br>
followed by the single byte leaf version.<br></blockquote><div><br></div><d=
iv>So far, all the defined PSBT types had a relatively short keydata (not m=
uch bigger than a couple of pubkeys).</div><div>I think that is a desirable=
property to keep, as it is often a reasonable assumption that dictionary k=
eys are not very large.</div><div>The control=C2=A0block as per BIP 341 can=
be up to 33 + 32*128 =3D 4129 bytes long.<br></div><div><br></div><div>Per=
haps it would be better to split this into PSBT_IN_TAP_LEAF_SCRIPT and=C2=
=A0PSBT_IN_TAP_LEAF_CONTROL_BLOCK (both with no keydata)?</div><div><br></d=
iv><div>Best,</div><div>Salvatore Ingala</div><div><br></div></div></div>
--000000000000599c7d05c5d09b60--
|
