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
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7BB35C0893
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2020 15:22:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 70B022043E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2020 15:22:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DfjZNvq9Osk2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2020 15:22:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.wpsoftware.net (wpsoftware.net [96.53.77.134])
by silver.osuosl.org (Postfix) with ESMTP id 24703203E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2020 15:22:03 +0000 (UTC)
Received: from boulet (boulot.lan [192.168.0.193])
by mail.wpsoftware.net (Postfix) with ESMTPSA id 2B479400DB;
Wed, 23 Dec 2020 15:22:02 +0000 (UTC)
Date: Wed, 23 Dec 2020 15:22:01 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: fiatjaf <fiatjaf@alhur.es>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20201223152201.GM106279@boulet>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
<5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
<1768da5c6f0.f63a34dc413157.2741477427673569054@alhur.es>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="7sazZNykp/fVZQka"
Content-Disposition: inline
In-Reply-To: <1768da5c6f0.f63a34dc413157.2741477427673569054@alhur.es>
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: Wed, 23 Dec 2020 15:22:04 -0000
--7sazZNykp/fVZQka
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 23, 2020 at 12:30:20AM -0300, fiatjaf via bitcoin-dev wrote:
> Hi Andrew.
>=20
> I'm just a lurker here and I have not much experience with PSBTs, but sti=
ll let me pose this very obvious question and concern: isn't this change go=
ing to create a compatibility nightmare, with some software supporting vers=
ion 1, others supporting version 2, and the ones that care enough about UX =
and are still maintained being forced to support both versions -- and for n=
o very important reason except some improvements in the way data is structu=
red?
>
Yes, software will have to support both versions for a long time (likely
forever, at least in the case of Core). But I think this is okay, for a
couple of reasons:
1. it is very easy to convert from the old to new format, and from new to
old (unless the new one uses features unsupported by the old). Indeed,
the conversion logic is essentially the same as the logic that the
Extractor role uses, so there isn't even that much redundant code.
2. There actually isn't a lot of software using PSBT out there, and most
of that that does use PSBT is under rapid development. The obvious
exception to this deployed hardware wallets, but as far as "software
developers supporting old things for the sake of old hardware wallets"
I think this transition is an order of magnitude simpler to handle
than many of the ad-hoc protocol changes that individual vendors have
done. In other words this is a "fact of life", and not even one of
the grosser ones.
3. PSBT is pretty-much a dumb pure data format, and the diff between the
new format and the old is pretty small.
> Ultimately I don't think it should matter if some data is structured in n=
ot-the-best-possible way, as long as it is clear enough for the computer an=
d for the libraries already written to deal with it. Backwards-compatibilit=
y and general interoperability is worth much more than anything else in the=
se cases.
>
The reasons for switching to PSBT 2 are actually more than just structuring
the data in a cleaner way. I agree that if the point of this upgrade were
just elegance, it would not be worth the compatibility loss. But there are
practical limitations that this proposal eliminates:
1. PSBT provides no way to modify the set of inputs or outputs after the
Creator role is done.
2. Because of this, it forces certain things (e.g. locktimes and sequence
numbers) to be chosen by the Creator, who may not have all the relevant
information, and who certainly might not have it before any Updaters
have done their part.
as well, of course, as elegance reasons:
3. Parsers of the existing PSBT need to understand the Bitcoin transaction
format just to learn e.g. how many inputs and outputs there are. It is
impossible to parse a PSBT without also parsing (almost) the whole
transaction.
4. Similarly to cross-check fields like 'non_witness_utxo' which are
committed to in the transaction, you have to parse the whole transaction
just to make sure that the purely-redundant data is correctly redundant.
5. If you put a 0-input transaction into a PSBT (which would be pointless
because there's no way to add inputs, but it's not forbidden so your
software still has to deal with this somehow..), you need a different
transaction parser than the normal one, because there is an ambiguity
related to segwit that PSBT resolves differently.
It's also worth considering that PSBT is a young protocol, and future
extensions will be easier starting from PSBT 2 than starting from the
original version.
=20
> Also let me leave this article here, which I find very important (even if=
for some reason it ends up not being relevant to this specific case): http=
://scripting.com/2017/05/09/rulesForStandardsmakers.html
>=20
--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--7sazZNykp/fVZQka
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAl/jYJYACgkQxYjWPOQb
l8Hr7Af+ObIbXCpcP8KzehFmBG9f2K/o2zkrI2HnZk6DufOCkGgQkNr2c5BYf9IW
yMgKf286QXfl6L02tH7rTquTr9v/jNNazFJFnx/+DKpCXeTMaUgcaGepVU2JyfYq
HiFbnGqFFlJomwX4JMUFHQjfgH7P0YlT098ZFwneO4/C7mkZtG2qIIU7DVi+W6E5
/C0H4tZht1AJcqEzM2YcCtnyelCrF3xChCfhNKTGg3W7o53JtQN7VD0tNw+vgfyC
Pn39UFK1qDCbtygYcLS+OIoT0KXyGq56aNafskC7LLit6FTdzSkVthAobx1v7Oif
AROa0jseK6Znp9kaB4K8l93PfDTSug==
=pOgg
-----END PGP SIGNATURE-----
--7sazZNykp/fVZQka--
|
