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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AD93C131F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Sep 2015 12:10:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9B0739C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Sep 2015 12:10:21 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 45AB01080051;
Tue, 15 Sep 2015 12:08:59 +0000 (UTC)
X-Hashcash: 1:25:150915:arthur@bitcoin-fr.io::vA0rRuq8rKpB5Ssk:bW3OB
X-Hashcash: 1:25:150915:bitcoin-dev@lists.linuxfoundation.org::AKNNvw2gSwJz0S63:a5T/+
From: Luke Dashjr <luke@dashjr.org>
To: "Arthur - bitcoin-fr.io" <arthur@bitcoin-fr.io>
Date: Tue, 15 Sep 2015 12:08:57 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.6-gentoo; KDE/4.14.8; x86_64; ; )
References: <201509150403.40909.luke@dashjr.org>
<c5f5105e2d5b9cc1873f84cb0b172285@rainloop.aaawop.com>
<15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com>
In-Reply-To: <15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201509151208.58326.luke@dashjr.org>
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
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 12:10:22 -0000
On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:
> September 15 2015 6:04 AM, "Luke Dashjr" <luke@dashjr.org> wrote:
> > I think probably the whole signed message thing needs to be rethought.
> > The most common "uses" today seem to be insecure cases that it doesn't
> > actually work in: people trying to prove ownership of bitcoins and/or
> > that they sent bitcoins (current signed messages can do neither).
> > Ideally, whatever the new method is should also avoid using the same key
> > as for signing transactions, since the public key is technically private
> > information. Furthermore, since addresses are semi-deprecated (by the
> > payment protocol), I'm not sure it makes sense to do this without
> > designing an entire authentication system, which may be rather complex.
> >
> > Luke
>
> My proposal is about the current signing process (which exists event it
> it's not perfect) but it could also work with a new signing message system
> tomorrow. It more about give users an easier way to access existing tools
> than the "sign message thing" itself.
One of my concerns is that making the existing signatures even easier will
cause incompatible uses to become more prolific and accepted, increasing the
overall risk. Hence my recommendation to satisfy these clearly-existing use
cases with a safe signature *first*.
> BTW I'm aware of privacy issues, but could you elaborate on why the use
> case your are referring to doesn't actually work?
The signed message proves that the person who *receives* payment with the
address agrees to a given message/contract.
It is therefore appropriate and a best practice for web wallet providers
(inherent problems with webwallets aside) to allow users to sign messages
with their deposit addresses. When bitcoins are received by this address, the
transaction creates a low-level UTXO representing the bitcoins *in the
wallet*, but this UTXO is not associated with the address itself. Therefore,
it is entirely possible that this UTXO remains unspent/valid on the
blockchain even after the user in question has spent their entire balance at
the webwallet and therefore such a signature proves only that they once
received the payment, but *not* that they presently still have the bitcoins
received.
Furthermore, it is proper for the UTXO to be redeemed at a low-level by the
wallet when an entirely unrelated user is sending a transaction. In such a
circumstance, the original recipient of the bitcoins would still be able to
sign a message, even though they have nothing to do with nor any right to the
goods/services purchased with the transaction redeeming that UTXO.
> Here are a use of
> bitcoin signatures ( https://bitcointalk.org/index.php?topic=497545.0 ) to
> speak about a real case.
Yes, there are a few good use cases for the current signed messages, but they
appear to be a minority at the moment. I suspect implementing any URI-based
signing would actually make them more difficult as well, since it is
additional code on the requester's part.
Luke
|
