summaryrefslogtreecommitdiff
path: root/f9/a06cd606f1f45f1d1ca14ed578110c3398f88e
blob: 6726dda6fe20ef9715363449be851f88af6b852a (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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 06AF81083
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Mar 2018 13:26:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-HK2-obe.outbound.protection.outlook.com
	(mail-oln040092255038.outbound.protection.outlook.com [40.92.255.38])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 618FA8B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Mar 2018 13:26:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=+Zazh3ExM4tyhqaVqrsKC0PJHyJQCEugSU8FM6o3lVk=;
	b=U573qC+P7n190Tk9/wLVlWK9nFy7KkOPFol3k0Sr9IvaPOtl2ujyNezUm+kmvw52fK9gvXldCWJbT1LeDhHa7x/516B4tlTu+HCJANejlI6pqW1JPWnoRNS4Cnb0gAHc5l4F5ofb844oKxy2xmBwoNckba3vLytAmmVfdNOG6l1Eo0EA/jfhYCPWRi80GQwhaGVJUtG1N5jmFIpPC2ms3O/+SKJhF53W+OuBpKKY6ZdAA/yu5U3rRZg2j5bqarIPYoT2rej4waraW2isggkmusOlYPhKN7WO86xqoMRMwCryYa23T4S8NT8Q0mooroRMyre7+X4MNKT+Kk/afROrQA==
Received: from PU1APC01FT053.eop-APC01.prod.protection.outlook.com
	(10.152.252.60) by PU1APC01HT079.eop-APC01.prod.protection.outlook.com
	(10.152.253.33) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.16;
	Tue, 13 Mar 2018 13:26:18 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.51) by
	PU1APC01FT053.mail.protection.outlook.com (10.152.253.128) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
	15.20.567.16 via Frontend Transport; Tue, 13 Mar 2018 13:26:18 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0548.021; Tue, 13 Mar 2018 13:26:18 +0000
From: Damian Williamson <willtech@live.com.au>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Sign / Verify message against SegWit P2SH and
	Bech32 addresses
Thread-Index: AQHTus0axltfECZTu0GoJJnO+22Qvw==
Date: Tue, 13 Mar 2018 13:26:17 +0000
Message-ID: <PS2P216MB017926BA48E2A8E1B4E17BBE9DD20@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:2C69444809BFAC23F07849FFCF6282ABFC27CB93772DCF61C018C1C7B6458DC1;
	UpperCasedChecksum:6205E2641490E582BA5CD640632C2EAA35943EEBFC05E7762AD307834909CFDD;
	SizeAsReceived:6954; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [AI2/8KtEEnUyOYW0RxVToxWihtSnrqo5]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT079;
	6:wAX8DndB2ZAPgiqetJsae9bKzGFVreAdqZlh/1Hd/tii46FssGqP4ZLHRDTOh3Vji1nhrDJiqprYyY/uLKZhQHpDDgR4Evn7LVMWc63ClOLCbNKjvPhmiTDdcfvw7eksQBV+wKHvR+hn7REUpVptW4yz58Qw03OMfG/vNxeFSpWKAwAdJ41A60ow9/JBumGMbe1mzXBIs1+DRW+mfrmHkjnsm6FsUM7c22x5Atzasp6kT/7leQv9/tDaR+qJramegBsyTJq0KEfr55cOyR40sqnDHsvRR8QukcBEkVnkUPuFhaXf+OOsRPpFXFfq+riqfogfeyBeHhV0jEE7aqnWbk/Si1jiF5izNJweF2arEn8=;
	5:GssxQ9TfrFrWulZX+MPTsIyD2YuHxNRm6qUGHKKSu8O+nSLeIOY2VstUMsWfYE53zKs5kQMCZuf11FnC2crj6YKyxSGg33t5K2Io0wDTjf3D7cj+NrwgY5qhilKYFZntq+wGWKUnP6T30u50vGtgo8Ia4bljeWoPJPRMrV9d8EY=;
	24:kyjlb+CAomC6/lNzMdk8q9aeqsSjyR26dDLSdM3FoMrTvbfw2d5CVaHla1Ld5uQiUibbF/Rk6KI59mtOsN+yWIUWOIJ/QVfRkty9w2pc1TQ=;
	7:IctNRNJ0XymETvlkmKvsP/RbRnBxjO7uVRj++9uwhVQXRuG9vwpM0ufI2SLr3LJlrg9tXxgHNtcqIG7dx8mJnbRipM0lwRrXPJf8E9CIAneYEP8W64koFp48DTMQNJJpGXUI4peZG3xrX7yPW1R037i5oM7XDA+q7ezzKD45J1kDk840GbRhQP1mTRZyNu/4qM5Z8lSdzhF0NTuUSUCIa/QAXabuPK9DQwWRmt08B2COH87visqfSqqeT7PRuLdE
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:PU1APC01HT079; 
x-ms-traffictypediagnostic: PU1APC01HT079:
x-ms-office365-filtering-correlation-id: db232b18-e346-431d-f98c-08d588e600dd
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT079; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT079; 
x-forefront-prvs: 0610D16BBE
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT079;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
x-microsoft-antispam-message-info: J8my2RcL4gEoF1D12/5R1H4EmwY1Ac9lR55iYrtijCmu+BEfVq3yAzMC7fuhWEX62n66YHSsd2hNa61L5Atvm1hqE5sPOx2e+W5yQnFew6VJVUOou4S2PBYTcoc7M8SWpey7CibpCmSAjtQgxekItPfJauzcK14XSybGMdVKZvnogMY8QW4eU+x/jFgBzrbS
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: db232b18-e346-431d-f98c-08d588e600dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2018 13:26:17.8539 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT079
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Tue, 13 Mar 2018 13:50:45 +0000
Subject: [bitcoin-dev] Sign / Verify message against SegWit P2SH and Bech32
 addresses
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: Tue, 13 Mar 2018 13:26:22 -0000

