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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W9w88-0001De-DD
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Feb 2014 12:26:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.96 as permitted sender)
client-ip=62.13.148.96; envelope-from=pete@petertodd.org;
helo=outmail148096.authsmtp.net;
Received: from outmail148096.authsmtp.net ([62.13.148.96])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W9w87-0001ke-7Z for bitcoin-development@lists.sourceforge.net;
Sun, 02 Feb 2014 12:26:32 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s12CQLn0025213;
Sun, 2 Feb 2014 12:26:21 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s12CQHah041558
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 2 Feb 2014 12:26:19 GMT
Date: Sun, 2 Feb 2014 07:26:10 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140202122610.GA22329@savin>
References: <CAAS2fgQmsxjkQFSiCdeMoVMaqq5720KpUpdkKZOE+XytHsWw0w@mail.gmail.com>
<20140124090218.GA15398@savin>
<CANEZrP0MnXr4xjaMPg7v7vTiDQr-y7esvEBE=xk=Y0BUGXak9A@mail.gmail.com>
<20140124154235.GA3741@netbook.cypherspace.org>
<20140124161330.GA31233@petertodd.org>
<20140125161901.GA17457@netbook.cypherspace.org>
<20140202023651.GA18666@savin> <op.xanddiq6yldrnw@laptop-air>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
In-Reply-To: <op.xanddiq6yldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 38b2dd28-8c05-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgAUHlAWAgsB AmIbWlZeUlt7W2M7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAB5y Z2ZPChl2dgBDcDBy ZUFgXj5YVBZ4IRJ/
SlNcRm0DeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA5LBSY1 TB1DVTghE0wORig1
M1Q8J0MHFUwVPw07 PVc7EUwZOlcNBwxa fQlVCS5DJl8ODwsB
IEsaZ0NMWBdUQDsU DBoyagVFHydbUC5V TEJJRwsCEDhIS2gg
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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
X-Headers-End: 1W9w87-0001ke-7Z
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] (space) efficient reusable addr via weil
pairing IBE (Re: Bait for reusable 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, 02 Feb 2014 12:26:32 -0000
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 02, 2014 at 01:16:20AM -0800, Jeremy Spilman wrote:
> >
> >Consequently you can now securely and very network/space efficiently
> >securely delegate searching a block by computing the private key for the
> >IBE pub key that any sender would use for that block, and sending it as
> >a query to a random (or node-capture defended random selected node).
> >The node can decrypt the encrypted bloom baits with it, but remains
> >powerless to correlate with bloom baits to other payments received by
> >the same user in bother blocks.
> >
>=20
> I'm not sure I've fully wrapped my head around it.
>=20
> d/Q - Identity key
> E - Generate an epoch-pubkey: E =3D Q * H1(epoch)
> r/P - Ephemeral privkey/pubkey, or discoverable from inputs
> S =3D r * K - Shared secret (ECDE)
There needs to be two separate payor pubkeys, which I called elsewhere
the "Filter" and "Recover" pubkeys - the latter I think corresponds to
what you meant by identity key. From those two pubkeys two separate
shared secrets are derived.
The key idea is that you can encrypt a short string of zeros with the
"Filter" pubkey using ECDH and place the resulting "filter bait" in the
transaction. This lets the payor give the secret key corresponding to
that pubkey to a semi-trusted third party. That third party can then
trial decrypt all filter bait seen in transactions in the blockchain,
and every time the decrypted string has a sufficient number of zeros
it's considered a filter pass and the transaction is given to the payor.
For n zero bits one in 2^n transactions will match at random, which sets
your false positive rate.
Basically think of it as a way to outsource the work required for
zero-prefix stealth addresses, but with (less) of a sacrifice of
anonymity compared to just giving the third-party your recovery pubkey.
Identity-based encryption only comes into it because it's nice to be
able to further limit what transactions the server knows about to
specific time intervals rather than forver into the future.
Interestingly both schemes can be used at once - a short public prefix
combined with a second private filter. What's interesting there is that
the public prefix can do a first-pass filtering, with the second private
filter relatively long but still providing plausible deniability - you
can always claim 100% of the matching transactions were false positives
because you didn't receive any funds!
> The full node then uses this privkey to decrypt the same byte in all
> the transactions in that epoch/block which match the expected
> layout/template, e.g. given a certain length OP_RETURN, pull the
> specific byte and decrypt.
>=20
> This decrypted byte is then in turn used as bloom bait which may or
> may not cause the transaction to be sent back to the SPV client.
There's no bloom filters involved; as I said before "bloom bait" is a
misleading name. "Filter bait" is a better term given it's a generic
concept.
> What encryption scheme is being used here?
XOR with the ECDH-calculated nonce is fine. (run the nonce though a hash
function first)
--=20
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJS7jliXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3NTgyOWY2MTY5Yzc5ZDdkNWFhYTIwYmZhOGRhNmU5ZWRi
MjM5M2M0Zjg2NjJiYTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvd6QgAiQgyi3wa0fFBuVDUFWEoHIIr
9oWWjeIa3Kfa8pG3m3GeJ+Ub9Z4JgAJS5P8+PeqTOZwYXGAImsQsJW7d/MB3pmY6
3SeVVT8NvVNemewKlXa70P11xy72goS+o5TA3PkGoGeJROhGE5wnXjvsQbeT4iMJ
IGMXn0I7+10esSx1nKIMxn35cdk/7I2mwXjk2HKz+iy5alxhLxNRoJP8q7YfoTTt
GKQAyWGBt38jjlpves9iLmTHLQreocZ5KI7JhD6fj/roHQ208/07C/ygv8LyvFCW
jnMEcheUp6Vj7dhDGzSwXzy/W8YY1WMNxSHY4k66qXVwyXuDHJlJI6n009AI3w==
=Cgze
-----END PGP SIGNATURE-----
--mP3DRpeJDSE+ciuQ--
|
