summaryrefslogtreecommitdiff
path: root/dc/cc3d3cdc798a5776becb5d0c0ee0fad6092e2d
blob: af1aa2fca5a823b737a43cdc1e06bfa11baff864 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1UpOiM-0005ui-W0
	for bitcoin-development@lists.sourceforge.net;
	Wed, 19 Jun 2013 20:10:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.172 as permitted sender)
	client-ip=209.85.223.172; envelope-from=etotheipi@gmail.com;
	helo=mail-ie0-f172.google.com; 
Received: from mail-ie0-f172.google.com ([209.85.223.172])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UpOiL-0003i8-8l
	for bitcoin-development@lists.sourceforge.net;
	Wed, 19 Jun 2013 20:10:46 +0000
Received: by mail-ie0-f172.google.com with SMTP id 16so14717516iea.3
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 19 Jun 2013 13:10:40 -0700 (PDT)
X-Received: by 10.50.108.114 with SMTP id hj18mr11191955igb.87.1371672639920; 
	Wed, 19 Jun 2013 13:10:39 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
	[76.111.96.126])
	by mx.google.com with ESMTPSA id fu2sm7675496igb.3.2013.06.19.13.10.39
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 19 Jun 2013 13:10:39 -0700 (PDT)
Message-ID: <51C21035.9080407@gmail.com>
Date: Wed, 19 Jun 2013 16:10:29 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
In-Reply-To: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
	boundary="------------060205010308040202080405"
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1UpOiL-0003i8-8l
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 20:10:47 -0000

This is a multi-part message in MIME format.
--------------060205010308040202080405
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
> 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't 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 "contact" 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's sequence are attributed to
> that contact. The wallet can organize the contacts, and roll-up the
> transaction history into 'ledgers' and 'balances' however they want --
> it could be based on the underlying BIP32 hierarchy or perhaps not.
> The cost of watching large a number of pubkeys, even if you 'look
> ahead' 100 pubkeys for each contact, is relatively small versus the
> benefits.
>  
>

What you just described is complimentary to what I am proposing.  There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances.  BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does).  And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory. 

So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts.  For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity.   If I
don't want that, I use your method.  If I do want that, I use my
method.  Given its simplicity, I don't know why both can't be options.

Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.

-Alan

--------------060205010308040202080405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 06/19/2013 03:29 PM, Jeremy Spilman wrote:<br>
    <blockquote cite="mid:5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="content-type">
      <div dir="ltr">
        <div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR:
          #000000">
          <div>
            <div style="FONT-SIZE: small; FONT-FAMILY: 'Calibri';
              FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal;
              TEXT-DECORATION: none; DISPLAY: inline">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*.</div>
            <div dir="ltr">
              <div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri';
                COLOR: #000000">
                <div>&nbsp;</div>
                <div>I don&#8217;t 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.</div>
                <div>&nbsp;</div>
                <div>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 &#8220;contact&#8221; 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&#8217;s sequence are
                  attributed to that contact. The wallet can organize
                  the contacts, and roll-up the transaction history into
                  &#8216;ledgers&#8217; and &#8216;balances&#8217; however they want &#8211; it could
                  be based on the underlying BIP32 hierarchy or perhaps
                  not. The cost of watching large a number of pubkeys,
                  even if you &#8216;look ahead&#8217; 100 pubkeys for each contact,
                  is relatively small versus the benefits.</div>
                <div>&nbsp;</div>
                <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What you just described is complimentary to what I am proposing.&nbsp;
    There is nothing stopping you from doing it that way, except that it
    may be inconvenient in some circumstances.&nbsp; BIP 32 does not
    prescribe a way to use multiple chains like you described with the
    convenient type-2 derivation (though we could create a variant that
    does).&nbsp; And all separate chains with their 100-address look-aheads
    may be fine for your desktop or mobile device, but maybe not a HW
    signing device with 128 kB of memory.&nbsp; <br>
    <br>
    So, some use cases might prefer having a different parent public key
    [and chaincode] per contact, some may prefer to synchronize across
    many contacts.&nbsp; For instance, maybe there's a benefit to using the
    same parent pubkey across multiple services, as a form of
    identity.&nbsp;&nbsp; If I don't want that, I use your method.&nbsp; If I do want
    that, I use my method.&nbsp; Given its simplicity, I don't know why both
    can't be options.<br>
    <br>
    Actually, it doesn't have to be specific to the payment protocol, it
    can just be alternative address encoding that some apps would use if
    they have a need for it. <br>
    <br>
    -Alan<br>
  </body>
</html>

--------------060205010308040202080405--