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: <achow101-lists@achow101.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 20F2AD6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 00:45:48 +0000 (UTC)
X-Greylist: delayed 00:06:33 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 22DE54DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 00:45:47 +0000 (UTC)
Date: Wed, 20 Jun 2018 20:39:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail; t=1529541551;
bh=VUltNiQ9FXp3shj6JHOg9HWGuyyt5sOs5EME5Q2/ggU=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=i6knOGJMcoLP6qOeU+hp7xNNuGqDA+3F94JWFUOojoaEMuuNdikbMjdeM1rtZqVqs
ry659hoSlS/KBq6xV2Ddk9YLSM/6ChukvRbMnRj2DtGP+NsyWlx6E4citRvhWvtpHC
2L04bG0MgSeOk3uzFirDVm5cwN74eWO2/+EHjitg=
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Achow101 <achow101-lists@achow101.com>
Reply-To: Achow101 <achow101-lists@achow101.com>
Message-ID: <CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
In-Reply-To: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==: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, 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
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: Thu, 21 Jun 2018 00:45:48 -0000
Hi,
On June 15, 2018 4:34 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>=20
> Hello all,
>=20
> given some recent work and discussions around BIP 174 (Partially
> Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.
> First of all, it's unclear to me to what extent projects have already
> worked on implementations, and thus to what extent the specification
> is still subject to change. A response of "this is way too late" is
> perfectly fine.
While I agree that the BIP itself should be revised to reflect these sugges=
tions, I fear that it may be too late. I know of a few other developers who=
have implemented BIP 174 already but have not yet responded to this email.
> =20
> - Generic key offset derivation
>
> Whenever a BIP32 derivation path does not include any hardened steps,
> the entirety of the derivation can be conveyed as "The private key fo=
r
> P is equal to the private key for Q plus x", with P and Q points and =
x
> a scalar. This representation is more flexible (it also supports
> pay-to-contract derivations), more efficient, and more compact. The
> downside is that it requires the Signer to support such derivation,
> which I don't believe any current hardware devices do.
> Would it make sense to add this as an additional derivation method?
While this is a good idea, I'm not sure that implementers would understand =
this as it requires knowing the cryptography which makes this possible. As =
an optional feature, not all wallets would understand it, and those that do=
could create PSBTs which other wallets do not understand and thus cannot s=
ign even if they have the private keys and actually can sign.
> =20
> - Hex encoding?
> =20
> This is a very minor thing. But presumably there will be some standar=
d
> way to store PSBTs as text for copy-pasting - either prescribed by th=
e
> spec, or de facto. These structures may become pretty large, so
> perhaps it's worth choosing something more compact than hexadecimal -
> for example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/).
Agreed. Are there any encodings that do not have double click breaking char=
acters?
On June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
> I think it could be more flexible (generic) in BIP174.
> It could be just a single child key {32-bit int}, or just a keypath ({32-=
bit int}]{32-bit int}=E2=80=A6) which is very likely sufficient for a HWW t=
o derive the relevant key without the creation of a lookup-window or other =
=E2=80=9Emaps".
This ignores all of the other times that a BIP32 keypath needs to be provid=
ed. It is not only used for multisig, there may be other times that there a=
re multiple derivation paths and master keys due to multiple inputs and suc=
h. Adding a field specific to multisig and HWW only seems pointless and red=
undant to me.
On June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>
> A question to consider is,
> will there be more per-output data? If yes, it might make sense to have
> an output section.
I think it is unlikely that there would be anymore per-output data.
> 3) The sighash type 0x03 says the sighash is only a recommendation. That
>seems rather ambiguous. If the field is specified shouldn't it be binding?
I disagree. It is up to the signer to decide what they wish to sign, not fo=
r the creator to specify what to sign. The creator can ask the signer to si=
gn something in a particular way, but it is ultimately up to the signer to =
decide.
> 4) Is it a good idea to skip records which types we are unaware of? We
> can't come up with a reasonable example, but intuitively this seems as a
> potential security issue. We think we should consider introducing a
> flag, which would define if the record is "optional". In case the signer
> encounters a record it doesn't recognize and such flag is not set, it
> aborts the procedure. If we assume the set model we could change the
> structure to <type><optional flag><length>{data}. We are not keen on
> this, but we wanted to include this idea to see what you think.
The idea behind skipping unknown types is to allow forward compatibility. A=
combiner written now should be able to combine transactions created in the=
future with new types as combining is really only just merging the maps to=
gether.
> In general, the standard is trying to be very space-conservative,
> however is that really necessary? We would argue for clarity and ease of
> use over space constraints. We think more straightforward approach is
> desired, although more space demanding. What are the arguments to make
> this as small as possible? If we understand correctly, this format is
> not intended for blockchain nor for persistent storage, so size doesn=
=E2=80=99t
> matter nearly as much.
Size is not really a constraint, but we do not want to be unnecessarily lar=
ge. The PSBT still has to be transmitted to other people. It will likely be=
used by copy and pasting the string into a text box. Copying and pasting v=
ery long strings of text can be annoying and cumbersome. So the goal is to =
keep the format still relatively clear while avoiding the duplication of da=
ta.
Andrew
|
