summaryrefslogtreecommitdiff
path: root/0e/5e1d7f6a6c17d3e5b9e0ff7bc1e157f27c2ae7
blob: 75425d9cec60470381abc084e470eaa1b1848377 (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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
Return-Path: <a.raspitzu@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 67470A47
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Jun 2018 09:00:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B343E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Jun 2018 09:00:57 +0000 (UTC)
Date: Sun, 24 Jun 2018 05:00:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1529830855;
	bh=sOh3ZvDuMJqafGNCkGkqZMtfQ8faQPHi2tTcB/itYZ0=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=mZvLpluEtIHToEnRyN0vwMXbGDJSDYwKOkw+5nyzJICt0FsdNMduFOf+oTydVq+pe
	q9N/MdtJtwGV3RtmMd2F2HQwmwjqrYCb62YnowInU08RJtuEnI73ZhZi/wr/I1KBsO
	t0qhb0pHTtECXPfRcsbfIE/v3M1o/VJg97WRQGEo=
To: Andrew Chow <achow101-lists@achow101.com>
From: Andrea <a.raspitzu@protonmail.com>
Reply-To: Andrea <a.raspitzu@protonmail.com>
Message-ID: <VL10ISVuFyUBiT2QCjil36o2GN1xLS3r7X3m1QYqBBYetcFsYKr_H3PG2Mqy5hC7SnbxWXqy7dYQ-sb83cEuZyLdy0SpIp3lxWmhql4UPO8=@protonmail.com>
In-Reply-To: <4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
	<21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
	<20180621195654.GC99379@coinkite.com>
	<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
	<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
	<87zhzlbfq5.fsf@jb55.com>
	<qqrkCNKaf2L_MWkEU5F2u3Jna2QdA-bGNPDE9aU64Im0SUlIo4mfexfp8CXQSj9vEp9XM25DHSJIp4HnKFyLsflAhreppaNJQy-g1hXtjNU=@achow101.com>
	<HWG4r9Lgi0mPONMhHwAXqnGPYeqeAvarQBUlqaRa-iZeysawpb2CN76M0ywrxbhLGJirwWViKIJqwadJcjYPRdYff4ISkSYXAO4a0SWBdVA=@protonmail.com>
	<4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com>
Feedback-ID: x-YXDi3m_TiFBHTDMZypFbA_HjfCQuhNiwHDBR0xli2NzJKdIoqs25GtJLT5wHvl0eyVBeRQs8LMD0l_SOtUrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 24 Jun 2018 12:26:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 24 Jun 2018 09:00:58 -0000

Keeping it for future extensions is a good point, my understanding was that=
 since we always need exactly one transaction it could be part of the defin=
ition of PSBT instead of being a key-value (although it is more of a breaki=
ng change).=20


Cheers, Andrea.

=E2=80=8B=E2=80=8B

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90

On June 24, 2018 10:28 AM, Andrew Chow <achow101-lists@achow101.com> wrote:

> =E2=80=8B=E2=80=8B
>=20
> I disagree with the idea that global types can be removed. Firstly, it
>=20
> is less of a breaking change to leave it there than to remove it
>=20
> entirely. Secondly, there may be a point in the future where global
>=20
> types would be useful/necessary. By having it still be there, we allow
>=20
> for future extensibility.
>=20
> Andrew
>=20
> On 06/24/2018 01:19 AM, Andrea wrote:
>=20
> > Hi,
> >=20
> > I think in the revised spec we can remove completely the "global types"=
 as a map or even as typed record. Since there is only one type (the transa=
ction) and it's compulsory to have one (and only one) we could just drop th=
e definition of global type and the key associated with it, simply after th=
e header + separator there must be a transaction. Having read all the discu=
ssion i also agree having per-input key derivation and per-output data is a=
 lot more handy for signers, no special feeling regarding the encoding.Look=
ing forward for the test vectors and the new spec.
> >=20
> > Cheers, Andrea.
> >=20
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
> >=20
> > On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev bitcoin-dev@list=
s.linuxfoundation.org wrote:
> >=20
> > > On 06/23/2018 10:00 AM, William Casarin wrote:
> > >=20
> > > > Since we're still considering the encoding, I wonder if it would be=
 a
> > > >=20
> > > > good idea to have a human-readible part like lightning invoices[1]?
> > > >=20
> > > > I don't think that is necessary.
> > >=20
> > > > Then perhaps you could drop the magic code as well?
> > > >=20
> > > > The magic is still necessary for the binary format in order to prev=
ent
> > >=20
> > > normal transaction deserializers from accidentally deserializing a ps=
bt.
> > >=20
> > > > Also we could do a base encoding that excludes + and / characters, =
such
> > > >=20
> > > > as base62 (gmp-style). It's easier to copy/paste (double clicking a
> > > >=20
> > > > string stops at / or + in base64 encodings).
> > > >=20
> > > > While that would be ideal, I think it is better to use an encoding =
that
> > >=20
> > > most wallets already support. Most wallets already have Base64 decodi=
ng
> > >=20
> > > available so that they can decode signed messages which also use Base=
64
> > >=20
> > > encoding. I think it is unnecessary to introduce another encoding.
> > >=20
> > > On 06/23/2018 11:27 AM, Peter D. Gray wrote:
> > >=20
> > > > Personally, I don't think you should spec an encoding. It should be=
 binary only and hex for developers and JSON interfaces. My thinking is tha=
t PSBT's are not user-visible things. They have a short lifetime and are no=
thing something that is "stored" or referenced much later. Hex is good enou=
gh and has no downsides as an excoding except for density.
> > > >=20
> > > > I think what will end up happening though is that, at least in the
> > >=20
> > > beginning, PSBTs will primarily be strings that people end up copy an=
d
> > >=20
> > > pasting. Since a PSBT can get pretty large, the strings are rather
> > >=20
> > > cumbersome to move around, especially as hex. At least with Base64 th=
e
> > >=20
> > > strings will be smaller.
> > >=20
> > > > On the other hand, suggesting a filename extension (probably .PSBT?=
) and a mime-type to match, are helpful since wallets and such will want to=
 register with their operating systems to become handlers of those mimetype=
s. Really that's a lot more important for interoperability at this point, t=
han an encoding.
> > > >=20
> > > > Agreed. I will include those in the BIP.
> > >=20
> > > > Looking forward to test vectors, and I might have more to say once =
my code can handle them (again).
> > > >=20
> > > > Feedback on the BIP as it stands now:
> > > >=20
> > > > -   Appendix A needs an update, and I suggest defining symbols (PK_=
PARTIAL_SIG =3D=3D 0x02) for the numeric key values. This helps implementer=
s as we don't all define our own symbols and/or use numeric constants in ou=
r code.
> > > >    =20
> > > >     Okay.
> > > >    =20
> > >=20
> > > > -   Those tables are just not working. Might want to reformat as de=
scriptive lists, point form, or generally anything else... sorry.
> > > >    =20
> > > >     I will try my best to fix that. Mediawiki sucks...
> > > >    =20
> > >=20
> > > Andrew
> > >=20
> > > bitcoin-dev mailing list
> > >=20
> > > bitcoin-dev@lists.linuxfoundation.org
> > >=20
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev