Paxos Gold (PAXG) — A crypto-based option for physical gold ownership

For many years, my non-crypto portfolio has been the Golden Butterfly, which holds a 20% allocation to gold.

Why so much? It’s a slight modification of the Harry Browne “Permanent Portfolio”, which is based on the forward thinking idea that the economy can be in one of four states, and that a sound portfolio would hold equal amounts of the asset class that reacts most dramatically in each of these economic states, and then capture gains through both appreciation and rebalancing.

As mentioned, the Golden Butterfly is a slight modification, tilting the allocation ever so slightly towards stocks:

  1. Prosperity → Stocks (40%)
  2. Deflation → Long-term US bonds (20%)
  3. Inflation → Gold (20%)
  4. Recession → Cash (20%)

When people look at this portfolio, they almost universally respond in horror. With low interest rates, long-term bonds are surely going to get crushed! Gold and cash earn no yield! Only 40% stocks?

What they’re missing is that the magic is in the uncorrelated relationship between the classes. It’s the package that matters, and for as long as we have data, this allocation has proven to be one of the most stable in times of both growth and drawdown of any mainstream portfolio.

So that’s why I hold gold. Now let’s talk about how I own it.

In the early years, I had accounts with BullionVault and GoldMoney, where you purchase title to physical, redeemable gold. Working with these firms, however, felt archaic. BitGold emerged, and brought the user experience of owning gold into the 21st century, but then dropped much of their fantastic user experience, when they merged with GoldMoney. Eventually, I moved away from GoldMoney, to purchasing the iShares Gold Trust ETF, IAU.

Owning an ETF is convenient for rebalancing, but it’s still a paper form of ownership, and so I’ve been keeping my eye open for alternatives. One did appear a few years ago, Vaultoro, a Berlin-based physical gold provider. My main hangup there, however, was that it’s bitcoin-based, i.e. you can’t deposit and withdraw fiat, making rebalancing within a larger portfolio a bit inconvenient.

A new solution to gold ownership has recently emerged that looks to have all the characteristics I’ve been looking for—and more! And that solution is Paxos Gold.

Paxos is the New York regulated company that issues the PAX USD stablecoin, whose market cap recently passed TrustToken’s TUSD. Pax Gold, or PAXG, is their new stablecoin product, in which each token is backed by one ounce of physical gold in a Brink’s vault in London.

Here’s what I find attractive about PAXG:

  • Trust. — Paxos is a New York regulated Qualified Custodian and financial services company, with a solid track record. (Binance, for example, chose Paxos to custody and issue their new USD stablecoin, BUSD.)

  • Physical ownership. — Each token is backed by physical gold, and is redeemable. At the Paxos website, you can even trace each token to the serial number of the London-vaulted 400 oz gold bar to which it corresponds.

  • Accessibility. — As an ERC-20 token on the Ethereum network, PAXG can be freely moved and traded as a bearer-instrument 24/7. You can choose to custody it at the Paxos website, where you can redeem it for cash or gold, or you could custody it yourself, say in a hardware wallet, and sell it on a public exchange.

  • Low fees. — Depending on volume, purchase fees can range between 0.03% and 1.00%, and Paxos additionally make money on Ethereum network transactions (0.02%). During their launch sale, however, there’s no purchase fees, and even a 2% rebate, on the first 7,000 tokens sold.

But perhaps most exciting about PAXG, is that it opens the door, for the first time, to earn yield on your held gold. For example, Nexo have already announced plans to add PAXG to the list of deposited stablecoins on which they pay 8% per year in-kind interest.

Of course, lending your gold, like lending anything, introduces third-party risks which one would need to take into consideration, but it’s very exciting to know that options to earn yield on held gold are being enabled through technological innovations like PAXG.

At the time of this writing, during its launch week, roughly $2.4M of PAXG has already been minted. With the benefits listed above, I’m excited to keep an eye on PAXG as a fascinating option for my gold holdings. (And if I end up going with PAXG, I guess I’ll have to stop referring to it as my “non-crypto” portfolio!)

The importance of plausible deniability in crypto products

One of the most important, yet overlooked, features of any crypto currency product is support for plausible deniability. This feature is best understood by example.

The Ledger and Trezor hardware wallets, like nearly all crypto wallets, are secured with a 24-word seed phrase. Access to the wallet is then secured with a four-digit PIN code. Most of us are familiar with this model by now.

What many people don’t realize is that these devices don’t just support one single wallet behind one single PIN, but rather support any number of wallets secured behind any number of PIN codes.

This feature, known as the “25th word feature”, allows you to add additional words to the seed—i.e. 25th words—thereby creating additional wallets, which you can then secure with additional PIN codes. And since there can be any number of 25th words, these devices support any number of wallets! Take a moment to think about the implications of that.

This feature provides both convenience and plausible deniability:

  • Convenience, in that you can have a default wallet, containing a small amount of currency that you use for day to day transactions, without having to expose your larger holdings.

  • Plausible deniability, in that if you were forced to open the wallet, you can open your default wallet containing a small amount of funds, and it would be impossible to know whether you have additional wallets, where you’d maintain your larger cold storage funds, secured behind additional PIN codes.

In my view, plausible deniability should be a core feature of crypto products, presented and promoted front and center. Uunfortunately, it’s often considered too complex by some products, and poorly implemented by those that do support it. Let’s look at at few more examples.

