“They are “lost” but anybody is free to prove they own them to the Hush Team and we will re-imburse them from our team funds”

The emission rate, modeled on Bitcoin, 21 million with a halving every 4 years, remains the same.

The Problem with Fees

There exists a fundamental problem in Zcash and its forks when it comes to fees and how users send funds. If not done correctly it is trivial for shielded transactions to be linked and the privacy broken.

There are 4 basic types of transactions in Zcash and its forks

Transparent (t) transactions, are just like Bitcoin transactions: t →t

2. Shielding transactions convert transparent coins to private (shielded) coins: t →z

3. Shielded transactions send shielded coins in private to other shielded addresses (zaddr): z→z

4. De-shielding transactions convert shielded coins to transparent coins: z→t

In realty there are many combinations of transactions depending on the UTXO set used, for example t,z → z or even t,t,t,t,t,t,z → t,t,t,z. User behavior can break privacy. If a user sends a shielding transaction of 123.456 coins, and sends in the following block a de-shielding transaction of 123.456 (minus miner fees), common sense dictates they are probably linked. Even if plausible deniability is protected, the use of custom transaction fees would remove that which is left. Combining t and z inputs in single transaction can have similar consequences for the uneducated user. Hush wants to educate users and provide tools that avoid these poor practices.

In all cases mining fees are paid, and are always transparent. For this reason custom mining fee values should NOT be used. Paying a custom fee of 0.0036352 for example will make linking even z-transactions trivial. Quoting from the Zcash Wallet Developer UX Checklist:

Disable users from setting their own transaction fees Do not allow users to customize fees.

Our network is fast enough that mining incentivization is not an issue.

Unique transaction fees can cause link ability within transactions, especially for zaddrs.

Sapling Woodchipper (CVE-2019–11636)

“HushList protocol research led to the discovery of the Sapling Woodchipper”



As part of his HushList research Duke Leto found that a Zcash shadow fee economy DOES exist, as displayed in the actions of mining pools. Leto discovered:

All/most pools will not mine a transaction larger than 1MB, though according to the Zcash protocol and codebase, they are allowed. This may have the unintended effect of taking less CPU-time to fill a block.

All/most pools will de-prioritize large transactions with the default transaction fee

Paying a double (or more) transaction fee will make large transaction get mined in the next block, i.e. a fee market exists

The ramifications for privacy are troubling since the behavior encourages paying higher custom transaction fees.

This research was published by Leto in CVE-2019–11636 (Sapling Woodchipper). Sapling Woodchipper is a DOS (Denial-of-Service) attack discovered by Leto which permits an attacker to fill blocks of Zcash 2.x and its forks at minimal cost. Quoting from the CVE:

Previously transactions could be at most 100KB in size but after Sapling activation, transactions can fill an entire block! This means that to fill all 576 daily Zcash blocks, one must only pay a single transaction fee per block, or a fixed cost of 0.0576 ZEC/day to fill all blocks. The following one line patch is the simplest mitigation to the Sapling Woodchipper, which goes back to the previous 100KB limit. It increases attack cost by roughly 10X-40X depending on blocksize.

Zcash developers have not patched this or acted upon Leto’s recommendations even though every major Zcash fork, including Komodo, has:

The author recommends Zcash and all source code forks of Zcash migrate to variable fees based on transaction size, to fully mitigate transaction-based Denial-of-Service attacks. Additionally, GUI wallets should be smart enough to know what current network fee conditions are, and give users a reasonable choice of paying different fees for confirmations in different timeframes, just like modern Bitcoin wallets.

Leto has not yet published his Proof-of-Concept (PoC) implementation of the attack.

HushList Privacy

When you send a message in HushList, you are sending it in the encrypted memo field of a Hush transaction, and bearing in mind what we now know about the dangers of custom fees and other poor practices in Zcash and its forks, it will be reassuring to know that HushList:

Always sends messages in transactions with 0 amount

Always sends messages with a fixed transaction fee

Always sends messages in shielded z → z transactions by default. There are a few cases where t addresses are used in HushList (e.g. a public hushlist, see the “Pen Name” use case later in the review)

By adhering to these three rules messages sent over HushList can be guaranteed full zero knowledge privacy, and are protected from blockchain analysis:

Since HushList always uses amount=0, that entire class of analysis goes away. Funds stay in zaddrs, they don’t pass thru and immediately go back to taddrs

SilentDragon

Now we understand the rich and complex history of Hush, its commitment to privacy, Hush’s ability to detect and patch critical vulnerabilities, we can discuss with gusto its present and future developments.

