Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1043C07FF for ; Mon, 16 Nov 2020 23:38:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 970A720656 for ; Mon, 16 Nov 2020 23:38:58 +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 1Hi2GFfpketf for ; Mon, 16 Nov 2020 23:38:57 +0000 (UTC) X-Greylist: delayed 00:36:45 by SQLgrey-1.7.6 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by silver.osuosl.org (Postfix) with ESMTPS id 0EA1F2011A for ; Mon, 16 Nov 2020 23:38:57 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id za3so26877429ejb.5 for ; Mon, 16 Nov 2020 15:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ametrano-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aSCBNtTqNMMIttEyfQOOAfJpcozS+Q6xEkSDiGXtALo=; b=TTilodTku5qsbYQvhS3k48d+l5FgOj/eSxt+V/V7e7rDLCszYu/WB6b15J/CDM8QI+ ZmqDRAuIw3CmWpf8HfyUPg+ZBRDELfgTWeWUEDeg+C6QbX3UnD2C0IUF+l0VtoOijT6A d3MpbDJ+t2P9vTZYRYG3PGg5/o0XsXkIkdgoC+O1emZjJROG9dRAO67Q+RX7msCT3vmT uBQbfYzOfeRo1f1DtgmusipDtHKes1/GRQw3FxzOK65aS6qgdhlShv7K4gIgmitgDqfD l5lE35cwnt5IP3dC7JymjdYCKWJjD39EaFJGOHGmTR+BQ1FD1VI3NJOKoptsbgEllkN8 wmlg== 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=aSCBNtTqNMMIttEyfQOOAfJpcozS+Q6xEkSDiGXtALo=; b=MF6Q6grgH0Q0P1g2JJ/x5jXvJOKI7/eU9ZoJFvjnOJ0L7rUlXseRLrAq5uKY/7R3nN rcoFMYNUbt24SY/gJ1g5oV8iU1aq8kltVkuz2s+XwvrPbC/CaBVFu/EwIJyJ6cC8sqwd kA2FjCuSEabRjQOwhOtEjfNiAaJBxlzpuacyiyHxHJ2mWUf07JJ6jNhJQ6EvVj3ztN4L 9qWq0xFX3dUgmSb9aDK17DfQHjh1C3ICU6OWkZ25UcWJ6yzRXqT30Stvc+5UGWMoJcZq evtMHVRnx2sqWMCPDZUC5zWSarikjv4UVIbIY7C3bMKS1vgRlZTjDHS2w/ZMmv9jr1Dt yI2A== X-Gm-Message-State: AOAM530ZuddZBkwoE4ucD9vuiBGh/c65giAaeVW8KjKTSYojKAj59nWQ vUleBu+BiByG4xC38JCEHmjoAgrqRbqLRJUio6SyIPtmy89t1zB6LLU= X-Google-Smtp-Source: ABdhPJx/S3N85GdQBkKkSKYlEJ+YoGlDIkqt7p/49GHJ+oG6Q7Zqut1ii3hC/PSdhU+tNJ2gM9TLbLy6Js+V5IdGaeM= X-Received: by 2002:a17:906:892:: with SMTP id n18mr16359775eje.1.1605569935022; Mon, 16 Nov 2020 15:38:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Ferdinando M. Ametrano" Date: Tue, 17 Nov 2020 00:38:19 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000a3b40f05b441e19f" X-Mailman-Approved-At: Mon, 16 Nov 2020 23:41:33 +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: Mon, 16 Nov 2020 23:38:58 -0000 --000000000000a3b40f05b441e19f Content-Type: text/plain; charset="UTF-8" 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 > --000000000000a3b40f05b441e19f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After having=C2=A0checked that the BIP174 test vectors do = not cover the=C2=A0proprietary=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 fields from the PSBT specifica= tions

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

--
Ferdinando M. Ametrano
<= span style=3D"margin:0px;padding:0px;font-size:10px;line-height:12px;color:= rgb(33,33,33);display:block">
<= /div>

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=C2=A0the ope= rations intrinsically required to finalize a valid transaction from PSBT m= anipulation.

Moreover, whatever information content they can provide= for non-standard PSBT manipulation, that content could stay in the unkn= own field without any loss of generality. How to structure and deal wit= h unknown data would be the responsibility=C2=A0of proprietary=C2=A0softwar= e or users wanting to provide proof-of-reserve. As long as BIP174 clearly p= rescribes that unknown=C2=A0data must be kept during PSBT manipulation, tha= t should be enough.

Let me stress the above point: I have a project = where we include proprietary information in the PSBT. Any PSBT software sup= porting unknown data gently keeps our proprietary information and our propr= ietary software retrieves that data from serialized PSBT with no problem. T= here is no need for a PSBT implementation to provide explicit support for= =C2=A0proprietary 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 so= mething?

Thanks
<= div>
--
Ferdinando M. Ametrano
--000000000000a3b40f05b441e19f--