Mobile Wallets

The Secure Enclave makes iOS devices surprisingly good platforms for secure wallets. But I would never use my iOS device to store significant amounts of crypto currency because nearly none of the current wallets support plausible deniability, and the one that does, doesn’t support it well from a UX perspective.

TrustWallet, BRD and Edge are all high-quality mobile wallets, and all of them support the interaction of launching with a prompt for a PIN code. None of them, however, support multiple wallets, secured behind multiple PIN codes.

I once spoke with BRD about this, and their view was that plausible deniability was too advanced for their users. At the same time, however, they argued for using BRD as one’s primary crypto storage, due to the security of the Secure Enclave. That would be a terrible recommendation, for a product that supports only a single wallet.

(Note that all of these products claim to technically support multiple wallets, by the fact that you can restore any number of wallets from different 24-word seeds. That’s terribly impractical, however, from a UX perspective.)

Ledger Nano X

Since the recently-launched Nano X, which does support multiple wallets secured by multiple PINs, is accompanied by an iOS app, Ledger Live, I was hopeful that plausible deniability would finally be supported in a useful way on a mobile device. Unfortunately, the implementation is such that it’s nearly as unwieldy as restoring a 24-word seed in the other wallets.

The Ledger Live mobile app supports “accounts”, which are individual currencies within a given wallet. If you had two sets of wallets behind two PINs on your Nano X, each of which held BTC and ETH, you would either have to have all four “accounts” always visible in Ledger Live—say, “BTC”, “BTC Cold”, “ETH” and “ETH Cold”—which, of course, defeats the whole purpose of plausible deniability, or you would need to add your cold storage accounts only when needed, and then have to remember to delete them from the app when done. (Deleting them in the app doesn’t affect their presence on the hardware device.)

So, unfortunately, the Nano X, combined with the Ledger Live mobile app, doesn’t move us forward in terms of usable plausible deniability on mobile devices.

Portfolio Tracking Apps

It would be great to track my full crypto portfolio in an app like Blockfolio.

Again here though, Blockfolio doesn’t support plausible deniability. As with mobile crypto wallets, Blockfolio could launch with the presentation of a PIN interface, behind which multiple portfolios are managed—i.e. my real portfolio, and then a shadow portfolio I’d open if forced. But since this isn’t supported by Blockfolio, or any of its competitors, I’m left to track my crypto holdings in a spreadsheet, locked away inside a hidden encrypted disk image.


My hope in publishing this article is to bring more awareness to the need for supporting plausible deniability as a core feature of crypto products, and for those that do support it, surface it in the user interface as a primary function of the product, rather than hiding it away behind the “Advanced” settings.

For further reading, and a great example of how beneficial plausible deniability can be in general, be sure to see my article about the Espionage product for Mac OS X.

How to use MakerDAO and DAI to create a leveraged long investment in ETH

In mid-2018, having learned how futures trading works on Bitmex, I opened a 2X leveraged perpetual ETH contract. The idea was to generate a boosted return on ETH, at a leverage level I felt was “acceptably” safe. Unfortunately, later in the year, the price of ETH moved downward so dramatically that my position ended up getting liquidated, and I lost my entire collateral.

Recently, I’ve discovered an alternative way to implement a leveraged long position in ETH, involving the MakerDAO system to borrow DAI—a stablecoin that should maintain a value of $1 USD—through the creation of a “Collateralized Debt Position” (CDP). (For a good general introduction to the MakerDAO system, see this article.)

The basic idea is—we can deposit ETH collateral with MakerDAO, borrow some DAI, and then use that DAI to buy more ETH. If our ETH increases in USD value in the future, our gains are leveraged, since we get to keep some of the ETH we purchased after selling enough to repay the DAI.

The best way to understand this, is to walk through a hypothetical example (which isn’t that hypothetical, since I did it myself this morning to figure out how everything works!)

MakerDAO network

To understand our hypothetical investment, we’ll need some data from the MakerDAO network, which we can get from the Maker System Overview page.


  • CurrentPrice — is the current value of ETH in USD.
  • LiquidationRatio — is set by Maker, and establishes the collateralization level at which your CDP would be closed and enough collateral removed to repay the DAI loan.
  • StabilityFee — This is an annualized fee charged by MakerDAO for the loan. It’s a running fee computed continually, so that a correct pro-rata charge can be made whenever you close the position.
  • LiquidationPenalty — This is an additional fee charged by MakerDAO, based on your DAI loan amount, if your CDP has to be liquidated.
  • PET — This is calculated by MakerDAO, and is the ratio of “Pooled ETH” to “Wrapped ETH” in the network. (I’m not sure what that means, but it doesn’t seem to matter for what we’re doing here.)

Loan, Fees & Investment

