From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A73E4C07FF for ; Mon, 16 Nov 2020 23:26:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 8B8FB20656 for ; Mon, 16 Nov 2020 23:26:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEPVcxlqoiSc for ; Mon, 16 Nov 2020 23:26:18 +0000 (UTC) X-Greylist: delayed 00:16:13 by SQLgrey-1.7.6 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by silver.osuosl.org (Postfix) with ESMTPS id 6E8C3203EA for ; Mon, 16 Nov 2020 23:26:18 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id d18so7611910edt.7 for ; Mon, 16 Nov 2020 15:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ametrano-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=I006URAWwSSmTwFTnaWJpLUqoPsSpwcFXn0WPcjpnWg=; b=u+n0LPzzSr7eJJe46OJJXjjHCFQeNetHU8YaIbw3vozCUdgV3pJA592Wzuyf1pkwtj yUE5h3IIlUpo8APi9bmWiib0nQa3mM8Sx79t0sznQdxH15+BDj8AYHm1PeKFKQKh4IKe 6hnPzGoSANl1ef45HnVDJIS3LCQTFOTs+iomijS/U1JewCctKrFtyS1tDOnjyXioBM+0 aGkUR3PWXR8SIQ7icR8x+qpPLBfUCkknV6xxnJM/XPVXAq+St6dajAx3QryhGMzFqNsU IWvKaVR8z6KEWc0XcRlRFR7N+LetDTy9Ka/WFGiH+E9IeTi61t1/GoiCxb4hSDoYLwch QhmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I006URAWwSSmTwFTnaWJpLUqoPsSpwcFXn0WPcjpnWg=; b=CDyJHPr9knqV676GBh1jYU4GBCWL7X07rkztaQy1aZo7pi/9UCBv4BkqMhh5ePICQS LEWKB/fhv14/bUnHSU0Af8Qr3He3AGO3aXpl4gU/yn45zkbkaYnf3X2WIhlbryo5ZZIL F+FrAlvrNsTvR+NxAg90F0R/iiLlR9fRGEVVPTBs0wvAaxWxhomUJrfJA9D91+rTT8qw P+uTI3m0RUxkELzcAkN+SD2H8s5UdXom+Xe/oAljq1AZMMPcF4rdQkVc1Tt9g3EWWzAv bNpRJ0ZzMYTeyugBJGBpqw8mqe4iIKrRIy4jku8j16Ed3BgRLmXQEtoeu8qhzB3OtX/Y zFGQ== X-Gm-Message-State: AOAM532VjqbhyhqsCdE7oBVtYX/MsAkTB/P0xhfonYW4SyJDX0e1hyba AwXfO0cwqOkM1HN5jAUPDSqD3DiApM1eWpY4i6rtYsHyMu0n8SRmXbs= X-Google-Smtp-Source: ABdhPJxwYKw4Okr00Ek4IcpqeXhvLlYHumZy2kgRK9mPdrKQy9J8HKcbcmVjaDEfUP18A/R14Sqx6yxsfDWCf4gkyBA= X-Received: by 2002:a17:906:35da:: with SMTP id p26mr16945212ejb.256.1605567730185; Mon, 16 Nov 2020 15:02:10 -0800 (PST) MIME-Version: 1.0 From: "Ferdinando M. Ametrano" Date: Tue, 17 Nov 2020 00:01:34 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000388fc605b4415e3a" X-Mailman-Approved-At: Mon, 16 Nov 2020 23:41:33 +0000 Subject: [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: Mon, 16 Nov 2020 23:26:19 -0000 --000000000000388fc605b4415e3a Content-Type: text/plain; charset="UTF-8" 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 --000000000000388fc605b4415e3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

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

First off, at face value they hav= e nothing to do with=C2=A0the operations intrinsically required to finaliz= e a valid transaction from PSBT manipulation.

=
= Moreover, whatever information content they can provide for non-standard PS= BT manipulation, that content could stay in the unknown field withou= t any loss of generality. How to structure and deal with unknown data would= be the responsibility=C2=A0of proprietary=C2=A0software or users wanting t= o provide proof-of-reserve. As long as BIP174 clearly prescribes that unkno= wn=C2=A0data must be kept during PSBT manipulation, that should be enough.<= /font>

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

My last conclusion is reinforced by the evidenc= e of all PSBT implementations I know of, including bitcoin core and HWI, no= t implementing proprietary and proof-of-reserve types. There is a high prob= ability that part of BIP174 would be just ignored.

Am I missing something?

Thanks
--
Ferdinando M. Ametrano<= /font>
<= /div>
--000000000000388fc605b4415e3a--