Skip to content

Commit

Permalink
Merge pull request #75 from MaxHillebrand/minor-fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
nopara73 authored Jul 11, 2020
2 parents 9b53581 + e23fda0 commit ecc35e5
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions main.tex
Original file line number Diff line number Diff line change
Expand Up @@ -568,7 +568,7 @@ \subsection{Unconditional Hiding}

\section{Security and Privacy} \label{sec:securitayandprivacy}

In this section, we discuss the security and privacy guarantees of the WabiSabi credential scheme for construction of CoinJoin transactions. Theft concerns addressed through Bitcoin's security model, making WabiSabi trustless in that regard. Since CoinJoins are an overt technique privacy strongly depends on the structure of the transactions themselves. WabiSabi is designed as a general purpose mechanism, so those details are outside of the scope of this work.
In this section, we discuss the security and privacy guarantees of the WabiSabi credential scheme for construction of CoinJoin transactions. Theft concerns are addressed through Bitcoin's security model, making WabiSabi trustless in that regard. Since most CoinJoins are an overt technique privacy strongly depends on the structure of the transactions themselves. WabiSabi is designed as a general purpose mechanism, so those details are outside of the scope of this work.

The goal of the protocol is to allow a coordinator to provide the service to honest participants, without learning anything about the mapping between registered input and outputs, apart from what is already deducible given the public amounts visible on the Bitcoin blockchain. WabiSabi leverages the unlinkability of anonymous credentials and the hiding property of the amount commitments to minimize privacy leaks when a set of participants utilizes a centralized coordinator to reach agreement about such a transaction.

Expand Down Expand Up @@ -601,7 +601,7 @@ \subsubsection{Active attacks}

Sybil attacks~\cite{douceur2002sybil} are inherent to mixing schemes, because a transaction between $n$ apparent participants $n-1$ of which are controlled by an attacker will fully link the victim's coins on both sides of the CoinJoin while giving the impression that the victim's privacy has been improved. There is a liquidity requirement for such an attack since participants must provide valid inputs\footnote{See also JoinMarket fidelity bonds: \url{https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af}}, as well as a cost imposed by mining fees.

An attacker attempting to Sybil attack all CoinJoins would need to control some multiple of the combined CoinJoin volume contributed by honest participants, and to successfully partition honest participants to a sufficient degree. In the centrally coordinated setting fees paid by users can arbitrarily increase the cost of Sybil attacks by other users. However, this does not protect against a malicious coordinator which is only bound by liquidity and mining fees. Furthermore, service fees paid by honest participants may reduce the cost of such an attack or even make it profitable.
An attacker attempting to Sybil attack all CoinJoins would need to control some multiple of the combined CoinJoin volume contributed by honest participants, and to successfully partition honest participants to a sufficient degree. In the centrally coordinated setting, fees paid by users can arbitrarily increase the cost of Sybil attacks by other users. However, this does not protect against a malicious coordinator which is only bound by liquidity and mining fees. Furthermore, service fees paid by honest participants may reduce the cost of such an attack or even make it profitable.

A malicious coordinator could also delay processing of requests in order to gain more through timing and ordering leaks. In the worst case the coordinator can attempt to linearize all requests by blocking and unblocking individual users to recover full set of labeled edges. This is possible when $k=1$ and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

Expand Down

0 comments on commit ecc35e5

Please sign in to comment.