In this section we’re going to look at securing a DAI loan, which starts by connecting a hardware wallet, like the Ledger Nano S, to the Maker Collateralized Debt Position Portal. (It seems like they’ll also let you create a web wallet, if you prefer.) Once connected, you deposit some ETH, generate some DAI, which you can then transfer away, and then later repay the DAI to close the CDP.

  • CollateralETH — This is the amount of ETH I deposited as collateral.
  • CollateralUSD — This is the USD value of that collateral at the time of CDP creation.
  • DAI — The amount of DAI I created (borrowed).
  • CollateralizationRatio — The value of my DAI relative to my collateral. The current minimum ratio is 150% (and the website warns you if you go that low, you can immediately get liquidated with even a small drop in the price of ETH). In my case, I’m using 300% collateralization.
  • PurchasedETH — With my 20 DAI, I was able to purchase 0.166 ETH. This is done elsewhere, of course, at an exchange supporting DAI and ETH. I did it within the Edge Wallet, which is useful, because I can create an ETH wallet just for this investment, which makes it easy to compare its current value with the amount of DAI used for the purchase.

Here is what the MakerDAO CDP Portal shows me after I’ve created my loan:

  • Since ETH has slightly increased since this morning, my CollateralizationRatio is slightly higher.
  • As you can see, I can still withdraw ETH from my collateral or generate additional DAI given that my CollateralizationRatio is still above the minimum of 150%. If I were to actually try to generate another 20 DAI, however, the platform warns me that I’m at risk of immediately losing my collateral.

So at this point, I’ve deposited 0.5 ETH, to borrow $20 in DAI, which I used to buy 0.166 ETH, meaning for each 1% increase in the price of ETH, I’ll be earning 1.33%.

The liquidation case

Let’s now look at what happens should the price of ETH drop to around the liquidation level.

  • PETH — This is a term used in the MakerDAO ecosystem that refers the amount of ETH I’ve “staked” in this loan. It’s simply the amount I deposited, minus the fee I’m charged, and is what I’ll get back after repaying the loan.
  • LiquidationPrice — This is the market price of ETH at which the CDP would be closed, and enough collateral removed to cover the outstanding DAI debt, plus the liquidation fee. (As you can see from the screenshot earlier, there’s a slight inaccuracy of few dollars in my model for determining the liquidation price. The MakerDAO liquidation formula say it’s an “estimate”, so I suppose the actual liquidation price must be more complex.)
  • CoverETH — This is how much ETH I’d need to buy (or have set aside), in order to repay the loan to avoid the liquidation fee. (I could also add ETH to the CDP to increase the LiquidationRatio again.)
  • RecoveredETH — This is PETH returned to me in paying off the loan, minus the ETH I had to spend to purchase enough DAI to repay it.
  • RemainingETH — This is my net ETH left over, which is the above RecoveredETH plus the ETH I bought with my DAI loan.

An important point to note here is that liquidation doesn’t consume all my collateral, as it does at Bitmex. There, as you approach liquidation, it’s hardly worthwhile to close the position. As the price of ETH is dropping, due to the settlement process between longs and shorts, liquidation is simply the point at which your position is worthless.

Liquidation stats

Let’s look at a few numbers of general interest, related to the liquidation case.

  • Allocation — If this were a serious investment I were making, this is the total amount I’d allocate to it. It’s the amount of collateral (0.5 ETH), plus the ETH I’d need to buy enough DAI to avoid liquidation (e.g. CoverETH, or 0.33 ETH).
  • LiquidationPriceDrop — This is the percentage by which the ETH price would need to drop to trigger liquidation. (50% might seem “safe”, but as I learned in my Bitmex experiment, that’s not safe in crypto.)
  • MaxLoss — This is the percent I’d lose on my investment (my collateral), in the case of repaying the loan just prior to liquidation.

Concluding thoughts

I hope you’ve enjoyed this walkthrough of using MakerDAO to borrow some DAI, which you can use to leverage your ETH position. I don’t pretend to be an expert in the Maker system by any means, but I wanted to publish this guide, since I didn’t find anything similar (including a calculation model), when I was trying to understand it.

The Bitmex experience reinforced a saying that in the investment world has proven its wisdom time and time again:

Don’t just do something; stand there!

So I don’t know whether I’ll actually create a significant leveraged position in ETH using MakerDAO, even though I have a long-term conviction around ETH. But it’s good to finally understand how the system works!

If you’ve enjoyed the article, or find any corrections that need to be made, please drop me a note in the comments. Thanks for reading!

Comparison of cryptocurrency exchange service rates

For those interested in trading cryptocurrencies, and wishing to avoid complex interactions with an exchange like Binance, a number of easy-to-use online cryptocurrency changer services exist, as well as in-wallet changers.

In this post, dated January 11, 2019, and which I hope to periodically update, I present a comparison of the ones I know about. For each, I’m comparing the BTC→ETH rate, and using CoinMarketCap as a reference.

Changer1 BTC → ETHPercent Loss
CoinMarketCap (Reference)28.78830.00%
Edge Wallet (Changelly)28.4513(1.17%)
Exodus Wallet27.6682(3.89%)

Of course, some exchanges require accounts, while others are anonymous, and so other factors may be involved in one’s choice than rate alone.

(PS: If you know of other services I should add to the list, please mention them in the comments, and I’ll add them to future updates.)

Usability issue in the Edge wallet

Despite being my favorite multi-currency mobile wallet, Edge has a terribly frustrating UI/UX issue, that I’ve been unable to communicate to the team though text on Twitter. So here it is, documented visually.

When launching the app, it will periodically prompt the user to double-check that they still know the app password. (I hate this feature. Once I demonstrate I have the password in my password manager, I don’t need or want periodic checks that I still have it. I’m a responsible adult.)

