Justus Ranvier [ARCHIVE] on Nostr: š Original date posted:2015-04-27 š Original message:-----BEGIN PGP SIGNED ...
š
Original date posted:2015-04-27
š Original message:-----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 at 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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150427/5ec2884a/attachment.bin>;
š Original message:-----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 at 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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150427/5ec2884a/attachment.bin>;