@ -509,11 +509,11 @@ If dust can attack us, dust can protect us.
\nsection{Introduction}
Sietch increases the privacy of \cite{Zcash} Protocol by making metadata-leakage
much harder to perform and adding \textbf{non-determinsim}, i.e. \cite{Hush} does not act
in the same way given the same inputs.
attacks much harder to perform and adding \textbf{non-determinsim}, i.e. \cite{Hush} does not act
in the same way given the same inputs. This makes simulating or "fuzzing" a HUSH full node very hard.
Coupled with Hush transitioning to enforced privacy in late 2020, we believe this
provides the highest level of privacy to users in the Zcash world and directly competes with
Hush transitioning to enforced privacy at Block 340000 in November 2020,
providing the highest level of privacy to users in the Zcash world and directly competing with
the excellent privacy features of \cite{Monero} and other \cite{CryptoNote} Protocol coins.
\nsection{Metadata Analysis of Zcash Protocol Blockchains: Basics}
@ -568,7 +568,7 @@ the core concepts here can be applied.
\nsubsection{Types Of Shielded Transactions}
There are many types of shielded transactions, mirroring the complexity of transparent transactions
in \cite{Bitcoin} Protocol. Here we introduce a convention for describing transactions and list commononly seen transactions:
in \cite{Bitcoin} Protocol. Here we introduce a convention for describing transactions and list commonly seen transactions:
\begin{itemize}
@ -627,7 +627,7 @@ This means that the history of HUSH and ZEC look different from a blockchain ana
On ZEC mainnet, all funds which are currently in a transparent address have passed through the shielded pool
at least once, usually in a very metadata-leaky way.
When Hush disables transparent outputs later this year, the only option will be for funds in transparent addresses to be
When Hush disabled transparent outputs at Block 340000, it made the only option for funds in transparent addresses is to be
sent to zaddrs and then never leave the shielded pool. Zcash continues to ignore zaddr adoption and will allow their users
to have optional (i.e. very little) privacy into the indefinite future.
@ -1033,23 +1033,25 @@ never stored in source code, or on disk. A random seed phrase is generated and t
is generated from that seedphrase, and then the private key and seed phrase are immediately deleted
from memory. Since every user now generates Sietch \zaddrs in-memory and they are thrown away, it
is essentially impossible to de-anonymize people in bulk. It requires reading memory from individual
nodes to recover those private keys or seedphrases. Currently SilentDragonLite uses this method,
while the \textbf{hushd} full node still uses a fixed set of 200 randomly chosen \zaddrs\cite{SietchRPC}, \cite{SietchHeader}.
We have an implementation that allows \textbf{hushd} to randomly generate Sietch addresses at
run-time which is still in testing, as it makes low-level changes to how \zaddrs are stored in \textbf{wallet.dat}.
nodes to recover those private keys or seedphrases. Currently SilentDragonLite (SDL) uses this method.
The \textbf{hushd} full node originally used a fixed set of 200 randomly chosen \zaddrs\cite{SietchRPC}, \cite{SietchHeader}
but now emulates the behavior of SDL. While SDL generates a random seedphrase and then uses shielded
addresses derived from that, \textbf{hushd} simply generates random public keys for which it does not
own the private key, and then derives a shielded addresses from this pubkey.
We also note that all Sietch outputs are valid and spendable, they are not "fake" and they are not
invalid outputs which are unspendable, because we belive those could be detected and leak metadata.
In every sense, from the cryptographic primitives in use to the entropy of the data, Sietch zdust
is legitimate and valid shielded transaction data, which makes it so powerful.
\nsection{Thoughts On Device Seizure}
Say Alice sent Bob and Charlie funds in a fully shielded transaction with shielded change: $ z \rightarrow z,z,z$ .
Say Alice sent Bob and Charlie funds in a fully shielded transaction with shielded change: $ z_A\rightarrow z_B,z_C,z_A $ .
Now let us say that Alice and Charlie have their devices seized, wallet.dat's "liberated" and uploaded
into chain analysis software that understands Zcash Protocol and ITM-Style Attacks. Bob is now in a
posistion where his \zaddr is known by the analyst/attacker, the exact amount sent to him in a certain
txid and potentially other metadata in a memo field. All of this data is valuable input which makes
transactions and potentially other metadata in a memo field. All of this data is valuable input which makes
the ITM attack better at it's job, and can often help "complete" partial de-anonymization which was
unable to fully "resolve" the data.
@ -1062,7 +1064,7 @@ and privacy buffer against real-life scenarios.
Low numbers of \zaddr outputs are bad for privacy, especially 1 or 2. Enforcing at least \textbf{4} likely makes the ITM attack
impractical since there are so many potential ways to swap in and out the remaining inputs. Hush chose \textbf{7} as a security buffer and because the slowdown associated with 7 outputs amounts
to about 5 seconds on modern hardware, when spending a small number of inputs. This seemed like a reasonable amount
to about 5 seconds or less on modern hardware, when spending a small number of inputs. This seemed like a reasonable amount
of time for users to make a transaction, given that the original Sprout \zaddrs took over a minute to make the simplest
of transactions.
@ -1071,21 +1073,23 @@ need to improve to reduce loss of privacy.
Do not advocate that users post \zaddrs and the txid's and explorer links they are involved in! Educate them to
keep this metadata to private messages, DMs and other non-public places. The fewer people that know your \zaddr,
the better!
the more privacy you have!
\nsubsection{Sapling Consolidation}
Sapling Consolidation is recommended and provides protection against metadata attacks
Sapling Consolidation is recommended for average userse and provides protection against metadata attacks
as well as \textbf{Denial-of-Service} attacks in addition to it's primary function of reducing the size of
wallet.dat files and hence making them much faster to use. \Hush has added \Sietch to our Sapling
Consolidation implementation and also made it leak less metadata
by reducing how many inputs it will ever spend at once, which is 8 to match the average number of outputs in \Sietch.
by reducing how many inputs it will ever spend at once, which is 8, to match the average number of outputs in \Sietch.
This means that when this feature is turned on, and a node receives a dust attack of many small inputs, the node
will magically clean up after the attack in the background with best practices for every transaction. These transactions
are guaranteed to leave the size of our \textbf{anonymity set} the same or increase it by 1 (if there is no change output).
The original implementation will spend up to 45 inputs at once and always sent to 1 output with fee=0, which trivially
The original implementation of Sapling Consolidation writen for ZER coin would spend up to 45 inputs at once and always sent to 1 output with fee=0, which trivially
stands out on the network. On the \Hush network, these consolidation transactions look exactly like a very common
$ z \rightarrow z $ with between 1 to 8 inputs and 7 or 8 outputs, blending into a large crowd of transactions which
$ z \rightarrow z,z,..,z$ with between 1 to 8 inputs and 7 or 8 outputs, blending into a large crowd of transactions which
have the same properties.
\nsection{Future Considerations}
@ -1130,8 +1134,10 @@ Only Zcash Protocol blockchains which enforce \zaddr usage have a chance at mean
\nsection{Special Thanks}
Special thanks to jl777, zawy, ITM, denioD and Biz for their feedback and all the people in the Hush community
involved in pushing the bleeding edge of privacy tech forward.
Special thanks to all HUSH community members and people that care about privacy.
Some people that gave constructive feedback to this paper include jl777, zawy,
denioD, Biz and of course ITM, who reported the attack to the HUSH community
and convinced it was real even though we didn't believe him for a long time.
