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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Vz9Ig-00044A-KI
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:16:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.65 as permitted sender)
client-ip=209.85.160.65; envelope-from=tier.nolan@gmail.com;
helo=mail-pb0-f65.google.com;
Received: from mail-pb0-f65.google.com ([209.85.160.65])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vz9If-0000ew-Dh
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:16:50 +0000
Received: by mail-pb0-f65.google.com with SMTP id rq2so12845193pbb.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 03 Jan 2014 10:16:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.66.182.199 with SMTP id eg7mr97127086pac.135.1388773003501;
Fri, 03 Jan 2014 10:16:43 -0800 (PST)
Received: by 10.70.70.196 with HTTP; Fri, 3 Jan 2014 10:16:43 -0800 (PST)
In-Reply-To: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
References: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
Date: Fri, 3 Jan 2014 18:16:43 +0000
Message-ID: <CAE-z3OW1GWo+CURVt+OJvEQDqBOiDjPNEsMjCU8BQ=0ZSn4UEg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7bd6c70a8c23ee04ef14e9c2
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
(tier.nolan[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: 1Vz9If-0000ew-Dh
Subject: Re: [Bitcoin-development] An idea for alternative payment scheme
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: Fri, 03 Jan 2014 18:16:50 -0000
--047d7bd6c70a8c23ee04ef14e9c2
Content-Type: text/plain; charset=ISO-8859-1
The random number that the buyer uses could be generated from a root key
too.
This would allow them to regenerate all random numbers that they used and
recreate their receipts. The master root would have to be stored on your
computer though.
The payment protocol is supposed to do something like this already though.
On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi <nadav@shesek.info> wrote:
> I had an idea for a payment scheme that uses key derivation, but instead
> of the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
> 1. The payee publishes his master public key
> 2. The payer generates a random "receipt number" (say, 25 random bytes)
> 3. The payer derives an address from the master public key using the
> receipt number and pays to it
> 4. The payer sends the receipt to the payee
> 5. The payee derives a private key with that receipt and adds it to
> his wallet
>
>
> Advantages:
>
> - It increases privacy by avoiding address reuse
> - The process is asynchronous. The payee is completely passive in the
> payment process and isn't required to provide new addresses before each
> payment (so no payment server required)
> - Its usable as a replacement for cases where re-used addresses are
> the most viable solution (like putting an address in a forum signature or
> as a development fund in a github readme)
> - The receipt also acts as a proof of payment that the payer can
> provide to the payee
> - Also, if the master is known to belong to someone, this also allows
> the payer prove to a third-party that the payment was made to that someone.
> If the output was spent, it also proves that he was aware of the payment
> and has the receipt.
> - Its a really thin abstraction layer that doesn't require much changes
>
> Disadvantages:
>
> - Losing the receipt numbers means losing access to your funds, they
> are random and there's no way to restore them
> - It requires sending the receipt to the payee somehow. Email could
> work for that, but a better defined channel that also can talk to the
> Bitcoin client and add the receipt would be much better.
>
> What do you think?
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--047d7bd6c70a8c23ee04ef14e9c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The random number that the buyer uses could be genera=
ted from a root key too.<br><br></div><div>This would allow them to regener=
ate all random numbers that they used and recreate their receipts.=A0 The m=
aster root would have to be stored on your computer though.<br>
<br></div><div>The payment protocol is supposed to do something like this a=
lready though.<br></div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi <span dir=3D"lt=
r"><<a href=3D"mailto:nadav@shesek.info" target=3D"_blank">nadav@shesek.=
info</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I had an idea for a pa=
yment scheme that uses key derivation, but instead of the payee deriving th=
e addresses, the payer would do it.</div>
<div><br></div><div>It would work like that:</div><div><ol><li>The payee pu=
blishes his master public key<br>
</li><li>The payer generates a random "receipt number" (say, 25 r=
andom bytes)<br></li><li>The payer derives an address from the master publi=
c key using the receipt number and pays to it<br></li><li>The payer sends t=
he receipt to the payee<br>
</li><li>The payee derives a private key with that receipt and adds it to h=
is wallet<br></li></ol></div><div><br></div><div>Advantages:</div><div><ul>=
<li>It increases privacy by avoiding address reuse<br></li><li>The process =
is asynchronous. The payee is completely passive in the payment process and=
isn't required to provide new addresses before each payment (so no pay=
ment server required)<br>
</li><li>Its usable as a replacement for cases where re-used addresses are =
the most viable solution (like putting an address in a forum signature or a=
s a development fund in a github readme)<br></li><li>The receipt also acts =
as a proof of payment that the payer can provide to the payee<br>
</li><li>Also, if the master is known to belong to someone, this also allow=
s the payer prove to a third-party that the payment was made to that someon=
e. If the output was spent, it also proves that he was aware of the payment=
and has the receipt.<br>
</li><li>Its a really thin abstraction layer that doesn't require much =
changes</li></ul></div><div>Disadvantages:</div><div><ul><li>Losing the rec=
eipt numbers means losing access to your funds, they are random and there&#=
39;s no way to restore them<br>
</li><li>It requires sending the receipt to the payee somehow. Email could =
work for that, but a better defined channel that also can talk to the Bitco=
in client and add the receipt would be much better.</li></ul></div><div>
What do you think?</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Rapidly troubleshoot problems before they affect your business. Most IT<br>
organizations don't have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami=
cs Pro!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--047d7bd6c70a8c23ee04ef14e9c2--
|
