[bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174

[bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174

[Ferdinando M. Ametrano]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

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*
www.ametrano.net/about

[-- Attachment #2: Type: text/html, Size: 3773 bytes --]

Re: [bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174

[Ferdinando M. Ametrano]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

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

https://github.com/bitcoin/bips/pull/1038

--
*Ferdinando M. Ametrano*
www.ametrano.net/about


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*
> www.ametrano.net/about
>

[-- Attachment #2: Type: text/html, Size: 5623 bytes --]

Re: [bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]

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
>
> https://github.com/bitcoin/bips/pull/1038
>
> --
> *Ferdinando M. Ametrano*
> www.ametrano.net/about
>
>
> 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*
>> www.ametrano.net/about
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


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

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

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 7451 bytes --]