summaryrefslogtreecommitdiff
path: root/66/dd057cb973a9a17017cb1407589cf44585f0da
blob: e9fc63e466cd6c648ead071abdb52d49967693c7 (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
Return-Path: <arthur@bitcoin-fr.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E014C1165
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Sep 2015 19:06:20 +0000 (UTC)
X-Greylist: delayed 00:09:16 by SQLgrey-1.7.6
Received: from mail.aaawop.com (area51.powaaa.com [62.210.66.225])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A15F249
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Sep 2015 19:06:20 +0000 (UTC)
Received: from rainloop.aaawop.com (area51.powaaa.com [62.210.66.225])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: arthur@powaaa.com)
	by mail.aaawop.com (Postfix) with ESMTPSA id 10AC743A62
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Sep 2015 20:57:02 +0200 (CEST)
Mime-Version: 1.0
Date: Mon, 14 Sep 2015 18:57:01 +0000
Content-Type: multipart/alternative;
	boundary="----=_Part_862_559512907.1442257021"
Message-ID: <c5f5105e2d5b9cc1873f84cb0b172285@rainloop.aaawop.com>
X-Mailer: RainLoop/1.8.2.291
From: "Arthur - bitcoin-fr.io" <arthur@bitcoin-fr.io>
To: bitcoin-dev@lists.linuxfoundation.org
X-Virus-Scanned: clamav-milter 0.98.6 at area51
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] URI scheme for signing and verifying messages
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 14 Sep 2015 19:06:21 -0000


------=_Part_862_559512907.1442257021
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,I realized that there isn't any way to ask for a signature (or to veri=
fy a message) as easily you can do when requesting a payment using a bitc=
oin URI scheme (BIP0021).I think a URI scheme to use the signing tools in=
 bitcoin core might be useful, and with a proper consensus it could becom=
e available in most bitcoin clients who already support message signing/v=
erifying and payment url (or QRCode) and enable new uses of bitcoin signa=
tures.A way to gain proper consensus is going through a BIP, so that's wh=
y I'm here: to present my idea publicly before going any further (draft B=
IP and reference implementation).Some thoughts=C2=A0- like BIP0021: "Bitc=
oin clients MUST NOT act on URIs without getting the user's authorization=
." so signing requires the user to manually approve the process=C2=A0- it=
 could use the same URI scheme than BIP0021 with an additional parameter =
(ex: signaction=3D) or use another one like BIP121 (ex: btcsig:)PS : I'll=
 also post a topic in "Development & Technical Discussion" section on Bit=
cointalk=0A=C2=A0--Arthur Bouquet

------=_Part_862_559512907.1442257021
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html; charset=3Dutf-8" /></head><body><div data-html-editor-font-wrap=
per=3D"true" style=3D"font-family: arial, sans-serif; font-size: 13px;">H=
i,<div class=3D"de2"></div><div class=3D"de1">I realized that there isn't=
 any way to ask for a signature (or to verify a message) as easily you ca=
n do when requesting a payment using a bitcoin URI scheme (BIP0021).</div=
><div class=3D"de2">I think a URI scheme to use the signing tools in bitc=
oin core might be useful, and with a proper consensus it could become ava=
ilable in most bitcoin clients who already support message signing/verify=
ing and payment url (or QRCode) and enable new uses of bitcoin signatures=
.</div><div class=3D"de1"></div><div class=3D"de2">A way to gain proper c=
onsensus is going through a BIP, so that's why I'm here: to present my id=
ea publicly before going any further (draft BIP and reference implementat=
ion).</div><div class=3D"de1"></div><div class=3D"de2">Some thoughts</div=
><div class=3D"de1">=C2=A0- like BIP0021: "Bitcoin clients MUST NOT act o=
n URIs without getting the user's authorization." so signing requires the=
 user to manually approve the process</div><div class=3D"de2">=C2=A0- it =
could use the same URI scheme than BIP0021 with an additional parameter (=
ex: signaction=3D&lt;verify/sign&gt;) or use another one like BIP121 (ex:=
 btcsig:)</div><div class=3D"de1"></div><div class=3D"de2">PS : I'll also=
 post a topic in "Development &amp; Technical Discussion" section on Bitc=
ointalk<br>=C2=A0</div><div class=3D"de2">--</div><div class=3D"de1">Arth=
ur Bouquet</div></div></body></html>

------=_Part_862_559512907.1442257021--