Ferdinando M. Ametrano [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-16 📝 Original message:After having checked that ...
📅 Original date posted:2020-11-16
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201117/3fe0ccf0/attachment.html>;
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201117/3fe0ccf0/attachment.html>;