Anyone have time to review ? if it is too long to read, just take a look at "UPDATE2, Solution" part.
Since this SPV wallet implementation will be used a lot by wallet developers and businesses, I prefer to get things right.
I know I can't have perfect privacy with SPV, but at least I can make the life of attackers a bit harder, and I think I found good compromise, which do not repeat past mistakes of existing implementations.
Topic: Best practice for SPV wallet (Read 718 times)
I am developing a SPV wallet for NBitcoin, so I was looking at the best practices to protect privacy.
I've read about some flaws about the current spv wallets, so I'm trying to not make the same mistakes.
I read this paper : http://eprint.iacr.org/2014/763 (actually, only the "OUR PROPOSED SOLUTION" interested me)
But it seems flawed, because it disregard completely the fact that bloom filter with a flag different to UPDATE_NONE will be modified on the remote peer.
So imagine I calculate 500 addresses and create a new bloom filter with fp = 10%.
Since it will be updated each time a matching scriptPubKey is detected because the outpoint will be added to the filter, the fp rate will increase with time.
If my client have 30 of such tracked outpoint, then the attacker will have received 270 false positive.
But since I need to recreate the filter to bring the fp down to my expected value to free my bandwidth, the attacker can take my two filters, and see which outpoints match both filters at the same time.
And with very high confidence, he will know which outpoint belongs to my client.
So I was thinking about using UPDATE_NONE, and, for each P2PKH I am tracking, adding the Hash and the public key to the filter. (similar to what bitcoinj does, afaik)
But then I fall into this problem (In summary, the attacker use the fact that the filter match both the hash + the public key blob to know with quasi-certainty which are the client's addresses, which can be mitigated only by increasing considerably fp rate)
So now, I'm stuck...
Any address/link/input/advices ? (Not making a SPV wallet not the right answer though)
UPDATE:
I think updating the filter when, by monitoring, I see that the fprate is going above a certain treshold. The privacy will only leak when I switch the filter, which should be rare, and only for the unspent outputs which stay accross both filters, what do you think ?
UPDATE2, Solution:
I will create a filter with (1000,0.0005,tweak) filled with 1000 lookahead keys + tracked outpoint. The number of tracked outpoint should relatively be small not to change the effective fp too much.
I will keep all the filter's parameters constant as changing any of them will leak addresses.
Time to times I will need to refresh the filter because of false positive outpoint polluting and making the effective fp too high. At this point, the tracked outpoint will leak.
Since this is rare occurence, when it happens, I will simply drop the connection to the peer and connect to a new one.
At 900 used key, I will renew the filter to get 2000 lookahead and change parameter to (2000,0.0005,tweak2), when doing so, I will drop connection to all existing peers. (so the first 1000 addresses does not leak)
I'm using the same algorithm than bitcoind to not connect to nodes in the same "network group", so it should mitigate the odds that the new peer is controlled by the same entity.
I can't just create a second filter with the new addresses + outpoint as specified in the paper, because I would need to connect to a higher number of nodes. (if I end up with 100 different filters, I need 100 connection to nodes)
I've read about some flaws about the current spv wallets, so I'm trying to not make the same mistakes.
I read this paper : http://eprint.iacr.org/2014/763 (actually, only the "OUR PROPOSED SOLUTION" interested me)
But it seems flawed, because it disregard completely the fact that bloom filter with a flag different to UPDATE_NONE will be modified on the remote peer.
So imagine I calculate 500 addresses and create a new bloom filter with fp = 10%.
Since it will be updated each time a matching scriptPubKey is detected because the outpoint will be added to the filter, the fp rate will increase with time.
If my client have 30 of such tracked outpoint, then the attacker will have received 270 false positive.
But since I need to recreate the filter to bring the fp down to my expected value to free my bandwidth, the attacker can take my two filters, and see which outpoints match both filters at the same time.
And with very high confidence, he will know which outpoint belongs to my client.
So I was thinking about using UPDATE_NONE, and, for each P2PKH I am tracking, adding the Hash and the public key to the filter. (similar to what bitcoinj does, afaik)
But then I fall into this problem (In summary, the attacker use the fact that the filter match both the hash + the public key blob to know with quasi-certainty which are the client's addresses, which can be mitigated only by increasing considerably fp rate)
So now, I'm stuck...
Any address/link/input/advices ? (Not making a SPV wallet not the right answer though)
UPDATE:
I think updating the filter when, by monitoring, I see that the fprate is going above a certain treshold. The privacy will only leak when I switch the filter, which should be rare, and only for the unspent outputs which stay accross both filters, what do you think ?
UPDATE2, Solution:
I will create a filter with (1000,0.0005,tweak) filled with 1000 lookahead keys + tracked outpoint. The number of tracked outpoint should relatively be small not to change the effective fp too much.
I will keep all the filter's parameters constant as changing any of them will leak addresses.
Time to times I will need to refresh the filter because of false positive outpoint polluting and making the effective fp too high. At this point, the tracked outpoint will leak.
Since this is rare occurence, when it happens, I will simply drop the connection to the peer and connect to a new one.
At 900 used key, I will renew the filter to get 2000 lookahead and change parameter to (2000,0.0005,tweak2), when doing so, I will drop connection to all existing peers. (so the first 1000 addresses does not leak)
I'm using the same algorithm than bitcoind to not connect to nodes in the same "network group", so it should mitigate the odds that the new peer is controlled by the same entity.
I can't just create a second filter with the new addresses + outpoint as specified in the paper, because I would need to connect to a higher number of nodes. (if I end up with 100 different filters, I need 100 connection to nodes)
Jump to: