From: Justus Ranvier <justus.ranvier@monetas•net>
To: bitcoin-development@lists•sourceforge.net
Cc: Brian Deery <brian@factom•org>
Subject: Re: [Bitcoin-development] Reusable payment codes
Date: Mon, 27 Apr 2015 15:54:36 +0000 [thread overview]
Message-ID: <553E5BBC.7070305@monetas.net> (raw)
In-Reply-To: <CAFjbNjFqj8OQS7PVd_yP7PCj68_jto=r-mT9gKXHsFRviBDt-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2015 02:53 PM, Brian Deery wrote:
> 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.
SPV clients that connect exclusively to hidden services through Tor
could mitigate this, especially if those clients broadcast their
transactions through different peers than the ones they use for
checking their balance.
Maybe they should even go the opposite way in terms of the false
positive rate.
A client could create a filter that *only* matches their notification
address and use that filter with a selected peer.
All the rest of their addresses would be contained in a different
filter that is never sent to the same full node which is watching
their notification address.
> 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.
I'm not sure this problem is solvable in general.
Any entity which has sent bitcoins to a known user could use that
knowledge to attempt to find their bloom filter (if they use one).
I think that for SPV to have any privacy at all clients need to get a
lot smarter about how they use bloom filters overall, such as by
connecting to more than one peer, only putting a subset of their
addresses in a single filter, and temporally varying the addresses
which they watch.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus@monetas•net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVPlu8AAoJECpf2nDq2eYj/cAP/iL9qlIkk/jz2N3mT4dIdrSn
rQ+m7dHOSeucUhePrjdM79VzDUQWGmewdi5a1e8wCL2PCBeq/7mapEpHrvWu3xUU
g0qtCa6CbSceW5pO1/BGnKpt298wrBIueeweR3/BPum90RrXT+T/ssQvjGvlY4Jg
ADFeH4axalmCkc87OsJhsEbAAbP9i/u96rItV9ECpOET9pRxp4PzNT/7nz/x5n+q
Lm/vuWy1yoWLUjXiAmXWJVzPs8+Pzf1liy3SEzkam156kUwTj/CqjI/uhf7heSx2
FYSswBc/R1fga7eu++Bm449KUTmyTnnEIT4109A1w18fidY2Dg6PpKYp5CGug96t
aHit1hqLfc8HpNUVWLrBrHsC7riy+QGta4Ie7fAl9SvFcNturkXBFxZLO8f34WMb
HFuWkcCAgZcS3hb1ShmyodMjnOWvHQo/dXAoUc+zI8yuiH9wAD6T4LOTkSwCjvvv
9y4Ia4Mr6v6oHQpUM8ddCMU4AyAYvZXFb68SsnWMZCCio3Ff9wqp2d690oSq36G7
jdjmxot7LrPMnJjNKwTl2jndDTB9Huh9sjWyE9gGBkkIib1purOYtucDsY3h6z7i
5ppG1KTph+xaOLMEvyJZyDNvPhrQGk1ll1kMoD2k7P/5OGV7QwQ0IxpoAqZ1uxJG
44rCXd7P+2R+Bza9qHSH
=d2l3
-----END PGP SIGNATURE-----
[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18686 bytes --]
next prev parent reply other threads:[~2015-04-27 15:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 14:53 Brian Deery
2015-04-27 15:54 ` Justus Ranvier [this message]
2015-04-27 16:46 ` Mike Hearn
2015-04-27 17:02 ` Justus Ranvier
2015-04-28 13:53 ` Justus Ranvier
2015-04-29 23:44 ` Justus Ranvier
-- strict thread matches above, loose matches on Subject: below --
2015-04-24 20:00 Justus Ranvier
2015-04-24 20:58 ` Gregory Maxwell
2015-06-16 16:26 ` odinn
2015-06-16 17:46 ` Peter Todd
2015-06-17 5:34 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553E5BBC.7070305@monetas.net \
--to=justus.ranvier@monetas$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=brian@factom$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox