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
Precedence: list


--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--