Anyway, here’s the UX problem:

If you have the password on the clipboard—which will be the case for probably 99% of the users—the iOS touch action to initiate a paste is a double tap into the password field. However, the instant you tap once, the iOS keyboard appears, and which shifts the screen upward so that the second tap registers into the “I forgot, change password” field.

Why does this happen? Because when the screen shifts upward, the “Change password” button ends up in the same vertical position previously occupied by the password field. You can see this visually:

And even knowing this happens, it’s still very difficult to avoid. In fact, it’s happened the last three times I’ve faced this unwanted password verification workflow.

Anyway, that second tap into the change-password button takes the user to this screen:

After a bit of confusion about how you ended up here, the user will naturally want to go back to the password check screen, and so he taps the back link in the upper left. Unfortunately, instead of being returned to the password-check screen, he’s taken to the settings screen!

This means that the next time he launches the wallet app, he’s going to be once again prevented from using the wallet due to the annoying password-check workflow, and will probably run into this same issue again. (It has happened to me four times in a row now.)

So, here is a summary of the problems:

  1. Tapping into the password filed on the first screen frequently ends up registering a tap into the “Change password” button because of the instant shift upwards as the keyboard appears.

  2. From the next screen, it’s impossible to get back to the previous!

Hope this explanation helps the team at Edge.

Understanding Zerocoin

This article was first published on the Veil blog.

In this article, we’ll describe the Zerocoin protocol—one of the beautiful technologies underlying the strong anonymity you’ll find in the Veil currency.

History of Zerocoin

The Zerocoin protocol was conceived in 2013 by John Hopkins researcher Matthew D. Green1, as an extension of Bitcoin, providing for optional anonymity in the Bitcoin network. We say “optional” anonymity since the Zerocoin model involves converting public bitcoins to anonymous zerocoins, and back.

So the first concept to understand is that in Zerocoin networks, there are two types of tokens (coins)—public tokens, known as basecoins, and anonymous tokens, known as zerocoins. (Misunderstanding of this concept is a common source of confusion in networks such as PIVX, where one finds “PIV” and “zPIV” coins.)

In Veil, the on-chain coins are called Basecoin Veil, and the anonymous coins are called Zerocoin Veil. Since the Veil wallet automatically converts basecoins to zerocoins, however, the general use of “Veil” is meant to imply the anonymous coin.

(You’ll notice that for Basecoin Veil, we used the term “on-chain”, rather than “public”, since in the Veil network, Basecoin transactions are also anonymized using “RingCT” technology, but explanation of that will be saved for another post.)

The logic behind Zerocoin

Imagine we’re considering how to design an extension to the bitcoin network that would allow us to convert bitcoins to zerocoins, and then be able to spend them later anonymously.

In order that the bitcoin monetary supply remains auditable, the creation of zerocoins can’t be anonymous, i.e. when we bring a zerocoin into existence, through a process known as minting, we necessarily have to take a bitcoin out of circulation, in a process known as burning, and since bitcoin is a public token, its removal (burning) also has to be public.

Therefore, if I minted 1.73458 zerocoins—something we’ll later see isn’t technically possible, but for the moment we’ll ignore that—by burning 1.73458 bitcoins, and if the world can know, since bitcoin is public, that I owned those 1.73458 bitcoins, then the world will also know that I now control 1.73458 zerocoins.

So the challenge in a network like this is:

If my creation of zerocoins is public, how can I later spend those zerocoins anonymously?

Fixed denominations

The above example already presents the very first challenge. If I created such a precise amount of zerocoins in the past, like 1.73458, then when that precise amount of zerocoins gets spent in the future, it wouldn’t be very hard to assume that the spend came from me. Why? Because there simply won’t be very many other zerocoin address “outputs” out there holding precisely 1.73458 coins.

Considering this problem, Green may have thought, “What if zerocoins only existed in fixed denominations, like cash bills or casino chips? If there only existed denominations of, say, 1 zerocoin, 10 zerocoin, 100 zerocoin, and 1,000 zerocoin, then maybe I could design a system in which, if you spend a 10 zerocoin, the network won’t know which of all the 10 zerocoins you spent.”

This idea of fixed denominations was ultimately implemented in the Zerocoin protocol, and made to work through the concepts of accumulators and zero-knowledge proofs.


In Zerocoin networks, an “accumulator” exists for each denomination supported by the network. So if the Bitcoin network supported denominations of, say, 10, 100 and 1,000 zerocoin, it would have three accumulators.

Conceptually, most people think of accumulators as “buckets”, holding all the coins of a particular denomination. But in reality, as we’ll see later, an accumulator is actually a single number, that cryptographically embeds knowledge of the existence of each outstanding zerocoin in that particular denomination.

As you might imagine, the particular choice of denominations in a Zerocoin network has to be carefully considered, and the trade-off is between convenience and anonymity.

To understand this, consider that when I spend a 10 zerocoin token, its traceability back to me—i.e. back to my minting of a 10 zerocoin token—is a function of the total number of 10 zerocoins that exist. If there’s only five 10 zerocoins in existence, and I spend one of them, it might not take much sleuthing to figure out it was me. On the other hand, if there are five million 10 zerocoins in circulation, the problem becomes much more difficult, if not impossible.

For this reason, a network that only has six denominations would likely provide greater anonymity than one that has a hundred different denominations (all other things being equal). For the Veil network, there will exist four denominations, and hence, four “accumulators”: 10, 1000, 1000 and 10000 Zerocoin Veil.

Zero-knowledge proofs

Zero-knowledge proofs2, to most mortals, are akin to black magic. We won’t get close to the math behind them, but here’s what a zero-knowledge proof is in practice:

A ZK proof is a method by which one party can prove to another that a given statement is true, without conveying any additional information apart from the fact that the statement is indeed true.

Mind blowing, I know. Don’t get scared!

How the Zerocoin protocol works

With all that as background, we can now proceed to explain how the Zerocoin protocol works in practice.

Let’s start by walking through the process of what happens when you mint zerocoin by burning basecoin—something that happens automatically in the Veil wallet.

Burning & Minting

Say you received an incoming payment of 10.73458 Basecoin Veil. Looking at that number, your wallet would know that it can convert 10 of those to a single 10 Zerocoin Veil token. (The remaining 0.73458 Basecoin Veil would stay as Basecoin Veil in your wallet.)

To create your new 10 Zerocoin Veil token, your wallet creates a unique serial number, that we’ll call “S”, and a random number, that we’ll call “V”. Your wallet then performs what’s known as a “one-way” cryptographic calculation known as the Pedersen Commitment, that takes V and S, and computes a number called, “C”:

C = comm(S,V)

This formula simply means that “comm” is a mathematical function—the Pedersen Commitment—that takes S and V as inputs, and produces the number C as an output. It’s “one-way” in the sense that S and V can’t be back-calculated from C.

Having computed C, our wallet now “burns” 10 Basecoin Veil—taking them out of circulation—in a blockchain-recorded transaction in which the value “C” is publicly recorded.

The “10 Zerocoin Veil” network accumulator number is then updated cryptographically to embed knowledge of the newly introduced “C” value.

By burning 10 Basecoin Veil in this way, we have also “minted” a brand new 10 Zerocoin Veil token, that is associated with the recorded number “C”, which is linked to me, and to the unique serial number, S, which at this point is only known to my wallet!

Before moving on, let’s review where we are:

  • We have burned 10 Basecoin Veil in a blockchain transaction that minted the creation of a 10 Zerocoin Veil token, recorded with the number, C.

  • Since the burned Basecoin Veil is public (or for Veil, more precisely “on-chain”), the number C is publicly visible.

  • Only our wallet knows the random number, V, used along with S, in the calculation of C.

  • Only our wallet knows the serial number, S, which is the unique identifier of our particular 10 Zerocoin Veil token, among all the tokens.

Spending anonymously

Now comes the interesting part: How do we later spend those 10 Zerocoin Veil anonymously? To do that requires that the spend can’t be linked back to the mint. Let’s look at how that’s done.

When I’m ready to spend my 10 Zerocoin Veil, my wallet calculates two zero-knowledge proofs, the first of which can be used independently, and the second which can only be used in tandem with the first.

In the first ZK proof, I mathematically prove that the coin I want to spend (the 10 Zerocoin Veil) exists in the 10 Zerocoin Veil accumulator, without revealing which coin that is. Mathematically, I have to prove that the value “C” I wrote to the blockchain during my mint exists in the accumulator, without revealing the particular value of “C” I’m proving—since that would point directly back to me!

To do this, I compute the Pedersen Commitment function using C and another random value, R, that I choose and is only known to me, to produce the output Y.

Y = comm(C,R)

(The inclusion of a random number R is critical, because if I just computed comm(C) to produce Y, then by computing comm(C) on all the recorded C’s in the blockchain, you could easily figure out which C I’m proving!)

When I provide the value Y to the network, the network can validate my proof using Y and the current accumulator number to confirm that, yes, I do control a particular coin in the accumulator, but without knowing which one, i.e. the network doesn’t know which “C” I used in the computation of Y.

Then, I publicly reveal the unique serial number, S, corresponding to my particular 10 Zerocoin Veil, and provide a second ZK proof demonstrating that I know some random value V, that, in turn, proves I control the still-unrevealed “C” used in the first proof.

That’s a mouthful, but is why the second proof is only meaningful in tandem with the first.

So in summary:

  • Proof 1 proves that I control one of the coins in the accumulator, corresponding to the minting recorded with C on the blockchain, but without revealing which C that is.

  • Proof 2 allows me to reveal the unique serial number, S, corresponding to my particular coin, without revealing which burn and mint transaction, C, it corresponds to.

Or said another way:

Zero-knowledge proofs have allowed me to prove that I control a specific token among all the 10 Zerocoin Veil tokens, without any connection to the specific blockchain transaction that created that coin.

At this point, my spend transaction will be recorded on the blockchain:

  • The transaction will publicly record my unique serial value, S, so that that coin can’t be double spent in the future.

  • 10 fresh Basecoin Veil will be put into circulation and delivered to the destination address of my transaction, and my 10 Zerocoin Veil can not be re-spent due to the public recording of its unique serial number, S.

And so, through the use of zero-knowledge proofs, I have spent my 10 Zerocoin Veil anonymously!


In this article, we’ve described the Zerocoin protocol—one of the beautiful technologies underlying the strong anonymity you’ll find in the Veil currency3.


  1. See 
  2. See 
  3. Thanks to Veil developer Random.zebra for helping me wrap my head around the concepts like zero-knowledge proofs described in this document, and to Veil team members for editing feedback. 

The morality of Proof-of-Work

Previously, my German cloud-hosting provider disallowed cryptocurrency mining, given that mining is a process that consumes 100% of a computer’s CPU capacity, and their virtual servers (VCPUs) share a common pool of computing resources.

Recently, however, they announced the availability of virtual servers with dedicated resources (dVCPUs), and so I emailed them asking whether, on those servers, mining is acceptable. I expected a positive response, since mining is acceptable at other dVCPU providers, but they responded that their policies on crypto mining would remain unchanged, given that:

We do actually care about our environment.

I had three immediate reactions to this, which I sent them by email:

  1. You, as an organization, are making a judgement that one use of energy is morally acceptable, while another is not. I lived in Germany for many years, and that seems contrary to the cultural value I understood, that moral judgements should be left to the individual.

  2. There is a valid argument to be made that the benefits to humanity of a censorship-proof form of money justifies the energy required to provide for that censorship resistance. More energy efficient mechanisms have been proposed (PoS, etc.), but nobody can say with absolute certainty whether they will ultimate prove to be equally secure. The global market, however, continually casts its vote, and for the moment, it trusts Proof-of-Work.

  3. You are a private organization, and I respect your right to implement any policy you want. So don’t interpret the above as any kind of insistence that you change.

I’d like to ask you, the reader, for your opinion. Should hosting providers disallow crypto mining, on the moral arguments around justified use of energy?

An example of earning contango premium with bitcoin futures

This is the first in a series of articles I’ll be posting as I learn about trading crypto currency futures, available on platforms like Bitmex and Deribit.1

On this page of the Bitmex documentation, in which they discuss market conditions known as contango and backwardation, the following is stated:

A trader can use this as a trading strategy: a futures contract trading at a large premium can be sold and the underlying asset bought so that the trader is market neutral and will thus earn the basis if they hold till settlement.

In this post, I want to walk through a numerical example to clarify how the above actually works. But first, we need to define some terms.

What is a bitcoin futures contract?

When you buy a bitcoin futures contract, you own the right to buy bitcoin, on a particular date known as the settlement date, at a particular price. This is known as taking a long position.

Conversely, when you sell a bitcoin futures contract, you own the right to sell bitcoin on the settlement date, at a particular price. This is known as taking a short position.

On platforms like Bitmex and Deribit, when the settlement date arrives and the contract is settled, the price difference is transferred by the platform, and paid in bitcoin. If I own the right to buy 1 BTC at $10,000 on the settlement date, and you are the counter-party, with the right to sell 1 BTC for $10,000 on the settlement date, and the spot price of bitcoin is $11,000, then Bitmex, on that date, will transfer $1,000 worth of bitcoin from your account to mine.

As you can imagine, a futures contract that settles tomorrow will probably trade today pretty close to the spot price, but a contract that settles three months from now will trade today at the price the market believes the spot price will be in three months.

If the 3-month contract price is higher than the current spot price, then the market is said to be in contango, and the price difference, referred to as the “basis” or “premium”, is positive. If the 3-month contract price is less than the current spot price, then the market is said to be in backwardation, and the premium is negative.

Now let’s look at that strategy…

With all that as background, let’s return to the trading strategy mentioned at Bitmex, and walk through a numerical example to see if this actually works.

Given this point, a trader can use this as a trading strategy: a futures contract trading at a large premium can be sold and the underlying asset bought so that the trader is market neutral and will thus earn the basis if they hold till settlement.

Imagine the Dec 28 contract is trading at $7,000, with spot BTC trading at $6,500. We’re in contango, and the premium is $500. So in this strategy, I sell 1 BTC of futures contracts, giving me the right to sell 1 BTC on Dec 28 for $7,000. And then I go buy 1 physical BTC at the spot price of $6,500. I’ve paid a total of $13,500.

Dec 28 arrives, and BTC spot is trading at $10,000. I lose $3,000 on my BTC short contract, but I make $3,500 on my physical BTC, netting me $500, which is exactly the premium in play three months earlier.2

What about the case in which the spot price of BTC is lower on Dec 28, for example if BTC spot is trading at $5,000? In that case, I make $2,000 on my contract, and I lose $1,500 on my BTC, again netting myself exactly the premium of $500.

And we see that, yes, this strategy does work (and in the process, we beginners now understand futures a little better.)

What about using leverage?

When you deposit 1 BTC at Bitmex or Deribit, you’re not limited to buying or selling futures contracts limited to 1 BTC. Depending on the platform, you can actually buy or sell contracts of up to 100 BTC or 50 BTC, respectively! This is called leverage.

Leverage allows you to amplify both your potential gains and losses. Say with your 1 BTC of collateral, you buy 2 BTC of futures at $6,500. And let’s say the spot price drops such that at settlement date BTC is trading at $5,000. In that case, you’d lose $3,000 (corresponding to 2 BTC) rather than $1,500, had you not used leverage. Vice-versa if the price of BTC goes up.

In addition to loss amplification, leverage also carries the risk of liquidation. The platform, at all times, has to ensure your 1 BTC is sufficient to cover your losses, meaning that in the above example, at anytime between purchase and the settlement date, the market price of BTC drops to a level at which your 1 BTC collateral couldn’t cover further losses, the platform will immediately settle your contracts, and you’ll lose your collateral.

With that disclaimer, let’s look at a contango example with leverage.

The Dec 28 contract is trading at $7,000 and spot at $6,500. We use our 1 BTC deposited at Bitmex to sell 2 BTC of bitcoin short futures, meaning the right to sell 2 BTC on Dec 28 at $7,000. Then we buy 2 physical BTC at $6,500. Our total cost is $20,000.

Dec 28 arrives, and the BTC spot is $8,000. We lose $2,000 on our futures contracts, and gain $3,000 on our physical BTC, netting a total of $1,000, or twice the $500 premium existing at purchase time.

The liquidation risk is that at some point prior to settlement date, the spot price of BTC goes to $14,000, such that the contract position loss on a 2 BTC position is $14,000 or 1 BTC. In that case, your short position would be liquidated, and you would lose your 1 BTC collateral (worth $14,000). However, you’d have the 2 physical BTC you purchased for $13,000, now worth $28,000. If you immediately sold those, your net would be $28,000 – $13,000 – $14,000 = $1,000.

In this way, it would seem to me that when the market is in contango, it would be sensible to use as much leverage as you can support purchasing of the physical commodity (bitcoin), to maximize the multiple of premium you can earn.

What the experts say…

I asked a couple of my favorite Twitter friends for feedback on the above, and wanted to include their essential insight:

From @notsofast:

So you have basically described hedged futures trading, or time arbitrage. It’s worth noting that a lot of traders don’t want to tie up that much capital for that long, just to capture that premium, even though it’s low-risk. They would rather base trades on TA on either futures or spot, and have them unhedged or naked.

There’s also the inherent assumption that the premium, or your profit window, will stay fairly constant right up until settlement or your stop is triggered; in practicality, well-capitalized entities go stop hunting when market short or long interest is unbalanced (as we recently saw with the massive percentage of shorts vs. longs at bitmex). That is, they will push the spot market up higher to force these shorters to cover at their stop losses, then let the market trickle back (or in the recent case, violently return) back to where it was.

Sometimes the futures do not move correspondingly. So your conclusion about it being risk-free to leverage the maximum possible in order to capture that guaranteed premium, may be correct in theory but doesn’t account for manipulative decoupling in short term stop hunting tactics or periods of imperfect correlation between futures and spot (for instance intervening pivot dates like ETF approvals)

The implication is that the manipulators– or it could be, just better capitalized traders monitoring the market and pushing it in the directions they want– know that it will cost them less to buy up the market to trigger the cascade of forced buys covering shorts, than they’ll lose when the market falls back down again. So they buy the market up, provide the liquidity for the forced buys to either cover their longs in profit and/or enter shorts at even better pricing, and then let the market return to equilibrium. And when I say “manipulators” it’s not so much a tinfoil hat accusation as it is, a better capitalized player exercising advantage. It’s like a card game where a player with a hand full of trump suit can force wins out of every other player.

And from @paul_btc:

You can buy the spot btc and use it as collateral in bitmex to short futures, which makes the initial quantity needed less than $13.5k. Also, it could be that you in theory should earn money with the trade, but fees take away the profit or actually make you negative, if the price differential is not big enough. Always, always, always take into account the fees.

  1. Those links contain my referral code, so I’ll receive some benefit if you signup through those. 
  2. You won’t get exactly this premium, given that you’ll pay trading fees. 


Today I’m happy to announce the launch of a new website, and my team’s first contribution to the PIVX project — This article explains why we created it.

PIVX needs a website addressing the first-time visitor

I recently sent a friend who’s new to crypto to the PIVX website, where he was met with the following message, front-and-center:

NEW MANDATORY WALLET UPDATE Must update wallet now.

We all know how important first impressions are, and his was that perhaps the project is experiencing some kind of crisis. Within the home-page rotating slider, other messages he could have been met with include:

  • “Zerocoin+PIV. Privacy meets Proof of Stake.” — He would have no idea what any of that means.

  • “Built on Bitcoin Core. First Proof of Stake currency to use 0.10.x Bitcoin core at launch. Now updated to 0.15.x” — He would have been completely confused by that.

  • “Incognito. PIVX is the first truly anonymous PoS crypto-currency by utilizing Zerocoin Protocol as our Transaction Protocol” — He’d know what incognito means, but would have no idea about any of the rest.

  • “60 second block time. Already very fast, PIVX transactions using SwiftX are near instant with ZERO confirmation wait time required.” — He wouldn’t know what “block time” means.

The most important visitor to the PIVX website is the one who knows little about PIVX. Why? Because they are a potential new customer—if we can convert them. I don’t think we have are optimizing our chances of converting them with the current messaging.

To that end, the highest priorities of the website should be to:

  1. Communicate what PIVX is, in terms that assume as little technical (and acronym) familiarity as possible.

  2. Motivate them choose PIVX.

  3. Provide them with calls to actions which anticipate what they’ll want to do next.

My goal with was to create the website I believe should be the first point of contact between a potential new customer, and the PIVX project.

Build credibility

