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
|
Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 42AACC000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Apr 2021 00:35:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2DC9C40214
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Apr 2021 00:35:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 mdRdv3JVolf6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Apr 2021 00:35:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com
[IPv6:2607:f8b0:4864:20::102b])
by smtp2.osuosl.org (Postfix) with ESMTPS id EE4E3401F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Apr 2021 00:35:42 +0000 (UTC)
Received: by mail-pj1-x102b.google.com with SMTP id nh5so3002531pjb.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Apr 2021 17:35:42 -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=qDAWKMds9d7aVA7PR/ggA4fxiUdWU5ooDzR58tKS048=;
b=qDWadg4u2S+hJUlpNwkwjhoPmFGYLd9QohtfsQRWHFWs4kv/EN7TtBI5F4xfDMfvnE
BG0Ps6874xaC7wpJ4PpwwNSg47LkGQ+vPVB++v5Ovc0jQj5RHXIqdqhdivpfD5ueDB/S
ySqMXd1ecmMIsrdfFXsotB/afj/VQmvQNyQAuf/RhsAIQlcCIw6k7nJsWehzU/V5PkSX
iDFhtSnCelI7UB7Og+MJs5Lgmm/4jQznRMMGLWdTsTVRTQ2u9+lEIBuYQa6xNtX2VcEa
JovdwDYQHjMLOH6IskJdF3L3L0j+3mNmE3fjr9R7ZBp+L1RXcvdHI8ijy35O5g8nH7q8
KH7g==
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=qDAWKMds9d7aVA7PR/ggA4fxiUdWU5ooDzR58tKS048=;
b=rQmkNVCF213UffL1xxmKKuGCmFCaqrgJhoDFJfLPaVoJGFOVfQl11jSgnfRz2L/5YI
ZFmMQ+Ye+JnLgC40KHly81EZL4b0d3FH4bXJ+gzTmYZ7FpYqeHwSKOUlEykyGnbFXBOL
KHfMXcMypPREMGJW3savBqH9giaq6oUqjthBqGAmfSmE5tfTGtWwkFMLBcR50kKskYh4
u4ol8LhQhQvwdOj220q6rV2OJkMQd8H6GAoeJjYddJaZGHnfJMXZwDofI/1pY+OtkAp0
NL50ZWkTv8Con5WCEFjraTgwSTpk03odGvrAF+sXb4jORD3nSZAoueQa0pc1OgCqqWuf
ynRg==
X-Gm-Message-State: AOAM532HPWQwymNPUwpHjSSesFVSPScjaWlCxD0CfqvWIfrThPPU+ewn
dzZjq3SPRdpg8V8ZTbXhqKscWtt/nXiPWkTB1CFPAEoUYSe7Gw==
X-Google-Smtp-Source: ABdhPJxNglyiFizo7nCP9wKIKJ4ZzuzjnNcdSxASj4KSb6o19dmGeIYUEJuEjmBus8IAQ5skqx4kQ4HnZAa40pEplWQ=
X-Received: by 2002:a17:90a:aa11:: with SMTP id
k17mr12739307pjq.60.1617582942064;
Sun, 04 Apr 2021 17:35:42 -0700 (PDT)
MIME-Version: 1.0
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
<CAH5Bsr22oQ_yOD1eom6gZhUVbr+bMj2W8rfWO=Edujhj9bNsEg@mail.gmail.com>
In-Reply-To: <CAH5Bsr22oQ_yOD1eom6gZhUVbr+bMj2W8rfWO=Edujhj9bNsEg@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 5 Apr 2021 10:35:14 +1000
Message-ID: <CAH5Bsr1P7L0Y1Lqq2jXHOD_hxSfsgZRK9a3_qGS8s7JMixBmxQ@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a8137d05bf2ee07d"
X-Mailman-Approved-At: Mon, 05 Apr 2021 21:47:48 +0000
Subject: Re: [bitcoin-dev] New PSBT version proposal
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, 05 Apr 2021 00:35:44 -0000
--000000000000a8137d05bf2ee07d
Content-Type: text/plain; charset="UTF-8"
On Wed, 10 Mar 2021 at 11:20, Lloyd Fournier <lloyd.fourn@gmail.com> wrote:
> Hi Andrew & all,
>
> I've been working with PSBTs for a little while now. FWIW I agree with the
> change of removing the global tx and having the input/output data stored
> together in the new unified structures.
>
> One thing I've been wondering about is how output descriptors could fit
> into PSBTs. They are useful since they allow you to determine the maximum
> satisfaction weight for inputs so you can properly align fees as things get
> added. I haven't seen any discussion about including them in this revision.
> Is it simply a matter of time before they make it into a subsequent PSBT
> spec or is there something I'm missing conceptually?
>
Sipa replied to me off list some time ago and explained what I was missing.
PSBTs have all the information you could want from a descriptor already.
For example the maximum satisfaction weight can be determined from the
witness/redeem script (I had forgot these fields existed). Therefore
descriptors are more useful in higher level applications while PSBTs are
useful for communicating with signing devices. Therefore there is no reason
for PSBTs to support descriptors.
LL
--000000000000a8137d05bf2ee07d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, 10 Mar 2021 at 11:20, Lloyd F=
ournier <<a href=3D"mailto:lloyd.fourn@gmail.com">lloyd.fourn@gmail.com<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Hi Andrew & all,</div><div><br></div><div>I've=
been working with PSBTs for a little while now. FWIW I agree with the chan=
ge of removing the global tx and having the input/output data stored togeth=
er in the new unified structures.</div><div><br></div><div>One thing I'=
ve been wondering about is how output descriptors could fit into PSBTs. The=
y are useful since they allow you to determine the maximum satisfaction wei=
ght for inputs so you can properly align fees as things get added. I haven&=
#39;t seen any discussion about including them in this revision. Is it simp=
ly a matter of time before they make it into a subsequent PSBT spec or is t=
here something I'm missing conceptually?</div></div></blockquote><div><=
br></div><div><br></div><div>
Sipa replied to me off list some time ago and explained what I was missing.=
PSBTs have all the information you could want from a descriptor already. F=
or example the maximum satisfaction weight can be determined from the witne=
ss/redeem script (I had forgot these fields existed). Therefore descriptors=
are more useful in higher level applications while PSBTs are useful for co=
mmunicating with signing devices. Therefore there is no reason for PSBTs to=
support descriptors.<br></div><div><br></div><div>LL<br></div><div><br></d=
iv><br></div></div>
--000000000000a8137d05bf2ee07d--
|
