It is very common to set aside one or more "version slots" for proprietary usage so that people adding their own features don't use version 7 only to have the official BIP add a REAL version 7 a couple months later.
It makes perfect sense to just say "anyone adding their own stuff, format your versions like this and stay out of our way"
As a BIP174 library, you don't have to add logic to "support" those versions, just treat them as unknown. The only people who will need to worry about the logic of parsing and encoding those versions are apps that utilize them.

2020年11月17日(火) 8:41 Ferdinando M. Ametrano via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
After having checked that the BIP174 test vectors do not cover the proprietary and proof-of-reserves types, I went ahead and submitted a PR to the bips repo for the removal of those fields from the PSBT specifications


--
Ferdinando M. Ametrano


On Tue, Nov 17, 2020 at 12:01 AM Ferdinando M. Ametrano <ferdinando@ametrano.net> wrote:
Hi all,

While implementing PSBT support in the btclib library (https://github.com/btclib-org/btclib), I have failed to understand the rationale for the proprietary and proof-of-reserves types.

First off, at face value they have nothing to do with the operations intrinsically required to finalize a valid transaction from PSBT manipulation.

Moreover, whatever information content they can provide for non-standard PSBT manipulation, that content could stay in the unknown field without any loss of generality. How to structure and deal with unknown data would be the responsibility of proprietary software or users wanting to provide proof-of-reserve. As long as BIP174 clearly prescribes that unknown data must be kept during PSBT manipulation, that should be enough.

Let me stress the above point: I have a project where we include proprietary information in the PSBT. Any PSBT software supporting unknown data gently keeps our proprietary information and our proprietary software retrieves that data from serialized PSBT with no problem. There is no need for a PSBT implementation to provide explicit support for proprietary and proof-of-reserves types.

My last conclusion is reinforced by the evidence of all PSBT implementations I know of, including bitcoin core and HWI, not implementing proprietary and proof-of-reserve types. There is a high probability that part of BIP174 would be just ignored.

Am I missing something?

Thanks
--
Ferdinando M. Ametrano
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3