mirrors/bisq
1
0
Fork 0
mirror of https://github.com/bisq-network/bisq.git synced 2024-11-20 02:12:00 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update comments

Browse Source
This commit is contained in:
Manfred Karrer 2016-04-16 23:41:52 +02:00
parent 20c181f94c
commit 267c43f3b6
1 changed files with 18 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
core/src/main/java/io/bitsquare/btc/WalletService.java
View File

@ -213,35 +213,30 @@ public class WalletService {
// Bloom filters in BitcoinJ are completely broken
// See: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
// Here are a few improvements to fix a few vulnerabilities.
// FalsePositiveRate of 0.5% leads to a probability of 0.0071 with 56 million pubkeys in the block chain and
// 200 keys.
// See: https://www.reddit.com/r/Bitcoin/comments/2vrx6n/privacy_in_bitcoinj_android_wallet_multibit_hive/coknjuz
// We use 1000 keys so we get an even better value.
// walletAppKit.setBloomFilterFalsePositiveRate(0.005);
// walletAppKit.setBloomFilterFalsePositiveRate(0.00001); //0.00001;
// Nr of false positives (56M keys in the blockchain): 0.005 * 56 000 000 = 280 000
// 0,00001 * 56 000 000 = 28 000 = 560
// 0,0001 * 56 000 000 = 28 000 = 5600
// 0,001 * 56 000 000 = 28 000 = 56 000
// 1333 / 5600 = 0.23 -> 23 % probability that pub key is in our wallet
// With higher fp rate values it fails to download the svp chain - seems it triggers Bitcoins DDoS protection ?
walletAppKit.setBloomFilterFalsePositiveRate(0.0001); // default is 0,00001;
// Default only 266 keys are generated (2 * 100+33). That would trigger new bloom filters when we are reaching
// a third under the limit (66). To avoid that we create much more keys which are unlikely to hit the
// new filter creation for most users. With 500 we get 1333 keys which should be enough for most users to
// never need to re-create a bloom filter
walletAppKit.setLookaheadSize(500);
// Bitsquare's BitcoinJ fork has added setBloomFilterTweak setter to reuse the same seed avoiding the trivial vulnerability
// Bitsquare's BitcoinJ fork has added a bloomFilterTweak (nonce) setter to reuse the same seed avoiding the trivial vulnerability
// by getting the real pub keys by intersections of several filters sent at each startup.
walletAppKit.setBloomFilterTweak(bloomFilterTweak);
// Avoid weakening probability by square root due to the default implementation using both pubkey and hash of pubkey
// See: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
// Avoid the simple attack (see: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/) due to the
// default implementation using both pubkey and hash of pubkey
walletAppKit.setInsertPubKey(false);
// Default only 266 keys are generated (2 * 100+33). That would trigger new bloom filters when we are reaching
// the threshold. To avoid reaching the threshold we create much more keys which are unlikely to cause update of the
// filter for most users. With lookaheadSize of 500 we get 1333 keys which should be enough for most users to
// never need to update a bloom filter, which would weaken privacy.
walletAppKit.setLookaheadSize(500);
// Calculation is derived from: https://www.reddit.com/r/Bitcoin/comments/2vrx6n/privacy_in_bitcoinj_android_wallet_multibit_hive/coknjuz
// Nr of false positives (56M keys in the blockchain):
// FP rate = 0,0001; Nr of false positives: 0,0001 * 56 000 000 = 5600
// We have 1333keys: 1333 / 5600 = 0.23 -> 23 % probability that a pub key is in our wallet
// With higher fp rate values it fails to download the svp chain - seems it triggers Bitcoins DDoS protection ?
walletAppKit.setBloomFilterFalsePositiveRate(0.0001);
// TODO Get bitcoinj running over our tor proxy. BlockingClientManager need to be used to use the socket
// from jtorproxy. To get supported it via nio / netty will be harder
if (useTor && params.getId().equals(NetworkParameters.ID_MAINNET))