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
|
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 <adam@cypherspace.org>) id 1VzBHR-0001Q6-7t
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 20:23:41 +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 1VzBHP-00009L-Dz
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 20:23:41 +0000
Received: from netbook (88-105-1-32.dynamic.dsl.as9105.com [88.105.1.32])
by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis)
id 0MC4Ay-1W80xr1hEO-009M4f; Fri, 03 Jan 2014 15:23:32 -0500
Received: by netbook (Postfix, from userid 1000)
id C209B2E4A57; Fri, 3 Jan 2014 21:23:25 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
Fri, 3 Jan 2014 21:23:21 +0100
Date: Fri, 3 Jan 2014 21:23:20 +0100
From: Adam Back <adam@cypherspace.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140103202320.GA16515@netbook.cypherspace.org>
References: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
<CAAS2fgQ8M6=Utj7SBpN4Fiv6rgBKvZfm5jpmwkFRuFsZYZLqHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CAAS2fgQ8M6=Utj7SBpN4Fiv6rgBKvZfm5jpmwkFRuFsZYZLqHQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140103:gmaxwell@gmail.com::bnV6qRxtl1F8QZ51:0000000000000000000
0000000000000000000000001ULN
X-Hashcash: 1:20:140103:nadav@shesek.info::NXGW5ZC15XNKQ2Ay:00000000000000000000
000000000000000000000000I0kA
X-Hashcash: 1:20:140103:bitcoin-development@lists.sourceforge.net::fMQ8kKY3nq9N0
RSP:000000000000000000003pd6
X-Hashcash: 1:20:140103:adam@cypherspace.org::sWDuNXtz7WtpYCtd:00000000000000000
0000000000000000000000007RLy
X-Provags-ID: V02:K0:vr+RbLLlESXLfapcK1J3B38iN1+MeRMr7aoVV8s4sLD
wKWzJJBfMdejcOX91dUPKYhIZNucvud5UmDJRYrevn0fBeM7ER
LNJDEJJ7MlALYjKa/bZQQpgt3n1yYA56D3qIPDEYbbyEfa0FYk
R08SOePSmhnG4I9pAV2yHbx2OEvZjUFFnX+kkz/bqYKo7I/kCZ
h6nF6ngZvR18MECLkA91GS5WlCTXWRy60TzYLoUxbPdUGQQj8X
EO20Bv8+de0MOSILWfLdqgYiWnEP9JwVMzmWoakdkd6q6KcOn9
EfK9aiYLv43RRjDVN/qTI5t7jEPTzxYrZBNg+gqll8sJ5yoMKA
IE93z59C5367N+H9b9PbSurDvczcoJkvvxtB27lwr
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: 1VzBHP-00009L-Dz
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
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 20:23:41 -0000
Seems like you (Nadav) are the third person to reinvent this idea so far :)
I wrote up some of the post-Bytecoin variants here:
https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530
The general limitation so far is its not SPV compatible, so the recipient
has to test each payment to see if its one he can compute the private key
for. Or the sender has to send the recipient out of band the derivation
key.
However at present most of the bitcoin infrastructure is using the bitcoin
broadcast channel as the communication channel, which also supports payer
and payee not being simultaneously online. You have to be careful also not
to lose the key. You dont want a subsequent payer data loss event to lose
money for the recipient. You want the message to be sent atomically.
It does seem like a very attractive proposition to be able to fix the
address reuse issue. Admonishment to not reuse addresses doesnt seem to
have been successful so far, and there are multiple widely used wallets that
reuse addresses (probably in part because they didnt implement HD wallets
and so are scared of losing addresses due to backup failure risks of non HD
wallets and fresh addresses).
Adam
On Fri, Jan 03, 2014 at 10:30:38AM -0800, Gregory Maxwell wrote:
>On Fri, Jan 3, 2014 at 10:00 AM, 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:
>>
>> The payee publishes his master public key
>> The payer generates a random "receipt number" (say, 25 random bytes)
>> The payer derives an address from the master public key using the receipt
>> number and pays to it
>> The payer sends the receipt to the payee
>> The payee derives a private key with that receipt and adds it to his wallet
>
>Allow me to introduce an even more wild idea.
>
>The payee publishes two public keys PP PP2.
>
>The payer picks the first k value he intends to use in his signatures.
>
>The payer multiplies PP2*k = n.
>
>The payer pays to pubkey PP+n with r in his first signature, or if
>none of the txins are ECDSA signed, in an OP_RETURN additional output.
>
>The payer advises the payee that PP+(pp2_secret*r) is something he can
>redeem. But this is technically optional because the payee can simply
>inspect every transaction to check for this condition.
>
>This is a (subset) of a scheme by Bytecoin published a long time ago
>on Bitcoin talk.
>
>It has the advantage that if payer drops his computer down a well
>after making the payment the funds are not lost, and yet it is still
>completely confidential.
>
>(The downside is particular way I've specified this breaks using
>deterministic DSA unless you use the OP_RETURN, ... it could instead
>be done by using one of the signature pubkeys, but the pubkeys may
>only exist in the prior txin, which kinda stinks. Also the private
>keys for the pubkeys may only exist in some external hardware, where a
>OP_RETURN nonce could be produced when signing).
>
>These schemes have an advantage over the plain payment protocol
>intended use (where you can just give them their receipt number, or
>just the whole key) in that they allow the first round of
>communication to be broadcast (e.g. payee announced to EVERYONE that
>he's accepting payments) while preserving privacy.
>
>------------------------------------------------------------------------------
>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
|
