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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1W2ILv-0000va-9q
for bitcoin-development@lists.sourceforge.net;
Sun, 12 Jan 2014 10:33:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W2ILu-0002qt-5F for bitcoin-development@lists.sourceforge.net;
Sun, 12 Jan 2014 10:33:11 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Sun, 12 Jan 2014 02:41:32 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
References: <20140106120338.GA14918@savin>
<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
<20140110102037.GB25749@savin>
Date: Sun, 12 Jan 2014 02:33:02 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <20140110102037.GB25749@savin>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -1.7 (-)
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 SPF_PASS SPF: sender matches SPF record
-0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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: 1W2ILu-0002qt-5F
Subject: Re: [Bitcoin-development] Stealth Addresses
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: Sun, 12 Jan 2014 10:33:11 -0000
> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.
Great point. Even if it's not a 3rd party, I think it's really important
to be able to scan for transactions with a key which can't actually spend
the funds.
The first approach is just one-pass ECDH. I think you're saying the second
approach is two rounds of ECDH but re-using the same e/P (usually referred
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key
for signing operations.
Payee: Publish Q, Q2 [d, d2 are privkeys, Q, Q2 are
pubkeys]
Payer: 1) Generate ephemeral key: e / P [e is privkey, P is pubkey]
2) S = e * Q [first shared secret]
3) S2 = e * Q2 [second shared secret, reusing
'e']
4) Q' = Q + H(S) [pay-to stealth address]
5) Q2' = Q2 + H(S2) [stealth 'marker']
Watch: 1) Look for TxOut with OP_RETURN <P>
2) Q2' = Q2 + H(d2 * P)
3) Check for Q2' elsewhere in the Tx
S/MIME for example, allows reuse of the ephemeral keypair. When reusing an
ephemeral keypair where A reuses (x, X) to encrypt different messages to
more than one user, A should verify the static public keys to prevent
small-subgroup attacks.[1][2]
Let's say you pay-to Q' and then Q2' value has to be somewhere else in the
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN
<P> <Q2'> would be 66 bytes.
But then Mallory could generate transactions with the right Q2' but with
his own pubkey in Step 2 instead of Q. So your scanner would detect a
payment, but you wouldn't be able to spend it, and Mallory could.
That's a good argument for putting Q2' in a 2-of-2 multisig so that
pulling this trick would at least make the transaction unspendable for
both parties, which may be good enough deterrent, but you're still going
to want to check it against your 'd' before fulfilling a large order. Your
online watch process could queue the matching transactions, which you
could move to your offline machine, decrypt your key, and verify the
transactions are spendable.
Now, you would need to get two pubkeys to the payer, throw in a prefix to
help standardize it, and end up with addresses that could look like (for
example):
xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
Those addresses are 74 bytes:
<Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>
xSTL Prefix = 0xC0CB9270
tSTL Prefix = 0xB2E27D50
NOTE: I do NOT have the corresponding privkeys for these four pubkeys!
Those just happened to be the first matching prefixes I found for 74 byte
addresses. I could try to find ones which start with a specific byte if
that's somehow better, like 0x04 to match BIP32.
Unfortunately, I don't think you can just derive a second public key from
the first to keep the address shorter, and still keep the first private
key secure, even if the second private key is stolen. You only get
equivalent security as BIP32 public derivation, where you can't lose a
child private key.
Do we also want xSTL (or whatever user friendly string) prefixes for
single pubkey (41 byte) stealth addresses?
I'll wait a couple days for feedback, then I'll try to implement the
following prototypes:
1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given
encrypted d/d2
Obviously extending QT directly for #1 would be ideal, I may even be able
to do that since supporting a new address type should be fairly contained.
But if not I'll punt to writing a node.js or python script which connects
to bitcoind via RPC.
Thanks,
Jeremy
[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
[2] - Validation of Elliptic Curve Public Keys
http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf
|
