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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Vz9WA-0003rz-J5
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:30:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.49 as permitted sender)
client-ip=209.85.215.49; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f49.google.com;
Received: from mail-la0-f49.google.com ([209.85.215.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vz9W9-0001RV-NW
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 18:30:46 +0000
Received: by mail-la0-f49.google.com with SMTP id er20so8273211lab.36
for <bitcoin-development@lists.sourceforge.net>;
Fri, 03 Jan 2014 10:30:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.6.201 with SMTP id d9mr25199756laa.25.1388773838962;
Fri, 03 Jan 2014 10:30:38 -0800 (PST)
Received: by 10.112.198.65 with HTTP; Fri, 3 Jan 2014 10:30:38 -0800 (PST)
In-Reply-To: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
References: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
Date: Fri, 3 Jan 2014 10:30:38 -0800
Message-ID: <CAAS2fgQ8M6=Utj7SBpN4Fiv6rgBKvZfm5jpmwkFRuFsZYZLqHQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Nadav Ivgi <nadav@shesek.info>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Vz9W9-0001RV-NW
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 18:30:46 -0000
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.
|
