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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1W3m6V-00019N-67
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 12:31:23 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.194])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W3m6T-0000Ty-AN
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 12:31:22 +0000
Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70])
by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis)
id 0MOOMv-1VxzD61Iij-006OFa; Thu, 16 Jan 2014 07:31:14 -0500
Received: by netbook (Postfix, from userid 1000)
id 3272F2E283F; Thu, 16 Jan 2014 13:31:07 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
Thu, 16 Jan 2014 13:31:06 +0100
Date: Thu, 16 Jan 2014 13:31:05 +0100
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20140116123105.GA30307@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140116:bitcoin-development@lists.sourceforge.net::hu2EtxghltRW9
IqO:000000000000000000000cyc
X-Hashcash: 1:20:140116:jeremy@taplink.co::xSAAhAg0wZU1sdbG:00000000000000000000
0000000000000000000000000+c0
X-Hashcash: 1:20:140116:alan@bitcoinarmory.com::7JWNf8rCJg//tTNT:000000000000000
000000000000000000000000190J
X-Hashcash: 1:20:140116:adam@cypherspace.org::lRdhfs8EAQbb8wpN:00000000000000000
0000000000000000000000004HON
X-Provags-ID: V02:K0:vbo4wzt9sYCA+13TgmnenfyMHskM90nBQBMP09MF91U
Y0UB+zgA/N8GRVqqCuPbwri/r7OsJHq+/I+5IfurCCOcvcko0t
UEuYkFC2Uy/1NeWwvRxnSbsbvQjAMujOq5CEfmNwc5oURQvHJx
mX8fr+25P8/V3D24LRpHgSqouKjNs7Ms40dlNBNdSHsI/DDOIm
IJfzaIwAlyaGycZfKLy7LVy25LCH0d9UgjQ2SXG25FuQtv7noJ
+Zo7XcLTkIfX6r3DL3iA0EbmOuMduTukVfPllcGhCaD+iOlhKL
ZiWH63rExdK23L1NqCzPs0EwGg0mQl+4u1JPbVNYV9w0xm7VSv
xxMp5jE7KU6QbN1/7x5cpXJNVEeMv6OceSYiOrX0+
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.194 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1W3m6T-0000Ty-AN
Cc: Alan Reiner <alan@bitcoinarmory.com>
Subject: [Bitcoin-development] TOFU verifiable HD publicly derived addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 12:31:23 -0000
Put this into a separate thread about Alan Reiner's user validatable HD
address idea.
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote:
>On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <adam@cypherspace.org> wrote
>>Maybe in the payment address case the service should choose the
>>derivation factor and communicate it and the client with the static
>>address, as suggested by Alan Reiner because then it can also serve
>>the function of allowing the service to tie the payment to the users
>>account.
>
>I think any change which requires more than a single published public
>message (e.g. a posting in a forum, or in a README.me in Github)
>should be seen as solving an entirely different problem.
Yes it is. This part is a separate topic, about simple TOFU cross-check &
verifiability of deposit addresses by users.
(However as we've seen in practice users treat as static and expect service
deposit addresses to be reusable. So it could be useful to combine.)
>But once you admit having that directed communication, then you are
>swimming very close to the payment protocol.
My view is that certification (X509 or raw ECDSA message signature) is
functionally inferior (and more complex) than communicating scalar, base
address because certification requires an online private key to
authenticate. Scalar, base does not require a private key. In fact you
could use HD address public derivation as the mechanism to derive the scalar,
where the deposit address recipient does not know the scalar. So I am a fan
of Alan Reiner's simple authenticatable derived address proposal.
Now of course you can take the private key offline and use eg private
derivation and upload batches, but that is complexity and work; so again its
an approach with arguably inferior characteristics.
Also to date payment message is application level, and while you could add
another level of signed message with a different offline X509 key, which
Mike Hearn did suggest as a future possibility, and upload signed addresses
in batches, its clunky by comparison, involves many more lines of code, adds
a security dependency on CAs, and I think you could somewhat argue is a
protocol layering violation.
Anyway if people want to do that, there is no loss in X509 signing a TOFU
validatable address form. ie go ahead and combine them. TOFU
validatability of the low level address format is useful, you can cross
check.
One could also consider augmenting the derivation with Timo Hanke's bind to
contract hash, though there is risk that both parties lose the contract and
if it has too much entropy that could lose coins.
Adam
|
