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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nadav@shesek.info>) id 1Vz93d-0002a4-6q
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:01:17 +0000
X-ACL-Warn:
Received: from mail-vc0-f174.google.com ([209.85.220.174])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vz93b-0004Bd-9c
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:01:17 +0000
Received: by mail-vc0-f174.google.com with SMTP id if17so7485049vcb.33
for <bitcoin-development@lists.sourceforge.net>;
Fri, 03 Jan 2014 10:01:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-type;
bh=lVN+ZUQycRgef6XGumW8hS3bWgZFRqG3ly6t6cLtibg=;
b=CUcblh+3KiCnk0PrigR3T8DQKwZy/rbMZvBtkKToKTREQBzDIFhQi+G8Fhbu5szcO9
5aY/y5XQaiG405Ro61HTlTn210EtEg+iG1PnlSuaWJrYNoq4Key+l1vYWXFI66NA4fvi
rKdr6VfjChkm1gDAfuKAfYE6hXAIdEMZ6ocV80HkV9Y76Li2jKGO3E2HLoAI7e0XlIR1
5ukkiwpLz85/KDeWxK28O6St7eYtc2yBWRimNU1PdY7maqBXSGdNcJKpgSBP5cTuDWC5
+irfPmAEc2MylbGVcGVb/Eye6N4l50K7lc6VgV3zBHkLenzvmWmSOuAsQzyaf+NX+RHv
exjw==
X-Gm-Message-State: ALoCoQlO5CSua3k5UzJDqnouL5B2H0O0sgBYBebgoNGjhWJjw74z20tgnOziNj1Mj6eLYZ+OnLKf
X-Received: by 10.220.186.202 with SMTP id ct10mr53314783vcb.14.1388772069652;
Fri, 03 Jan 2014 10:01:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.245.98 with HTTP; Fri, 3 Jan 2014 10:00:49 -0800 (PST)
X-Originating-IP: [84.228.227.229]
From: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 3 Jan 2014 20:00:49 +0200
Message-ID: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b676fd0e300ca04ef14b1d0
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1Vz93b-0004Bd-9c
Subject: [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:01:17 -0000
--047d7b676fd0e300ca04ef14b1d0
Content-Type: text/plain; charset=ISO-8859-1
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?
--047d7b676fd0e300ca04ef14b1d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I had an idea for a payment scheme that uses key deri=
vation, but instead of the payee deriving the addresses, the payer would do=
it.</div><div><br></div><div>It would work like that:</div><div><ol><li>Th=
e payee publishes 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>
--047d7b676fd0e300ca04ef14b1d0--
|
