Unfortunately I need to waste my time to react on the menace called Bitcoin Unlimited.
So instead of being productive I have to write up here a statement and announcement how Bitsquare would deal with a potential hard fork scenario. Let me know to whom I can send the invoice for this ;-).
As many of you might have noticed on Twitter, Bitsquare is in clear opposition to BU and I personally consider it not only as a reckless and irresponsible behavior of an out-of-control power cartel but as a political attack on Bitcoin.
In the rather unlikely event that they really start a hard fork and the even more unlikely event that they would succeed to take over the Bitcoin network and destroy the current version I would either move the main currency to what will be the follower project of the current Bitcoin Core development branch or move to another Altcoin like Monero.
This personal position might explain why I react rather emotional and radical in regards to BU.
I experience it not only as a threat for Bitcoin but as a threat to the work I was spending my time the last 3 years.
Beside that personal statement I want to give a bit of background what a hard fork would mean for Bitsquare and how we would deal with it.
-
We use BitcoinJ as SPV wallet and unfortunately we have not only inherited a severe privacy issue with the broken bloom filters [1] but also another weakness which got more visible in the light of the current HF discussions [2].
BitcoinJ follows blindly the longest PoW chain, even if that chain is breaking Bitcoin consensus rules. So a user could end up to be on the BU chain without having any control over that decision!
I think it is mandatory to give the user full control which chain he wants to support. A consensus rule violation is nothing what we can delegate to a corrupt mining cartel. -
Beside that problem there are risks with replay attacks. There have already been much written about that topic so I refer to the links below [3].
-
Even worse in Bitsquare we create a joint transaction of both traders (the deposit multisig tx gets inputs from both traders) so it might be that one input comes from the BU chain and the other from the BTC chain. Even if that deposit tx would not get confirmed on the BTC chains as the inputs of the consensus rule violating chain will be rejected it might get confirmed on the BU chain, leading to the risk that the user thinks it is safe to start the Fiat or Altcoin transfer, just to discover that he was on the wrong chain.
-
Bitsquare uses zero confirmation transactions in the preparation for a trade (funding tx to the wallet, offer fee payment tx). Only the deposit tx requires at least 1 confirmation. That has no security risks as if anyone would do a double-spend the deposit tx would become invalid so rendering the double spend pointless. The max. damage is loss of time and decreased user experience.
Zero confirmation transactions would become more risky and create a serious usability issue in case of a HF. We cannot wait for 1 confirmation (or probably there will be required many more confirmations in such a scenario) at each preparation step. That would render the process very slow. Beside that it would require software changes.
Conclusion:
In case of a HF scenario trading on Bitsquare would become highly disrupted and risky.
What can we do against it?
Mid-term we want to get rid of BitcoinJ. But we need to get the SPV Bitcoin Core [4] first released and then the dev resources to change the whole wallet implementation.
There are other plans for fraud proofs [5], something what Satoshi initially envisioned for the SPV model but unfortunately never got implemented.
Hopefully that will be available soon, but we cannot count on that, specially as it would need to be implemented in BitcoinJ as well.
So what can we do short-term?
-
We can provide a white-list of trusted Bitcoin nodes to connect to where we are 100% sure that they are running as BTC nodes. Alternatively any user can run his own BTC node locally or remotely and connect only to that or use his own white-list.
I am aware that providing a whit-list is a problematic strategy on its own, but so far I have not found a better one which is feasible from the technical effort and time horizon. Fraud proofs would be the best solution. -
So the above might help us to solve the problem that a user has no control over which chain he uses.
But there is still the problem that some users might prefer BU and point their client to BU nodes. We could split the network by using a different protocol version but if the users is lying about his preference for BU we don’t gain anything and a trader might end up in a mix of BU and BTC inputs for his deposit tx, leading to the above described usability degradation. -
The replay attack problem is even harder to solve. As we cannot expect that BU will build in a working replay attack protection (even if they would intend to do it it is highly questionable if it would work - I doubt highly their competence).
A certain time after the HF there will be likely solutions how to securely split one’s coins [6].
One thing is important to emphasize:
If the user does not do anything, no trading and not moving their BTC there is no risk! The fund are safe in the wallet, only when the user is doing a transaction he enters the stomp BU is preparing.
So what will be our strategy in the event of a HF?
- First we will publish an alert message to the network (similar like we send out update messages). That message will tell the user to not use Bitsquare for trading and not transferring funds.
- We likely will release a white-list of BTC nodes, that can be added by the user in the settings.
- As soon there is either clear that BTC is the winning chain or there is a clear solution how to protect against replay attacks and how to make sure to follow the right chain and trade with a peer who follows the same chain we would send out another message to signal it is safe for trading again. That would probably comes with a new software release as well.
- In the highly unlikely event that BU will be the winning chain, we will move over to either the new Bitcoin Core Coin or another Altcoin like Monero (though that will not be possible atm as there is no MultiSig support as well as other technical hurdles).
So be assured Bitsquare will not run on BUgCoin!
There is no way that we can stop trading as even if we stop our seed nodes the users would connect to any of the previously connected peers if one is online.
Only first time users would not be able to connect to the network without the seed nodes. So the effect of that attempt would be very limited.
This proofs that we are already that censorship resistant that even I cannot stop it anymore, even in a case I really would like to.
References:
[1] https://bitsquare.io/blog/privacy-in-bitsquare/
[2] https://groups.google.com/forum/#!topic/bitcoinj/PmMN18xxCI0
[3] https://bitcoinmagazine.com/articles/beginners-guide-surviving-coin-split/
https://bitcoinmagazine.com/articles/how-light-clients-can-protect-themselves-coin-split/
https://bitcoinmagazine.com/articles/bitcoin-unlimited-miners-may-be-preparing-51-attack-bitcoin/
https://blog.greenaddress.it/2017/03/27/greenaddress-position-on-contentious-forks/
https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-fork-71e572506d7d#.2b9r6ss3p
https://medium.com/@bitrated/bitrateds-position-on-network-splits-and-bitcoin-unlimited-4685c5c3f8e8
[4] https://github.com/bitcoin/bitcoin/pull/9483
[5] https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
[6] http://docs.electrum.org/en/latest/hardfork.html