The HUSH Review with Duke Leto

13 min readJun 29, 2021

This article was originally published on The Daily Chain, 18th November 2019.

“Hush is focused on giving every human the freedom to speak and transact privately”
Duke Leto, July 2019

Concept

HushList is an anonymous messaging and mailing list protocol which uses the encrypted memo field of the Zcash protocol. HushList also supports small file uploads up to 200KB in size.

“HushList Protocol is another layer on top of the Zcash Protocol that adds communications privacy to the existing financial privacy features”

Hush v1

HushList runs and is developed on Hush, one of the first two Zcash forks along with Komodo.

Hush began life as Zdash and was started in November 2016 by Joseph Stuhlman, who left shortly after creating the project. In the beginning no notion of encrypted messaging existed in any roadmap.

radix42 originally had the idea for encrypted messaging and mailing lists using the Zcash memo field, most apt since it was she who was instrumental in keeping the memo field in the Zcash protocol when it was being designed. For this reason she is known as The Savior of The Memo Field, without which Hush would not be possible. radix42 took over as lead dev in 2017 and published this roadmap, and Zdash rebranded to Hush.

On February 11th 2018 the HushList Protocol Specification whitepaper was published by Duke Leto and radix42. Both individuals are demonstrably cypherpunks and between them have made innumerable contributions to cryptocoin development, especially Zcash and Komodo. radix42 is also the person that successfully “bugged satoshi to start the first bitcoin mailing list”

radix42 left the project later the same year following disputes with miners (“I was ousted by a miner coup” she told me) during a period of illness, and this left her disenchanted. She contributes for sister coin PirateChain ($ARRR) and remains in close working contact with Duke Leto, now lead dev of Hush. When I asked Duke about Jane he had the following comments:

“Think of radix42 as a genius that goes from town to town, whenever they want, dropping off magic spells and then leaving to go to the next place”

When I told radix42 I thought Duke Leto made a good lead dev, she responded saying:

“Duke has the chops that’s for sure!”

Hush v2

In October 2018 Hush v2 was launched, and was a first foray into the Komodo Ecosystem with the integration of Komodo’s DPoW (Delegated Proof-of-Work) a technology that notarizes chain data to the Bitcoin blockchain. This effectively eliminates the chances of double-spends and 51% attacks to perform reorgs.

Sprout

Sprout is the name of Zcash’s first implementation of zero knowledge (zk-SNARKS) proofs and private transactions. Sprout transactions are notoriously slow and consume huge resources and time to create the anonymous shielded transactions (or z transactions). So resource hungry was Sprout that all the work on HushList was mostly theoretical, since actual implementations were impracticable.

Earlier this year in February 2019 the Zcash team disclosed an inflation bug in Sprout that may have created an unknown quantity of ZEC. They had known about it for 11 months before disclosure.

Sapling

Sapling is Zcash’s second major implementation of zero knowledge proofs and transactions and they are exponentially faster and less resource demanding than Sprout transactions. Sapling enables anonymous HushList messages to be created and sent in a reasonable time frame, and allows low-powered mobile devices to send shielded transactions

Quoting from the Hush v3 whitepaper:

Now that shielded Sapling transactions run in seconds with megabytes not gigabytes of RAM usage, HushList protocol can be upgraded to take advantage of Sapling features and actually be implemented by GUI wallets and other applications.

When Hush v3 was launched earlier this year with a new genesis block, Sapling was enabled in Block 1, which means no Sprout UTXOs will ever exist on the Hush v3 blockchain and it is protected from any Sprout related security issues. This also means that the size of the blockchain has been dramatically reduced, and the setup files required slashed from 1.6GB to only 50MB. Hush is “the most bandwidth-efficient Zcash protocol coin.”

Hush v3

Hush v3 migrated to a new codebase based on Komodo and Zcash 2.0x. The move to Komodo, as mentioned in the v3 whitepaper written by Duke Leto, “frees up other developer resources to work on wallets, explorers, HushList protocol and applications which sit on top of the RPC interface” and since jl777, Komodo lead dev and adviser to Hush, is “constantly doing low-level blockchain internals coding” upstream.

Hush now benefits from the features of Komodo, most notably Komodo’s UTXO-based smart contracts, known as Custom Consensus(CC’s), which was initially an open standards draft from the Internet Engineering Task Force (IETF). Hush has already integrated five smart contracts, plans to integrate more and is developing its own contract, all of this to pave the way for dApp development on top of Hush.

As announced on July 23, the brand new nSPV superlite client released by Komodo will be used by Hush and is the latest example of the benefit of having Komodo and jl777 upstream. For more information on nSPV check otu this thread on twitter.

Only two months ago, April 14th 2019, Hush v3 was released with a new genesis block. Balances from the v2 chain are carried over to the v3 chain. all funds except (1)~681,000 Hush created during a series of 51% attacks before DPoW was added, and (2) 71,000 HUSH which were “locked” into Sprout funds in the old Hush chain. For more detials and to clain your HUSH, see the website.

“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 linkability within transactions, especially for ziaddrs.

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.

“Nobody wants to admit that Zcash is broke as shit”

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

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 Amandas memos, yet Amandas identity is ”psuedonymous”, 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 psuedonym 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, the guy who could have brought Zcash (ZEC) to its knees with Sapling Woodchipper, but instead made HUSH and all Zcash forks stronger.

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 1431), the story of Hush is both startling and inspiring.

Thanks

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