--_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Current implementation of sign/verify is broken for SegWit and Bech32 addre=
sses.


Please add the following reference to the use cases:

---

# Does blockchain.info show balances for addresses that are in cold storage=
?

Yes.

>... is there any way for me in another country to confirm that what my col=
league views is actually accurate and correct?

Since they use Bitcoin Core, yes, there is a way to verify that they hold t=
he addresses that they claim. Have them sign a message with each address th=
at they claim to have the holdings on, using Bitcoin Core you can verify th=
at they indeed have those addresses and check them on blockchain.info to fi=
nd the current balance.

Only works in Bitcoin Core currently for addresses starting with a '1' (not=
 Segwit addresses starting with a '3' and not Bech32 addresses starting wit=
h 'bc1' - the developers are aware of this and I will remind them shortly.)

In Bitcoin Core, your transaction opposite goes to File -> Sign Message and=
 signs any message with one of the holding addresses. Copy the message, add=
ress and signature and send to you via probably plain text format email is =
the easiest. Repeat for each additional address holding the balance of BTC =
that they are offering to sell.

In Bitcoin Core, you go to File -> Verify Message and key the details provi=
ded EXACTLY - spaces, new lines and all characters must be an EXACT match. =
Click on verify and voil=E0.

I prefer the form of signed message as follows (don't key the top and botto=
m bar rows for the message, just the contents and you can check this yourse=
lf, the bottom row is the signature). I like to key the address used for ve=
rifying as a part of the message but that is not strictly necessary:

    ------------------------------
    Something that I want to sign.

    bitcoin:1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg
    ------------------------------
    Signture:
    IGaXlQNRHHM6ferJ+Ocr3cN9dRJhIWxo+n9PGwgg1uPdOLVYIeCuaccEzDygVgYPJMXqmQe=
SaLaZVoG6FMHPJkg=3D

This contains all of the compact information necessary to verify the messag=
e.

Example of verified message:
![verified message][1]

[1]: https://i.stack.imgur.com/zv1xq.png

---

https://bitcoin.stackexchange.com/a/72281/75001



Solution seems to be straight-forward, as noted in Issue# [10542](https://g=
ithub.com/bitcoin/bitcoin/issues/10542#issuecomment-306584383)


>And it would in theory be possible to make signmessage work for a P2SH-P2W=
PKH address, in cases where the verifier knows the embedded pubkeyhash alre=
ady. But in that case you don't need "sign with a witness address" function=
ality - *you could just sign with the embedded key (see validateaddress), a=
nd have the verifier check that*.


>The point is to not further the misunderstanding that signmessage signs wi=
th an address - it never did. It signs with a keyhash, and verify with a ke=
yhash.


This is an important feature, there are few other ways to verify that an ad=
dress is held. Note that the linked issue is not currently labeld GUI and p=
robably could be - unless a new issue should also be opened?


Regards,

Damian Williamson


