summaryrefslogtreecommitdiff
path: root/05/0389e57bf5f0eacb5312856286a9bda5280dd9
blob: 45f78f020e4e4f8d00bedd16df17c872719412ef (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
Return-Path: <ferdinando@ametrano.net>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A73E4C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Nov 2020 23:26:18 +0000 (UTC)
Received: by mail-ed1-f52.google.com with SMTP id d18so7611910edt.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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" <ferdinando@ametrano.net>
Date: Tue, 17 Nov 2020 00:01:34 +0100
Message-ID: <CADfmNEk3nr33MMym1D_n8_DWgj39AWoOuTpFbBO0U6MZis_=vA@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D""><font face=3D"verd=
ana, sans-serif">Hi all,</font></div><div class=3D"gmail_default" style=3D"=
"><font face=3D"verdana, sans-serif"><br></font></div><div class=3D"gmail_d=
efault" style=3D""><font face=3D"verdana, sans-serif">While implementing PS=
BT support in the <i>btclib</i> library (<a href=3D"https://github.com/btcl=
ib-org/btclib">https://github.com/btclib-org/btclib</a>), I have failed to =
understand the rationale for the <i>proprietary</i> and <i>proof-of-reserve=
s</i> types.</font></div><div class=3D"gmail_default" style=3D""><font face=
=3D"verdana, sans-serif"><br></font></div><div class=3D"gmail_default" styl=
e=3D""><font face=3D"verdana, sans-serif">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.</font></div><div class=3D"gma=
il_default" style=3D""><font face=3D"verdana, sans-serif"><br></font></div>=
<div class=3D"gmail_default" style=3D""><font face=3D"verdana, sans-serif">=
Moreover, whatever information content they can provide for non-standard PS=
BT manipulation, that content could stay in the <i>unknown</i> 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></div><div class=3D"gmail_default" style=3D""><font face=3D"verdana, =
sans-serif"><br></font></div><div class=3D"gmail_default"><font face=3D"ver=
dana, sans-serif">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=A0<i>pr=
oprietary</i> and <i>proof-of-reserves</i> types.</font></div><div class=3D=
"gmail_default"><font face=3D"verdana, sans-serif"><br></font></div><div cl=
ass=3D"gmail_default"></div><div class=3D"gmail_default" style=3D""><font f=
ace=3D"verdana, sans-serif">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.</font></div><div class=
=3D"gmail_default" style=3D""><font face=3D"verdana, sans-serif"><br></font=
></div><div class=3D"gmail_default" style=3D""><font face=3D"verdana, sans-=
serif">Am I missing something?</font></div><div class=3D"gmail_default" sty=
le=3D""><font face=3D"verdana, sans-serif"><br></font></div><div class=3D"g=
mail_default" style=3D""><font face=3D"verdana, sans-serif">Thanks</font></=
div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><font face=3D"verdana, san=
s-serif">--<br></font></div><div dir=3D"ltr"><div><font size=3D"1" face=3D"=
verdana, sans-serif"><span style=3D"margin:0px;padding:0px;line-height:12px=
;color:rgb(33,33,33);display:block"><span style=3D"margin:0px;padding:0px;l=
ine-height:12px;display:block"><b>Ferdinando M. Ametrano</b></span></span><=
/font></div><div><span style=3D"margin:0px;padding:0px;font-size:10px;line-=
height:12px;color:rgb(33,33,33);display:block"><div style=3D"color:rgb(34,3=
4,34);font-size:small"><font face=3D"verdana, sans-serif" style=3D"font-siz=
e:10px;color:rgb(17,85,204)"><a href=3D"https://www.ametrano.net/about" sty=
le=3D"font-size:10px;color:rgb(17,85,204)" target=3D"_blank">www.ametrano.n=
et/about</a></font></div></span></div></div></div></div></div></div></div><=
/div></div></div></div></div>

--000000000000388fc605b4415e3a--