well as public and private lists. The HushList protocol can run on any fork of \Zcash that has a compatible memo field, though certain advanced features might not be fully supported
on all chains. HushList is developed and tested on the Hush mainnet and testnets and is designed to run on any \ZEC code fork including but not limited to \HUSH, \KMD, \ZCL, \ZEN and the upcoming \BTCP and \ZAU forks. HushList is also compatible with Bitcoin Hush \BTCH, which is a \KMD asset chain.
In addition to the above properties, \HushList provides users with censorship-resistant
storage and retrieval, since every \Hush full node will have an encrypted copy of every
\HushList memo. Furthermore, sending and receiving via one or more blockchains is a serious deviation from traditional server-client design which easily allows a Man-In-The-Middle Attack and Deep Packet Inspection (DPI). Network traffic monitoring and correlation is made much harder, because there is no longer a packet with a timestamp and "selectors" going from one unique IP to another unique IP via a very predictable network route.
All Zcash forks have what we will classify into FOUR categories of transactions.
Let $ t \rightarrow t $ be called a \transparent transaction, which is identical to a \Bitcoin transaction, consisting entirely of transparent inputs and outputs. \HushList protocol implementations \MUSTNOT create \transparent transactions, they do not protect metadata in any way and lack memo fields. These transactions can be done with traditional wallet software and does not have any part in \HushList protocol.
Let $ t \rightarrow z $ be called \shielding transactions, which takes transparent
value stored in UTXOs and transforms them to \xShielded value stored inside of \notes
which are protected by \zkSNARKs.
Let $ z \rightarrow z $ be called \xShielded transactions, which take \xShielded value
from one \xShielded address to another, and is fully protected by \zkSNARKs. \HushList implementations \MUST support these transactions, and additionally \SHOULD educate users that they are the most private type of transaction, which minimized metadata leakage.
Let $ z \rightarrow t $ be called \deshielding transactions, which take \xShielded value
stored in \notes in $z$ and transfer them to \UTXOs stored in $t$. \HushList\MUSTNOT create \deshielding transactions, as they leak metadata and can potentially link a previously \xShielded address $z$ to a transparent address $t$. \HushList implementation \SHOULD attempt to prevent, at all costs, accidentally sending to a $t$ address via the \zsendmany RPC command.
An easy way to summarize the support transactions of \Hushlist is to say: All receivers must by \shielded addresses, senders can be either \transparent or \shielded addresses.
Each \HushList\MUST have a default blockchain and network that it is attached to, and the default
chain \SHOULD be HUSH. The default network \MUST be assumed to be "mainnet" if not specified, similar to how the *master* branch is assumed in many Git commands if not specified. The user \MUST be able to set their GLOBAL default chain (not implemented yet) as well as a default chain for each list.
Each list also has a tadd+zaddr dedicated to that list, so the user has dedicated addresses to send psuedo/anon messages, as well as default fee and amount. The default amount is
$0.0$ and the default fee is currently $0.0001$ but these numbers are subject to change.
\HushList supports file attachments and embedding arbitrary binary data, it is not limited to ASCII. \HushList does not impose file size limits and network fees and CPU/RAM costs provide natural incentives for spammers to find cheaper and easier-to-access dumping grounds.
The design of \HushList is inspired by Git. The reference implementation is a command-line
program which is a very thin wrapper around an API, which is implemented as a various Perl modules. \HushList uses many of the same subcommands as Git which have intuitive meanings,
which provide "easy-onramps" to learn how to use the CLI.
This document specifies a protocol and the authors provide a reference implementation of this protocol in cross-platform Perl which can be easily installed on millions of computers around the world via CPAN and other methods.
\HushList should work across any platform that supports Perl and the coin being used. In this case, cryptocoins are much less portable than Perl, so Perl will not be the limiting factor.
various blockchains and using various software stacks. The design of \HushList is compatible with Simple Payment Verification (SPV) light wallets and a future version of \HushList will learn to speak to an ElectrumX backend server, which natively supports Hush as of the upcoming 1.2.1 release.
This code is still in active development, consider it EXPERIMENTAL and ONLY FOR DEVELOPERS at this point pending a security review. This is the bleeding edge, folks.
The current reference implementation can send and receive memos, including files on disk or simple strings of text, as long as they are up to 512 bytes.
Since \HushList memos have, by default, an amount of $0.0$, all the costs associated with using \HushList are network costs. Users may additionally add a non-zero amount to a \HushList memo.
If there are no taddr or zaddr funds in the entire wallet, \HushList\SHOULD present the user a taddr + zaddr which can be used to "top up" the current \HushList wallet from another wallet/exchange/etc.
\HushList maintains a database of contacts which use the address as the unique ID and additional metadata. Since \HushList supports multiple blockchains, it \MUST have a contact database
for each chain. Each chain \MUST have it's own contact namespace, so you can have Bob on Hush and Bob and Zcash and they will not conflict.
\HushList internally associates lists to Contacts, not the address of a contact. This allows the user to update the address of a contact in one place and things work correctly the next time the address of that contact is looked up. Lists contain Contacts and Contacts have addresses.
A \HushList contact may only have ONE address, either taddr or zaddr, but not both.
To have a taddr and zaddr for a person, you can simply create two contacts, such
as tBob and zBob. In terms of the metadata that is revealed when communicating with
tBob or zBob, they are quite different, and it is healthy for metadata minimization
A user may choose to send a \HushList memo via multiple coins as long as there is a valid
address for each Hush Contact on for each coin. For example, if you have addresses for three of your friends on each of the \HUSH, \KMD and \ZEC chains, then you may choose to redundantly send a memo on all of the chains. This provides a backup of the data on the other chains should one of them be blocked (such as dropping any packets for certain peer-to-peer ports), filtered or temporarily inaccessible.
Additionally a user may choose to send day-to-day memos on a inexpensive chain such as \HUSH
which has lower network difficulty and for things that need to have \Bitcoin-level security, an archive copy to \KMD can be sent. \KMD uses the delayed-Proof-Of-Work \cite{dPOW} algorithm ensuring that once the information is engraved on the Bitcoin blockchain, it would be required both blockchains in question to be compromised to prevent accessing the data.
A public \HushList means publishing the PRIVATE KEY of a taddr (or potentially a zaddr)
such that this address is no longer owned by a single individual. By intentially
publishing the PRIVATE KEY in a public place, the owner has put all FUNDS and more importantly, the metadata of all transactions to that address, in the public domain.
By default, \HushList\MUST refuse to publicize the PRIVATE KEY of an address that has non-zero balance. \HushList implementations \SHOULD protect users from accidental monetary loss in every way possible. Even so, a user could accidentally send funds to an address that has been publicized and this very real confusion is still looking for good answers.
Very recent developments in \Zcash might allow the potential to use "viewing keys" in the fture, but as this feature has not been fully merged to master at this time and lacks a RPC interface, \HushList chooses to use PRIVATE KEYS which are core \Zcash protocol that is well-supported in all forks. If "viewing keys" are one day to be used, that feature will need to be merged into multiple \Zcash forks, which does not seem likely in the near-term.
Since creating a private \HushList requires making a transaction on the network to store data in the memo-field, it has a cost. This cost will be the fee of the transaction, most likely around 0.0001 but each chain is different and fees obviously change as blockchains get more active.
Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.
does leak the metadata of the amount, since it was a de-shielding transaction, from $ t \rightarrow z $. All \HushList memos have amount=0.0 by default so this is not normally a concern.
The biggest concern for metadata leakage in \HushList is in de-shielding $t \rightarrow z$ transactions which leak amount metadata.
The only time \HushList does a de-shielding transaction is when the local wallet has 0 shielded value and it must transfer value from a taddr OR when the user chooses to send from a psuedonymous taddr to a \HushList.
The first case we call a "shielded top-up" and happens rarely but we would not want to always have the same default amount to "top-up" because that amount can be searched for on the public chain. For this reason, we add some noise to the exact amount of our topups. For instance, if the user wanted to move up to 1 HUSH, we would generate a random number between 0.9 and 1.0 and then subtract it from the top-up amount. Then all \HushList users wouldhave slightly different top-up amount instead of a few easily searchable amounts.
In the second case, normal transactions will have amount=0 which will stand out and
network transaction analysis is possible. If these psuedonyms choose to actually send non-zero amounts, network analsysis can be made harder since most \HushList messages use amount=0.
yet Amandas identity is "psuedonymous", i.e. everybody knows that every message from $ t_A$ is the same person, but her identity remains unknown. If at any time in the future, Amanda would like to *cryptographically prove* that she is the identity behind $t_A$, all she must do is create a signed message with her private key, which proves her ownership of it.
A more "nuclear" option is to publish the PRIVATE KEY of $t_A$. If any transparent value resides in $t_A$, it can simply be moved to another address before publication.
This option "burns" the identity somewhat, as no messages after the publishing of the PRIVATE KEY can be known as the original authors or any other person who learned
Amanda needs to be concerned about her IP address being tied to $ t_A $ by a passive network attacker who records the Internet and is encouraged to use a proxy, Tor or other means depending on risk and operational security needs.
\nsubsection{Last Will And Testament User Story - Xerxes}
Xerxes would like to store a copy of their Last Will And Testament in multiple secure locations, where they cannot be lost nor destroyed by parties that would benefit
from the destruction of the Will.
Xerxes can use HushList protocol to store their will in many different blockchains, in the hopes that at least one will survive longer than him, and to prevent
censorship if he only stored the data on one chain. Xerxes can choose to additionally make the will public initially, or after some time period, or only leave
instructions for retreiving the will with executors of their Estate.
This use case also supports the continual updating of a Will, and provides a record of all the changes to a will, with timestamps and cryptographic certainty.
This record can be verified by any and all exectuors, with or without making the records public. Indeed, a public HushList can be used to provide instructions
and the actual Will, and newer memos to that list are public proof that the person has changed their Will.
\nsubsection{"Oppressed Minority" user story - Francesca and Nicolau}
Francesca and Nicalau live in a place where their local religion/government/organization is oppressed by a larger religion/government/organication that controls everything around them, yet they still want to safely communicate.
Dana wants to communicate 0-day exploits about nation-state infrastructure to the people that run this critical infrastructure, without anybody else listening in on this very sensitive information.
Martha has data about something that must be transported from internal-only systems, to external places, preferably many, while knowing that the data is not tampered with or even viewed until the appropriate time.
This is an extension of the "Pen Name" User Story. Let's say that for some reason a journalist Billy is already known publicly, but is censored from all media locally in various places. Billy can use HushList to publish his writing (and also source data, encrypted or not) to multiple blockchains to make it permanently mirrored across thousands of servers and very hard to censor.
Additionally, a special thanks to the Komodo Platform\cite{Komodo}, which has embraced Hush as one of the first cryptocoins to be added to their BarterDEX \cite{BarterDEX} atomic swap platform and continues to support the Hush Community in various ways.