From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 01126C0052 for ; Thu, 26 Nov 2020 23:32:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id D8554878BA for ; Thu, 26 Nov 2020 23:32:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am4k-V36qXX6 for ; Thu, 26 Nov 2020 23:32:12 +0000 (UTC) X-Greylist: delayed 00:07:28 by SQLgrey-1.7.6 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by whitealder.osuosl.org (Postfix) with ESMTPS id ADF7A875DC for ; Thu, 26 Nov 2020 23:32:12 +0000 (UTC) Received: by mail-qk1-f181.google.com with SMTP id h20so2953731qkk.4 for ; Thu, 26 Nov 2020 15:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitcoinbank.co.jp; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fJMJ8w8iNXG3KWIhF4kNrW06zizuBryH1CUXU2DIeGA=; b=RVlgbrIg3cziccqGKAMdsy/EYdHvMalPlXRVCXKublj7CeVoYZ6VFYZacJVEgyHg8a HMob+O/3Ui19JROZ1GF7Z0BaSAEdjlQZ8VZkRnFWLelh2iJtM5BaKFzrEikazkT4X+hx Enp2uzGl5dhK9WzvrOlAPiUwBovblNfRqsVtWSL5pwsUORlimwjOcFuleCYPMYYMlWhf tZn6JGQpOoQGVEbs3znNQVbSQsu+wNh53gxyZJ6mvnbWUcUcmv9gAo5uNsTlXmPqWS5m HNRrOTcn6wBBR9cNoQFoHY4f65h/WdqHTwIagzulpQ8lFTNUT2wYTQUFghxYLi0En30c qnkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fJMJ8w8iNXG3KWIhF4kNrW06zizuBryH1CUXU2DIeGA=; b=sNf5r+FFg2hSl0VLIvBgWRYbtDQ3LPLmAPqCvVXyH2PwnJPLGFJ8PZYS3NDir12VkB qPLvY97mvrVvcD1UQHWbd7yGDI9kFccFqntLuJCCnqJpBOUUi13tMWZVvBjy+8pF3FJ8 /okMxImXfi6abBzik6XrGjPDg26XRPcv80l+SP6QdMsdM62ELcqbxGWaSxLCAVHDiDJD XdKfc2vKzRpHlvC7BmLrcY+MhvHv+j+9fTaXZgyfusu6H/j8MTyhfNJihKM4YugUC3FL KJl+rT48HeaSCX5coh8jX68Av65ZJS4lI1I8xWGMOSU0qBTSwtMNdwMJNGe2VVb9S+Bc sZJw== X-Gm-Message-State: AOAM531CtT/8qAsnSoaqZn+tZw+IMxX/ZqgWdYJHr/mTxB08xG8z67mp Ww86j1jmS3Iyj/EtbgZ00x7YmsYsbcMDefBLLTtfhgLo5II2 X-Google-Smtp-Source: ABdhPJzE1NY86tjH7c4y+RuJuZK2LvCJrIKoNHQyZS4NZeKR3L2fu3i61PahYJp1OorWh9rynFDOwDGqUpb9fqXmcPU= X-Received: by 2002:a37:a312:: with SMTP id m18mr5686126qke.268.1606433082914; Thu, 26 Nov 2020 15:24:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Underwood Date: Fri, 27 Nov 2020 08:24:32 +0900 Message-ID: To: "Ferdinando M. Ametrano" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000043517805b50ad976" X-Mailman-Approved-At: Fri, 27 Nov 2020 08:09:46 +0000 Subject: Re: [bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 23:32:14 -0000 --00000000000043517805b50ad976 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E5=B9=B411=E6=9C=8817=E6=97=A5(=E7=81=AB) 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 d= ata >> 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 enoug= h. >> >> Let me stress the above point: I have a project where we include >> proprietary information in the PSBT. Any PSBT software supporting unknow= n >> data gently keeps our proprietary information and our proprietary softwa= re >> retrieves that data from serialized PSBT with no problem. There is no ne= ed >> 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 implement= ing >> 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 > --=20 ----------------- Jonathan Underwood =E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81= =E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3= =82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC ----------------- =E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81= =AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94= =E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82 =E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3 --00000000000043517805b50ad976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is very common to set aside one or more "version s= lots" for proprietary usage so that people adding their own features d= on'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 ad= ding their own stuff, format your versions like this and stay out of our wa= y"
As a BIP174 library, you don't have to add logic to "su= pport" 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=E5=B9=B411=E6=9C=8817=E6=97=A5(=E7=81=AB) 8= :41 Ferdinando M. Ametrano via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:=
After hav= ing=C2=A0checked that the BIP174 test vectors do not cover the=C2=A0prop= rietary=C2=A0and=C2=A0proof-of-reserves=C2=A0types, I went ahead= and=C2=A0submitted a PR to the bips repo=C2=A0for the removal of those fie= lds from the PSBT specifications
<= font face=3D"verdana, sans-serif">
https://github.com/bitcoin/bips/pull/1= 038

--
Ferdinando M. Ametrano
<= /div>


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

While implement= ing 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 h= ave nothing to do with=C2=A0the operations intrinsically required to final= ize a valid transaction from PSBT manipulation.

Moreover, whatever i= nformation content they can provide for non-standard PSBT manipulation, tha= t content could stay in the unknown field without any loss of genera= lity. How to structure and deal with unknown data would be the responsibili= ty=C2=A0of proprietary=C2=A0software or users wanting to provide proof-of-r= eserve. As long as BIP174 clearly prescribes that unknown=C2=A0data 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 pr= oprietary information and our proprietary software retrieves that data from= serialized PSBT with no problem. There is no need for a PSBT implementatio= n to provide explicit support for=C2=A0proprietary and proof-of-r= eserves types.

My last conclu= sion is reinforced by the evidence of all PSBT implementations I know of, i= ncluding bitcoin core and HWI, not implementing proprietary and proof-of-re= serve types. There is a high probability that part of BIP174 would be just = ignored.

Am I missing something?

Thanks
<= div dir=3D"ltr">
--
Ferdinando M. Ametrano=
=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
-----------------
Jonathan Underwood
= =E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3= =83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83= =B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
----------------= -

=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3= =83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82= =8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B= =E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3= =80=82

=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3= FDAD998682F3590FEA3
--00000000000043517805b50ad976--