--_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">Current implementation of sign/ve=
rify is broken for SegWit and Bech32 addresses.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Please add the following referenc=
e to the use cases:</p>
<p style=3D"margin-top:0;margin-bottom:0">---<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"></p>
<div>
<div># Does blockchain.info show balances for addresses that are in cold st=
orage?<br>
<br>
Yes.<br>
<br>
&gt;... is there any way for me in another country to confirm that what my =
colleague views is actually accurate and correct?<br>
<br>
Since they use Bitcoin Core, yes, there is a way to verify that they hold t=
he addresses that they claim. Have them sign a message with each address th=
at they claim to have the holdings on, using Bitcoin Core you can verify th=
at they indeed have those addresses
 and check them on blockchain.info to find the current balance.<br>
<br>
Only works in Bitcoin Core currently for addresses starting with a '1' (not=
 Segwit addresses starting with a '3' and not Bech32 addresses starting wit=
h 'bc1' - the developers are aware of this and I will remind them shortly.)=
<br>
<br>
In Bitcoin Core, your transaction opposite goes to File -&gt; Sign Message =
and signs any message with one of the holding addresses. Copy the message, =
address and signature and send to you via probably plain text format email =
is the easiest. Repeat for each additional
 address holding the balance of BTC that they are offering to sell.<br>
<br>
In Bitcoin Core, you go to File -&gt; Verify Message and key the details pr=
ovided EXACTLY - spaces, new lines and all characters must be an EXACT matc=
h. Click on verify and voil=E0.<br>
<br>
I prefer the form of signed message as follows (don't key the top and botto=
m bar rows for the message, just the contents and you can check this yourse=
lf, the bottom row is the signature). I like to key the address used for ve=
rifying as a part of the message
 but that is not strictly necessary:<br>
<br>
&nbsp;&nbsp;&nbsp; ------------------------------<br>
&nbsp;&nbsp;&nbsp; Something that I want to sign.<br>
&nbsp;&nbsp; &nbsp;<br>
&nbsp;&nbsp;&nbsp; bitcoin:1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg<br>
&nbsp;&nbsp;&nbsp; ------------------------------<br>
&nbsp;&nbsp;&nbsp; Signture:<br>
&nbsp;&nbsp;&nbsp; IGaXlQNRHHM6ferJ&#43;Ocr3cN9dRJhIWxo&#43;n9PGwgg1uPdOLVY=
IeCuaccEzDygVgYPJMXqmQeSaLaZVoG6FMHPJkg=3D<br>
<br>
This contains all of the compact information necessary to verify the messag=
e.<br>
<br>
Example of verified message: &nbsp;<br>
![verified message][1]<br>
<br>
[1]: https://i.stack.imgur.com/zv1xq.png <br>
</div>
</div>
<p style=3D"margin-top:0;margin-bottom:0">---</p>
<p style=3D"margin-top:0;margin-bottom:0"><a href=3D"https://bitcoin.stacke=
xchange.com/a/72281/75001" class=3D"OWAAutoLink" id=3D"LPlnk231610" preview=
removed=3D"true">https://bitcoin.stackexchange.com/a/72281/75001</a></p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p></p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Solution seems to be straight-for=
ward, as noted in Issue# [10542](<a href=3D"https://github.com/bitcoin/bitc=
oin/issues/10542#issuecomment-306584383" class=3D"OWAAutoLink" id=3D"LPlnk6=
23905" previewremoved=3D"true">https://github.com/bitcoin/bitcoin/issues/10=
542#issuecomment-306584383</a>)</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">&gt;And it would in theory be pos=
sible to make
<code>signmessage</code> work for a P2SH-P2WPKH address, in cases where the=
 verifier knows the embedded pubkeyhash already. But in that case you don't=
 need &quot;sign with a witness address&quot; functionality - *you could ju=
st sign with the embedded key (see
<code>validateaddress</code>), and have the verifier check that*.</p>
<p><br>
</p>
<p>&gt;The point is to not further the misunderstanding that <code>signmess=
age</code> signs with an address - it never did. It signs with a keyhash, a=
nd verify with a keyhash.</p>
<p><br>
</p>
<p>This is an important feature, there are few other ways to verify that an=
 address is held. Note that the linked issue is not currently labeld GUI an=
d probably could be - unless a new issue should also be opened?</p>
<p><br>
</p>
<p>Regards,</p>
<p>Damian Williamson<br>
</p>
<br>
<p></p>
</div>
</body>
</html>

--_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_--