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
174
175
176
177
178
179
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <brian@factom.org>) id 1YmklS-00017I-Cx
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 15:16:06 +0000
Received: from mail-ie0-f180.google.com ([209.85.223.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YmklP-0004NG-1h
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 15:16:06 +0000
Received: by iejt8 with SMTP id t8so128521170iej.2
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Apr 2015 08:15:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc
:content-type;
bh=ukCjf1VIVVmOik23Ilgvf+F+MDttUJksjmr4Gkf28U4=;
b=HihrzbHKemml8zoCLS4bUMDDvVZTg4K1/Kx0lXhhkCOBKRB0IcPT9bbbrcz6SVJK+X
1CdKfr6oAZK/U61rI0nAKJM949H8BAez7OxYUyqTcHBr4I/Cx1Jtvlsr2v4KNKT4cCX3
ndS47sBiEFQmJBcwYWvTlXbiNTVBUJLlCHfBjqOi+xrI6tfByskIRy9KRmQTd9XGT2F+
KmLbHYPhcxm4ZLVY9i1/L8IU9Osdu1ReQsIM6Ylz3eg2wyC1nw47L5FqJ9S8XZk66NV8
QPhbTf56qA9BQyQGVl1xX33HZBLJjmC4gx9y3euyUi7hLR/QzUAQbdF+Q30rG7kOrbQd
qeeA==
X-Gm-Message-State: ALoCoQmJ4n71QeWmixN27X4N1a6D5hsz3RYT88pnoX5UyYE0qXcHPUCC8YLI750XclTXyexN+C8I
MIME-Version: 1.0
X-Received: by 10.42.132.200 with SMTP id e8mr12399753ict.86.1430146439806;
Mon, 27 Apr 2015 07:53:59 -0700 (PDT)
Received: by 10.64.113.131 with HTTP; Mon, 27 Apr 2015 07:53:59 -0700 (PDT)
Date: Mon, 27 Apr 2015 09:53:59 -0500
Message-ID: <CAFjbNjFqj8OQS7PVd_yP7PCj68_jto=r-mT9gKXHsFRviBDt-A@mail.gmail.com>
From: Brian Deery <brian@factom.org>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=90e6ba3fd5fb859dcc0514b5eab7
X-Spam-Score: 1.0 (+)
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
X-Headers-End: 1YmklP-0004NG-1h
Cc: Justus Ranvier <justus.ranvier@monetas.net>
Subject: Re: [Bitcoin-development] Reusable payment codes
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: Mon, 27 Apr 2015 15:16:06 -0000
--90e6ba3fd5fb859dcc0514b5eab7
Content-Type: text/plain; charset=UTF-8
Hi Justus:
CC'ing mailing list because more bloom filter and HD wallet experts there
can chime in for some of these thoughts. I refined some ideas we went over
earlier.
Here are some critiques/worries about the payment codes.
With identities explicitly tied to a payment code, bloom filter clients can
have identities tied to them.
1. There will be a 1:1 relationship between a payment code owner and their
identity. Presumably the payment code would be strongly and publicly tied
to the identity. This makes the notification address strongly tied to the
user. An SPV client connecting to a full node who has a list of
notification address can tie an identity to a bloom filter and connecting
IP.
2. The client can use a bloom filter with a higher false positive rate. An
active attacker can counter that by sending several payment codes to an
individual user. The user would then add to their bloom filter all the
shared addresses between them and the attacker. Even with a high false
positive filter, always matching all the attacker's payment codes would
strongly tie the user to the filter.
Here are some data savings and privacy addition ideas:
65 bytes -> 0 bytes extra.
1. Can you choose only even or odd DER encoding? That would save you 1
byte. This would probably throw out 50% of possible addresses though.
2. Can the chain code be fixed or derived from the x value? Could the
chain value be the x value itself? (The main question is can a
deterministic public seed be represented as a single 32 bit number? Maybe
the chain code can be a constant. Maybe it is ok since subsequent pubkeys
are derived from this. I only know enough crypto to be dangerous.) That
would save you 32 bytes. Someone who understands HD wallets would be
better to look at this one. it would probably be a non-standard derivation.
That leaves you with 32 bytes to communicate to bootstrap the channel.
3: Since you are already looking at the pubkey of the transaction sending
the notification transaction, then you are assuming control of the sending
mechanism. If you can be sure to use a disposable bitcoin address to send
the notification, then 1 more savings might be possible. Also assuming the
above two points are possible.
Can you encode the "x value" into the signature's R value? This would
basically make this transaction look like a standard bitcoin transaction
and gets rid of the op_return completely.
I still like the idea of a common meeting point, a la bitmessage. The
receiver of the payment code would trial-decode all payment codes sent to a
common pre-specified dead drop address (perhaps a charity address). "to
send me money, first donate to this charity of my choice." This trades off
more work on the receivers part to get some privacy as to the number of
people interacting with that receiver.
-cheers
-Brian Deery
--90e6ba3fd5fb859dcc0514b5eab7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Justus:</div><div><br></div><div>CC'ing mailin=
g list because more bloom filter and HD wallet experts there can chime in f=
or some of these thoughts.=C2=A0 I refined some ideas we went over earlier.=
</div><div><br></div><div>Here are some critiques/worries about the payment=
codes.</div><div><br></div><div>With identities explicitly tied to a payme=
nt code, bloom filter clients can have identities tied to them. =C2=A0</div=
><div><br></div><div>1. There will be a 1:1 relationship between a payment =
code owner and their identity.=C2=A0 Presumably the payment code would be s=
trongly and publicly tied to the identity.=C2=A0 This makes the notificatio=
n address strongly tied to the user.=C2=A0 An SPV client connecting to a fu=
ll node who has a list of notification address can tie an identity to a blo=
om filter and connecting IP. =C2=A0</div><div><br></div><div>2. The client =
can use a bloom filter with a higher false positive rate.=C2=A0 An active a=
ttacker can counter that by sending several payment codes to an individual =
user.=C2=A0 The user would then add to their bloom filter all the shared ad=
dresses between them and the attacker.=C2=A0 Even with a high false positiv=
e filter, always matching all the attacker's payment codes would strong=
ly tie the user to the filter.</div><div><br></div><div><br></div><div><br>=
</div><div>Here are some data savings and privacy addition ideas:</div><div=
><br></div><div>65 bytes -> 0 bytes extra.</div><div><br></div><div>1. C=
an you choose only even or odd DER encoding?=C2=A0 That would save you 1 by=
te.=C2=A0 This would probably throw out 50% of possible addresses though.</=
div><div>2. Can the chain code be fixed or derived from the x value?=C2=A0 =
Could the chain value be the x value itself? =C2=A0(The main question is ca=
n a deterministic public seed be represented as a single 32 bit number?=C2=
=A0 Maybe the chain code can be a constant.=C2=A0 Maybe it is ok since subs=
equent pubkeys are derived from this.=C2=A0 I only know enough crypto to be=
dangerous.) That would save you 32 bytes.=C2=A0 Someone who understands HD=
wallets would be better to look at this one. =C2=A0it would probably be a =
non-standard derivation.</div><div><br></div><div>That leaves you with 32 b=
ytes to communicate to bootstrap the channel.</div><div><br></div><div>3: S=
ince you are already looking at the pubkey of the transaction sending the n=
otification transaction, then you are assuming control of the sending mecha=
nism.=C2=A0 If you can be sure to use a disposable bitcoin address to send =
the notification, then 1 more savings might be possible.=C2=A0 Also assumin=
g the above two points are possible.</div><div><br></div><div>Can you encod=
e the "x value" into the signature's R value?=C2=A0 This woul=
d basically make this transaction look like a standard bitcoin transaction =
and gets rid of the op_return completely.</div><div><br></div><div><br></di=
v><div><br></div><div>I still like the idea of a common meeting point, a la=
bitmessage.=C2=A0 The receiver of the payment code would trial-decode all =
payment codes sent to a common pre-specified dead drop address (perhaps a c=
harity address). =C2=A0"to send me money, first donate to this charity=
of my choice." =C2=A0This trades off more work on the receivers part =
to get some privacy as to the number of people interacting with that receiv=
er.</div><div><br></div><div><br></div><div>-cheers</div><div>-Brian Deery<=
/div></div>
--90e6ba3fd5fb859dcc0514b5eab7--
|
