From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BB35C0893 for ; 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 ; 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 ; 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 ; 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 To: fiatjaf , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--