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
|
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 8F0A71384
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Sep 2015 13:21:58 +0000 (UTC)
X-Greylist: from auto-whitelisted 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 D34E8139
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Sep 2015 13:21:57 +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 3C78643093;
Tue, 15 Sep 2015 15:21:56 +0200 (CEST)
Mime-Version: 1.0
Date: Tue, 15 Sep 2015 13:21:56 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <e11d23636bee1bfc73e89b375c2844ac@rainloop.aaawop.com>
X-Mailer: RainLoop/1.8.2.291
From: "Arthur - bitcoin-fr.io" <arthur@bitcoin-fr.io>
To: "Luke Dashjr" <luke@dashjr.org>
In-Reply-To: <201509151208.58326.luke@dashjr.org>
References: <201509151208.58326.luke@dashjr.org>
<201509150403.40909.luke@dashjr.org>
<c5f5105e2d5b9cc1873f84cb0b172285@rainloop.aaawop.com>
<15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com>
X-Virus-Scanned: clamav-milter 0.98.6 at area51
X-Virus-Status: Clean
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,URIBL_SBL
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [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: Tue, 15 Sep 2015 13:21:58 -0000
September 15 2015 2:10 PM, "Luke Dashjr" <luke@dashjr.org> wrote:=0A> On =
Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:=0A>=
=0A>> September 15 2015 6:04 AM, "Luke Dashjr" <luke@dashjr.org> wrote:=
=0A>>> I think probably the whole signed message thing needs to be rethou=
ght.=0A>>> The most common "uses" today seem to be insecure cases that it=
doesn't=0A>>> actually work in: people trying to prove ownership of bitc=
oins and/or=0A>>> that they sent bitcoins (current signed messages can do=
neither).=0A>>> Ideally, whatever the new method is should also avoid us=
ing the same key=0A>>> as for signing transactions, since the public key =
is technically private=0A>>> information. Furthermore, since addresses ar=
e semi-deprecated (by the=0A>>> payment protocol), I'm not sure it makes =
sense to do this without=0A>>> designing an entire authentication system,=
which may be rather complex.=0A>>> =0A>>> Luke=0A>> =0A>> My proposal is=
about the current signing process (which exists event it=0A>> it's not p=
erfect) but it could also work with a new signing message system=0A>> tom=
orrow. It more about give users an easier way to access existing tools=0A=
>> than the "sign message thing" itself.=0A> =0A> One of my concerns is t=
hat making the existing signatures even easier will=0A> cause incompatibl=
e uses to become more prolific and accepted, increasing the=0A> overall r=
isk. Hence my recommendation to satisfy these clearly-existing use=0A> ca=
ses with a safe signature *first*.=0A> =0A=0AIdeally yes, but it will tak=
e some time to make a new signature system.=0AI could also propose a URI =
scheme that will work with a future implementation but be compatible with=
the current one explaining its limitations (ex: sigversion=3D1 to use th=
e current system, default value is sigversion=3D2 which won't work until =
a new system is developped).=0A=0A>> BTW I'm aware of privacy issues, but=
could you elaborate on why the use=0A>> case your are referring to doesn=
't actually work?=0A> =0A> The signed message proves that the person who =
*receives* payment with the=0A> address agrees to a given message/contrac=
t.=0A> =0A> It is therefore appropriate and a best practice for web walle=
t providers=0A> (inherent problems with webwallets aside) to allow users =
to sign messages=0A> with their deposit addresses. When bitcoins are rece=
ived by this address, the=0A> transaction creates a low-level UTXO repres=
enting the bitcoins *in the=0A> wallet*, but this UTXO is not associated =
with the address itself. Therefore,=0A> it is entirely possible that this=
UTXO remains unspent/valid on the=0A> blockchain even after the user in =
question has spent their entire balance at=0A> the webwallet and therefor=
e such a signature proves only that they once=0A> received the payment, b=
ut *not* that they presently still have the bitcoins=0A> received.=0A> =
=0A> Furthermore, it is proper for the UTXO to be redeemed at a low-level=
by the=0A> wallet when an entirely unrelated user is sending a transacti=
on. In such a=0A> circumstance, the original recipient of the bitcoins wo=
uld still be able to=0A> sign a message, even though they have nothing to=
do with nor any right to the=0A> goods/services purchased with the trans=
action redeeming that UTXO.=0A> =0A>> Here are a use of=0A>> bitcoin sign=
atures ( https://bitcointalk.org/index.php?topic=3D497545.0 ) to=0A>> spe=
ak about a real case.=0A> =0A> Yes, there are a few good use cases for th=
e current signed messages, but they=0A> appear to be a minority at the mo=
ment. I suspect implementing any URI-based=0A> signing would actually mak=
e them more difficult as well, since it is=0A> additional code on the req=
uester's part.=0A=0AOk,thx for your answer, I actually agree with you up =
until the last sentence. (if not I wouldn't propose this URI scheme :-)=
=0A=0A--=0AArthur
|
