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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timo.hanke@web.de>) id 1UpJK2-0001Zq-SP
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 14:25:18 +0000
Received: from mout.web.de ([212.227.15.14])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UpJK0-0002Ab-Rr for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 14:25:18 +0000
Received: from crunch ([137.226.152.116]) by smtp.web.de (mrweb003) with
ESMTPA (Nemesis) id 0MT8cQ-1UiBlo47QU-00S9DZ;
Wed, 19 Jun 2013 16:25:11 +0200
Date: Wed, 19 Jun 2013 16:25:10 +0200
From: Timo Hanke <timo.hanke@web.de>
To: Alan Reiner <etotheipi@gmail.com>
Message-ID: <20130619142510.GA17239@crunch>
References: <51BFD886.8000701@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51BFD886.8000701@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V03:K0:gq1PZkR6sCnnL7LUA0qqw9VUZ6Vzwi8lat1LpU5rp+3zvbKQahh
JkXCcDqvGlvDYlV9V2tw+Z1RUaF7PgP3mgf1jOxUbQN5hFVOayO8Y+qH6V/HRxu8rFdfTEh
RRXLSQ8WqOhFh1yW6AXgSu65xPzsteDXPbOkAeVX6YojdogYkb6aYuIJVbYZthm8SfvraEL
o26QT7TgegkrMZIJIAK3A==
X-Spam-Score: -1.3 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.15.14 listed in list.dnswl.org]
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UpJK0-0002Ab-Rr
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
- Payment Protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: timo.hanke@web.de
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: Wed, 19 Jun 2013 14:25:19 -0000
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called "destination":
> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to "destination", which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same "destination".
Depending on what you have in mind that the transaction should "prove"
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
> Goal: An alternative address format made possible by BIP 32, which allows one
> to specify a "Wallet ID" and "One-time payment" code, instead of the standard
> one-use Base58-Hash160 addresses. This allows parties with a persistent
> relationship to be able to prove that payment addresses they provide each other
> are linked to a particular wallet, reducing exposure to MitM attacks without
> the need for SSL or a web of trust, and without compromising the privacy of
> either party. For instance, this could be used between businesses that
> frequently do business, by exchanging and verifying public keys beforehand, or
> could be used by an exchange to identify if a customer withdrawal address is
> related to their last deposit address, and if not enforce extra authentication
> measures.
>
> Background:
> I haven't been following the payment protocol discussions/development much, so
> I apologize if this has already been addressed. I'm calling it
> "wallet-linkable" addresses, which would be an optional second form for sending
> someone your address. With BIP 32, the address is computed by the payee (the
> person sending the address to receive money):
>
> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> checksum)
>
> What I'd like to do is have the option, when specifying an address through the
> payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]} and let
> the receiver of that address compute the address on their own. This is no
> significant burden on the receiver, but it does provide the useful property
> that they can recognize when addresses specified in this way come from the same
> wallet -- because the PubKeyParent will be the same. Remember, this is
> optional for the person providing the address.
>
> One nice, accidental feature of BIP 32 is that the Multiplier[i] used above
> does not actually reveal the "chaincode" (I think Pieter started calling it the
> "tweak"). It is derived from the chaincode but doesn't reveal it. Therefore,
> the payer sees the parent public key, but that's not useful to derive any of
> the other addresses unless they also have the chaincode. But they can verify
> that the PublicKeyParent is identical between transactions, and thus is
> accessible only to that wallet. It allows them validate a specific address
> provided by the payee, but not generate or identify any other addresses.
>
> Use Cases:
> (1) So, just like with PGP/GPG, when two parties decide they will start a
> relationship, they can start by exchanging the public keys of their wallet and
> verify them in a reliable manner. After that, when one party requests a
> payment address from the other, they can optionally send {PubKey, Multiplier},
> and the payer's software will identify the owner of that address, or let you
> select who you think the address belongs to and it will verify it. If the
> payee's system is compromised and address is replaced, the address received by
> the payer won't validate. This doesn't help if the side sending the money is
> compromised.
>
> (2) When a customer first provides a deposit to an exchange, it will send
> money from an address in their wallet and the software will provide the
> exchange the {PubKey,Mult}. When the customer later provides a withdrawal
> address, the site can automatically trust the address as long it is provided in
> the alternate form and the public keys match. If they don't, it might be the
> same customer just requesting a withdrawal to a different wallet, which is
> fine, but they'll have to go through an extra verification step to do so.
>
>
> Downsides:
> Multi-sig/P2SH - The only way this works with P2SH, violates one of the goals
> of P2SH slightly, but may not matter much if it's all done under the hood by
> the software. Instead of providing a 20-byte hash of a script, you provide all
> the public keys and multipliers for the individual addresses. The payer's
> software automatically verifies all addresses and creates the P2SH script
> itself (after a divine decree that public keys will always be sorted
> lexicographically in the multi-sig script). The blockchain still benefits from
> the "compression" of moving the bulky scripts to the TxIn, but it does require
> revealing more information than is necessary for the payer to pay the payee.
> But it may not really be a problem, given the benefits. It might just be
> slightly longer strings to exchange during initialization and for each
> transaction.
>
> I have various reasons I'd like to use this, and it'd be nice to have some
> community backing, so I don't have to twist anyone's arm to trust me that it's
> legit.
>
> -Alan
>
>
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
|
