sietch-whitepaper/sietch_ru.tex

% Dedicated to Craig Leto
\documentclass{article}
\usepackage[main=russian,english]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T2A]{fontenc}
\RequirePackage{amsmath}
\RequirePackage{bytefield}
\RequirePackage{graphicx}
\RequirePackage{newtxmath}
\RequirePackage{mathtools}
\RequirePackage{xspace}
\RequirePackage{url}
\RequirePackage{changepage}
\RequirePackage{enumitem}
\RequirePackage{tabularx}
\RequirePackage{hhline}
\RequirePackage[usestackEOL]{stackengine}
\RequirePackage{comment}
\RequirePackage{needspace}
\RequirePackage[nobottomtitles]{titlesec}
\RequirePackage[hang]{footmisc}
\RequirePackage{xstring}
\RequirePackage[unicode,bookmarksnumbered,bookmarksopen,pdfview=Fit]{hyperref}
\RequirePackage{cleveref}
\RequirePackage{nameref}

\RequirePackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber]{biblatex}
\addbibresource{sietch_ru.bib}

% Fonts

\RequirePackage{inconsolata}
\RequirePackage[bb=ams]{mathalfa} 

% Quattrocento is beautiful but doesn't have an italic face. So we scale
% New Century Schoolbook italic to fit in with slanted Quattrocento and
% match its x height.
\renewcommand{\emph}[1]{\hspace{0.15em}{\fontfamily{pnc}\selectfont\scalebox{1.02}[0.999]{\textit{#1}}}\hspace{0.02em}}

% While we're at it, let's match the tt x height to Quattrocento as well.
\let\oldtexttt\texttt
\let\oldmathtt\mathtt
\renewcommand{\texttt}[1]{\scalebox{1.02}[1.07]{\oldtexttt{#1}}}
\renewcommand{\mathtt}[1]{\scalebox{1.02}[1.07]{$\oldmathtt{#1}$}}

\newcommand{\zsendmany}{\textbf{z\_sendmany}}

% bold but not extended
\newcommand{\textbnx}[1]{{\fontseries{b}\selectfont #1}}
\crefformat{footnote}{#2\footnotemark[#1]#3}

\DeclareLabelalphaTemplate{
  \labelelement{\field{citekey}}
}

\DefineBibliographyStrings{english}{
  page  = {page},
  pages = {pages},
  backrefpage = {\mbox{$\uparrow$ p\!}},
  backrefpages = {\mbox{$\uparrow$ p\!}}
}

\setlength{\oddsidemargin}{-0.25in}
\setlength{\textwidth}{7in}
\setlength{\topmargin}{-0.75in}
\setlength{\textheight}{9.2in}
\setlength{\parindent}{0ex}
\renewcommand{\arraystretch}{1.4}
\overfullrule=2cm

\setlength{\footnotemargin}{0.6em}
\setlength{\footnotesep}{2ex}
\addtolength{\skip\footins}{3ex}

\renewcommand{\bottomtitlespace}{8ex}

% Use rubber lengths between paragraphs to improve default pagination.
% https://tex.stackexchange.com/questions/17178/vertical-spacing-pagination-and-ideal-results
\setlength{\parskip}{1.5ex plus 1pt minus 1pt}

\setlist[enumerate]{before=\vspace{-1ex}}
\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,before=\vspace{-1ex},after=\vspace{1.5ex}}

\newlist{formulae}{itemize}{3}
\setlist[formulae]{itemsep=0.2ex,topsep=0ex,leftmargin=1.5em,label=,after=\vspace{1.5ex}}

\newcommand{\docversion}{Whitepaper Version 0.6}
\newcommand{\termbf}[1]{\textbf{#1}\xspace}
\newcommand{\Hushlist}{\termbf{HushList}}
\newcommand{\HushList}{\termbf{HushList}}
\newcommand{\Hushlists}{\termbf{HushLists}}
\newcommand{\HushLists}{\termbf{HushLists}}

\newcommand{\doctitle}{Атакуем Zcash Протокол Ради Забавы И Выгоды} % Attacking Zcash Protocol For Fun And Profit
\newcommand{\leadauthor}{Duke Leto + Hush Разработчики} % Duke Leto + The Hush Developers

\newcommand{\keywords}{анонимность, протокол zcash, криптографические протоколы, zk-SNARKs, утечка метаданных, деанонимизация, электронная коммерция и оплата, финансовая приватность, математика с нулевым разглашением, линкабельность, графики транзакций, защищённые транзакции, анализ блокчейна}

% \newcommand{\keywords}{anonymity, zcash protocol, cryptographic protocols, zk-SNARKs, metadata leakage, de-anonymization, electronic commerce and payment, financial privacy, zero knowledge mathematics, linkability, transaction graphs, shielded transactions, blockchain analysis} 

\hypersetup{
  pdfborderstyle={/S/U/W 0.7},
  pdfinfo={
    Title={\doctitle, \docversion},
    Author={\leadauthor},
    Keywords={\keywords}
  }
}

\makeatletter
\renewcommand*{\@fnsymbol}[1]{\ensuremath{\ifcase#1\or \dagger\or \ddagger\or
    \mathsection\or \mathparagraph\else\@ctrerr\fi}}
\makeatother

\renewcommand{\sectionautorefname}{\S\!}
\renewcommand{\subsectionautorefname}{\S\!}
\renewcommand{\subsubsectionautorefname}{\S\!}
\renewcommand{\subparagraphautorefname}{\S\!}
\newcommand{\crossref}[1]{\autoref{#1}\, \emph{`\nameref*{#1}\kern -0.05em'} on p.\,\pageref*{#1}}

\newcommand{\nstrut}[1]{\texorpdfstring{#1\rule[-.2\baselineskip]{0pt}{\baselineskip}}{#1}}
\newcommand{\nsection}[1]{\section{\nstrut{#1}}}
\newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}}
\newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}}

\newcommand{\introlist}{\needspace{15ex}}
\newcommand{\introsection}{\needspace{30ex}}

\mathchardef\mhyphen="2D

% http://tex.stackexchange.com/a/309445/78411
\DeclareFontFamily{U}{FdSymbolA}{}
\DeclareFontShape{U}{FdSymbolA}{m}{n}{
    <-> s*[.4] FdSymbolA-Regular
}{}
\DeclareSymbolFont{fdsymbol}{U}{FdSymbolA}{m}{n}
\DeclareMathSymbol{\smallcirc}{\mathord}{fdsymbol}{"60}

\makeatletter
\newcommand{\hollowcolon}{\mathpalette\hollow@colon\relax}
\newcommand{\hollow@colon}[2]{
  \mspace{0.7mu}
  \vbox{\hbox{$\m@th#1\smallcirc$}\nointerlineskip\kern.45ex \hbox{$\m@th#1\smallcirc$}\kern-.06ex}
  \mspace{1mu}
}
\makeatother
\newcommand{\typecolon}{\;\hollowcolon\;}

% We just want one ampersand symbol from boisik.
\DeclareSymbolFont{bskadd}{U}{bskma}{m}{n}
\DeclareFontFamily{U}{bskma}{\skewchar\font130 }
\DeclareFontShape{U}{bskma}{m}{n}{<->bskma10}{}
\DeclareMathSymbol{\binampersand}{\mathbin}{bskadd}{"EE}

\newcommand{\hairspace}{~\!}
\newcommand{\hparen}{\hphantom{(}}

\newcommand{\hfrac}[2]{\scalebox{0.8}{$\genfrac{}{}{0.5pt}{0}{#1}{#2}$}}


\RequirePackage[usenames,dvipsnames]{xcolor}
% https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips
\newcommand{\todo}[1]{{\color{Sepia}\sf{TODO: #1}}}

\newcommand{\changedcolor}{magenta}
\newcommand{\setchanged}{\color{\changedcolor}}
\newcommand{\changed}[1]{\texorpdfstring{{\setchanged{#1}}}{#1}}

% terminology

\newcommand{\term}[1]{\textsl{#1}\kern 0.05em\xspace}
\newcommand{\titleterm}[1]{#1}
\newcommand{\quotedterm}[1]{``~\!\!\term{#1}''}
\newcommand{\conformance}[1]{\textbnx{#1}\xspace}

\newcommand{\Zcash}{\termbf{Zcash}}
\newcommand{\Hush}{\termbf{Hush}}
\newcommand{\Zerocash}{\termbf{Zerocash}}
\newcommand{\Bitcoin}{\termbf{Bitcoin}}
\newcommand{\CryptoNote}{\termbf{CryptoNote}}
\newcommand{\ZEC}{\termbf{ZEC}}
\newcommand{\ZEN}{\termbf{ZEN}}
\newcommand{\ZCL}{\termbf{ZCL}}
\newcommand{\KMD}{\termbf{KMD}}
\newcommand{\BTCH}{\termbf{BTCH}}
\newcommand{\BTCP}{\termbf{BTCP}}
\newcommand{\ZAU}{\termbf{ZAU}}
\newcommand{\VOT}{\termbf{VOT}}
\newcommand{\BTCZ}{\termbf{BTCZ}}
\newcommand{\LTZ}{\termbf{LTZ}}
\newcommand{\HUSH}{\termbf{HUSH}}
\newcommand{\zatoshi}{\term{zatoshi}}
\newcommand{\puposhi}{\term{puposhi}}
\newcommand{\zcashd}{\textsf{zcashd}\,}
\newcommand{\hushd}{\textsf{hushd}\,}

\newcommand{\MUST}{\conformance{MUST}}
\newcommand{\MUSTNOT}{\conformance{MUST NOT}}
\newcommand{\SHOULD}{\conformance{SHOULD}}
\newcommand{\SHOULDNOT}{\conformance{SHOULD NOT}}
\newcommand{\ALLCAPS}{\conformance{ALL CAPS}}

\newcommand{\note}{\term{note}}
\newcommand{\notes}{\term{notes}}
\newcommand{\Note}{\titleterm{Note}}
\newcommand{\Notes}{\titleterm{Notes}}
\newcommand{\dummy}{\term{dummy}}
\newcommand{\dummyNotes}{\term{dummy notes}}
\newcommand{\DummyNotes}{\titleterm{Dummy Notes}}
\newcommand{\commitmentScheme}{\term{commitment scheme}}
\newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}}
\newcommand{\commitmentTrapdoors}{\term{commitment trapdoors}}
\newcommand{\trapdoor}{\term{trapdoor}}
\newcommand{\noteCommitment}{\term{note commitment}}
\newcommand{\noteCommitments}{\term{note commitments}}
\newcommand{\NoteCommitment}{\titleterm{Note Commitment}}
\newcommand{\NoteCommitments}{\titleterm{Note Commitments}}
\newcommand{\noteCommitmentTree}{\term{note commitment tree}}
\newcommand{\NoteCommitmentTree}{\titleterm{Note Commitment Tree}}
\newcommand{\noteTraceabilitySet}{\term{note traceability set}}
\newcommand{\noteTraceabilitySets}{\term{note traceability sets}}
\newcommand{\joinSplitDescription}{\term{JoinSplit description}}
\newcommand{\joinSplitDescriptions}{\term{JoinSplit descriptions}}
\newcommand{\JoinSplitDescriptions}{\titleterm{JoinSplit Descriptions}}
\newcommand{\sequenceOfJoinSplitDescriptions}{\changed{sequence of} \joinSplitDescription\changed{\term{s}}\xspace}
\newcommand{\joinSplitTransfer}{\term{JoinSplit transfer}}
\newcommand{\joinSplitTransfers}{\term{JoinSplit transfers}}
\newcommand{\JoinSplitTransfer}{\titleterm{JoinSplit Transfer}}
\newcommand{\JoinSplitTransfers}{\titleterm{JoinSplit Transfers}}
\newcommand{\joinSplitSignature}{\term{JoinSplit signature}}
\newcommand{\joinSplitSignatures}{\term{JoinSplit signatures}}
\newcommand{\joinSplitSigningKey}{\term{JoinSplit signing key}}
\newcommand{\joinSplitVerifyingKey}{\term{JoinSplit verifying key}}
\newcommand{\joinSplitStatement}{\term{JoinSplit statement}}
\newcommand{\joinSplitStatements}{\term{JoinSplit statements}}
\newcommand{\JoinSplitStatement}{\titleterm{JoinSplit Statement}}
\newcommand{\joinSplitProof}{\term{JoinSplit proof}}
\newcommand{\statement}{\term{statement}}
\newcommand{\zeroKnowledgeProof}{\term{zero-knowledge proof}}
\newcommand{\ZeroKnowledgeProofs}{\titleterm{Zero-Knowledge Proofs}}
\newcommand{\provingSystem}{\term{proving system}}
\newcommand{\zeroKnowledgeProvingSystem}{\term{zero-knowledge proving system}}
\newcommand{\ZeroKnowledgeProvingSystem}{\titleterm{Zero-Knowledge Proving System}}
\newcommand{\ppzkSNARK}{\term{preprocessing zk-SNARK}}
\newcommand{\provingKey}{\term{proving key}}
\newcommand{\zkProvingKeys}{\term{zero-knowledge proving keys}}
\newcommand{\verifyingKey}{\term{verifying key}}
\newcommand{\zkVerifyingKeys}{\term{zero-knowledge verifying keys}}
\newcommand{\joinSplitParameters}{\term{JoinSplit parameters}}
\newcommand{\JoinSplitParameters}{\titleterm{JoinSplit Parameters}}
\newcommand{\arithmeticCircuit}{\term{arithmetic circuit}}
\newcommand{\rankOneConstraintSystem}{\term{Rank 1 Constraint System}}
\newcommand{\primary}{\term{primary}}
\newcommand{\primaryInput}{\term{primary input}}
\newcommand{\primaryInputs}{\term{primary inputs}}
\newcommand{\auxiliaryInput}{\term{auxiliary input}}
\newcommand{\auxiliaryInputs}{\term{auxiliary inputs}}
\newcommand{\fullnode}{\term{full node}}
\newcommand{\fullnodes}{\term{full nodes}}
\newcommand{\anchor}{\term{anchor}}
\newcommand{\anchors}{\term{anchors}}
\newcommand{\UTXO}{\term{UTXO}}
\newcommand{\UTXOs}{\term{UTXOs}}
\newcommand{\block}{\term{block}}
\newcommand{\blocks}{\term{blocks}}
\newcommand{\header}{\term{header}}
\newcommand{\headers}{\term{headers}}
\newcommand{\blockHeader}{\term{block header}}
\newcommand{\blockHeaders}{\term{block headers}}
\newcommand{\Blockheader}{\term{Block header}}
\newcommand{\BlockHeader}{\titleterm{Block Header}}
\newcommand{\blockVersionNumber}{\term{block version number}}
\newcommand{\blockVersionNumbers}{\term{block version numbers}}
\newcommand{\Blockversions}{\term{Block versions}}
\newcommand{\blockTime}{\term{block time}}
\newcommand{\blockHeight}{\term{block height}}
\newcommand{\blockHeights}{\term{block heights}}
\newcommand{\genesisBlock}{\term{genesis block}}
\newcommand{\transaction}{\term{transaction}}
\newcommand{\transactions}{\term{transactions}}
\newcommand{\Transactions}{\titleterm{Transactions}}
\newcommand{\transactionFee}{\term{transaction fee}}
\newcommand{\transactionFees}{\term{transaction fees}}
\newcommand{\transactionVersionNumber}{\term{transaction version number}}
\newcommand{\transactionVersionNumbers}{\term{transaction version numbers}}
\newcommand{\Transactionversion}{\term{Transaction version}}
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
\newcommand{\coinbaseTransactions}{\term{coinbase transactions}}
\newcommand{\CoinbaseTransactions}{\titleterm{Coinbase Transactions}}
\newcommand{\transparent}{\term{transparent}}
\newcommand{\xTransparent}{\term{Transparent}}
\newcommand{\Transparent}{\titleterm{Transparent}}
\newcommand{\transparentValuePool}{\term{transparent value pool}}
\newcommand{\deshielding}{\term{deshielding}}
\newcommand{\shielding}{\term{shielding}}
\newcommand{\shielded}{\textbf{\term{shielded}}}
\newcommand{\sheilded}{\textbf{\term{shielded}}}
\newcommand{\shieldedXTN}{\term{shielded} $ t \rightarrow z $ transaction}
\newcommand{\shieldedXTNs}{\term{shielded} $ t \rightarrow z $ transactions}
\newcommand{\shieldedNote}{\term{shielded note}}
\newcommand{\shieldedNotes}{\term{shielded notes}}
\newcommand{\xShielded}{\term{Shielded}}
\newcommand{\Shielded}{\titleterm{Shielded}}
\newcommand{\blockchain}{\term{block chain}}
\newcommand{\blockchains}{\term{block chains}}
\newcommand{\mempool}{\term{mempool}}
\newcommand{\zchain}{\textbf{zchain} }
\newcommand{\treestate}{\term{treestate}}
\newcommand{\treestates}{\term{treestates}}
\newcommand{\nullifier}{\term{nullifier}}
\newcommand{\nullifiers}{\term{nullifiers}}
\newcommand{\xNullifiers}{\term{Nullifiers}}
\newcommand{\Nullifier}{\titleterm{Nullifier}}
\newcommand{\Nullifiers}{\titleterm{Nullifiers}}
\newcommand{\nullifierSet}{\term{nullifier set}}
\newcommand{\NullifierSet}{\titleterm{Nullifier Set}}
% Daira: This doesn't adequately distinguish between zk stuff and transparent stuff
\newcommand{\paymentAddress}{\term{payment address}}
\newcommand{\paymentAddresses}{\term{payment addresses}}
\newcommand{\viewingKey}{\term{viewing key}}
\newcommand{\viewingKeys}{\term{viewing keys}}
\newcommand{\spendingKey}{\term{spending key}}
\newcommand{\spendingKeys}{\term{spending keys}}
\newcommand{\payingKey}{\term{paying key}}
\newcommand{\transmissionKey}{\term{transmission key}}
\newcommand{\transmissionKeys}{\term{transmission keys}}
\newcommand{\keyTuple}{\term{key tuple}}
\newcommand{\notePlaintext}{\term{note plaintext}}
\newcommand{\notePlaintexts}{\term{note plaintexts}}
\newcommand{\NotePlaintexts}{\titleterm{Note Plaintexts}}
\newcommand{\notesCiphertext}{\term{transmitted notes ciphertext}}
\newcommand{\incrementalMerkleTree}{\term{incremental Merkle tree}}
\newcommand{\merkleRoot}{\term{root}}
\newcommand{\merkleNode}{\term{node}}
\newcommand{\merkleNodes}{\term{nodes}}
\newcommand{\merkleHash}{\term{hash value}}
\newcommand{\merkleHashes}{\term{hash values}}
\newcommand{\merkleLeafNode}{\term{leaf node}}
\newcommand{\merkleLeafNodes}{\term{leaf nodes}}
\newcommand{\merkleInternalNode}{\term{internal node}}
\newcommand{\merkleInternalNodes}{\term{internal nodes}}
\newcommand{\MerkleInternalNodes}{\term{Internal nodes}}
\newcommand{\merklePath}{\term{path}}
\newcommand{\merkleLayer}{\term{layer}}
\newcommand{\merkleLayers}{\term{layers}}
\newcommand{\merkleIndex}{\term{index}}
\newcommand{\merkleIndices}{\term{indices}}
\newcommand{\zkSNARK}{\term{zk-SNARK}}
\newcommand{\zkSNARKs}{\term{zk-SNARKs}}
\newcommand{\libsnark}{\term{libsnark}}
\newcommand{\memo}{\term{memo field}}
\newcommand{\taddr}{\textbf{\term{taddr} }}
\newcommand{\taddrs}{\textbf{\term{taddrs} }}
\newcommand{\zaddr}{\textbf{\term{zaddr} }}
\newcommand{\zksnarks}{\textbf{\term{zk-SNARKs}}}
\newcommand{\zaddrs}{\textbf{\term{zaddrs} }}
\newcommand{\memos}{\term{memo fields}}
\newcommand{\Memos}{\titleterm{Memo Fields}}
\newcommand{\keyAgreementScheme}{\term{key agreement scheme}}
\newcommand{\KeyAgreement}{\titleterm{Key Agreement}}
\newcommand{\keyDerivationFunction}{\term{Key Derivation Function}}
\newcommand{\KeyDerivation}{\titleterm{Key Derivation}}
\newcommand{\encryptionScheme}{\term{encryption scheme}}
\newcommand{\symmetricEncryptionScheme}{\term{authenticated one-time symmetric encryption scheme}}
\newcommand{\SymmetricEncryption}{\titleterm{Authenticated One-Time Symmetric Encryption}}
\newcommand{\signatureScheme}{\term{signature scheme}}
\newcommand{\pseudoRandomFunction}{\term{Pseudo Random Function}}
\newcommand{\pseudoRandomFunctions}{\term{Pseudo Random Functions}}
\newcommand{\PseudoRandomFunctions}{\titleterm{Pseudo Random Functions}}

% conventions
\newcommand{\bytes}[1]{\underline{\raisebox{-0.22ex}{}\smash{#1}}}
\newcommand{\zeros}[1]{[0]^{#1}}
\newcommand{\bit}{\mathbb{B}}
\newcommand{\Nat}{\mathbb{N}}
\newcommand{\PosInt}{\mathbb{N}^+}
\newcommand{\Rat}{\mathbb{Q}}
\newcommand{\typeexp}[2]{{#1}\vphantom{)}^{[{#2}]}}
\newcommand{\bitseq}[1]{\typeexp{\bit}{#1}}
\newcommand{\byteseqs}{\typeexp{\bit}{8\mult\Nat}}
\newcommand{\concatbits}{\mathsf{concat}_\bit}
\newcommand{\listcomp}[1]{[~{#1}~]}
\newcommand{\for}{\text{ for }}
\newcommand{\from}{\text{ from }}
\newcommand{\upto}{\text{ up to }}
\newcommand{\downto}{\text{ down to }}
\newcommand{\squash}{\!\!\!}
\newcommand{\caseif}{\squash\text{if }}
\newcommand{\caseotherwise}{\squash\text{otherwise}}
\newcommand{\sorted}{\mathsf{sorted}}
\newcommand{\length}{\mathsf{length}}
\newcommand{\mean}{\mathsf{mean}}
\newcommand{\median}{\mathsf{median}}
\newcommand{\clamp}[2]{\mathsf{clamp\,}_{#1}^{#2}}
\newcommand{\Lower}{\mathsf{lower}}
\newcommand{\Upper}{\mathsf{upper}}
\newcommand{\bitlength}{\mathsf{bitlength}}
\newcommand{\size}{\mathsf{size}}
\newcommand{\mantissa}{\mathsf{mantissa}}
\newcommand{\ToCompact}{\mathsf{ToCompact}}
\newcommand{\ToTarget}{\mathsf{ToTarget}}
\newcommand{\hexint}[1]{\mathbf{0x{#1}}}
\newcommand{\dontcare}{\kern -0.06em\raisebox{0.1ex}{\footnotesize{$\times$}}}
\newcommand{\ascii}[1]{\textbf{``\texttt{#1}"}}
\newcommand{\Justthebox}[2][-1.3ex]{\;\raisebox{#1}{\usebox{#2}}\;}
\newcommand{\hSigCRH}{\mathsf{hSigCRH}}
\newcommand{\hSigLength}{\mathsf{\ell_{hSig}}}
\newcommand{\hSigType}{\bitseq{\hSigLength}}
\newcommand{\EquihashGen}[1]{\mathsf{EquihashGen}_{#1}}
\newcommand{\CRH}{\mathsf{CRH}}
\newcommand{\CRHbox}[1]{\SHA\left(\Justthebox{#1}\right)}
\newcommand{\SHA}{\mathtt{SHA256Compress}}
\newcommand{\SHAName}{\term{SHA-256 compression}}
\newcommand{\FullHash}{\mathtt{SHA256}}
\newcommand{\FullHashName}{\mathsf{SHA\mhyphen256}}
\newcommand{\Blake}[1]{\mathsf{BLAKE2b\kern 0.05em\mhyphen{#1}}}
\newcommand{\BlakeGeneric}{\mathsf{BLAKE2b}}
\newcommand{\FullHashbox}[1]{\FullHash\left(\Justthebox{#1}\right)}
\newcommand{\setof}[1]{\{{#1}\}}
\newcommand{\range}[2]{\{{#1}\,..\,{#2}\}}
\newcommand{\minimum}{\mathsf{min}}
\newcommand{\maximum}{\mathsf{max}}
\newcommand{\floor}[1]{\mathsf{floor}\!\left({#1}\right)}
\newcommand{\trunc}[1]{\mathsf{trunc}\!\left({#1}\right)}
\newcommand{\ceiling}[1]{\mathsf{ceiling}\left({#1}\right)}
\newcommand{\vsum}[2]{\smashoperator[r]{\sum_{#1}^{#2}}}
\newcommand{\vxor}[2]{\smashoperator[r]{\bigoplus_{#1}^{#2}}}
\newcommand{\xor}{\oplus}
\newcommand{\band}{\binampersand}
\newcommand{\mult}{\cdot}
\newcommand{\rightarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\rightarrow}
\newcommand{\leftarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\leftarrow}

\newcommand{\JoinSplit}{\text{\footnotesize\texttt{JoinSplit}}}

\newcommand{\affiliation}{\hairspace$^\dagger$\;}
\newcommand{\affiliationDuke}{\hairspace$^\ddagger$\;}

\newcommand{\ITM}{\textbf{ITM Атака} }
\newcommand{\Sietch}{\textbf{Sietch} }
\newcommand{\Metaverse}{\textbf{Metaverse Metadata} }
\newcommand{\Attacks}{\textbf{Attacks}}
\newcommand{\MimbleWimble}{\textbf{MimbleWimble} }
\newcommand{\Shieldedru}{\textbf{Защищённая} }
\newcommand{\shieldedru}{\textbf{защищённая} }
\newcommand{\pp}{{"} } % the way to make it generates a space after ""
\newcommand{\ppp}{{-}} % the way to eliminate the long black line after using two words with dash (word-secondword)
\newcommand{\pppp}{{"}}

\begin{document}

\title{\doctitle \\
\Large \docversion}
\author{
\Large \leadauthor\hairspace\thanks{\; hush.is, https://keybase.io/dukeleto, F162 19F4 C23F 9111 2E9C 734A 8DFC BF8E 5A4D 8019}
}
\date{\today}
\maketitle

\renewcommand{\abstractname}{}
\vspace{-8ex}
\begin{abstract}
\normalsize \noindent \textbf{Краткий обзор.} % Abstract

Данный документ, впервые, опишет как именно работает \ITM (связывающая атака против защищённых транзакций) против Zcash Протокола и \Hush как первую криптовалюту имеющую \Sietch - смягчение оборонительного характера против данной атаки. Sietch уже работает и запущен, так же проходят этапы улучшения на основе отзывов экспертов. Это не научная статья о несбыточных мечтах. Документ описывает производственный код и сети.

% This paper will outline, for the first time, exactly how the \ITM (a linkability attack against shielded transactions) works against Zcash Protocol and how \Hush is the first cryptocoin with a defensive mitigation against it, called "\Sietch". Sietch is already running live in production and undergoing rounds of improvement from expert feedback. This is not an academic paper about pipedreams. It describes production code and networks.

Мы начнем с обзора упоминаний о способе атак метаданных, которые могут быть использованы против Блокчейнов Протокола Zcash. Будет включена стоимость данной атаки и модель угроз. Документ далее опишет "ITM Атаку\pppp, являющая конкретным примером нового класса атак метаданных против блокчейнов, который автор опишет как \Metaverse \Attacks.

% We begin with a literature review of all known metadata attack methods that can be used against Zcash Protocol blockchains. This includes their estimated attack costs and threat model. This paper then describes the "ITM Attack" which is a specific instance of a new class of metadata attacks against blockchains which the author describes as \Metaverse \Attacks.

Документ далее объясняет Sietch в деталях, что было ответом на подобные атаки. Мы надеемся новые знания и теория помогут криптовалютам увеличить их безопасность против очень хорошо финансируемых врагов, включая национальные государства и компании занимающиеся анализом блокчейнов.

% The paper then explains Sietch in detail, which was a response to these new attacks. We hope this new knowledge and theory helps cryptocoins increase their defenses against very well-funded adversaries including nation states and chain analysis companies.

Несколько других проблем конфиденциальности и атак метаданных против Протокола Zcash будут рассмотрены и опубликовы впервые. Идеи в этом документе применяются ко всем криптовалютам которые используют графики транзакций, что можно сказать про всю известную криптовалюту. В особенности, класс атак Metaverse Metadata подходит для всех форков \Bitcoin (включая Dash, Verge, Zerocoin и их форки), криптовалюта Протокола \CryptoNote (например Monero) и монеты Протокола \MimbleWimble (Grin, Beam, т.д), но они здесь не рассматриваются, только детально описываются, как применять методы к их блокчейнам.

% A few other new privacy issues and metadata attacks against Zcash Protocol coins will also be enumerated for the first time publicly. The ideas in this paper apply to all cryptocoins which utilize transaction graphs, which is to say just about all known coins. Specifically, the Metaverse Metadata class of attacks is applicable to all \Bitcoin source code forks (including Dash, Verge, Zerocoin and their forks), \CryptoNote Protocol coins (Monero and friends) and \MimbleWimble Protocol (Grin, Beam, etc) coins but these will not be addressed here other than a high-level description of how to apply these methods to those chains.

\begin{quote}
Мы верим в приватность zdust % In privacy zdust we trust.

Если пыль (dust) может атаковать нас, пыль может защитить нас. % If dust can attack us, dust can protect us.

    - Sietch Mottos % – Sietch Mottos
\end{quote}

\vspace{2.5ex}
\noindent \textbf{Keywords:}~ \StrSubstitute[0]{\keywords}{,}{, }.
\end{abstract}

\vspace{-10ex}
\phantomsection
\addcontentsline{toc}{section}{\Large\nstrut{Содержание}}

\renewcommand{\contentsname}{}
% http://tex.stackexchange.com/a/182744/78411
\renewcommand{\baselinestretch}{0.85}\normalsize
\tableofcontents
\renewcommand{\baselinestretch}{1.0}\normalsize
\newpage

\nsection{Введение}

Sietch увеличивает приватность \cite{Zcash} Протокола, где утечка метаданных становится намного сложнее для выполнения и добавляет \textbf{индетерминизм}, например \cite{Hush} не действует аналогичным образом при тех же inputs. Это делает имитирование или "распыление\pp в полной ноде HUSH затруднительным.

% Sietch increases the privacy of \cite{Zcash} Protocol by making metadata-leakage 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

Hush перешел на принудительную приватность на Блоке 340000 в Ноябре 2020, обеспечивая высочайший уровень конфиденциальности для пользователей в мире Zcash и напрямую конкурируя с отличными функциями конфиденциальности \cite{Monero} и других монет Протокола \cite{CryptoNote}.

% Hush transitioning to enforced privacy at Block 340000 in November 2020, providing the highest level of privacyto users in the Zcash world and directly competing with the excellent privacy features of [Monero] and other[CryptoNote] Protocol coins.

\nsection{Анализ Метаданных Блокчейнов Протокола Zcash: Основы} % Metadata Analysis of Zcash Protocol Blockchains: Basics

\nsubsection{Концепции и Определения} % Concepts and Definitions

Этот документ будет связан с \textbf{графиками транзакций}, которые мы определяем в традиционном математическом смысле как комплекс нод с набором вершин соединяющих узлы. В криптовалютах это всегда работает как ориентированные графики, поскольку всегда есть неизрасходованные средства, которые становятся потраченными, то есть направление связано с каждой транзакцией. Это направление может быть опредено математически, используя временную метку транзакции. Вовремя транзакции, неизрасходаванные inputs становятся потраченными после транзакции. Outputs несуществуют перед транзакцией и являются потраченными после транзакции.

% This paper will be concerned with \textbf{transaction graphs}, which we define in the traditional mathematical sense, of a set of nodes with a set of vertices connecting nodes. In cryptocoins these always happen to be directed graphs, since there are always funds which are unspent becoming spent, i.e. a direction associated with each transaction. This direction can be mathematically defined using the timestamp of the transaction. Inputs are unspent at the time of the transaction and become spent after the transaction. Outputs do not exist before the transaction and are unspent after the transaction.

Значительное количество математической истории было уделено изучению \textbf{теории графов}, но которая не была применена в анализе блокчейнов, в основном потому, что еще несколько лет назад не существовало блокчейнов для анализа, как и финансовой выгоды от изучения этой информации. Но все очень резко изменилось.

% There is a great deal of mathematical history devoted to the study of graph theory that has not been applied toblockchain analysis, mostly because there was no blockchains to analyze just a few years ago and there was nofinancial profit in studying the data. That has obviously drastically changed.

Недавно мы обнаружили улучшенное программное обеспечение анализа блокчейна который использует "семантически обогащённые\pp графики транзакций с поисковой системой и расширенными кластероообразованными алгоритмами для создания диаграмм о сложных денежных потоках через большое количество адресов \cite{OBitcoinWhereArtThou}.

% Recently we have seen improved blockchain analysis software that employs "semantically enriched" transaction graphs with search engines and advanced clustering algorithms to make user-friendly diagrams about complex money flows thrue many addresses \cite{OBitcoinWhereArtThou}.

Этот документ, в большинстве своем, описывает \textbf{графики защищённых транзакций}
которые называются \textbf{ориентированные ациклические графы (DAGs)} где нода представляет собой \textbf{транзакцию}
с уникальным айди (id) называющиеся \textbf{txid}. Поступающие вершины являются inputs, которые были потрачены и уходящие вершины являются новыми outputs, которые были созданы. Полноценная \textbf{защищённая} транзакция
не раскрывает адрес ни Алисы, ни Боба, ни количество обмениваемых средств, но это разглашает большое количество метаданных на уровне протокола, что не появится в эксплорерах (исследователях) блоков, и что недостаточно хорошо изучено в криптоиндустрии.

% This paper will be primarily concered with \textbf{shielded transaction graphs} which are \textbf{directed acyclic graphs (DAGs)} where a node represents a \textbf{transaction} with a unique id called \textbf{txid}. The incoming vertices are inputs being spent and the outgoing vertices are new outputs being created. A fully \shielded transaction does not reveal the address of Alice, nor Bob, nor the amount transacted but it does leak a large amount of metadata at the protocol level, which is not rendered by block explorers nor well understood by the industry.

\Shieldedru транзакция имеет как минимум один \textbf{защищённый} адрес, который упоминается как zaddr.

% A \sheilded transaction has at least one \shielded address, referred to as a \zaddr.

Нас волнует только \textbf{Zcash Протокол}, который позволяет нам узнать слаженный язык и обозначения для описания новой \textbf{ITM Атаки} \zaddr (связывающая атака) и меры по смягчению воздействия этой атаки. Все методы описанные здесь могут технически быть использованы против открытых (прозрачных) блокчейнов, но это не имеет смысла, поскольку утечка всех метаданных и так уже существует в этих блокчейнах. Новые атаки могут рассматриваться как "сжатие\pp новой утечки метаданных из zaddrs из тех мест, где никто и не подумал бы смотреть.

% We here concern ourselves only with \textbf{Zcash Protocol} which allows us to specify a coherent language and symbols to describe the new \ITM \zaddr linkability attack and mitigations against it. All techniques here could technically also be used against transparent blockchains, but since they leak all the useful metadata already, it would serve no purpose. These new attacks can be thought of as "squeezing" new metadata leakage from zaddrs out of places that nobody thought to look.

Атака таких монет, у которых есть только график транзакций на уровне P2P, но не хранится в блокчейне (например криптовалюта на Протоколе MimbleWimble), становится более сложной и дорогой. Поскольку национальные государства не чувствительны к уровням издержек и очевидно имеют интерес деанонимизировать любые блокчейны, MW монеты не защищены от этих новых атак, описанные в документе. График транзакций по-прежнему существует и поэтому ключевые концепции могут быть применены.

% For those coins which only have a transaction graph at the network p2p level but not stored on their blockchain(such as MimbleWimble coins), it does raise the bar and attack cost. Since nation-states and are not cost-sensitiveand obviously have a vested interest to de-anonymize all blockchains, MW coins are not immune to these newattacks being applied. A transaction graph still exists and so the core concepts here can be applied.

\nsubsection{Типы защищённых транзакций} % Types Of Shielded Transactions

Существует много типов защищённых транзакций, отражающие сложность прозрачных (незащищённых) транзакций в \cite{Bitcoin} Протоколе. Здесь мы представим конвенцию для описания транзакций и список часто встречаемых транзакций:

% 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 commonly seen transactions: 

\begin{itemize}

\item Полностью защищённая транзакция $T$ со сдачей $z \rightarrow (z,z)$
\item Полностью защищённая транзакция $T$ без сдачи $z \rightarrow z$
\item Защищённая транзакция $T$ с прозрачной сдачей  $z \rightarrow (z,t)$
\item Незащищённая транзакция $T$ со сдачей $z \rightarrow (t,z)$
\item Незащищённая транзакция $T$ без сдачи $z \rightarrow t$
\item Защищённая транзакция $T$ без сдачи $t \rightarrow z$
\item Защищённая транзакция $T$ с прозрачным получателем и без сдачи $t \rightarrow (z,t)$
\item Защищённая транзакция $T$ с прозрачным получателем и со сдачей $t \rightarrow (z,t,t)$
\item Защищённая транзакция $T$ с защищённой сдачей (автощит, autoshield) $t \rightarrow (z,z)$

\end{itemize}

% \begin{itemize}

% \item A fully shielded transaction $T$ with change $z \rightarrow (z,z)$
% \item A fully shielded transaction $T$ with no change $z \rightarrow z$
% \item A shielded transaction $T$ with transparent change $z \rightarrow (z,t)$
% \item A deshielding transaction $T$ with change $z \rightarrow (t,z)$
% \item A deshielding transaction $T$ with no change $z \rightarrow t$
% \item A shielding transaction $T$ with no change $t \rightarrow z$
% \item A shielding transaction $T$ with transparent receiver and no change $t \rightarrow (z,t)$
% \item A shielding transaction $T$ with transparent receiver and change $t \rightarrow (z,t,t)$
% \item A shielding transaction $T$ with shielded change (autoshield) $t \rightarrow (z,z)$
% \end{itemize}

Выше приведены наиболее распространенные транзакции. Теперь предположим, что мы хотим описать транзакцию, которая отправляется на 5 \zaddrs адресов и на 3 прозрачных адреса без сдачи: $z \rightarrow z,z,z,z,z,t,t,t$. Для описания очень крупных транзакций можно использовать индексы: $ z \rightarrow z_{52}, t_{39} $.

% The above summarizes the most common transactions. Now say we want to describe a transaction which sends to 5 \zaddrs and 3 transparent addresses with no change: $z \rightarrow z,z,z,z,z,t,t,t$ . To describe very large transactions subscripts can be used : $ z \rightarrow z_{52}, t_{39} $.

Более сложные транзакции, такие как $ t,t,t \rightarrow z $ возможны, что и есть, скорее всего, защищённая транзакция, созданная z\_shieldcoinbase. Необработанные транзакции
могут быть настолько сложными, насколько это допустимо, а некоторые могут быть классифицированы как защищёнными и незащищёнными одновременно, например,  $ t,z \rightarrow t,z $ что разрешено
по правилам консенсуса, но на данный момент RPC способ не создает подобную транзакцию ни в одной криптомонете Протокола Zcash, известные авторам данного документа. Даже в этом случае необработанные транзакции могут создавать их и если/когда они появятся они будут сильно выделяться как очень уникальные транзакции.

% More complex transactions such as $ t,t,t \rightarrow z $ are possible, which is a shielding transaction most likely created by z\_shieldcoinbase. Raw transactions are free to be as complex as allowed and some may be classified as shielding and de-shielding at the same time, such as $ t,z \rightarrow t,z $ which is allowed by consensus rules but no RPC method currently creates such a transaction in any Zcash Protocol coin known to the authors. Even so, raw transactions could create them and if/when they show up they will stand out greatly as very unique transactions.

Индивидуальная сделка $T$ является подграфом полного графа транзакции $T \subset \mathbb{T}$ с одним числом вершин.

% An individual transaction $T$ is a sub-graph of the full transaction graph $T \subset \mathbb{T}$ with vertex count of one.

\nsubsection{Различия между KMD + HUSH + ZEC}

Напоминаем, что проект Komodo был самым первым добытым генезис блоком Протокола Zcash. Сообщество Komodo взяло Zcash исходный код и сначала добыли собственный генезис блок, 13 сентября 2016 \cite{KMDGenesis} перед Генезис блоком Zcash 28 октября 2016 \cite{ZcashGenesis}. Мейннет Hush был запущен сразу после 17 ноября 2016 \cite{HushGenesis} и был форком исходного кода Zcash 1.0.8, а не форком Komodo.

% We remind people that the Komodo project was the very first Zcash Protocol genesis block to be mined. The Komodo community took Zcash source code and mined their own genesis block first, on September 13th 2016 \cite{KMDGenesis} before the Zcash Genesis block on October 28th 2016 \cite{ZcashGenesis}. The first Hush mainnet was launched just after on November 17th 2016 \cite{HushGenesis} and was a source code fork of Zcash 1.0.8, not Komodo source code.

Существует понятие как \textbf{Правило Экранирования-Защиты, (Shielding Rule)} в Zcash, что стало одной из самой больших ошибок
совершенным проектом способствуя отсутствию приватности. Изначально KMD и ZEC мейннет были очень похожи
в том, что они оба разрешили \textbf{необязательное} использование zaddrs. Главная особенность в том, что jl777 уже разрабатывал свои
дополнения конфиденциальности поверх Протокола Zcash, и он правильно понимал, что принуждение людей к немедленному \textbf{экранированию} средств просто поспособствует людей делать это неверно.

% There is something called the \textbf{Shielding Rule} in Zcash that ended up being one of the largest mistakes made by the project, which contributes to it's lack of privacy. Originally KMD and ZEC mainnet were very similar in that they both optionally allowed zaddrs. The main difference is that jl777 was already developing his own privacy additions on top of Zcash Protocol, and he rightly saw that forcing people to shield funds immediately will just cause them to do it poorly.

В мейннет ZEC, новые добытые coinbase средства должны сначала быть отправлены на zaddr адрес, до того как они могут быть отправлены на прозрачный адрес. По началу казалось хорошей идеей, это "дополняет набор анонимности\pp заставляя всех переходить на защищённые адреса, увеличивая пул таких адресов. Но не всё то золото, что блестит.

% On ZEC mainnet, newly mined coinbase funds must be sent to a zaddr first, before they can be sent to a transparent address. This seems like a good idea at first, it "increases the anonymity set" by forcing everybody to go into the shielded pool. But all that glitters is not gold.

Практический эффект \textbf{Правила Экранирования} Zcash способствует заражению пула всех защищённых адресов с утечкой метаданных, особенно
с ценовой и временной утечкой метаданных, делая данное Правило фактически бесполезным. В среднем, средства в мейннет ZEC проводят только 1.4 hops ("прыжков-переводов") в защищённом пуле, что по сути, почти все средства проводят только 1 hop ("прыжок-перевод"), чтобы удовлетворить правило, и сразу же отправить обратно на прозрачный адрес. Очень часто точно такое же количество "входит\pp и "выходит\pp в следующем блоке или через один, полностью уничтожая цель zaddrs адресов.

% The practical effect of the Zcash \textbf{Shielding Rule} is to infect the shielded pool with metadata leakage, specifically value and timing metadata, making it almost useless. On average, funds on ZEC mainnet only spend 1.4 hops in the shielded pool, which is to say, almost all funds only spend 1 hop, to satisfy the rule, and then immediately come out. Very often the exact same amount is going in and coming out in the next block or two, completely defeating the purpose of zaddrs.

У KMD нет \textbf{Правила Экранирования}, как и у мейннет HUSH, что означает, что новые добытые coinbase могут быть отправлена на taddr сразу же, не заставляя пользователей заражать пул защищённых адресов с утечкой метаданных по причине неверного использования. Изначальная версия мейнет HUSH была основана на исходном коде ZEC и использовало их \textbf{Shielding Rule}, но когда Hush запустил второй мейннет в апреле 2019, он был основан на исходном коде KMD и, следовательно, \textbf{Shielding Rule} было удалено.

% KMD does not have the \textbf{Shielding Rule}, nor does the current HUSH mainnet, which means newly mined coinbase can be sent to a taddr immediately, without forcing people to infect the shielded pool with metadata leakage by using it improperly. The original HUSH mainnet was based on ZEC source code and used their shielding rule, but when Hush launched it's second mainnet in April 2019,  it was based on KMD source code and hence removed the \textbf{Shielding Rule}.

Это означает, что история HUSH и ZEC выглядит иначе с точки зрения блокчейн аналитика. В мейннет сети ZEC, все средства которые на данный момент находятся на прозрачных адресах прошли через защищённый-экранированный пул адресов как минимум один раз, и обычно задействуя все возможные виды утечки метаданных.

% This means that the history of HUSH and ZEC look different from a blockchain analyst point of view.  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.

Hush отключил переводы на прозрачные адреса на Блоке 340000, и поэтому сейчас единственный вариант отправить средства с прозрачного адреса - это отправить их на zaddrs адреса и никогда не покидать пул защищённых адресов. Zcash продолжает игнорировать принятие zaddr и будет позволять пользователям иметь необязательную (то есть почти нулевую) приватность в дальнейшем неопределенном будущем.

% 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.

\nsection{Анализ Метаданных Блокчейнов Протокола Zcash: Расширенная версия}

% \nsection{Metadata Analysis of Zcash Protocol Blockchains: Advanced}

\nsubsection{Активные и Пассивные Атаки/Аналитика}

% \nsubsection{Active vs Passive Attacks/Analysis}

Помимо простого анализа общедоступной информации, доступной для каждой полной ноды, существует \textbf{активный режим} возможный в любом анализе. То есть, чтобы заразить данные (средства) и посмотреть, как реагирует блокчейн, чтобы "следить за деньгами\pppp, если можно так выразиться. Некоторые организации должны предоставить \zaddrs своим клиентам или знать \zaddrs своих клиентов, такие как биржи, майнинговые пулы и провайдеры кошельков. Кроме того, многие люди предпочитают публично публиковать zaddrs и txid, которые связывают их личность в социальных сетях и реальную жизнь с уникальными идентификаторами блокчейна. Многие пользователи случайно деляться этой информацией, не понимая, что Github вопросы (issues) и посты на форумах являются ресурсами для добычи этих данных OSINT, но другие демонстративно публикуют эту информацию, например zecpages.com. Наше мнение таково, что они хотят как лучше, и каким-то образом помогают принятию zaddrs в массы, но так же они слишком упрощают работу по деанонимизации. Многие из этих пользователей публикуют скриншоты, включая их zaddr и id транзакции или ссылки на эксплорер. Это позволяет связать адрес zaddr и ShieldedInput или ShieldedOutput, что не должно быть возможным, и значительно упрощает работу блокчейн аналитика. Это позволяет программному обеспечению потенциально сказать "У этого twitter пользователя такой-то zaddr адрес, средства которого были отправлены txid еще одному Twitter пользователю zaddr адреса\pp и другие аналогичные примеры.

% In addition to purely analyzing public information available to every full node, there is an \textbf{active mode} possible in any analysis. That is, to inject data (funds) and see how the blockchain reacts, to "follow the money" as it were. Some organizations must provide \zaddrs to their customers or know the \zaddrs of their customers, such as exchanges, mining pools and wallet providers. Also, many individuals choose to publicly post zaddrs and txid's which tie their social media and real life identities to unique blockchain identifiers. Many users accidentally paste this information, not realizing that Github issues and forum posts are mined for this OSINT data, but other defiantly choose to post it, such as zecpages.com . Our opinion is that they mean well, and are helping adoption in some way, but they are making the job of de-anonymization much too easy. Many of these users will post screenshots including their zaddr and transaction id or explorer link. This allows linking a zaddr to a ShieldedInput or ShieldedOutput, which should never normally be possible, and makes the job of the analyst that much easier. It allows software to potentially say "This twitter user owns this zaddr and sent funds in this txid which eventually ended up in a zaddr owned by another twitter user" and other similar inferences.

Как пример активного режима против биржи, которая поддерживает \textbf{zaddr}, злоумышленник может создать аккаунт и получить депозит \zaddr на бирже. На данный момент все формы пыльных атак ("dust attacks") доступны для атакующего лица.

% As an example of active mode against an exchange that supports \zaddrs, the attacker can create an account and get a deposit \zaddr at the exchange. All forms of dust attacks are now available to the attacker.

Точно так же для майнинговых пулов, которые поддерживают выплаты в \textbf{zaddr}, атакующее лицо присоединяется к пулу и майнит достаточное количество для одной выплаты. Теперь они будут знать один из zaddrs и точное количество средств, которое было выплачено в этой транзакции. Майнинговые пулы это огромное количество информации, которая может быть использована для деанонимизации \zaddrs и пулы должны быть аккуратны и не позволять утечки важной информации.

% Similarly for mining pools which support paying out to \zaddr, an attacker can join the pool and mine enough to get a single payout. They will now know one of the zaddrs and the exact amount being paid out in that transaction. Mining pools are a wealth of information to de-anonymize \zaddrs and must be very careful to not leak useful metadata.

Стоит упомянуть \cite{LuckPool} как пример майнингового пула использующий Лучшие Практики, который поддерживает \textbf{zaddrs}, они не публикуют \zaddrs публично, не позволяя искать \zaddr и не показывают какие \zaddrs получили выплату. Еще очень давно сообщество Hush так же связалось со всем майнинговыми пулами Pirate и они удалили общедоступные метаданные о \zaddr майнерах, когда им сообщили о риске для их конфиденциальности. Все майнинговые пулы, которые могут делать выплаты в \zaddrs должны следовать этим примерам. Вся публичная информация о \zaddrs может быть подана для ITM и \Metaverse атак.

% We would like to mention \cite{LuckPool} as an example of Best Practices by a mining pool that supports \zaddrs, they do not list any \zaddr publicly, do not allow searching by \zaddr and do not show which \zaddrs are being paid out. The Hush community also reached out to all Pirate mining pools long ago and they emoved public metadata about \zaddr miners when their were told the privacy implications. All mining pools which can pay out to \zaddrs should follow these guidelines. All public data about \zaddrs can be fed into ITM and \Metaverse attacks.

\nsubsection{Временной Анализ} % \nsubsection{Timing Analysis}

Данный анализ использует эвристический метод тех транзакций, которые ближе к друг другу и скорее всего связаны, или транзакции образующие подобный временной паттерн. Например, при транзакции в одно и то же время каждый день, или две транзакции, с временным интервалом в 1 час раз в неделю. В публичных (прозрачных) блокчейнах, количество всегда доступно и временной/ценовой анализ имеет большую роль для дальнейшей де-анонимизации. В Протоколе Zcash, у нас есть только тайминг, и только иногда количество. Полностью защищённые $z \rightarrow z$ не имеют какой-либо информации о количестве, в то время как $ z \rightarrow t $ и $ t \rightarrow z $ имеют только частичную количественную информацию.

% This analysis uses the heuristic that transactions that are close together are likely to be related, or transactions that form a similar temporal pattern are related. For instance, if you make a transaction at exactly the same time every day, or two transactions, spaced 1 hour apart once per week. In transparent blockchains, the value is always available and timing/value analysis is very powerful. In Zcash Protocol, we only have the timing, and only sometimes the value. Fully shielded $z \rightarrow z$ have no value info, while $ z \rightarrow t $ and $ t \rightarrow z $ have only partial value information.

Существуют так же недавние атаки временного анализа такие как \cite{PING-REJECT} которая может использовать сетевой временной анализ для связывания IP адреса пользователя и их \zaddr адреса.

% There are also recent advanced timing analysis attacks such as \cite{PING-REJECT} which can use network-based timing analysis to link together a user's IP address to their \zaddr.

\nsubsection{Количественный Анализ} % \nsubsection{Value Analysis}

Количественный Анализ и Временной Анализ по сути одинаковые понятия в Биткойн Протоколе, но разделяется на
дополнительные методы, когда мы добавляем \zaddrs в анализ. В $ t \rightarrow z $ транзакции, у нас есть "идеальная утечка метаданных\pp в том смысле, что мы знаем точное количество средств отправляемых на защищенный output. Довольно редко, но все же случается, в случае траты output, который точно равен отправленной сумме и плюс комиссия. Так же есть вариант $ t,t,...,t \rightarrow z $ транзакции, создаваемая z\_shieldcoinbase RPC, что превращает прозрачные coinbase outputs в один защищённый output и дает утечку всей суммы, переданной на этот единственный защищённый output. Более встречаемая транзакция $ t \rightarrow z,z $ вносит неопределенность, но все же дает
полезные метаданные. Если прозрачный input был 10 HUSH, то мы знаем, что сумма значений на всех экранированных outputs должна быть 10 HUSH и что любой отдельный output не может быть больше 10 HUSH. Это дает нам максимальное значение (верхнюю границу) для значения в защищённом output, что является полезным для аналитика блокчейна. 

% Value Analysis and Timing Analysis are essentially the same in Bitcoin Protocol but bifurcate into complimentary methods when we add \zaddrs to the analysis. In a $ t \rightarrow z $ transaction, we have "perfect metadata leakage" in the sense that we know the exact amount of funds going into that shielded output. These are somewhat rare but do happen, in the case of spending an output which exactly equals the amount being sent plus fee. There is also the case of $ t,t,...,t \rightarrow z $ transaction, which are created by z\_shieldcoinbase RPC. This turns transparent coinbase outputs to a single shielded output and leaks the total amount of value transferred to that single shielded output. The more common $ t \rightarrow z,z $ transaction introduces uncertainty but it still provides useful metadata. If the transparent input was 10 HUSH than we know that the sum of values in all shielded outputs must be 10 HUSH and that any one individual output cannot be larger than 10 HUSH. This gives us a maximum value (upper bound) for the value in a shielded output and is very useful to blockchain analyst.

Сейчас рассмотрим процесс потери защищённости (de-shielding) $ z \rightarrow t $, что так же считается как "идеальная утечка метаданных\pp в том смысле, что мы точно знаем точное количество в \textbf{zaddr}, который владеет этим защищённым output и сейчас находится в прозрачном адресе. Часто встречается $ z \rightarrow t,z$ адрес со сдачей добавляет неопределенность и
мы не знаем ни точной суммы, поступающей на защищённый адрес для сдачи, ни общей потраченной суммы тем же \textbf{zaddr}. 

% Now we consider the de-shielding $ z \rightarrow t $ which can also be considered to be "perfect metadata leakage" in the sense that we definitely know that an exact amount was in a \zaddr which owned that Shielded output and now is in a transparent address. The more common $ z \rightarrow t,z$ with a change address adds uncertainty and we do not know the exact amount going to the shielded change address nor the total amount of value being spent by that \zaddr.

Существуют улучшенные формы Количественного Анализа, такие как \textbf{Danaan-Gift Атаки}, так же известные как \textit{дактилоскопия вредоносной ценности} ("malicious value fingerprinting") \cite{BiryukovFeher}. Предположим, идет отправка определенного количества средств на \textbf{zaddr}, например 0.72345618 и далее наблюдаем, происходит ли транзакция $ z \rightarrow t $, в которой находятся все или большинство этой суммы, возможно слегка изменена из-за стандартной транзакционной комиссии. Данная атака не имеет высокую вероятность работы в любых обстоятельствах, но может быть эффективной "при частом повторении\pppp, т.к ничего не останавливает злоумышленника атаковать вновь и вновь.

% There are advanced forms of Value Analysis such as \textbf{Danaan-Gift Attacks}, also known as malicious value fingerprinting \cite{BiryukovFeher}. The basic idea is you can send very specific amounts of funds to a \zaddr such as 0.72345618 and see if a $ z \rightarrow t $ transaction happens which has all or most of these particular values, perhaps modified by a default transaction fee. This attack does not have a high probabilty of working in any one circumstance, but it's like effective to "do on repeat", as nothing stops the attacker from trying again and again.

\Hush обойдёт почти все Количественные Анализы, отключив прозрачные outputs в конце Ноября 2020 и станет "конфиденциальным по умолчанию\pp блокчейном на блоке 340,000 \cite{HushHalving}.

% \Hush will sidestep most value analysis by disabling transparent outputs in late November of 2020 and become a "privacy by default" blockchain at block 340,000 \cite{HushHalving}.

\nsubsection{Анализ Комиссий} % \nsubsection{Fee Analysis}

Этот анализ не самый лучший и не очень эффективный, но зато очень простой, чтобы анализировать комиссию каждой транзакции, не важно защищённой или нет, поиск закономерностей, такие как использование нестандартных комиссий, использование более низких комиссий чем обычно и так же тех, которые платят большие комиссии. Иногда это автоматизированное программное обеспечение, которое
создает метаданные о комиссиях, выделяясь среди большинства других способов. В других случаях это другие пользователи выбирающие индивидуальную комиссию в своем кошельке, пытаясь снизить затраты. Анализ не требует никаких расходов и никак не вовлекает \textbf{zaddrs}. Программное обеспечение для анализа комиссий в Биткойн можно напрямую использовать в цепочках Протокола Zcash практически без изменений.

% This analysis is not very clever nor effective but it's simple to analyze the fee of every transaction, no matter whether it is shielded or not, and look for patterns such as non-standard fee use, using lower fees than normal for transaction size and those that pay large fees. Sometimes it is automated software which creates this fee metadata, by standing out from the crowd of most implementations. Other times it is individual users choosing a custom fee in their wallet, trying to save money. This analysis is essentially free and does not involve \zaddrs at all. Fee analysis software from Bitcoin can be directly used on Zcash Protocol chains with little to no change.

\nsubsection{Атаки Пыли} % \nsubsection{Dust Attacks}

Пыль (Dust) - это термин, используемый в разговорной речи, а также очень специфический термин, который происходит от внутренностей (internals) исходного кода Биткойна. Мы не нуждаемся в строгом определение и мы использует Пыль подразумевая очень малую (потенциально нулевое) количество, которое стоит дёшево для злоумышленника. Атаки Пыли могут быть в форме \textbf{Отказа-в-Обслуживании} или \textbf{Утечки Метаданных} и мы ориентируемся на последнюю форму. "Активный режим\pp в ITM атаке это форма Атаки Пыли, где мы переводим средства известному \textbf{zaddr}, узнавая, что происходит дальше.

% Dust is a term used colloquially and also a very specific term that comes from Bitcoin source code internals. We do not need a strict definition and we use it to mean any very small (potentially zero) amount that does not meaningfully cost much to the attacker. Dust attacks can be in the form of \textbf{Denial-of-Service} or \textbf{Metadata Leakage} and we focus on the latter. The "active mode" of the ITM attack is a form of Dust Attack, where we send funds to a known \zaddr to see what happens to them.

Подобные атаки могут быть использованы вместе с \textbf{Danaan-Gift Attacks} и так же с \cite{BiryukovFeherVitto}.

% These attacks can be combined with \textbf{Danaan-Gift Attacks} as well \cite{BiryukovFeherVitto}.

\nsubsection{Input/Output Arity Анализ}

Как бы там ни было, Sapling \zaddr транзакции имеют общедоступное количество inputs и outputs. Это пожалуй единственная потерянная функция по сравнению с предыдущей Sprout имплементацией, которая использовала JoinSplits, что скрывало точное количество inputs и outputs. Количество используемых inputs в защищённой транзакции и количество защищённых выходов говорят о многом.   

% For better or worse, Sapling \zaddr transactions have a publicly visible number of inputs and outputs. This is perhaps the only feature loss from the previous Sprout \zaddr implementation, which used JoinSplits that obscured the % exact number of inputs and outputs. The number of inputs you use in your shielded transaction and the number of shielded outputs tells a story.

Один упрощенный пример активной "Input Arity Атаки\pp происходит примерно следующим образом: Атакующее лицо Элис находит или узнаёт о zaddr Боба и она так же знает, что на этом адресе нет средств т.к это только созданный адрес. Затем она переводит 69 (или другое уникальное количество) пыльных outputs в одной транзакции, платя транзакционный сбор. Когда Боб тратит эти средства, Элис может посмотреть на транзакцию, содержащую 69 inputs и далее идентифицировать txid содержащий \zaddr на который она отправляла и затем соединить вместе ее изначальные inputs и outputs этой транзакции.

% One simplified example of an active "Input Arity Attack" is as follows: The attacker Alice discovers or finds out the zaddr of Bob and knows it currently has no funds since it is a newly created address. She now sends 69 (or some other very unique number) dust outputs in a single transaction, paying the transaction fee. When Bob spends those funds, Alice can look for a transaction containing 69 inputs and then identify that txid contains the \zaddr she sent to and link together her original inputs to the outputs of that transaction.

Что касается output arity анализа, если у вас очень уникальное количество outputs в вашей транзакции в сети - это плохо для вашей анонимности. Если никто, кроме вас не делает переводы с 42 защищёнными outputs каждый вторник в 13:00, все ваши транзакции могут быть анализированы с точки зрения одного единственного владельца, а не потенциально разных владельцев.

% As for output arity analysis, if you have a very unique number of outputs in your transaction on the network, that is bad for your own privacy. If nobody on the network makes transactions with 42 shielded outputs every Tuesday at 1pm, except you, all your transactions can be analyzed from the perspective of being a single owner, instead of potentially different owners.

\Sietch сильно препятствует и input, и output анализу потому что большинство транзакций в сети будут иметь 8 outputs, что означает для всех транзакций с отправкой между 1 и 7 получателями, все выглядят одинаково. В мейннет Zcash, все они могут быть тривиально изолированы и изучены от их output arity. \Hush смешивает воедино все эти очень распространенные output arity транзакции в "одну корзину". Те, кто отправляют 9 и более \zaddr outputs не могут быть защищены и стандартные output arity гистограммы могут быть использованы для изучения транзакций с большим количеством outputs.

% \Sietch greatly hinders both input and output analysis because most transactions on the network will have 8 outputs, which means for all the transactions that send to between 1 and 7 receivers, all look the same. On Zcash mainnet, all of these are trivally able to be isolated and studied by their output arity. \Hush mixes together all of these very common output arity transactions into "one bucket". People sending to 9 or more \zaddr outputs are not protected by this and normal output arity histograms can be used to study transactions which have many outputs.

\nsubsection{Биржи и Майнинговые Пулы} % \nsubsection{Exchanges and Mining Pools}

Утечка огромного объёма метаданных проходит через биржи и майнинговые пулы в их повседневной работе, поэтому они должны прикладывать большие усилия для уменьшения утечки, что в их интересах, а так же для блокчейнов, на которых они полагаются. 

% These entities leak massive amounts of metadata in their normal operations and must expend large amounts of effort to reduce the leakage for their own benefit as well as the blockchains they rely on.

\nsubsection{Что не показывает эксплорер/обозреватель блоков?} % \nsubsection{What does the explorer not show?}

Удивительно многое! Около дюжины или более уникальных id (айди) могут быть обнаружены практически в каждой защищённой транзакции и все эти идентификаторы имеют потенциальный риск выдать часть метаданных и коррелироваться друг с другом.   

% A surprisingly large amount! About a dozen or more unique id's can be discovered about every shielded transaction and all of these identifiers have the potential to leak small bits of metadata and be correlated to each other.

Новая RPC (рандомизированная частичная проверка) z\_viewtransaction может быть использована для просмотра всех необработанных данных, которые обеспечивают доказательства с нулевым разглашением (zero knowledge proofs) zaddrs адресов.

% The new RPC z\_viewtransaction can be used to see all the raw data which powers the zero knowledge proofs of zaddrs.

% \nsection{De-anonymization techniques literature review}

% \nsubsection{Applications to new Shielded-only Chains}

\nsection{ITM Атака: Возможность Связывания z2z Транзакций} %ITM Attack: z2z Transaction Linkability

\textbf{ITM} атакует конкретно транзакцию $T:z\rightarrow z,z$, то есть полностью защищённую транзакцию Протокола Zcash, которая имеет самый высокий уровень конфиденциальности. Сначала мы дадим определение успешной атаки, где любое из следующих данные могут быть установлены: 

% The \textbf{ITM Attack} specifically "attacks" a transaction $T:z\rightarrow z,z$, i.e. a fully-shielded Zcash Protocol transaction which has the highest level of privacy. First we describe the definition of the attack success, if any of the following datums can be ascertained:

\begin{itemize}

\item  Количество отправляемых средств в \textbf{zaddr}.
% \item  The value in the \zaddr sending funds.
\item  Количество получаемых средств в любом из \textbf{zaddrs}.
% \item  The value any of the \zaddrs receiving funds.
\item  Любое количество потраченных ShieldedInputs в транзакции.
% \item  The value of any ShieldedInputs spent in the transaction.
\item  Ряд возможных значений отправленных на любой \textbf{zaddr}, например 0.42 и 1.7 (с учетом погрешности)
% \item  A range of possible values being sent to any \zaddr, such as between 0.42 and 1.7 (with error estimate)
\item  Ряд возможных значений хранящихся в отправителе \textbf{zaddr}.
% \item  A range of possible values stored in the sending \zaddr.

\end{itemize}

Если утечка каких-либо из вышеперечисленных метаданных может "просочиться\pp - атака будет считаться успешной. Мы заметили что эта атака полностью пассивна по своей сути, но может быть значительно улучшена путем добавления активных компонентов "по вкусу". Вот почему атаки для утечки метаданных такие поскольку это можно рассматривать как метод анализа или прямую атаку. 

% If any of the above metadata can be "leaked", the attack is a success. We note that this attack is completely passive in it's core, but can be greatly improved by adding active components "to taste". This is why metadata leakage attacks such as this can be thought of a method of analysis or an outright attack.

\textbf{ITM Атака} берет айди (id's) транзакций и \zaddrs как input, или другие OSINT, которые легко найти в Github, Twitter, Discord, Slack, публичных формах, рассылочном списке, IRC и многих других местах. С этой публичной информацией, \textbf{ITM Атака} может перейти с теоретически интересной атаки к действительной деанонимизации \zaddr адреса, который соответствует аккаунтам в социальных сетям, емейл адресам, IP адресам, информации о местоположении и не только.
 
% The \textbf{ITM Attack} takes transaction id's and \zaddrs as input, or other OSINT which is readily available on Github, Twitter, Discord, Slack, public forms, mailing lists, IRC and many other locations. With these public resources, the \textbf{ITM Attack} can bridge the gap from theoretically interesting attack to actually de-anonymizing a \zaddr to it's corresponding social media accounts, email addresses, IP addresses, location data and more.

Данная атака не для "воскресных войнов\pp или людей с небольшим бюджетом, и не предназначена быть рентабельной для атак на один \textbf{zaddr}. Это лучше всего подходит для серьёзных игроков и больших целей, такие как NSA, GCHQ и им подобным. Вероятно, они уже используют анализ атак описанных в этом документе.

% This attack is not for weekend warriors or individuals with small budgets and is not cost-effective for attacking a single \zaddr. It's best suited for the largest players in The Great Game, i.e NSA, GCHQ and friends. It's highly likely they already utilize analysis and attacks described in this paper.

Только наиболее финансируемые частные компании, занимающиеся анализом блокчейнов, смогут позволить себе инфраструктуру для такого типа атак, но как только данные были "добыты\pp - это становится продаваемым товаром для тех, у кого меньше ресурсов. 

% Only the most well-funded private blockchain analysis companies will be able to afford the infrastructure for this attack, but once the data is "mined" it is a commodity that can be bought and sold to those with less resources.

ITM Атака является дополнительным "слоем\pp анализа, который может быть наложен поверх всех остальных типов анализа, и таким образом имея потенциальную возможность "закончить\pp большинство "частичных де-анонимизаций\pppp, например места где блокчейн аналитика предоставляет некоторую информацию, но не достаточно для полного де-анона. При добавлении временной, количественной и комиссионной аналитики, можно идентифицировать, что определенные \zaddrs были вовлечены во многих транзакциях и их примерные input и outputs значения. Эта информация не доступна любым иным способом и точные значения не так важны.

% The ITM Attack is an additional "layer" of analysis that can be overlaid on top of all other types of analysis, and in that way it has the potential to "finish" a lot of "partial de-anonymizations", i.e. places where blockchain analysis provides some data, but not enough to fully de-anon. When added to timing analysis, amount analysis and fee analysis, it can identify that certain \zaddrs being involved in many transactions and their approximate input and output values. This data is not available any other way and exact values are not very important.

Если блокчейн аналитик сможет найти транзакцию, которая вовлекает не менее 1М USD против нескольких пенни - это наложит курс для дальнейшего расследования и анализа. Идеальная де-анонимизация не требуется и на практике не так важна. Программное обеспечение с использованием информации из ITM анализа даст возможность идентифицировать как outputs транзакции, так и определённые промежутки значений и потенциальные вовлечённые zaddrs из OSINT данных.

% If a blockchain analyst can ascertain a transaction involves at least 1M USD in value versus a few pennies of value, that directs the course of analysis and investigation. Perfect de-anonymization is not needed and in practice does not matter. Software enabled with data from ITM analysis will be able to identify transaction outputs as having certain ranges of values and potentially their associated zaddrs from OSINT data.

\nsubsection{ITM Атака: Предположения} % \nsubsection{ITM Attack: Assumptions}

В духе радикальной прозрачности и открытости, полностью рабочий пример кода был сделал в качестве упражнения для заинтересованных компаний блокчейн анализа. Мы опишем атаку достаточно детально для экспертов, чтобы доказать наши доводы, так же для разработчиков, которые смогут использовать данный пример для атаки или защиты.

% Fully working example code is left as an exercise to the interested blockchain analysis company. We shall describe the attack in enough detail for experts to verify our claims and for developers to implement attacks and or defenses, in the spirit of radical transparency.

Мы предполагаем, что у атакующего лица есть хотя бы 100,000 USD средств вовлеченные в изучение операций одного определенного Zcash блокчейна. Основные затраты пойдут на покупку GPU/FPGA ферм для обработки данных. Блокчейны с бóльшей историей и защищённым пулом адресов повлияют на цену соответственно.

% We assume an attacker has at least 100,000 USD in funds to dedicate to the operation of studying one particular Zcash blockchain. Most of this cost is in the purchase of a GPU/FPGA farm to crunch data. Blockchains with more history and larger shielded pools will be more costly to study.

Стоит сказать, что данная атака не является разовой с точки зрения финансовых затрат, это методология для изучения всего блокчейна и дальнейшего возможного индексирования и поиска потенциально важной информации. Компании занимающиеся блокчейн анализом и IC готовы стратегически использовать эту информацию за наименьшие расходы, поскольку у них уже есть налаженная инфраструктура для поддержки нового набора данных.

% We note that this attack is not financially feasible as a one-off, it's a methodology to study an entire blockchain which can then be indexed and search for potentially valuabledata. Blockchain anlaysis companies and the IC are strategically positioned to use this information with the least cost, since they already have massive infrastructure to support this new dataset.

\nsubsection{ITM Атака: Победа над \zksnarks} % \nsubsection{ITM Attack: Defeating \zksnarks}

Мы можем думать об этой атаке как о "победе\pp над математикой с нулевым разглашением только на практике, но не в теории. Требуется серьёзная квалификация. Мы ни в какой степени не "сломали\pp математику \zksnarks, мы используем преимущество того как \textbf{zk-SNARKs} применен на более высоких уровнях протокола, то есть Zcash Transaction Format Protocol и ему подобные правила консенсуса. 

% We can think of this attack as a "defeat" of zero-knowledge mathematics only in practice, not in theory. Many qualifications are needed. We in no way "broke" the mathematics of \zksnarks, we are taking advantage of how \zksnarks are being used in higher level protocols, i.e. the Zcash Transaction Format Protocol and it's associated consensus rules.

Поэтому \textbf{zk-SNARKs} логичны и мы не утеряли \textbf{"знания"} напрямую из \textbf{zero-knowledge proof} - это математически невозможно. Мы теряем "знания\pp от того как эти доказательства использованы в крупных системах как Zcash Протокол, который сам по себе является добавлением к Биткойн Протоколу с печально известной утечкой метаданных.

% So \zksnarks are sound and we have not actually leaked \textbf{knowledge} directly from a \textbf{zero-knowledge proof}, that is mathematically impossible. We have leaked knowledge from how these proofs are used in the larger system called Zcash Protocol, itself an extension of Bitcoin Protocol which notoriously leaks metadata.

\nsubsection{ITM Атака: Инфраструктура} % \nsubsection{ITM Attack: Infrastructure}

Данная атака предполагает хранение значительного количества промежуточных данных в дополнение к необработанным блокчейн данным на диске. После компьютерных мощностей, хранение данных занимает вторую позицию по расходам. Возможно, аренда компьютерной мощности поможет снизить расходы, но это не повлияет на расходы связанные с хранением данных. При анализировании блокчейна в $ B $ байт, примерная оценка будет $100*B $ байт на промежуточные данные для анализа информации и далее очень сжатая версия финальной полезной информации может храниться в $B\div100 $ байт или меньше. Поэтому, финальный размер данных будет меньше, чем input данные, но промежуточные данные скорей всего будут на два порядка больше.

% This attack requires storing a lot of intermediate data in addition to the raw blockchain data on disk. Data storage costs are likely the number two expense after computing power. It is possible renting compute power can lower computing expenses but will not lower data storage costs. If one is analyzing a blockchain of $ B $ bytes then a reasonable estimate is that $100*B $ bytes of intermediate storage will be needed to analyze the data and then a highly compressed version of the final useful data can likely be stored in $B\div100 $ bytes or less. That is, the final datasize will be much smaller than the input data but our intermediate will likely be two orders of magnitude larger.

Предположим, у нас есть смоделированный искусственный блокчейн на блоке $N$, находящийся в состоянии покоя, аналитик располагает собственным майнинговым хешрейтом для "рывка\pp цепи вперед с помощью собственно\ppp определённых правил консенсуса. Этого можно добиться блокируя все посторонние ноды и подключаясь только к локальному хешрейту. 

% Assume we have a simulated blockchain at block $N$, held in stasis and the analyst has their own mining hashrate to "push" the chain forward by it's own defined consensus rules. This can be accomplished by blocking all outside nodes and only connecting to the local hashrate.

Мы так же допускаем, что аналитик сможет без проблем "запустить\pp блокчейн на определенной высоте блока и попытаться внести изменения для получения новых данных. Это тривиально возможно с образами виртуальных машин, docker контейнерами и/или Git, и остается в качестве упражнения для мотивированных блокчейн аналитиков.

% We also assume the analyst can easily "spin up" a blockchain at a certain block height and try a new change to extract new data. This is trivially possible with virtual machine images, docker containers and/or Git, and is left as an exercise to the motivated blockchain analyst.

Возможно существует намного более производительные способы запустить \textbf{"ITM Атаку"}, но на данный момент этот известный метод очень дорогой. Это только доступно для компании или организации, которая желает де-анонимизировать целый блокчейн, но это и есть как раз то, от кого/чего мы хотим защититься.

% There may be much more performant ways to launch an \ITM but currently the method known is quite expensive. It's only viable for a company or organization that wants to de-anonymize the entire blockchain, but that is indeed who we want to protect against.

\nsubsection{ITM Атака: Оракул Консенсус} % \nsubsection{ITM Attack: Consensus Oracle}

Сейчас рассмотрим определенную $T: z \rightarrow z,z$ на заданной высоте блока $H$, которая определяет специальный \textbf{защищённый пул} включающий непотраченные защищённые outputs и имеющие к ним отношение метаданные, такие как \textbf{Merkle Tree} данные.

% We now analyze a specific $T: z \rightarrow z,z$ at a speficic block height $H$ which defines a specific \textbf{shielded pool} containing unspent shielded outputs and their associated metadata, such as \textbf{Merkle Tree} data.

Если более подробно, то симуляция будет использовать \textbf{SaplingMerkleTree} внутреннюю структуру данных Протокола Zcash, определенная в src/zcash/IncrementalMerkleTree.hpp. ITM Атака фокусируется на этой структуре данных, но остальные могут и следует быть обнаружены как metadata oracles, например \textbf{SaplingWitness} данные.

% Very specifically, the simulation will use the \textbf{SaplingMerkleTree} internal Zcash Protocol datastructure defined in src/zcash/IncrementalMerkleTree.hpp . The ITM Attack focuses on this data structure but others can and should be explored as metadata oracles, such as the \textbf{SaplingWitness} data.

На полученной высоте блока $H$ защищённая "заметка\pp или \textbf{zUTXO} является либо потраченной, либо нет.

% At any given block height $H$ a shielded "note" or \textbf{zUTXO} is either spent or unspent.

Как и прозрачная \textbf{UTXOs}, \textbf{zUTXO} может быть создана из \mempool (ряд неподтвержденных транзакций), например output транзакции в этом блоке может быть потрачена другой транзакцией, как $ t \rightarrow z $ тратя UTXO из mempool и создавая zUTXO. ITM Атака не зависит то того, был ли zutxo потрачен из mempool или нет.

% Just like transparent \textbf{UTXOs}, a \textbf{zUTXO} can be created from the \mempool (set of unconfirmed transactions), i.e. the output of a transaction in this block can be spent by another transaction, such as a $ t \rightarrow z $ spending a UTXO from the mempool and creating a zUTXO. The ITM Attack does rely on the fact of a zutxo being spent from the mempool or not.

Известные Sapling обязательства/якоря являются "свапнутыми\pp в SaplingMerkleTree по одному, в попытке определить, были ли они израсходованы. Если новое "дерево решений\pp недействительно, то добавленные данные привели к тому, что оно стало недопустимым деревом по определенной причине и
эта конкретная причина удобно приводится, когда ошибки консенсусного уровня генерируются в Протоколах Bitcoin и Zcash. У этих ошибок есть свои ошибочные коды, и они могут стать источником утечки информации для начинающего аналитика. Утечка данных происходит путем проверки различных известных битов данных и анализа точных согласованных кодов ошибок. 

% Known Sapling commitments/anchors are "swapped" into the SaplingMerkleTree one at a time, in an attempt to identify if they are being spent. If the new solution tree is invalid, then the data that was added caused it to become an invalid tree for a particular reason and that particular reason is conveniently given when consensus-level errors are emitted in Bitcoin and Zcash Protocols. These errors have their own error codes and provide a wealth of information leakage to the aspiring analyst. By trying various known bits of data and analyzing the exact consensus error codes emitted, information is leaked.

Ниже есть изображение канонической ситуации, в которой работает \ITM, то, что мы называем \zchain: 

% Here we depict the canononical situation which the \ITM works upon, what we call a \zchain :

\includegraphics[scale=0.9]{itm-zchain.pdf}

Сначала отметим, что удаление zutxo/notes из SaplingMerkleTree не делает транзакции недействительными и
расходование транзакционного output зависит от того, действителен и присутствует ли zutxos. 

% First we note that removing zutxo/notes from the SaplingMerkleTree does not invalidate the transactions and spending a transaction output depends on the zutxos being valid and present.

Более простая \zchain только $ t \rightarrow z $ или $ t \rightarrow z \rightarrow z $ не имеет достаточной структуры для утечки метаданных. Нужна структура, в которой мы можем удалить "внутренний zutxo\pppp, от которого зависят другие вещи. 

% A simpler \zchain of only $ t \rightarrow z $ or $ t \rightarrow z \rightarrow z $ does not have enough structure to leak metadata. We need a structure where we can remove an "inner zutxo" that other things depend on.

\ITM помечает $z3$ как недействительный с помощью HaveShieldedRequirements() или \newline GetSaplingAnchorAt() возвращая ложный аргумент, когда условия на самом деле действительны. Операция не будет завершена при попытке выполнить $z4$ транзакцию, поскольку доказательство zk-snark обнаружит зависимость в $z2$. ITM называет это "обратным доказательством". Существует так же возможность "прямого доказательства\pppp, когда z4 позволяет потратить z2, но не z3. В этом случае мы с большой вероятностью можем сказать $ t \rightarrow z1 \rightarrow z2 \rightarrow z3 $. 

% The \ITM marks $z3$ as invalid via HaveShieldedRequirements() or GetSaplingAnchorAt() returning false when actually the conditions are valid. When $z4$ transaction is attempted, it will fail since the zk-snark proof will reveal a depedency on $z2$. ITM calls this a "reverse proof". There is also the possibility of a "forward proof" when z4 allows the z2 to be spent but z3 fails. In that instance, we can say $ t \rightarrow z1 \rightarrow z2 \rightarrow z3 $ with high probability.

Эти \textbf{zchains} являются основными объектами для атак и изучения в ITM Атаке, в итеративном процессе, где изучаются цепочки размера $N$ и иногда может быть определена связь, но часто это невозможно. Когда \ITM находит действительное обратное доказательство, ITM может попытаться расширить свои знания попробовав подцепи (subchains), чтобы получить больше метаданных. Это форма добычи метаданных. Каждый раз, когда добывается новый блок, могут быть потрачены новые средства, и процесс можно повторить.

% These \textbf{zchains} are the main objects of attack and study in an \ITM, where it is an iterative process. Where chains of size $N$ are studied and sometimes a linkage can be determined, but often it cannot. When \ITM does find a valid reverse proof, it can attempt to extend it's knowledge by trying subchains, to get more metadata. It is a form of metadata mining. Each time a new block is mined, new funds can become spent and the process can be repeated.

Подводя итог, \ITM требует, чтобы zutxo был потрачен для попытки отследить его связность с другими предыдущими ztuxos. Неизрасходованный zutxo не может быть проанализирован. Кроме того, $ t \rightarrow z $ и $ z \rightarrow t $ в настоящее время не кажутся уязвимыми. Только $ z \rightarrow z $ транзакции могут быть проанализированы, и только "внутри\pp zchain может происходить утечка метаданных, самые новые неизрасходованные zutxos "не выдадут\pp метаданные. 

% To summarize, the \ITM requires a zutxo be spent to attempt to trace it's linkability to other previous ztuxos. An unspent zutxo cannot be analyzed. Additionally, $ t \rightarrow z $ and $ z \rightarrow t $ do not currently seem vulnerable. Only $ z \rightarrow z $ transactions can be analyzed, and only the "inside" of the zchain can leak metadata, the very newest unspent zutxos do not give up metadata.


\nsection{Атаки Метавселенная Метаданных/Metaverse Metadata Attacks} % \nsection{Metaverse Metadata Attacks}

Атака ITM является частным случаем того, что мы называем \textbf{Атаки Метавселенная Метаданных}, применяемые
на защищенные графики транзакций в Протоколе Zcash.

% The ITM Attack is a special case of what we name \textbf{Metaverse Metadata Attacks}, applied to Zcash Protocol shielded transaction graphs.

Термин \textbf{Метавселенная} уместен, потому что можно смоделировать альтернативные возможные истории блокчейна, чтобы увидеть, какие правила консенсуса были бы произведены. Тщательно изменяя по одному фрагменту данных за раз, аналитик может использовать правила консенсуса в такой момент истории блокчейна как \textbf{oracle}. В этом смысле, \textbf{Metaverse} атаки можно классифицировать как \textbf{консенсусные oracle атаки}, и аналогичные атаки: \textbf{oracle сжатие} и \textbf{oracle дополнение}, такие как \cite{BREACH}, \cite{CRIME} и \cite{HEIST} против SSL/TLS. 

% The term \textbf{Metaverse} is appropriate because alternate possible blockchain histories can be simulated to see what consensus rules would have produced. By meticulously changing one piece of data at a time, the analyst can use the consensus rules at that moment in blockchain history as an \textbf{oracle}. In this sense, \textbf{Metaverse} attacks can be classified as \textbf{consensus oracle attacks}, similar to \textbf{compression oracle} attacks and \textbf{padding oracle} attacks such as \cite{BREACH}, \cite{CRIME} and \cite{HEIST} against SSL/TLS.

В то время как вышеупомянутые атаки являются \textbf{атаками по сторонним каналам} с использованием времени ответа на запросы, Атаки Метавселенная Метаданных - это сторонние каналы изучающие данные публичной цепи и ошибки консенсус-уровня в симуляциях.

% While the above attacks are \textbf{side-channel attacks} using the timing response of requests, Metaverse Metadata Attacks are side-channels that study public chain data and consensus-level errors in simulations.

Это новый метод, насколько известно авторам, который публично не описывался. Консенсусные правила блокчейна можно моделировать в вакууме, а научный метод изменения одной переменной за раз можно использовать для извлечения метаданных из общедоступных данных конфиденциальной криптомонеты. Существует неисчислимое количество метаданных, которые можно "добыть\pp из общедоступных данных блокчейна, соединенных с источниками данных OSINT.

% As far as the authors know this is a new technique that has not been publicly described. Blockchain consensus rules can be simulated in a vacuum and the scientific method of changing one variable at a time can be used to extract metadata from privacy coin public data. There is untold amounts of metadata which can be "mined" from public blockchain data married to OSINT datasources.

\nsection{Sietch: Теория} % \nsection{Sietch: Theory}

\nsubsection{Sietch: Основы} % \nsubsection{Sietch: Basics}

ITM Атака основана на том факте, что наиболее распространенная защищённая транзакция в большинстве существующих в настоящее время блокчейнов Zcash Протокола имеет только 2 outputs $T: z \rightarrow z,z$ и основной факт, что если какое-то количество "утраченных\pp метаданных об одном output, если это \textbf{израсходованное} или \textbf{неизрасходованное}, или диапазон данных возможных значений - в этих случаях много метаданных будет получено и для другого output. 

% The ITM Attack relies on the fact that the most common shielded transaction on most currently existing Zcash Protocol blockchains have only 2 outputs $T: z \rightarrow z,z$ and the basic fact that if some metadata can be leaked about one output, if it's \textbf{spent} or \textbf{unspent} or it's range of possible values, it provides a lot of metadata on the other output as well.

Если бы было 3 outputs, тогда возникла бы неопределенность, а не более прямое алгебраическое соотношение, такое как "если один output имел сумму=5, то другой output имел сумму $total - 5$". Когда задействованы 3 \zaddr outputs, зная значения одного \zaddr output не дает столько информации о значении любого другого конкретного \textbf{zaddr}. 

% If there were 3 outputs, then there would be uncertainty involved, instead of a more direct algebraic relation such as "if one output had amount=5 then the other output had an amount of $total - 5$". When 3 \zaddr outputs are involved, knowing the value of one \zaddr output does not provide as much information on the value of any other particular \zaddr.

Очевидно, что этот принцип усиливается, поскольку увеличивается количество outputs, утечка любого количества \zaddr input делают метаданные значительно менее ценными и дорогими для использования. 

% This principle obviously increases, as the number of outputs increases, the leakage of the amount of any one \zaddr input becomes exceedingly less valuable and expensive metadata to utilize.

Хорошим решением было сделать Sietch обязательным для использования по своему замыслу, и все пользователи используют Sietch по умолчанию не зная об этом. Sietch делает каждую отдельную защищённую транзакцию более сложной, что затрудняет анализ граф транзакций, помогающий даже пользователям со специальным программным обеспечением, не использующее Sietch.

% By design, Sietch is opt-out and by default all users use it without knowing it, which has worked well. Sietch makes every individual shielded transaction more complex which creates a harder-to-analyze transaction graph, helping even users which have custom software that does not use Sietch.

"Коллективный иммунитет\pp против деанонимизации - это совместное воздействие того, что почти все пользователи Hush, не подозревая об этом, постоянно используют Sietch. Каждая транзакция нуждается в нескольких дополнительных секундах, и сообщество Hush считает, что оно того стоит.

% The effect of almost all Hush users using Sietch all the time without knowing it, is a "herd immunity" against de-anonymization. The price is waiting a few extra seconds for each transaction and the Hush community feels it is quite well worth it. 

Даже если некоторые outputs транзакции полностью деанонимизированы, существует множество других \newline outputs, где точные отправляемые значения не могут быть установлены, что имитирует случай когда инфицированный человек не может легко заразить другого человека вирусом, так как люди рядом с ним уже выздоравливают или имеют иммунитет. 

% Even if some outputs of a transaction are completely de-anonymized, there are so many other outputs that exact values being transferred cannot be ascertained. This mimics the case where an infected person cannot easily infect another person with a virus because the people near them are already in recovery or immune.

\nsubsection{Sietch: Индетерминизм} % \nsubsection{Sietch: Non-Determinism}

В дополнение к минимальному количеству \zaddr outputs, Sietch вводит \textbf{индетерминизм} в Zcash Протокол. Хорошая идея была Zcash'у унаследовать детерминизм от Биткойна. Но в приватных монетах оказывается, что детерминизм может снизить конфиденциальность в некоторых ситуациях, и это на самом деле не является требованием для работы криптовалюты.

% In addition to a minimum number of \zaddr outputs, Sietch introduces \textbf{non-determinism} into Zcash Protocol. Zcash inherited determinism from Bitcoin, where it is a good idea. In privacy coins, it turns out that determinism can reduce privacy in some situations and it is not actually a requirement for the cryptocoin to function.

Sietch использует 3 вида индетерминизма: % Sietch employs 3 kinds of non-determinism:

% Sietch employs 3 kinds of non-determinism:

\begin{itemize}
\item 1 Порядок автоматически добавляемых \zaddr outputs случайны
\item 2 Точное количество автоматически добавленных outputs случайны
\item 3 Отправленные \zaddrs случайны  
\end{itemize}

% \begin{itemize}
% \item 1 The order of automatically added \zaddr outputs is random
% \item 2 The exact number of automatically added outputs is random
% \item 3 The \zaddrs which are sent to are random
% \end{itemize}

Разработчики Hush считают, что недетерминизм является мощным средством против \textbf{Metaverse Атак}, потому что при попытке смоделировать блокчейн и искать oracles или "добыть\pp полезные биты метаданных, результат "теста\pp больше не детерминирован, и поэтому некоторые атаки станут непрактичными или невозможно.

% Hush developers feel that non-determinism is a powerful mitigation against \textbf{Metaverse Attacks} because when attempting to simulate the blockchain and look for oracles or leak useful bits of metadata, the outcome of a "test" is no longer deterministic and therefore some attacks will become impractical or impossible.

\nsection{Sietch: Код в Производстве} % \nsection{Sietch: Code In Production}

Sietch использует по умолчанию правило минимального количества outputs, в виде 7 \zaddr outputs в транзакции, потому что
средняя защищённая транзакция не расходует точные input значения и есть output сдача, на практике средняя транзакция Hush имеет 8 \zaddr outputs.

% Sietch uses a default rule of a minimum of 7 \zaddr outputs in a transaction. Because the average shielded transaction does not spend the input values exactly and there is a change output, in practice the average Hush transaction has 8 \zaddr outputs.

На данный момент это не правило консенсуса и применяется только на уровне RPC. В настоящее время есть различные реализации Sietch в нашем full node (SD, SilentDragon) и lite (более простая версия, SilentDragonLite) кошельке. 

% This is currently not a consensus rule and only enforced at RPC layer. There are currently various implementations of Sietch in our full node and lite wallets.

Каждый раз, когда транзакция выполняется с количеством менее 7 \zaddr outputs, уровень RPC автоматически добавляет их, что означает, что все программные обеспечения, использующие уровень RPC защищены без какого-либо изменения кода. Программное обеспечение, использующее необработанные транзакции должны позаботиться об этом сами. 

% Whenever a transaction is made with less than 7 \zaddr outputs, the RPC layer automatically adds them, which means all software which uses the RPC layer is protected with absolutely no code changes. Software which uses raw transactions must take care of this themselves.

На практике это позволяет скрыть количество получателей до средних транзакции в сети Hush. Когда вы видите $ z \rightarrow z,z,z $ транзакцию в основной сети ZEC вы можете быть почти уверены, что это один \zaddr отправляет 2 другим \zaddrs и output сдачи. Он так же может быть отправлен на три outputs без сдачи, с резко меньшей вероятностью. Этот тип транзакции "обновлен\pp как минимум до $ z \rightarrow z_7 $ и поэтому вы не знаете, скольким получателям были отправлены средства, за исключением случаев, когда это большое количество. На практике это скрывает большинство транзакций в сети, и в основном это выплаты из майнинг пула, которые обычно используют множество \zaddr outputs или другое автоматизированное программное обеспечение. 

% This has the practical effect of hiding the number of recipients to the average transactions on the Hush network. When you see a $ z \rightarrow z,z,z $ transaction on ZEC mainnet, you can be almost sure it is one \zaddr sending to 2 other \zaddrs and a change output. It could also be sending to three outputs with no change, with drastically less probability. This type of transaction is "upgraded" to $ z \rightarrow z_7 $ at a minimum and so you don't know how many recipients are being sent to, except if it is a large number. In practice, this obscures most transactions on the network and it is mostly mining pool payouts which routinely use many \zaddr outputs or other automated software.

Некоторые транзакции выглядят как $ t \rightarrow t,t,z,t $, что является прозрачным адресом, отправляемый на
два других прозрачных адреса, один защищённый адрес и output сдачи. Когда Sietch включен, эта транзакция "улучшается\pp до $ t \rightarrow t,t,z,t,z_6$, чтобы удовлетворить минимум 7 \zaddr output правило. Первоначально была известна точная сумма, передаваемая в \textbf{zaddr}, потому что все другие значения в транзакции прозрачны и отображаются в общедоступной цепочке блоков. Но в "улучшенной\pp транзакции мы можем только убедиться, что некоторая сумма $A$ была отправлена и распространена через 7 outputs, некоторые из которых могут иметь нулевое значение.

% Some transactions look like $ t \rightarrow t,t,z,t $ which is a transparent address sending to two other transparent addresses, one shielded address and a change output. When Sietch is enabled, this transaction is "upgraded" to $ t \rightarrow t,t,z,t,z_6$ to satisfy the minumum of 7 \zaddr output rule. Originally the exact amount of value being transferred to the \zaddr would be known, because all other values in the transaction are transparent and appear on the public blockchain. But in the "upgraded" transaction we can only ascertain that some amount $A$ was sent and spread out across 7 outputs, some of which may be of zero value.

Как правило, транзакции Sietch значительно усложняют деанонимизацию цепочки на индивидуально транзакционном уровне, которые затем выстраиваются в очень надежный и сложный защищённый граф транзакций. Средняя защищённая ZEC транзакция в основной сети имеет два outputs, поэтому этот защищённый график транзакций выглядит как двоичное дерево, а блокчейн Hush с Sietch выглядит как дерево, которое разбивается на 8 частей на каждом узле. Попытка проследить за потоком средств становится комбинаторно непрактичной и дорогой даже для самых крупных игроков. 

% In general, Sietch transactions make the job of de-anonymizing a chain much harder at the individual transaction level, which then builds up into a very strong and complex shielded transaction graph. The average ZEC mainnet shielded transaction has two outputs and so it's shielded transaction graph looks like a binary tree, while the Hush blockchain with Sietch looks like a tree that splits into 8 parts at each node. Trying to follow the flow of funds becomes combinatorially impractical and expensive for even the largest players.

Здесь мы сравниваем, как выглядит граф защищённых транзакций в основной сети Zcash (ZEC) по сравнению с
графом защищённых транзакций, который мы увидим с \Sietch в основной сети HUSH. Эти два графика показывают два \textbf{hops, прыжка-перехода}, где мы определяем один переход (hop) как $ z \rightarrow z $ и два перехода (hops) как
$ z \rightarrow z \rightarrow z $ и так далее. После нескольких переходов (hops) легко увидеть, что защищённый
граф транзакций блокчейна с поддержкой \Sietch блокчейна превращается в "звезду\pp потенциальных направлений поступления средств. Традиционная цепочка Zcash Протокола представляет собой двоичное дерево, и это означает, что если в любой момент вы можете взять под контроль этот \zaddr output, вы знаете метаданные о большом подграфе
графа транзакций, например, захват незащищенного wallet.dat файла с мобильного телефона, ноутбука или персонального компьютера. Вместе с \Sietch, если у кого-то из друзей Алисы конфискуют телефон, там по-прежнему остаются 7 из 8 мест, куда могли бы уйти средства, что могло быть 1-7 фактических outputs или некоторое количество outputs автоматически добавленные \textbf{Sietch}'ем. Невозможно точно узнать \textbf{сколько} люди получили средств, за исключением того, что получили не более 8, и мы не знаем, все ли средства перевелись одному \zaddr output и остальное было нулевым, или некоторая комбинация средств с несколькими \zaddrs. 

% Here we compare what a Zcash (ZEC) mainnet shielded transaction graph looks like, compared to the shielded transaction graph we would see with \Sietch on the HUSH mainnet. These two graphics show two \textbf{hops} where we define one hop as $ z \rightarrow z $ and two hops as $ z \rightarrow z \rightarrow z $ and so on. After a few hops, it's easy to see that the shielded transaction graph of a \Sietch-enabled blockchain explodes into a "star" of potential avenues for funds to flow in. A traditional Zcash Protocol chain is a binary tree and that means that if at any point you can take control of that \zaddr output, you know metadata about a large sub-graph of the transaction graph, such as seizing an unprotected wallet.dat file from a mobile phone, laptop or desktop computer. With \Sietch, if one of Alice's friends has their phone seized, there are still 7 of 8 places where funds could have gone, which may have been 1-7 actual outputs or some number of outputs automatically added by \Sietch. There is no way to know exactly \textbf{how many} people received funds except that at most 8 did and we do not know if all funds went to one \zaddr output and the rest were zero or some combination of funds in multiple \zaddrs.

Наша цель, чтобы атакующие лицо вынуждено было изучать гораздо более сложный набор данных из-за \textbf{Sietch} - это
превращает каждую транзакцию Hush в отдельную крепость, а затем, когда мы соединяем много таких транзакций, весь защищённый граф транзакций становится очень устойчивым к деанонимизации в любых условиях. В среднем \Sietch силен во всех областях этого большого набора "нод" (узлов) и "ребер". 

% An attacker is forced to study a much more complex dataset with \Sietch and that is our goal. It makes each Hush transaction a little fortress in it's own right, and then when we connect many of these, the entire shielded transaction graph is very resistant to de-anonymization at any given place. On average, it is strong in every area of this large set of nodes and edges.

После 10 переходов Sietch распределит \zaddr средства на потенциально $ 8^{10} = 1073741824 $ защищённых outputs в среднем, в то время как "простой\pp протокол Zcash дает график транзакций размером примерно $ 2^{10} = 1024 $.

% After 10 hops Sietch will spread \zaddr funds into potentially $ 8^{10} = 1073741824 $ shielded outputs on average while the "plain" Zcash Protocol gives a transaction graph of size  $ 2^{10} = 1024 $ on average.

\begin{center}
\includegraphics[scale=0.314]{sietch-graph.pdf}

\includegraphics[scale=0.420]{zec-graph.pdf}
\end{center}

\nsection{Детали Реализации} % \nsection{Implementation Details}

В настоящее время у нас есть четыре реализации Sietch, две из которых находятся в производстве, одна устаревшая и еще одна в стадии тестирования. Первоначальные отзывы разработчиков приватных монет указали на некоторые проблемы в изначальных реализациях, поднимая модели угроз, о которых мы вначале не думали. 

% We currently have four implementations of Sietch, two running in production, one which was deprecated and another still in testing. Initial feedback by privacy coin developers pointed out some issues in our initial implementations, bringing up threat models we did not initially think about.

Ранее все реализации Sietch имели фиксированный список zaddrs адресов, встроенных в исходный код, и эти zaddrs были добавлены случайным образом в качестве outputs для \zaddr транзакций. Это не лучший вариант, потому что если приватные ключи из этих Sietch адресов скомпрометированы, становится возможным включить эти данные в цепочку
программного обеспечения для анализа и потенциально убрать преимущества конфиденциальности Sietch. Отмечаем, что в худший вариант - это вернуться к приватности существовавшая до Sietch.

% Originally all Sietch implementations had a fixed list of zaddrs embedded in source code, and these were randomly added as outputs to \zaddr transactions. This is not ideal, because if the private keys of those Sietch addresses are compromised, it would be possible to include that data into chain analysis software and potentially remove the privacy benefits of Sietch. We note that the worst case is to revert to pre-Sietch privacy.

В ответ на это, разработчик Hush реализовал рандомизированные Sietch \zaddrs во время исполнения, которые никогда не сохраняются в исходном коде или на диске. Случайная seed фраза генерируется, а затем из этой seed фразы создается случайный \textbf{zaddr}, а затем приватный ключ и seed фраза немедленно удаляются из памяти. Практически невозможно деанонимизировать людей массово, поскольку каждый пользователь теперь генерирует Sietch \zaddrs в памяти. Для восстановления этих приватных ключей или seed фраз требуется чтение памяти с отдельных узлов (нод). В настоящее время SilentDragonLite (SDL) использует этот метод. Полный узел \textbf{hushd} изначально использовал фиксированный набор из 200 случайно выбранных \zaddrs \cite{SietchRPC} \cite{SietchHeader}, но теперь имитирует поведение SDL. В то время как SDL генерирует случайную seed фразу, а затем использует полученные из нее защищённые адреса, \textbf{hushd} просто генерирует случайные публичные ключи, для которых он не владеет приватным ключом, а затем извлекает защищённые адреса из этого открытого ключа. 

% In repsonse to this, a Hush developer implemented randomized Sietch \zaddrs at run-time, which are never stored in source code, or on disk. A random seed phrase is generated and then a random \zaddr 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 (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.

Мы также отмечаем, что все Sietch outputs являются действительными и расходуемыми, они не являются "фальшивыми\pp и не являются недействительными outputs, которые нельзя израсходовать, поскольку мы полагаем, что они могут быть обнаружены и повлечь за собой утечку метаданных. Во всех смыслах, от используемых криптографических примитивов до энтропии данных, Sietch zdust - это легитимные и достоверные защищенные данные транзакций, что делает его таким мощным инструментом. 

% 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{Мысли об Изъятии Оборудования} % \nsection{Thoughts On Device Seizure}

Допустим, Алиса отправила Бобу и Чарли криптовалюту в полностью защищённой транзакции с защищённой сдачей: $ z_A \rightarrow z_B,z_C,z_A $. 

% Say Alice sent Bob and Charlie funds in a fully shielded transaction with shielded change: $ z_A \rightarrow z_B,z_C,z_A $.

Теперь предположим, что устройства Алисы и Чарли были конфискованы, файл wallet.dat "освобожден\pp и загружен в программное обеспечение для анализа цепочек, которое понимает Zcash Протокол и Атаки в стиле ITM. Теперь Боб находится в положении, где его \zaddr известен аналитику/злоумышленнику, точная сумма, отправленная ему в определенных транзакциях, и, возможно, другие метаданные в мемо-поле. Все эти данные являются ценными input, которые улучшают работу ITM-атаки и часто могут помочь "завершить\pp частичную деанонимизацию, которая не смогла полностью "разрешить\pp данные. 

% 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 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.

Даже без каких-либо новых атак, захват устройства и загрузка содержимого wallet.dat в программное обеспечение для анализа блокчейна представляет огромную угрозу для приватных/анонимных монет, поэтому им следует разрабатывать системы, которые предполагают, что это произойдет, и изолировать, и сопоставить возможный ущерб. Sietch предоставляет один из таких способов обеспечить защиту и конфиденциальность от реальных случаев. 

% Even without any new attacks, device seizure and uploading wallet.dat contents into blockchain analysis software poses an enormous threat to privacy coins and so they should design systems that assume this will happen and to isolate and comparmentalize the damage possible. Sietch provides one such way to provide a safety and privacy buffer against real-life scenarios.

\nsection{Рекомендации для монет на Протоколе Zcash} % \nsection{Advice To Zcash Protocol Coins}

Малое количество \zaddr outputs плохо для конфиденциальности, особенно 1 или 2. Применение хотя бы \textbf{4}, вероятно, сделает атаку ITM непрактичной, поскольку существует очень много потенциальных способов поменять местами оставшиеся inputs. Hush выбрал \textbf{7} в качестве буфера безопасности, так как замедление, связанное с 7 outputs, составляет около 5 секунд или меньше на современном оборудовании при использовании небольшого количества inputs. Это казалось разумным промежутком времени для совершения транзакции, учитывая, что исходные Sprout \zaddrs занимали более минуты, чтобы осуществить простейшие транзакции.

% 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 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.

Транзакции будут выделяться, если позволить пользователям тратить огромное количество inputs одновременно. GUI Кошельки (с графическим интерфейсом) и необходимость обучения пользователей очень важна для уменьшения потери конфиденциальности. 

% Allowing users to spend huge numbers of inputs at once makes their transactions stand out. GUI wallets and education need to improve to reduce loss of privacy.

Не призывайте пользователей размещать \textbf{zaddrs}, ссылки на txid и explorer, в которых они участвуют! Обучайте их хранить эти метаданные в личных сообщениях, прямых переписках и других закрытых местах. Чем меньше людей знают ваш \textbf{zaddr}, тем больше вы сохраняете свою приватность!

% 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 more privacy you have!

\nsubsection{Sapling Консолидация} % \nsubsection{Sapling Consolidation}

Sapling Консолидация рекомендуется для среднего пользователя и обеспечивает защиту от атак на метаданные, а также от \textbf{Denial-of-Service} атак в дополнение к своей основной функции - уменьшения размера файлов wallet.dat и, следовательно, ускорения их использования. \Hush добавил \Sietch в нашу реализацию Sapling Консолидации, а также снизил утечку метаданных за счет уменьшения количества inputs, которые пользователь когда-либо будет тратить за один раз, что составляет 8, дабы соответствовать среднему количеству outputs в \textbf{Sietch}. 

% 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.

Это означает, что когда эта функция включена, и узел "нода\pp получает атаку пыли из множества мелких inputs, узел волшебным образом очистится после атаки в фоновом режиме с лучшими Практиками для каждой транзакции. Эти транзакции гарантированно оставят размер нашего \textbf{набора анонимности} прежним или увеличат его на 1 (если нет output сдачи). 

% 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).

Первоначальная реализация Sapling Консолидации, написанная для монеты ZER, потребляла бы до 45 inputs одновременно и всегда отправляла бы на 1 output с комиссией=0, что тривиально выделялось в сети. В сети \Hush эти транзакции консолидации выглядят в точности как очень распространенные $ z \rightarrow z,z,..,z $ между 1-8 inputs и 7 или 8 outputs, смешиваясь с большим количеством транзакций, которые имеют те же свойства. 

% 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,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{Дальнейшие Обсуждения} % \nsection{Future Considerations}

В этом разделе рассматриваются различные новые технологии, появляющиеся на рынке, и то, как они взаимодействуют с существующими и новыми методами анализа метаданных. 

% This section considers various new technologies coming down the pipeline and how they interact with existing and new metadata analysis techniques.

\nsubsection{Защищённая coinbase ZIP-213} % \nsubsection{Shielded Coinbase ZIP-213}

Защищённая coinbase интересна, но в ней происходит утечка большого количества метаданных, привязанных к zaddress майнера, которые могут использоваться в этом анализе. Мы рекомендуем Pirate, Arrow и другие монеты, реализующие принудительное использование \textbf{zaddr}, избегать внедрения новой \cite{ZIP-213} "Защищённой coinbase". Сообщество Hush не соглашается с окончательным выводом ZIP-213 о том, что можно сделать \zaddr output майнера общедоступным и что только пользователи, озабоченные "постквантовой\pp \newline конфиденциальностью, должны беспокоиться об утечке метаданных. Sietch можно рассматривать как надежную защиту от квантовых компьютеров, но требуются дальнейшие исследования, чтобы увидеть, какие показатели квантовые компьютеры могут иметь для алгоритмов теории графов, составляющих основную часть атаки.

% Shielded coinbase is interesting but leaks a grave amount of metadata tied to the zaddress of the miner, which can feed into this analysis. We recommend Pirate, Arrow and other coins implementing enforced \zaddr usage avoid implementing the new \cite{ZIP-213} "Shielded Coinbase". The Hush community does not agree the the final conclusion of ZIP-213 that it is ok to make the miner \zaddr output public and that only users concerned with "post-quantum" privacy need to worry about metadata leakage. It gives no recourse to these users, and so in that sense Sietch can be seen an a valid defense against quantum computers. Further research is required to see what kind of speed up quantum computers can have on graph theory algorithms that make up the bulk of an attack.

Защищённая Coinbase резко снизит конфиденциальность \zaddr майнеров, потому что они будут повторно использовать один и тот же \zaddr для каждого блока, и это приведет к утечке \zaddr на котором происходит добыча монет. "Нормальное\pp поведение майнинга сначала происходит на taddr, а затем переводит на \textbf{zaddr}, который изолирует утечку метаданных на taddr, \zaddr майнера никогда не разглашается публично. ZIP-213 говорит о том, что майнеры должны создавать новый адрес для каждого блока, но это просто не произойдет - никто этого делать не будет, так как это необязательное условие пользования, так же это делает файлы wallet.dat очень большими, медленными, более сложными для резервного копирования и, что наиболее важно, простои, необходимые для остановки zcashd и перезапуск с новым zaddr напрямую приводят к потере денег для майнера. Все исследования анонимных монет указывают на тот факт, что большинство пользователей делают только то, что является обязательным, они не делают дополнительной работы для обеспечения конфиденциальности. Майнеры не исключение.

% Shielded Coinbase will drastiscally reduce privacy of \zaddr miners, because they will re-use the same \zaddr for every block and it leaks the \zaddr being mined to. The "normal" behavior of mining to a taddr first then sending to a \zaddr isolates metadata leakage to the taddr. The \zaddr of a miner is never disclosed publicly. ZIP-213 says miners should make a new address for every block but that simply will not happen because it's optional and also makes wallet.dat files very large, slower, more annoying to backup, and most importantly, the downtime it would take to stop zcashd and restart with a new zaddr directly translates into lost money for a miner. All privacy coin research points to the fact that most users only do what is mandatory, they do not go out of there way to do extra work to get privacy. Miners are no exception.

Используя Временной Анализ и Количественный Анализ с Защищённой Coinbase, аналитик может получить гораздо лучшую оценку минимального значения, которое, вероятно, имеет \textbf{zaddr}, и сколько средств проходит через него за интервал времени, а также txid, которые коррелируют с \textbf{zaddr}. Все они также могут использоваться в качестве inputs для ITM Атаки. Кроме того, \zaddr майнеров открываются для атак с помощью атак пыли, потому что их \zaddr навсегда останется всем известным в публичном блокчейне.

% By using Timing and Value Analysis with Shielded Coinbase, an analyst can get a much better estimate on the minimum value a \zaddr likely has and how much funds pass thru it per time interval, as well as txid's to correlate to the \zaddr. These can all be used as inputs to the ITM Attack, as well. Additionally, \zaddr miners open themselves up to dust attacks because their \zaddr is publicly known on the public blockchain, forever.

ZIP-213 - это увлекательное теоретизирование, которое можно реализовать с лучшими свойствами конфиденциальности, но меньшей возможности проведения аудита, то есть с точным знанием того, сколько новых средств добывается в каждом блоке. Принимая во внимание ITM Атаку в частности и атаки Метавселенная Метаданных (Metaverse Metadata) в целом, ZIP-213 не повысит конфиденциальность цепочки блоков, а уменьшит ее, заразив защищённый пул слишком большой утечкой метаданных. По этим многим причинам мир Hush и Komodo игнорирует ZIP-213 и, действительно, игнорирует всё Обновление Сети Heartwood, поскольку оно не имеет функций анонимности. 

% ZIP-213 is a fascinating academic exercise which could be implemented with better privacy properties but less auditability, i.e. knowing exactly how much new funds are being mined in each block. Taking into account the ITM Attack in particular and Metaverse Metadata attacks in general, ZIP-213 will not increase the privacy of a blockchain but decrease it by infecting the shielded pool with too much metadata leakage. For these many reasons, Hush and Komodo world are ignoring ZIP-213, and indeed, ignoring the entire Heartwood Network Upgrade, as it has no privacy features.

Таким образом, Защищённая Coinbase была реализована компанией Electric Coin с небольшим практическим учетом повышения конфиденциальности в их блокчейне, хотя это интересная техническая часть работы, поскольку увеличение использования \zaddr не приводит к увеличению прибыли, маловероятно, что у них когда-либо будет значимая конфиденциальность в основной сети Zcash. Только блокчейны протокола Zcash, которые обеспечивают использование \textbf{zaddr}, имеют шанс на значительную конфиденциальность. 

% In summary, Shielded Coinbase was implemented by Electric Coin Company with little practical regard to increasing privacy on their blockchain, though it is an interesting technical peice of work. Since increased \zaddr usage does not translate into more profits, it does not seem likely that they will ever have meaningful privacy on Zcash mainnet. Only Zcash Protocol blockchains which enforce \zaddr usage have a chance at meaningful privacy.

\nsection{Особая Благодарность} % \nsection{Special Thanks}

Особая благодарность всем членам сообщества HUSH и людям, которые заботятся о конфиденциальности, которые дали конструктивный отзыв об этой статье, включают Daira Hopwood, jl777, zawy, denioD, Biz и, конечно же, ITM, которые сообщили об атаке сообществу HUSH и убедил нас, что это правда, хотя мы ему долго не верили. 

% Special thanks to all HUSH community members and people that care about privacy. Some people that gave constructive feedback to this paper include Daira Hopwood, jl777, zawy, denioD, Biz and of course ITM, who reported the attack to the HUSH community and convinced us it was real even though we didn't believe him for a long time.

\nsection{Признательность} % \nsection{Acknowledgements}

Это независимо финансируемая исследовательская работа без сторонних источников финансирования. Финансирование от компании Electric Coin, Zcash Foundation или любой другой коммерческой или некоммерческой организации получено не было. 

% This is an independently funded work of research with no third party funding sources. No funding from Electric Coin Company, Zcash Foundation or any other for-profit or non-profit entity was received.

\nsection{Справочные Материалы} % \nsection{References}

\begingroup
\hfuzz=2pt
\renewcommand{\section}[2]{}
\renewcommand{\emph}[1]{\textit{#1}}
\printbibliography
\endgroup

\begin{center}
\textbf{Высказывайся И Совершай Транзакции Свободно - hush.is}

% \textbf{Speak And Transact Freely - hush.is}

\end{center}

\end{document}