Bisq v0.9 is one of the biggest updates to Bisq ever: it brings the Bisq DAO to testnet, as well as a striking new visual design (among a host of other improvements and bug fixes).
The Bisq DAO—the mechanism that will enable decentralized governance of the Bisq exchange—will soon be going live on mainnet. To prepare for that launch, core DAO functionality is enabled on testnet in this new release. You can buy BSQ tokens, use them to make a compensation request, and vote on other requests.
To write a blog post about privacy in Bisq has been already a long time on my TODO list.
One reason why I postponed it for so long was that I tried to fix the weaknesses rather than to explain such complicated stuff to a broader (potentially non-technical) audience.
But as we still don’t have the resources to fix the main issue (see section below about the BitcoinJ bloom filter) I want to explain the background of the issue and propose the solution how you can protect your privacy even in the presence of that existing weakness.
Beside that I want to give an overview about different areas where privacy is relevant in Bisq.
I think we have already achieved a very high level of protection of user’s privacy. We can do still better and are working on further improvements.
But the main goal of that article is to give those who take privacy serious enough background and guide them how they can get out the most from Bisq.
Be warned, that blog post will be a bit technical. Privacy is a complex topic and requires some basic understanding about how Bitcoin transactions work.
So let’s get started.
One area where privacy plays an important role is how the data between the peers are transferred.
With Tor we get a very high level of privacy on the transport layer. So there are no IP addresses visible which could be used to identify a trader. As we use hidden services we even don’t have the issue that the exit nodes are a critical bottleneck in Tor.
In Bisq there are mainly 2 different types of messages:
Broadcast messages (e.g. offers are broadcasted to all peers)
Direct messages (e.g. 2 peers are communicating directly in the trade process)
In the first case the messages are not encrypted as all users need to be able to read the offers. The only identifying data included in an offer is the onion address of the offer-maker. That is required to contact him when one wants to take the offer.
The direct messages are sent directly to the other peer and are encrypted and signed in Bisq. Beside that it is encrypted as well on the Tor layer.
Though there are some things which needs to be considered – even with Tor.
The repeated usage of the onion address carries a potential privacy concern: Onion addresses of offers and trades could be used to map together an identity.
But that privacy leak to the trading peer can be also seen as a feature – and is actually used as such:
The small icon on the right of an offer entry or trade shows the onion address, whether you have traded already as well as the nr. of trades. This kind of “P2P reputation” (only you get the info about the data which you have anyway in the app from past trades – there is no centralized data collection) can be useful to easily identify traders with which one has traded already.
You can even tag a peer with arbitrary text like “Fast trader” (this data is only used in the scope of your local application).
Edit peer info
There might be different opinions if the re-use of the onion address for all offers and trades is positive (can be used for reputation) or if it is considered negative in regards to privacy.
In future versions we want to make it possible to reset your onion address (in the settings).
There might be another option that we use separate onion addresses for each offer. But that might be resource heavy as multiple Tor circuits need to be maintained, multiple hidden service published (takes about 30 sec. – that is the delay at the application startup) and will complicate code as well. So this is not considered for the near future.
Beside that we will support an optional GPG key which can be used for reputation.
In the next version we will add this already on the data layer, though it is not implemented yet in the UI. With that key we could build a reputation system where a user can proof with his signature that he is the originator of certain offers or trades if he wants to and to whom he wants to.
That way we decouple the network ID with reputation and users can choose if they want to build up a long term reputation at the cost of loss of some privacy to the trading peer or if they prefer to not use reputation and in case of network ID renewals the offers and trades cannot be associated to one identity.
What can you do now?
For users who don’t want to connect potentially all their offers to one identity it is recommended to create a new data directory from time to time (you must not have open offers, trades or disputes) or to use a program argument (e.g. –appName=Bisq-2) so a new data directory with that given name will be created and you can run multiple instances of Bisq in parallel which are completely unrelated (that setup is used by developers as well).
The usage of the network ID (onion address) might be seen as privacy weakness but to have a long term ID is a requirement for reputation.
In future we will decouple that by using an optional GPG key for reputation and enable renewal of the onion address.
Privacy in Fiat trades
When the users are trading Bitcoin with a national currency the transfer of the Fiat currency requires usually some personally identifying data.
With a bank transfer it is typically the name and the bank account number. With other payment methods it might be an email address or phone number (e.g. ClearXchange, Interac, Swish,…). Only with OKPay and PerfectMoney an account number alone is sufficient. But even there the account is usually verified in the registration process at the payment provider so the company knows the real life identity behind that account number.
It is important to understand that only the trading peer will see that account data (the name in the case of a bank transfer) as well as the arbitrator in case of a dispute.
In all trades which are not disputed, the arbitrator has no access to this data. The account data is only stored locally on your computer.
The Fiat receiver needs to expose his bank data to the other peer, otherwise the Fiat sender could not transfer the money.
The Fiat sender usually also gets exposed by the receiving bank as most banks show the name and bank account nr. of the sender in the transaction history.
There is another important reason why we exchange the account data in both directions:
There are some known social engineering scams where a BTC seller receives the Fiat money from a victim who got tricked into a purchase at some Ebay-like platforms but the victim never receives the purchased good. The scammer gives the victim the bank account nr. of the BTC seller, the BTC seller receives the Fiat and then releases the BTC to the scammer. After a few days the victim discovers that he got scammed, goes to the police and probably requests a bank chargeback. The seller gets in trouble to explain that he was not the scammer and probably accepts the chargeback to avoid more hassles.
Luckily that never happened at Bisq but we need to be careful not to attract such scammers.
To protect against such fraud we require the Fiat receiver to only release the BTC if the bank data in the Bisq application is matching with the data on his bank statement, otherwise he needs to open a dispute.
The payment account data (e.g. bank account number and name in case of a bank transfer) could be encrypted by default when the data is exchanged with the arbitrator in case of a dispute. In most cases the arbitrator does not require the data so the traders privacy is better protected. Only in those rare cases when the arbitrator needs the data for the dispute resolution process he can request the decrypted data from the trader.
The exposure of the bank account data to the other peer (and arbitrator in case of a dispute) is a necessary requirement when a Fiat transfer is involved. In future releases we might add an improvement that the arbitrator does not see the account data by default and has to request it from the trader if needed.
Avoiding coin merge
The returned change amount when funding an offer and/or trade as well as the funds you get out from a completed trade are re-used for other trades if you choose to use the Bisq internal wallet.
This connects the trades at the Bitcoin transaction graph level.
To avoid that, you need to fund each offer independently from an external wallet and withdraw the funds at the end of the trade to an external wallet.
Of course you need to take care that you don’t leak your privacy with coin merge again in the external wallet (you can use multiple external wallets as well to make that easier).
UI-wise that strategy is fully supported in Bisq (in fact it was the only option initially) but we are aware that most people prefer the more convenient usage of the internal wallet to re-use bitcoins from one trade for funding the next trade.
Unfortunately there is no good solution to combine both convenience with privacy here.
To offer a tool (similar to coin control in Bitcoin Core) to let the user decide which unspent transaction outputs (UTXO) should be used for funding an offer or trade might help to mitigate the problem. But there is some complexity and difficulty involved to decide which UTXO to use as well the problem that often you don’t have enough options to choose from. So that approach does not look like a feasible strategy to solve that issue. It is a conceptual problem from the way how transactions are connected in a graph in Bitcoin.
Coinjoin is one of the very few strategies to combat that issue.
We have rough plans to either add Coinjoin to Bisq in future, integrate an external Coinjoin implementation in a user friendly manner or find another solution with an automated trade to an Altcoin which has strong privacy protection built in at the protocol level like Monero or Zcash.
If you want strong privacy you need to fund each trade independently and withdraw the funds from a completed trade to an external wallet where you have to take care to not merge the coins again (which is not easy).
Privacy in the Bitcoin network
The connection to the Bitcoin network (we use BitcoinJ which uses the SPV model) is by default over Tor (we use a mix of connections to clear-net full nodes which are passing the Tor exit nodes and full nodes running as hidden services, therefore never exiting the Tor network).
The user can pass a program argument to use a custom Bitcoin full node as well. Alternatively a locally running Bitcoin node (localhost) can be used. The Bisq application discovers that local node automatically and uses it as the only node for the Bitcoin network connection. So no configuration is required.
The users who don’t run their own full Bitcoin node are exposed to a severe privacy leak inherited from the broken BitcoinJ bloom filters12.
I tried to fix the most critical flaws3 but unfortunately it turned out that it requires more effort to fix that4. So the bloom filters are still leaking considerable information to full nodes (in case those are operated by chain analysis companies spying on the network).
What is leaked:
A spying full node will find out quite easily that all the addresses created by the HD wallet (about 1300) are from one wallet (belongs to the same owner).
They don’t see the IP address as we use Tor (with other BitcoinJ wallets even the IP address is leaked).
If one of those addresses is connected to the real life identity of the user all the other addresses are de-anonymized as well (derived from the fact that all come from one wallet – same owner).
Revealing a real life identity can happen easily if you use one of your wallet addresses for any service where you have to register with your ID (centralized exchanges, merchants,…).
Even if you don’t leak any Bisq address, with more sophisticated graph analysis using typical usage patterns (e.g. coin merge) it can happen easier than expected that you lose your privacy.
So don’t expect privacy on the Bitcoin level unless you run your own full node or you really know what you are doing and are aware of all the pitfalls.
We have some bounties open in that area and we consider this a high priority issue which hopefully gets solved soon. Any developer experienced with BitcoinJ is very welcome to get in touch with us!
Unfortunately the bloom filters are broken also on the design level, but to fix the implementation flaws would give us at least some level of improvement (and render the effort for the spies higher as well as reduce the quality of their data due to a higher degree of uncertainty – though there might be controversial opinions about that).
That said, you should not be tempted to assume that the privacy problems of bloom filters are fixed after the BitcoinJ bloom filter implementation flaw is fixed.
To get a new bloom filter design implemented and deployed to Bitcoin Core is unfortunately something we cannot expect to happen soon. There are a few interesting efforts in that direction but I am not aware that anyone is working on that567.
But there is another very promising solution on the horizon: To use a Bitcoin Core node in SPV mode8. Jonas Schnelli is working on that and we consider to replace BitcoinJ by that as soon it is production ready and we have enough dev resources to implement it.
So what can a user do in the current situation to get a protection against those spying full nodes?
As said initially the only protection is to run your own full node, either locally (then Bisq connects by default to it) or you pass the IP address to your node (or a trusted node you know) via a program argument (—btcNodes=[comma separated IP addresses]).
But it is important to do that already at the first startup and always. One connection to the public Bitcoin network can be enough that you get connected to a spying node and your privacy is leaked (only a new data directory which creates a new wallet will help then – in our GitHub wiki there are instructions how to do that).
To communicate that complicated issue by displaying a popup at the first Bisq startup would be too confusing and overstraining for most users.
One possible compromise might be to use by default a white-list of trusted full nodes. The user can change to run his own local or remote full node, use his own list of trusted nodes or use the public Bitcoin network. As explained above it must already be taken care of at the first startup, so to use the public network as default would require a popup explaining the complex topic.
To use a white-list of trusted nodes compiled by the Bisq developers introduces centralization and trust issues.
Though I think that is less critical as the user can change afterwards to the public network without any damage, which is not true for the other direction (first public then trusted nodes).
This is clearly controversial and not an optimal solution at all, but might be preferable to the current state where everyone is leaking potentially (and I assume to a high probability) their privacy.
We have not decided to go that road yet, but it is in discussion.
Though as said above a SPV Bitcoin node would be probably the solution we will go mid-term and that would solve that issue anyway.
For achieving privacy protection on the Bitcoin network level you need to run your own full node.
We are trying to fix the implementation flaws in BitcoinJ but unfortunately bloom filters are already broken on the design level so we will never get proper privacy with the current bloom filters (Bitcoin side).
Alternatively we could provide a white-list of trusted full nodes and use that as default instead of the connection to the public network. This is a problematic approach as well and still in discussion.
The mid-term goal is to use a SPV Bitcoin node integrated in Bisq (similar like we use the Tor binary). For the user that would be transparent and the usability comparable with the current BitcoinJ SPV model. That would not only solve the bloom filter issue but also other weaknesses of BitcoinJ’s SPV model (e.g. no validation of consensus rules; in case of a hardfork with Bitcoin Unlimited it would follow automatically the longest PoW chain).
Those who care about privacy, take the time to understand the complex context 91011 and are willing to take the burden to run a full node as well keeping the funding of trades independent to avoid coin merge, can use Bisq with a very high level of privacy protection.
The others are probably leaking their privacy already in many other areas as well so Bisq does not really make their exposure worse.
This is not a satisfying situation though as we want to provide privacy by default in a user friendly manner. Convenience and privacy are unfortunately often hard to combine.
But we will continue to work to find the best solutions to solve those current weaknesses.
With all that said we have to emphasize that Bisq has already archived a very high level of privacy protection and clearly outperforms any other Bitcoin exchange in that matter.
No registration required. No centralized data collection.
We use Tor by default for all network traffic. So your IP address never get leaked!
Our UI supports coin merge avoidance.
Bisq uses a HD wallet. No address re-use
There will be future improvements to decouple the network ID with an optional reputation key.
Once we can use a SPV Bitcoin Core node instead of BitcoinJ we get rid of the bloom filter problem.
Protection of privacy is not only a core value of Bisq but we see it also as a fundamental property of money to achieve fungibility.
Bitcoin and the surrounding infrastructure (like exchanges) need to improve in that area so Bitcoin can develop it’s full potential as sound money. Sound money for a sound society. Protection of privacy has to be the default state for all, not just a privilege for techies and geeks.
America’s founding fathers have been more aware of this than today’s retarded politicians.
As we cannot expect much support from that side, let’s build our new model as we think it should look like and make the retarded model obsolete.
The team reviewed all bounty submissions, but there was no single name that clearly stood out. The Bitsquare bounty of 0.5 bitcoin will be distributed to those with best contributions.
We recently announced that Bitsquare is rebranding. Finding a new name is a challenging task, so the team offered a bounty to get some inspiration from the growing community. The rules of the bounty were introduced in the official forum of Bitsquare, where community members could make proposals for new brand name. If a given proposal ends up being selected by the team, the respective person will receive 0.5 bitcoin. In case none of the proposed names are selected, there is no winner to claim the bounty of 0.5 BTC. However, due to the active engagement by the community, we promised that in the event of no winner, the bounty will still be distributed to those who offered the best contributions towards finding a new name.
The bounty ran for more than 5 weeks and ended on February 20. We counted more than 2000 unique proposals from a total of 266 users. The team reviewed all proposals, but none of them really stood out as a clear winner. So as promised, Manfred will distribute the bounty of 0.5 bitcoin to those users, who we believe offered the best contributions.
Each member of the core team put forth their selection of “best” proposals from those offered by the community. This process resulted in a short list of good names. For each of those names we listed the user who first proposed it and found out that three users appeared multiple times. We decided that those users deserve to receive part of the bounty, as they have proposed multiple high-quality names. Two more users stood out with their alternative contributions – valuable discussion and constructive feedback, both of which are helpful in the search of a new brand name.
The team selected the following winners (listed here in alphabetical order):
dsteam – for offering 9 names the team evaluated as good
FreepWho – for active participation in the forum, for offering constructive feedback and for posting -good motivation for his/her proposals
mirelo – for offering 6 good names, plus motivating his/her proposals
spoken – for offering 11 names that were very close to being selected
vieuxvicq – for offering high-quality constructive feedback and valuable discussion
silverback – for proposing Bisqui, for being active in the forum and for motivating his/her proposals
These users should contact Manfred (PM from forum or email – see address and gpg key at contact page), stating their bitcoin address, in order to receive their share of the bounty: 0.1 BTC each. Nevertheless, we thank everyone who contributed in the forum for their desire to help the team!
New brand name
The team has stopped on a new brand name that at this point will not be disclosed. The reasons for this are several: checking with lawyers for any potential conflicts, securing domain names, changing slogan and name of DAO tokens, etc. All these need to be settled before we are comfortable disclosing the new name. We hope to complete this shortly.
Thank you once again to those who participated in the bounty hunt! Keep an eye on this space for the announcement of the new brand name.
With the recent Bitfinex heist models for decentralized exchanges have received a bit more attention as usual.
This is a repeating pattern happening every few months after a major incident. And it goes back to business as usual after people are entertained by the next soap opera. So I do not expect that the majority of cryptoland citizens will radically change their behavior. And that has several understandable reasons. But beside that, there is lack of awareness for critical problems and lack of visions for possible solutions.
People are used to traditional models and centralized exchanges are serving exactly that. They are similar to stock exchanges or Forex trading. They satisfy what those types of traders or speculators are looking for. Nothing wrong with serving people’s demands and habits, right?
What makes the difference?
But hey, isn’t there something different between Bitcoin and that traditional Fiat world? Wasn’t there something what created excitement for those who consider themselves as early adopters or cypherpunks?
Do you think Satoshi tried to satisfy people from the finance industry or give the mainstream users a more convenient payment method? Certainly not! Paypal was built with that mindset, Bitcoin wasn’t. It was built with a vision beyond the short sighted demands and habits derived from the past.
So like with everything what is new, those new models require a little bit of endeavor from those who are brave enough to explore that new territory.
What are the differences?
A P2P exchange has differences and will not perfectly satisfy people who are used to centralized exchanges.
But let’s first define the term exchange how we understand it, because many people use it with a different meaning:
The main feature is to exchange one currency to another.
The feature to speculate on price movements, short-selling, hedging or lending are extended features which some centralized exchanges provide, but I think that is outside of the core definition of an exchange.
How the exchange is implemented, if it uses automatic order matching or how fast the exchange happens are secondary characteristics.
A Fiat exchange means that national currencies are used, not IOUs for representing them.
Before we look at the reasons why the decentralized model provides a unique value let us have a look to the drawbacks:
Bitsquare is slower and trading is a more manual process.
That will be improved in future but the basic model that users control their funds require settlement controlled by the user and that takes a bit of time, even in the case for crypto currencies (blockchain confirmation). The exchange process will never be able to compete with high frequency trading. But that sort of speculative activity might get served by other solutions in future (Options, CFD,…).
You need to install a desktop app and you can’t run it in your browser, smartphone or your golden caged iPad.
The simple reason for that is that peer-to-peer means: all peers are equal – equally serving other peers and consuming from other peers. Smartphones or tablets are not good in serving. Web browsers are clients in the classical client-server architecture so they fail if you want to use them to serve other peers.
But sure, it would be convenient and nice to be able to run real P2P apps just everywhere. It might even happen some day but it comes with considerable challenges and effort. So please have patience or join our forces to make it earlier happen.
What’s on the table?
So beside those drawbacks, why should you be interested in P2P applications? You can ask the exactly same question: Why should you be interested in Bitcoin? You get security and privacy!
The security model is obvious:
If there is no sever to hack, you cannot steal money and user’s identity data from it.
Identity theft will become even more crucial in future as it is already. Regulation will soon enter that area as well.
If you don’t accumulate funds you don’t attract criminals.
That is an aspect which usually does not get much attention, because big numbers are impressive in our society.
Excuse me to remind on one of cryptoland’s latest soap operas, it just fits perfectly to that topic: The DAO. That completely pointless strategy to collect an enormous amount of money, without any concrete need for it was not only fatally damaging their own project. That often repeated, unethical but profitable model of externalizing risks and costs to others caused immense damage to their host community: Ethereum – giving cryptoland a new soap opera episode called ETC against ETH. Too bad that the real problems are not getting solved by those excitements.
Privacy – security’s sensitive brother
Beside security, privacy is an even more important issue. I think the relevance of privacy is widely underestimated. If you have read that infamous EU proposal, you should be alerted. The MIT ChainAnchor project is another warning sign that our financial privacy is at risk and governments are getting more and more drunk of power abuse. The 4 horsemen are riding again. Actually they never stopped riding the last 20 years as it seems they are pretty efficient in their job. Shocking how cheap that works…
We are getting closer to a critical junction: The future is the result of that what is getting prepared now. If we don’t engage to form it, others will do it for us.
Bitcoin seems to become the wet dream for governments to get full control and surveillance over the financial life of it’s citizens if we allow them to continue that path. Financial information is even more critical and valuable than information derived from communication.
Matching users Bitcoin addresses with the user’s real life identity threatens Bitcoin’s weak privacy model and makes chain analysis a simple exercise – and even more crucial – it destroys a core property of sound money: [Fungibility]7
Those companies who are engaged in that business of weakening privacy cannot be considered as anything else than parasites – destroying it’s host for short term profits.
So even those who are not convinced of the importance of the protection of privacy should be alarmed about that, because such a currency will never find mass adoption. No company will use Bitcoin when they know that they have zero privacy with their transactions. Furthermore, people will not accept Bitcoin as payment if they cannot be sure that they can spend it later without risk. The burden of verifying the history of a coin and evaluating it’s risk would produce too much friction for mass adoption. All that would make Bitcoin inferior to the USD or EUR.
How can a decentralized exchange like Bitsquare help here?
“Governments are good at cutting off the heads of centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be standing their ground.”
– Satoshi Nakamoto
Decentralization is a requirement to achieve censorship resistance. Censorship resistance is a foundation for a free society. Americas founding fathers have been more aware of that than todays retarded politicians and their corrupted media industry.
But can a decentralized exchange be efficient?
Lack of efficiency is not that what causes the most pain in our world. We are pretty good with efficiency in many areas. Resilience is the area where we are terrible weak.
The blockchain is not good at efficiency but it is very resilient. From an efficiency point of view it is the worst, slowest and most expensive database. Only censorship resistance gives it value and significance.
The fact that Bitcoin’s efficiency outperforms the bank’s efficiency and that they consider the “blockchain” revolutionary, is just because the banks are so unbelievably inefficient and have slept the last 20 years (or longer). They get woken up now by FinTech companies who are now considered “revolutionary” simply by applying modern IT to the banking world. We are witnessing the cheapest revolution of the century.
Bitcoin will remain alien to banks. Bitcoin is a complete contradiction to their concept and culture.
Where are we now? What is left?
We see now the first wave of P2P apps like Bitsquare and OpenBazaar operational and flourishing. But of course there is a lot of headroom for improvements. Same like there was headroom to find creative solutions to scale Bitcoin (the right way).
It took a bit of time but solutions like Segregated Witness will give us a basket of gifts not a one-time-shot: When you try to solve 1 problem and get 10 others solved as by-product, you know you are doing right. Then synergy happens.
That kind of synergy is what Bitsquare is aiming for. There will be soon an announcement regarding that topic.
Beside that, we are working hard to bring the project to the next level:
Automated trading for altcoins
The decentralized arbitration system
Micro credit market
And of course many improvements from the feedback we get from our users
If you have not already visited our survey, please lend us 5 min. of your time and let us know what you expect and think about Bitsquare.
If we start to explore the new possibilities, potential and characteristics of decentralized applications we might end up in a completely new territory. A territory which is not built by replicating old habits from the past. It might need a bit of openness and courage for trying out new paths, but you know: the revolution will not be televised.
Gil Scott-Heron - The Revolution Will Not Be Televised (Full Band Version) - YouTube
Some of you might ask what causes the delay of the beta release which was planned for that summer.
The reason for the delay is a change in a fundamental part of the application – the P2P network.
The following might be a bit technical. If you are not interested in those details you can skip to the last paragraph as well.
Bitsquare used TomP2P which is the most mature Java DHT implementation available and I was lucky to get the author – Thomas Bocek – on board to help to fix the open issues with Nat traversal.
Those issues was the source of a constant concern since the project start as for any P2P network it is a big challenge to overcome the restrictions set up by NATs and firewalls to avoid that nodes are accessible from other nodes in the internet.
Bernd Prünster introduced another idea to me which turned out to not only solve the NAT problematic but also helps to mitigate other open issues I had with a DHT solution: Using a Tor proxy to delegate the network traffic over Tor and therefore delegate the NAT problematic to Tor, which has solved that to a very satisfying level (they even pass through Chinas great firewall).
But no worry the Bitsquare user don’t need to do anything. It is all integrated into the application and no special setup is required. There are also no performance drawbacks with the small amount of data sent by Bitsquare.
Using Tor not only solved the network connectivity issues but also adds the high level of anonymity Tor provides to Bitsquare. In fact we use Tors Hidden Services for every node to make the P2P communication completely anonymous (as far Tor provides that).
That solved another open issue with the previous solution: The offerer need to be able to get contacted by a taker and therefore leaked his IP address when publishing an offer.
Now there are no IP addresses used but onion addresses. Those cannot be used to reveal the real location or identity of the user and that previous privacy issue is therefore solved.
The network routing algorithm used to transport the data (offers) previously stored in the DHT to all users is now a flooding (or gossiping) algorithm. A similar one is used in Bitcoin to provide a very robust P2P network with less vulnerabilities as a structured network like a DHT.
More sophisticated and effective routing algorithms like Kademlia routing which is used in DHTs come with a serious Sybil attack risk, as anyone who can control certain nodes could control the storage of certain data. The problem is that the network ID creation is free and the network ID is used to derive the storage location. So you can create a huge amount of netwok IDs and then select those which are giving you the control over the data storage location of the data you want to control.
That vulnerability is mitigated with the flooding algorithm as every node stores everything.
Satoshi has chosen the flooding algorithm for Bitcoins P2P network to obtain a highly decentralized and randomized network structure which is very important to secure the network against hostile takeover of parts of the network.
Though it came with some costs regarding resource usage. As we know, every full node in the Bitcoin network has to store 50 GB of blockchain data.
Luckily Bitsquare uses very small amount of short living data and the number of nodes will be much smaller as well. I estimate there will be data storage requirements of a few hundreds of Kilobytes or a few Megabytes. Each data has an expiration date, so our requirements will not cause any scalability problems.
Additionally to the publicly readable data like the offers there are data stored which need to remain private. There are trade process messages which are stored in a kind of mailbox in case the peer is offline. Those data are encrypted and signed and also sent to every node for storage. Only the receiver (who has the private key) can decrypt the data. A similar approach is used in Bitmessage.
Of course building a custom P2P network is a task which needs time and caution. That’s what causes the delay in the roadmap to release the Beta version.
The new network is basically already implemented in the application but it is not completed yet.
I hope that we can release the Beta version in about 2-6 weeks.