SilentDragon is a cross-platform desktop full node GUI wallet for HUSH with HushList chat, file upload and mailing list (not yet supported) features. Windows binaries are available to download and simple instructions for compiling on Linux and macOS are available on Github. Duke commented in discord “mac binaries will come soon, our windows binaries were kind of a canary in the coal mine, to find various bugs so we can make binaries for more platforms on the next release.”

Protocol

HushList is a protocol, and Hush the name of the cryptocoin which supports its development. Any blockchains which are “ZEC forks [that] have updated to Sapling will be able to use the full protocol”. This includes: ZEC, KMD, ZCL, ZEN, VOT, BTCZ, BTCH. Leto emphasized the importance of the protocol running on many chains:

If you are a government wanting to censor something that happened on HushList protocol, and it only runs on one coin and one chain, you just need to block 1 port

The Hushlist Protocol Specification describes in detail how the protocol actually works, and in parts describes:

The differences between public and private hushlists

How to subscribe to hushlists

How sending and receiving messages works, and the costs

How HushList maintains a database of contacts

How top-up fees a are further obfuscated with random values

How HushList minimizes metadata leakage at every step

The HushList URL scheme and parameters (hushlist://)

The first HushList memo contained the following text which is forever embedded in the 512 byte memo field of the this transaction:

A beginning is the time for taking the most delicate care that the balances are correct. — ”Manual of Muad’Dib” by the Princess Irulan 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. – Reverend Mother Gaius Helen Mohiam Polish comes from the cities; wisdom from the desert. — Arrakeen villager saying Be prepared to appreciate what you meet. — Fremen proverb

File Upload

HushLists file upload is a very powerful privacy tool.

Any file up to 200KB can be uploaded to Hush, and while this size limit puts some constraints on what a user can upload, a 200KB text file contains a lot of words. 200KB is equivalent to 200,000 characters or roughly 66.6 pages of a paperback.

The uploader is also protected from the metadata leakage associated with Internet routing, IP addresses, and timestamps held as metadata in Internet traffic but not present in the Hush blockchain. Hush also supports TOR connections.

Use Cases

The final pages of the HushList Protocol Specification are full of use case examples, three of which I will share here.

1. 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 retrieving 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 executors, 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.

2. “Security Researcher” user story - Gordon

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.

3. “Pen Name” user story - Amanda

Let Amanda have a transparent address tA and let there be a PUBLIC HushList with shielded address zL. Amanda sends HushList memos from tA to a PUBLIC HushList with a de-shielding transaction, ie.

tA → zL.

Any person who is subscribed to this public HushList will be able to see Amanda's memos, yet Amanda's identity is ”pseudonymous”, i.e. everybody knows that every message from tA 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 tA, 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 tA. If any transparent value resides in tA, 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 the key.

Of course Amanda is free to never reveal her identity and remain a pseudonym indefinitely.

Amanda needs to be concerned about her IP address being tied to tA 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.

Future

Hush is as deeply committed to privacy, if not more, than any other blockchain project to date. The project is mature and continually improving, has a fair mining emission (the same as Bitcoin) and an absolutely tenacious Lead Dev in Duke Leto

Tensions with Zcash devs over governance, the Sprout inflation bug ‘hush-up’, the lack of reaction to Sapling Woodchipper, and opinions on scaling and security (“Nobody wants to admit that Zcash is broke as shit”) will likely abate now Zcash has turned in its new direction. Komodo will continue to improve on the codebase, and Hush right by its side with jl777 serving as adviser.

SilentDragon is developing at pace and introducing new features and improving performance, and the addition of smart contracts and dApps will add tremendous value to Hush and its bleeding-edge privacy tools. Still under most radars (CMC Rank 1021), the story of Hush is both startling and inspiring.

Donations

Please send tips. I cant write without them. Thank you!

ETH: 0x9c996533f421164e4F5A4ef4558425c441ac848B

BTC: 1BtdwtRRirwdUFWBots2ffE47nzHAgmiTv

HUSH: zs18jwgjjp9au86qkv84wntk4ct4vesms4xmvkzxlljheg2k3sncg75jlfyualxw55x60wmukgmyfn

KMD: RA9xPmFm7rhbo1C2o43J1HKvz2BLSX8uEs

Thanks

Thanks to Duke Leto and radix42 for talking to me about Hush, and sharing so much.

Useful Links

Website

Discord

Twitter (Team)

Twitter (Duke Leto)

GitHub (HushList)

GitHub (SilentDragon)

HushList Protocol Specification

Whitepaper v3

Hush Explorer

Coingecko

Excahnge (Graviex)