On Wed, Dec 23, 2020 at 12:30:20AM -0300, fiatjaf via bitcoin-dev wrote:
> Hi Andrew.
> 
> I'm just a lurker here and I have not much experience with PSBTs, but still let me pose this very obvious question and concern: isn't this change going to create a compatibility nightmare, with some software supporting version 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 no very important reason except some improvements in the way data is structured?
>

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 not-the-best-possible way, as long as it is clear enough for the computer and for the libraries already written to deal with it. Backwards-compatibility and general interoperability is worth much more than anything else in these 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.

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

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