Jonathan Underwood [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-26 📝 Original message:It is very common to set ...

📅 Original date posted:2020-11-26
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


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

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

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201127/e60d2a92/attachment.html>;