The second reason for building the site was to try to create credibility for my team within the PIVX project, since there’s a couple of projects we’d like to pursue:

  1. First, we’d like to build a desktop wallet for the masses. Not only would it be the best wallet in all of crypto, it would incentivize, especially new users, to choose PIVX.

  2. Second, we’d like to build a PIVX website that improves on the current information architecture, copywriting and design, as well as improving technical infrastructure.

Since I can’t present the professional work of my team without compromising my privacy, I wanted to actually build something that could serve as a taste of the quality we’re capable of producing.


With that as background, let’s talk about the website. The following were our goals:

  • We wanted tight and concise content, that communicates what PIVX is, as well as the tent-post aspects that collectively make PIVX unique among crypto currencies, in terms likely to be understood by as broad an audience as possible.

  • We want it to be initially text based, and particularly mobile friendly, so that the initial experience will be as fast as possible, and accessible on all devices.

All in all, we’re quite happy with the way it turned out. Technically, it’s built with Jekyll, a static site generator, and uses pretty much plain-vanilla HTML, CSS, JavaScript and SVG graphics.

Check it out today:

We hope the PIVX project likes, adopts and promotes the site!

How to protect crypto holdings on a Mac with plausible deniability

We all know that if you’re going to manage your own private keys, the best solution is a hardware wallet. But sometimes we may want to hold coins which are too new or too immature to have been integrated into hardware wallets, and in those occasions we need a secure way of storing those funds on our local computer.

For those using Mac OS X, this article describes a fantastic approach, that integrates the powerful concept of plausible deniability.

Introducing Espionage

Espionage is an application for Mac OS X that lives in the menu bar, and when clicked, presents the user with a simple window asking for a password:

When you enter a correct password, the window unlocks to display a list of folders that the user has added for control by Espionage:

From this list, let’s navigate to the “Confidential” folder in the Finder, and look at its contents prior to unlocking it in this Espionage list:

We see a single file called “my_innocous_file.png”, but this folder could just as well contain anything we wanted an attacker to see, if they hacked our computer, or otherwise coerced us into revealing its contents.

Now, having opened our password protected list in Espionage, let’s click to unlock the “Confidential” folder in Espionage:

And once unlocked, let’s return to the Finder and see what few find inside now:

We find completely different contents!

What’s happening behind the scenes is the following:

When we drag a folder into an Espionage list for management, the app creates an encrypted disk image, and moves the original contents of the folder into the disk image, after which it empties the original folder. You’re then free to put any innocuous contents into the folder you like.

Then, anytime you unlock that folder in Espionage, it will mount the encrypted disk image at that point in Finder, replacing the folder’s innocuous contents with the protected contents in the encrypted disk image.

Later, when you then re-lock the folder in Espionage, the disk image is closed, and the original innocuous contents are returned.

This means that for someone poking around your folders in the Finder, they’ll find innocuous contents, without any indication that you maintain a shadow version of the same folder, locked away behind a password-protected list in Espionage!

Plausible deniability

Espionage goes even further, by providing for plausible deniability. How does that work? Espionage is not only capable of maintaining a singe list of folders, behind a single password. Rather, it’s capable of maintaining any number of folder lists, behind any number of passwords!

This means that even if someone knows you have Espionage running on your Mac, there’s no way for them to know how many lists of folders you are actually managing. You can even manage two lists of identical folders, such that if you were coerced to open a list in Espionage, you could open an innocuous list, without the attacker knowing you have another copy of the same list behind a different password.

This is known as plausible deniability.

(And if you’ve cleverly asked the question, “But what if the attacker searches for the number of disk images on my computer?”, Espionage helps with this as well, by creating, on first launch, a large number of empty disk images, such that this search wouldn’t reveal the number of folders you’re actually protecting.)

Using Espionage to protect crypto holdings

Let’s now put Espionage to work to protect our crypto holdings. Most wallet apps store their data in the “Application Support” folder within your local “Library” folder. For example, the Ravencoin wallet stores its data here:

~/Library/Application Support/Raven

As you’re probably already thinking, you can create a protected list in Espionage that contains the application data folders for all your crypto wallets. I’ve created a test one here containing the data folders for my Ravencoin and Hexxcoin wallet data:

So if someone discovers that I’ve got the Ravencoin wallet on my computer, and coerced me to open it, they’d find an empty wallet:

And if I wanted to make things look more realistic, I could maintain a small around of RVN in this innocuous version of the wallet. Now, let’s unlock the Ravencoin folder in Espionage:

…and then re-open the Ravencoin app, to access our real data:


As you can see, an application like Espionage opens the door to a world of data protection possibilities, including everything from crypto data folders, to confidential documents folders, to more. I know someone who even keeps their entire email application data folder protected!

While our first line of defense will always be a hardware wallet, for those times when that’s simply not an option, Espionage provides us with the means to greatly increase the security of funds held directly on our Macs!

As you’ll have noticed from my previous articles, I’m transitioning from the world of traditional investing, to the world of crypto investing, and in the process am doing a lot of hands-on learning to make sure I understand the ins and outs of this space.

Through this blog, and for the benefit of new entrants to this space, I hope to write articles that simplify some of the complex topics that I’ve struggled with, including details that many others have glossed over or left out entirely.

I hope you’ve enjoyed this one about data security on a Mac, and if you have any questions or feedback, don’t hesitate to leave a comment below or email me through the contact form.