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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1UpO4I-0000gW-EJ
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 19:29:22 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1UpO4H-000207-38 for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 19:29:22 +0000
Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ;
Wed, 19 Jun 2013 12:29:42 -0700
Message-ID: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
Date: Wed, 19 Jun 2013 12:29:19 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0F1D_01CE6CE8.9EFF3160"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
oclient: 192.168.168.158#jeremy@taplink.co#465
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UpO4H-000207-38
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
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 19:29:22 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_0F1D_01CE6CE8.9EFF3160
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
If you have two parties who want to form a persistent relationship, by =
exchanging and verifying public keys beforehand, then I think the =
canonical way to do this with BIP32 is for the parties to exchange =
PubKey and *ChainCode*.
I don=E2=80=99t understand the use case for handing out individual =
multipliers, if what you desire is a persistent relationship. If each =
party dedicates a child-wallet for receiving coins, and saves a =
PubKey/ChainCode for sending coins, the two parties can transaction =
securely forever without ever exchanging any more information, and =
without any address reuse.
I think ideally, the default behavior is that wallets always dedicate a =
new child node {PubKey, ChainCode} to each party they transact with. At =
the presentation layer, you have a =E2=80=9Ccontact=E2=80=9D and each =
contact has a transaction history. You can send coins to a contact at =
any time, and internally the wallet picks the next address in their =
sequence. Any funds received on pubkeys from contact=E2=80=99s sequence =
are attributed to that contact. The wallet can organize the contacts, =
and roll-up the transaction history into =E2=80=98ledgers=E2=80=99 and =
=E2=80=98balances=E2=80=99 however they want =E2=80=93 it could be based =
on the underlying BIP32 hierarchy or perhaps not. The cost of watching =
large a number of pubkeys, even if you =E2=80=98look ahead=E2=80=99 100 =
pubkeys for each contact, is relatively small versus the benefits.
What might be nice is a =E2=80=98Contact Request=E2=80=99 protocol, =
basically the same as a PaymentRequest but no actual payments are sent, =
just child wallets created:
message Contact {
optional uint32 contact_version =3D 1 [default =3D 1];
optional string pki_type =3D 2 [default =3D "none"];
optional bytes pki_data =3D 3;
required bytes serialized_contact_details =3D 4;
optional bytes signature =3D 5;
}
message ContactDetails {
optional string network =3D 1 [default =3D "main"];
required bytes pubkey =3D 2;
required bytes chaincode =3D 3;
optional string memo =3D 4;
optional string response_url =3D 5;
}
Alice sends a Contact+ContactDetails to Bob. If Bob accepts, he sends =
his own Contact+ContactDetails (without a response_url) back to Alice. =
Basically just like adding a contact to your IM contacts.
Alice could send a Contact+ContactDetails to Bob without a response_url, =
in which case after accepting the contact, Bob could send funds to =
Alice, but not receive funds.
You could probably pack the whole message inside a bitcoin:// URI if you =
wanted to.
Thanks,
--Jeremy
------=_NextPart_000_0F1D_01CE6CE8.9EFF3160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<META content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3Dcontent-type></HEAD>
<BODY dir=3Dltr bgColor=3D#ffffff text=3D#000000>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>
<DIV=20
style=3D"FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; =
COLOR: #000000; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: =
inline">If=20
you have two parties who want to form a persistent relationship, by =
exchanging=20
and verifying public keys beforehand, then I think the canonical way to =
do this=20
with BIP32 is for the parties to exchange PubKey and *ChainCode*.</DIV>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV> </DIV>
<DIV>I don=E2=80=99t understand the use case for handing out individual =
multipliers, if=20
what you desire is a persistent relationship. If each party dedicates a=20
child-wallet for receiving coins, and saves a PubKey/ChainCode for =
sending=20
coins, the two parties can transaction securely forever without ever =
exchanging=20
any more information, and without any address reuse.</DIV>
<DIV> </DIV>
<DIV>I think ideally, the default behavior is that wallets always =
dedicate a new=20
child node {PubKey, ChainCode} to each party they transact with. At the=20
presentation layer, you have a =E2=80=9Ccontact=E2=80=9D and each =
contact has a transaction=20
history. You can send coins to a contact at any time, and internally the =
wallet=20
picks the next address in their sequence. Any funds received on pubkeys =
from=20
contact=E2=80=99s sequence are attributed to that contact. The wallet =
can organize the=20
contacts, and roll-up the transaction history into =
=E2=80=98ledgers=E2=80=99 and =E2=80=98balances=E2=80=99=20
however they want =E2=80=93 it could be based on the underlying BIP32 =
hierarchy or=20
perhaps not. The cost of watching large a number of pubkeys, even if you =
=E2=80=98look=20
ahead=E2=80=99 100 pubkeys for each contact, is relatively small versus =
the=20
benefits.</DIV>
<DIV> </DIV>
<DIV>What might be nice is a =E2=80=98Contact Request=E2=80=99 protocol, =
basically the same as a=20
PaymentRequest but no actual payments are sent, just child wallets=20
created:</DIV>
<DIV> </DIV>
<DIV>message Contact {</DIV>
<DIV> optional uint32 contact_version =3D 1 [default =
=3D 1];</DIV>
<DIV> optional string pki_type =3D 2 [default =3D =
"none"];</DIV>
<DIV> optional bytes pki_data =3D 3;</DIV>
<DIV> required bytes serialized_contact_details =3D =
4;</DIV>
<DIV> optional bytes signature =3D 5;</DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV>message ContactDetails {</DIV>
<DIV> optional string network =3D 1 [default =3D =
"main"];</DIV>
<DIV> required bytes pubkey =3D 2;</DIV>
<DIV> required bytes chaincode =3D 3;</DIV>
<DIV> optional string memo =3D 4;</DIV>
<DIV> optional string response_url =3D 5;</DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV>Alice sends a Contact+ContactDetails to Bob. If Bob accepts, =
he sends=20
his own Contact+ContactDetails (without a response_url) back to Alice. =
Basically=20
just like adding a contact to your IM contacts.</DIV>
<DIV> </DIV>
<DIV>Alice could send a Contact+ContactDetails to Bob without a =
response_url, in=20
which case after accepting the contact, Bob could send funds to Alice, =
but not=20
receive funds.</DIV>
<DIV> </DIV>
<DIV>You could probably pack the whole message inside a bitcoin:// URI =
if you=20
wanted to.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>--Jeremy</DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML>
------=_NextPart_000_0F1D_01CE6CE8.9EFF3160--
|
