From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: fiatjaf <fiatjaf@alhur•es>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New PSBT version proposal
Date: Wed, 23 Dec 2020 15:22:01 +0000 [thread overview]
Message-ID: <20201223152201.GM106279@boulet> (raw)
In-Reply-To: <1768da5c6f0.f63a34dc413157.2741477427673569054@alhur.es>
[-- Attachment #1: Type: text/plain, Size: 4068 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-23 15:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 22:25 Andrew Chow
2020-12-10 11:28 ` Sanket Kanjalkar
2020-12-16 17:44 ` Andrew Poelstra
2020-12-22 20:12 ` Andrew Chow
2020-12-23 3:30 ` fiatjaf
2020-12-23 15:22 ` Andrew Poelstra [this message]
2020-12-23 21:30 ` Andrew Chow
2021-01-02 6:34 ` Jeremy
2020-12-23 21:32 ` Andrew Chow
2021-01-15 17:28 ` Andrew Chow
2021-01-21 19:50 ` Andrew Chow
2021-01-06 23:26 ` Rusty Russell
2021-01-06 23:48 ` Andrew Chow
2021-01-08 0:40 ` Rusty Russell
2021-01-14 17:07 ` Andrew Chow
2021-03-10 0:20 ` Lloyd Fournier
2021-04-05 0:35 ` Lloyd Fournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201223152201.GM106279@boulet \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=fiatjaf@alhur$(echo .)es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox