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
204
205
206
207
208
209
210
211
212
|
Return-Path: <tomas.susanka@satoshilabs.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FFCDCC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 14:32:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail.sldev.cz (mail.sldev.cz [88.208.115.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62ECA732
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 14:32:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by mail.sldev.cz (Postfix) with ESMTP id B0B3CE1030
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 14:32:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.sldev.cz
Received: from mail.sldev.cz ([127.0.0.1])
by localhost (mail.sldev.cz [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IPdXA-m4baFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 14:32:08 +0000 (UTC)
Received: from [10.8.0.16] (unknown [10.8.0.16])
by mail.sldev.cz (Postfix) with ESMTPSA id 1D994E0F78
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Jun 2018 14:32:08 +0000 (UTC)
To: Achow101 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
From: Tomas Susanka <tomas.susanka@satoshilabs.com>
Openpgp: preference=signencrypt
Autocrypt: addr=tomas.susanka@satoshilabs.com; prefer-encrypt=mutual; keydata=
xsFNBFnSDNoBEACvDIbCm85qgyNTEl7PkHq5nv50DIg7LSOz6dkkmCPdFLLUV0+Yz0kJGbbQ
0GiVBh+emQu6zu4bumo7+9yWM/70Ak06jnlePqIAMYw+FTqeMRvDBVDnTsVzHA2zBO9CI3/q
wEbWyhijztjFmtt1QZpCdqS/cAiumUrYK9/TR9yQDCIfGcbqDY3C692phLtupR8Injpebr63
0Pvll6PB2I7ESqM5RRYfm1yzJIqjFxsF9tUPSnEOSJJ9fxa2SdC5fqAKvFC/O/QCnh5/PIm5
uS/v9r9ulu7bmSKztjRSC2p75HSD6Vg6RjADlRUIuS8HFrKJjryHhlal2DnpVnPX6Dv/G8up
hWq/NKuM/FNlonOJgttf0syyoBT6mVSVXz+oTAnxUCWPoAGO1qg07Is1hLRga3cJM3ND+bHw
TlNAMAV44/Gm8Lt82TOQKVPo/d/GMv1VPEGG131Yz9jO3juCh3I4Z5+3joRVS+bDit0TP5O7
wB1O94szSWKkOOZxhY93dzGE/lIt6ASXR6aBB6JE95PBc97cX380Dew7VB4d2UwYkuAtqHmu
g0vFjOyjVJuxHLYBMFKsocvNQFxmBfWpAficvJvNwihCykOdSdF3woa9vFaDNkjpz+oc6uzN
iTvxLoQoiXWRzUs4Zm5qVxuiCe6P87ICZQic6n2fv5rcZCU84QARAQABzS1Ub21hcyBTdXNh
bmthIDx0b21hcy5zdXNhbmthQHNhdG9zaGlsYWJzLmNvbT7CwZQEEwEIAD4WIQQx60xcC8hh
5pSytXZaMf+ev00EzAUCWdIM2gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAK
CRBaMf+ev00EzGaWD/99dV6WKHzftbKdoitIUUEXzaXAXy1/llRGQcuY5LSb497zNDvLtSpn
09fH9k4ofH7nTYVGqgPD3E92P02ERXb3kmVbgsqpf4JNjMU7khzZGANpRh+X6u7cN4enSQ3N
BzKyjgDllnQspwBsvHEKmTYySKj6DTyvZGoABwLZlaHwJblqy1xJEmk77m68LBASa0LiMOMa
TbHUJmeSF/hq+q/eY5p3ULk94G3nqpGELi7FMc80HvjR6aE7TNZcXqhtc9/TArdPk4t9sA2I
3H0fiF1gkgApu09pXXhFQP2e94ebWvFvwMPTOHB6my5objdZrutUv91FsWs3MntaHBDjOA0L
aI8Y5N0xWgQMXE8WD35a1Ed7qkGHdsiCfEyzI43qQkhCMdenr7ZesV33fhp+drPoRF1nOJVV
TihBfa0qZM7mZOIo0bppvl/tfRiyU3AZqP0Xl8vh60Z1YbzROfC82U168nepIQkNF0U9giEs
fc0or9lcxukyljHFyavacC2FyCsbOP9gfMoLzJe2Igg0NKB4zZYW2SJJllirDOHmpWk0x98b
uAuQFJ6rxDZbxM//cUf5lyqRgGlLr2R6UlqbAglZ8VpOy3mU8Nnu9pIk5C5+vV+mn7Rq4DaM
o3LI4eCnr+G9w0lkeRedmlIYRjc476fVJdud1oUGeKXZTXd27iFNEM7BTQRZ0gzaARAApuUx
h/b2pJufTrIx1YvghnKWZqM74xV0bq+/8VDTRIAeiqLW9qX30l/QsUqdhT+FeZZIGgHfLXJc
nrIpBJqKqtfCMXsSYMBZLzt+I7fn1ULvNm6ZbxcWpKRMvjhFYk1+PD/tSgxyUTlI5TM/7gH0
DvHN20BhtWFAejRBuvVlRSUpBctpQzN0UihKQyEEflY7ok+e0Sv/BtQA1/eZGYAzuHbEng9l
cLhoAZYfPmXceD0YfMu9hdDJmhFiLAjHGz8EqfJyAs6ivt/6X92gxInf8qMD+ikFOaI8GpO5
dCUh0cZPyxVycR9qccqqPwCusOPzighzRNodYhA/ggNtJHy2MFz8P6eDY1VLsXLcOF/DZ/Hg
61uFuIGEOMXwpa1QE3lC5TD3osDcIM7Hire3yFWV/MV/x5qp76cMJU6J6FInTk3q9CjVfpyG
Kt2mDkuyL7Tf5W51IEcHb6+oQUdisVuc8zKAiMmXbZrBftk4JgfoJyuf0Q6J57Nb3qSVeN/8
0v8CS2Xf0pMKrVa1TGHpQOSV3+GL/FEoeJ7E6mLxsOGCWD4X2x14jTQIPdjIlaWy1QQUtCrF
pAqi4mj3gndSsab4XQn+E9WGu9fUHWsKf7ssYkX9//S0e8QnPF9YcWjC1E+87s8RHc3+1CJW
RRCo6jk4uO6qZrPt4kuBO2ksOvYuFiMAEQEAAcLBfAQYAQgAJhYhBDHrTFwLyGHmlLK1dlox
/56/TQTMBQJZ0gzaAhsMBQkJZgGAAAoJEFox/56/TQTMazgQAK4nbHD5OiLO0iFQe6iN/gpX
t46BQjYo0GJSpnJEshqF4XAwbMdZ80QfHLY1ShKDv1vFEJX8LSTEsrueNd0beeAQ1LRSW6Fx
w6nBzE1QuM6TqtxZen0z4A5wH6DLouQ9zVTdb4lBSY9prlZp8OKeLFuPRLoPu5zN715awXgu
sesh6upNtvTua4EFLEcqGH43e1msPj0HWOJ0EKIkdajoPD6krnNolZGnYSCiAhayEAaUmabj
ZbiJwj5HM1cLGj/tmDJYgk35tfAiy/3HIcok/23ndaXGglzh49Cp/M5NHruKlEaWmXtG/D3x
eSpS/BgE96uuhMUtZx0QJwG+KW/fHDAkHgx/aPH54mtdfG08kbZMhbj0Hc/oWrJpSId+4xoy
6Gwvskx5ZAWnXwuGARGnPHrLCxPQ7gbStu/6FG8c/3c0Gsd8ToFIJjmLaUi8BN1JfKscDADK
l4SFM6PNVTSlcSyi821Tv0sc3c/6OOfO3zSdq1/xrXc+vWQJSghhWHbuaCXTUxT5BoPeVHbp
CikOKts/7QdrOCYA5XbCeP1BsiEYz6NwV1QXzn6/6gBfHFDMSXSPih98n4mhIpsw3v2wJRco
aSf3kveBq8gULnOlEnrqyh/sUtdDd5xlXifUslSFDltVumygxffY8da22e9uHKwb6JalvA1h
btmov0pL2yb9
Message-ID: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
Date: Thu, 21 Jun 2018 16:32:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: cs
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Thu, 21 Jun 2018 14:34:03 +0000
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 14:32:12 -0000
Hello,
First of all, let me thank you for all the hard work you and others have
put into this.
On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> While I agree that the BIP itself should be revised to reflect these su=
ggestions, I fear that it may be too late. I know of a few other develope=
rs who have implemented BIP 174 already but have not yet responded to thi=
s email.
We do realize that this discussion should have happened earlier, however
agreeing on a good standard should be the number one priority for all
the parties involved.
The fact that someone already implemented this is indeed unfortunate,
but I don't think we should lower our demands on the standard just
because of a bad timing.
>> A question to consider is,
>> will there be more per-output data? If yes, it might make sense to hav=
e
>> an output section.
> I think it is unlikely that there would be anymore per-output data.
Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.
The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that case it doesn=E2=80=99t =
make
sense to include it in PSBT
We got stuck on the idea of the Creator providing future (output)
redeem/witness scripts. But that seems to be a minority use case and can
be solved efficiently via the same channels that coordinate the PSBT
creation. Sorry to change opinions so quickly on this one.
>
>> 3) The sighash type 0x03 says the sighash is only a recommendation. Th=
at
>> seems rather ambiguous. If the field is specified shouldn't it be bind=
ing?
> I disagree. It is up to the signer to decide what they wish to sign, no=
t for the creator to specify what to sign. The creator can ask the signer=
to sign something in a particular way, but it is ultimately up to the si=
gner to decide.
This seems very ambiguous. The Signer always has the option of not
signing. *What* to sign is a matter of coordination between the parties;
otherwise, you could make all the fields advisory and let anyone sign
anything they like?
We don't understand the usecase for a field that is advisory but not
binding. On what basis would you choose to respect or disregard the
advisory field? Either one party has a preference, in which case they
have to coordinate with the other anyway - or they don't, in which case
they simply leave the field out.
> Size is not really a constraint, but we do not want to be unnecessarily=
large. The PSBT still has to be transmitted to other people. It will lik=
ely be used by copy and pasting the string into a text box. Copying and p=
asting very long strings of text can be annoying and cumbersome. So the g=
oal is to keep the format still relatively clear while avoiding the dupli=
cation of data.
I agree. Just to put some numbers on this: if we expect a 5-part
derivation path, and add the master key fingerprint, that is 4 + 5*4 =3D
24 bytes (~32 base64 letters) per input and signer. I'd argue this is
not significant.
If we used full xpub, per Pieter's suggestion, that would grow to 32 +
32 + 5*4 =3D 84 bytes (~112 letters) per input/signer, which is quite a l=
ot.
On the other hand, keeping the BIP32 paths per-input means that we don't
need to include the public key (as in the lookup key), so that's 32
bytes down per path. In general, all the keys can be fully reconstructed
from their values:
redeem script key =3D hash160(value)
witness script key =3D sha256(value)
bip32 key =3D derive(value)
The one exception is a partial signature. But even in that case we
expect that a given public key will always correspond to the same
signature, so we can act as if the public key is not part of the "key".
In other words, we can move the public key to the value part of the recor=
d.
This holds true unless there's some non-deterministic signing scheme,
*and* multiple Signers sign with the same public key, which is what
Pieter was alluding to on Twitter
(https://twitter.com/pwuille/status/1002627925110185984). Still, I would
argue (as he also suggested) that keeping the format more complex to
support this particular use case is probably not worth it.
Also, we can mostly ignore deduplication of witness/redeem scripts.
These still need to be included in the resulting transaction, duplicated
if necessary, so I think counting their repetition against the size of
PSBT isn't worth it.
Best,
Tomas
|
