The What Bitcoin Did podcast interview with Roger Ver

I’ve been really enjoying following the “What Bitcoin Did” podcast, and watching Peter McCormack’s evolution as a journalist.

This week I was particularly excited to see an interview with Roger Ver appear in the queue, but having listened to it, I came away disappointed.

Roger Ver’s personal time, effort and investment were fundamental to Bitcoin achieving its take-off velocity, and in a real way we owe him gratitude for finding ourselves in a world that is going to benefit immensely from crypto currencies and blockchain technologies.

From my observation point, however, it seems that anchors of bitterness tied to the Bitcoin/Bitcoin-Cash split, and the circumstances surrounding that, have harmed his influence and creditability, and create tremendous friction in achieving the goals he wants to achieve.

While he could promote Bitcoin Cash on its own merits, every promotion of the currency is presented alongside a case against Bitcoin (Core). Not against Litecoin, DASH, or Monero; always against Bitcoin Core. Against that backdrop, it’s then hard to imagine he had no involvement in the sudden uptick in BCH propaganda from the @bitcoin twitter handle, or the Bitcoin(BCH) fiasco of’s explorer. It seems important to Roger to refer to the BCH/BTC fork as a “split”, instead of BCH going off on its own.

And he may well be right that BCH is truer to Satoshi’s white paper, but what’s important are Satoshi’s ideas; not who makes a claim to the name he created. We now live in a world in which anyone who has heard of Bitcoin, also knows it stands alongside many other currencies competing in the marketplace.

Given how fundamentally I agree with Roger’s worldview, and given the capability he has demonstrated in being able to further a cause, I find the current situation almost tragic. And my hope was that in the podcast, Peter was going to explore that idea.

But there is a journalistic fine line between exploring an idea, and arguing for one, and as the podcast played out, it became clear to me that Peter had fallen into the space of the latter. It seemed to me that, whether consciously or unconsciously, what Peter set out to achieve in the podcast, was to get Roger to acknowledge being mistaken about something. Anything.

This seemed apparent when Roger would state something universally agreeable, and legitimately relevant to his story, like that censorship is unforgivable given how fundamental free speech is to human progress, and Peter would respond almost instantaneously with, “Yeah, but…” Time after time. “OK, but…”, “Right, but…”, “Sure, but…” I don’t remember an occasion in which Peter seemed to pause, to actually contemplate what Roger had just said.

This isn’t meant to be a ding on Peter. One doesn’t become a Pulitzer winner overnight. And my disappointment isn’t that I didn’t like the interview. My disappointment, and the only reason I’m writing this, is that I felt Peter was working on a strategy that could have led to a great interview, and not just for Peter’s show, but perhaps transformational for Roger himself. And that’s the opportunity I felt may have been missed.

PIVX and the importance of privacy

Costly compromises in privacy always start innocently

Some years ago, the government of the country in which I reside passed a law requiring residents to declare their financial accounts located in foreign countries. Ostensibly, the purpose of this law was to support a new “wealth tax”—a small tax levied on one’s worldwide assets.

Although the wealth tax was economically trivial, failure to accurately report on such accounts would result in draconian fines, as well as potential criminal proceedings. Residents were assured by the government that their knowledge of these accounts would not be used for other purposes, but the imbalance between benefit of purpose and consequence of non-compliance felt ominous.

Later, as a resident with financial activities in other countries, I was subjected to a tax audit, which concluded in the revenue service making a claim against me that was contrary to international law, and the only way I could defend myself would be through appeal to international court. Not only would that path be expensive and complex, but if I chose to pursue it, the law required first paying the claimed amount, and then trying to have it returned through a reversal in court.

The revenue service pointed out that I shouldn’t bother even trying to argue that I don’t have the funds to pay, because they have access to the information I’d previously reported regarding foreign accounts.

Costly compromises in privacy always start innocently.

Governments love cryptocurrency

Having knowledge of a resident’s foreign financial accounts is useful to governments, but it’s not, in their perspective, ideal—because they don’t yet have systems in place to monitor the activities of these accounts, and information exchange between western countries is not yet complete.

For those reasons, governments still have to rely on their residents to accurately update their records periodically. Where I live, these records have to be updated annually, and reported changes of balance can be investigated.

While your first instinct might be that governments would fear a situation in which its residents begin shifting wealth from traditional financial institutions into crypto currency, they actually love the idea. Why? Because if they know the addresses on which you hold crypto wealth, they can perfectly monitor incoming and outgoing movements themselves on the blockchain.

And for that very reason, the country where I reside is discussing new laws requiring its residents to declare all addresses on which they hold crypto currency. And failure to provide those addresses, on an ongoing and complete basis, is subject to the same draconian fees and potential criminal proceedings as those covering the current foreign accounts reporting requirements.

PIVX and privacy

The fundamental currency of the PIVX network is the PIV, which is as transparent on its blockchain as bitcoin. The PIVX project, however, was born out of the importance of privacy, and implemented something called the “zerocoin protocol” that allows PIVX users to convert their publicly traceable PIV to and from a currency called zPIV, within their PIVX wallets.

The zPIV holdings of a PIVX user are anonymous. They are not associated with any addresses on a blockchain, and therefore can’t be viewed or monitored. Nobody other than the PIVX user themselves have visibility into their zPIV holdings.

And with this week’s release of PIVX version 3.1, the project further promoted privacy, by incentivizing users to convert their holdings to zPIV, as those anonymously held funds now earn an attractive rate of (anonymous) interest—upwards of 6% per year!

This capability has tremendous benefit for someone like myself. Specifically, if I hold wealth in zPIV, I can—without perjuring myself and becoming a criminal—refuse to provide any government with blockchain access to monitor that wealth—on the basis that it’s not technically possible. That is pretty profound.

Today, the community of people in the developed world directly affected by loss of privacy may be relatively small. But the world is changing, societies continue to cede privacy in the name of other values such as security, and the unexpected consequences of these sacrifices usually become apparent only once its too late.

For that reason, I’m thankful for projects like PIVX that work to provide individuals with the tools and technologies that support self-sovereignty and individual freedom.

The challenge of product design in open source crypto projects

Over the next few years, the crypto space is going to welcome a wave of new users coming for the benefits, but not necessarily with deep interest in the technology.

To onboard these people with minimum friction, and help them realize the benefits of crypto, among our top priorities today should be improvements in the usability of products such as wallets, and discovery of ways to communicate new paradigms in terms that are familiar and understandable.

Most crypto projects are open source, and evolve collaboratively. While providing for the essential properties of transparency and trust, developers are ultimately the gatekeepers, and in this article I’m going to explore how this can present some impediments to design progress.

Demonstrating the problem

To demonstrate my concern, I want to talk about a recent interaction with the developers of the PIVX project.

For context, you know that Bitcoin transactions are not private. DASH forked from Bitcoin, adding transaction mixing to provide a level of privacy through obscurity. PIVX forked from DASH to push further into anonymity, through the zerocoin protocol.

Common to both DASH and PIVX is that their wallets allow for sending both public and private transactions. And since privacy is at the core of both of these projects, the design of their respective wallets should prioritize making sure that user transactions are private, when they want or expect them to be. And particularly for a product named “Private Instant Verified Transactions” (PIVX), I would argue we should assume the user’s expectation is privacy.

Despite these design concerns, however, it’s actually quite common to hear the following complaint from people new to both DASH and PIVX:

I came to the coin for privacy, and just discovered that none of my transactions are private, because the default transactions are public!”

This problem is so widespread that even the hosts of the CryptoBasics podcast—a show intended to explain the basics to new users—were completely confused, and stated, “A great benefit of PIVX, compared to say, DASH, is that the wallet by default sends private transactions!” A member of the PIVX team had to join the show the following week to clarify that, no, that’s not the case.

Does this concern developers?

As a product designer, a misalignment in user expectation and product experience is a huge problem. In addition to errors, frustration and wasted time, such misalignment can ultimately drive our customers to better offerings.

In a previous article, I highlighted these problems within the context of the PIVX project, and proposed some mechanisms to help.

This article was circulated within the project, and a while later I was contacted by one of the core developers, who wanted to communicate a response he’d provided internally on the issue of “unexpected default behavior”:

Regarding “privacy by default” in terms of sending transactions: When a system offers multiple transaction types such as we do, the term default implies that given no user input of which to use, the program will make the decision for the user.

In this sense, we do not have any default, as the user is required to make a conscious decision otherwise no transaction is made. All arguments made about transactions not being “private by default” are born from a misunderstanding of the way default works in such systems.”

What concerned me with this comment is that, to me, it feels authoritative while, (in my opinion) completely missing the point. Why is that concerning? Because it’s hard to change someone’s mind, if their mind isn’t open to the possibility they’re wrong.

To my response that misalignment between expectations and experience is a very important problem, especially in the context of privacy, the developer wrote:

I’m not in total disagreement with you, but I will say that “expectations” with how a particular piece of crypto software operates are largely “inherited” (meaning that the expectation from one program to another remain the same) and this is nothing short of a falsehood in the expectations themselves. There are no grounds nor precedent to expect one program to perform exactly like another, even if said two programs are similarly related in field.

He believes the problem is with users, and their inherited and false expectations.

Feeling we were talking past each other, I tried to communicate my point through an admittedly non-perfect analogy:

Let’s say you install VPN software, and click connect. Later you learn your connection wasn’t private. You raise a concern that the product experience didn’t match your expectation, and you’re told you missed the setting to “Make connection private”. You say that that the default behavior in a virtual “private” network app should be privacy, and you’re told that there is no default, because you have a choice, and if you expected otherwise, then that’s a falsehood in your inherited expectations.

His response was that the analogy was largely irrelevant, but where it was, the problem is with users not having done their due diligence; particularly, not having read the documentation.

The case you describe is closer to a “not knowing” case, in which we provide abundant information on via the website and the technical papers that have been published. I’m not saying that the user is “at fault” per-say [sic], just that they have not performed due diligence into the product itself if their expectations match what you have stated.

So if their expectation is privacy, in a product who’s name is Private Internet Verified Transaction, then they clearly have failed to do proper due diligence.

He went on to say that the time for UI discussion had anyway passed, and raising these concerns now was doing more harm to the project than good. He pointed me to a closed GitHub pull request, representing the “UI overhaul” that had taken place for the forthcoming version 3.1 of the wallet.

I haven’t used version 3.1 of the app yet (since it’s not out), but looking at the pull request, it seemed to consist of little more than a developer changing the fonts, colors and spacing within the Qt wallet, and moving the tabs from the top to the side. When I pointed out that this “UI overhaul” was little more than an aesthetic makeover, his response was:

UI overhauls are usually aesthetic makeovers.

Point by point

Let’s start with the question of whether the product presents a choice to the user. When a user who wants to send some PIV opens the PIVX wallet, here’s the navigation structure they see:

As soon as their eye and mouse see the “Send” tab, we can expect they’ll conclude they found the place where sending happens. We can also anticipate that the user will expect if there are any decisions to be made about sending, they’ll find those choices in the “Send” area.

What we can’t expect is that it will occur to the user to continue exploring other areas of the wallet, looking for additional send features. In the case of PIVX, if the user wants to send private transactions, they need to first navigate into the “Privacy” tab. And since western users scan from left to right, we can expect that a user opening the app to send PIV won’t even see the Privacy tab!

So user choice in the PIVX wallet is obscured through a problem with UI hierarchy. If the default path through which 99% of users send a transaction doesn’t inform them that there actually is a choice to be made, then the product really isn’t offering a choice.

Next, let’s talk about the view that the user should be reading manuals—something completely antithetical to the end goal of every product designer on the planet. Put their products in front of users, and there is no clearer pointer back to the drawing board, than seeing a user get stuck and have to go digging into documentation.

Finally, let’s talk about the notion that a UI overhaul activity is “normally an aesthetic makeover”. Show the PIVX 3.1 “UI overhaul” to the community of professional product designers worldwide, and the response will be uniform—what we see here is putting lipstick on a pig. In the words of Steve Jobs, “Design is about how it works, more than what it looks like.”

What’s going on?

Fundamentally, there are two problems here:

First, there’s the problem that UI/UX design isn’t considered a discipline. To many, anyone with an aesthetic opinion is qualified to participate in product design.

This view, which couldn’t be further from the truth, is unfortunately widespread. When the DASH project posted the competing logo re-design candidates from Ogilvy & Mather and Tharp & Clark, fifteen minutes didn’t pass before considered conversation was overwhelmed with a flood of people posting their own logo candidates. Why pay those firms when I bought Corel Draw?

Second, in open source projects like these, the developers are ultimately the gatekeepers, as they are the ones who can commit code to the project repository. This means that the job of the designer is not only to create an effective user experience, but also to convince developers to agree with their views.

And developers tend to be people who are both capable of, and actually enjoy, managing complexity. They desire freedom through tools that are maximally configurable. It’s not in their nature to remove functionality in the interest of broader adoption. Why would we ever remove the ability to manage a “masternode server” from the product everyday people are supposed to use to send and receive crypto currency?

If you’re a developer, and actually interested in understanding this frustration, imagine the roles are reversed—that designers are the gatekeepers, and you’re trying to point out that implementing a state-machine through the human-natural approach of a nested if/then/else statements will eventually collapse at a certain complexity.

And to your argument that computer science offers a more reliable and maintainable implementation approach (although less understandable from a common-sense perspective) the designer replies, “Nah, I kinda like the look of this nested structure.” Or worse, he says something along the lines of, “If the state machine gets out of hand, it’s probably because you didn’t indent properly.”

At some point, you’d tire of talking, throw up your hands and say, “Listen, I’m sorry but this just isn’t a matter of arbitrary opinion!”

Where do we go from here?

So that’s where we are today. How do we move forward?

Well, we don’t abandon hope, because crypto is just too important. We need well-designed products in order to deliver the deepest level of benefits to the common person, and to adequately introduce them to a world of new paradigms.

We also don’t push against the open source model. That’s critical for trusted, verifiable and peer-reviewed software.

Somehow, we have to find a way to evolve the open source model to accommodate the role of product designers.

This will involve education. We have to get to a point where developers defer the product design role to designers, and come to believe themselves that effective design is as important as quality code. And they have to come to believe that product design is a discipline, involving principles and techniques that come through training, and involve depth of thinking far beyond surface aesthetic judgements and common sense.

It also involves people speaking up. In the PIVX discord, so many people sent private messages saying, “Keep it up! I agree with you! This is important!” What these people should do, instead, is express those opinions publicly. Let the developers know that this is important.

Finally, it will likely involve the emergence of tools that allow designers to do their job. These tools will come from those rare developers who are, themselves designers, and have the technical insight necessary to create design and prototyping tools that expose the services and capabilities of the underlying blockchain to the designers.

In the meantime, I plan to stop talking, and start sketching. Starting with the crypto wallet, my plan is to wireframe my take on the ideal product, and post it to the community for comment. Perhaps actually seeing a usable alternative to what exists, members in the community will rally around the idea of making it happen.

In consideration of those future users, like my doctor, neighbor and family members, I sure hope we get there!

Introduction to zPIV and zPIV staking in PIVX 3.1

One of the most exciting new features in PIVX 3.1 is the ability to privately stake zPIV, in addition to PIV. The term used by the project for zPIV staking is zPoS—which means “zPIV Proof of Stake”.

For existing PIVX users upgrading to 3.1 (currently at “build version”, perhaps the most common question will be, “How do I switch to zPIV staking?” This article attempt to answer that. We’ll begin with a refresher of some basics, though, and then get to earning rewards through staking!

Is zPIV a “coin” that’s different than PIV?

PIV is the coin/token/currency of the PIVX network. zPIV is also a token supported by the network, and in that regard, we’ll use the term “coin” in this article. Technically, it’s a “state” of the PIV coin, but since that can be a little hard to imagine, the PIVX project encourages people to think of zPIV conceptually as “casino chips”, i.e. something anonymous you switch into and out of from PIV, on a one-to-one basis.

(And for an essay on why that privacy capability is important, have a read of this.)

Can I transact in zPIV?

Absolutely, that’s the whole point — you can send and receive zPIV anonymously! Keep in mind, though, that although you may send someone zPIV, the recipient always receives and equivalent amount of PIV, not zPIV. On the blockchain, these received PIV appear as if they were just created. They have no history, and no information about the sender is revealed.

For me personally, I like to think of my PIV holdings as my PIVX “Checking Account”, and my zPIV holdings as my PIVX “Private Savings Account”.

What exactly is staking?

In a “Proof of Stake” network like PIVX, transaction blocks produced by the network are validated by the wallets of everyday users like you and I. For that reason, your staking wallet needs to be continually running, and connected to the internet!

When the network needs a new block validated, it randomly chooses a wallet for the job, and then awards some PIV to that wallet for its work. That’s how you earn PIV through staking! This is more energy efficient, and results in wider distribution, than miners in a “Proof of Work” network like Bitcoin.

Is staking safe, if I have to leave my wallet open?

Leaving your wallet open for staking is safe, as long as you have enabled “wallet encryption”. When your wallet is encrypted, any attempt to initiate a transaction will require the encryption password.

To unlock your wallet for staking, do “Settings” → “Unlock Wallet…” and before entering your wallet password, enable the “For anonymization and staking only” setting.

Why should I stake zPIV instead of PIV?

There are two main reasons:

  • Privacy — Like casino tokens, zPIV coins are completely anonymous, due to the “zerocoin protocol” on which they are based. Staking zPIV coins is likewise anonymous.

  • Higher earnings — While PIV staking remains an option, zPIV staking results in higher rewards, as 3 PIVs are awarded to zPIV stakers per validated block, as opposed to 2 for PIV stakers.

How much can I earn?

Staking wallets are chosen for block validation and rewards randomly, but weighted by the amount of coins being staked, and the time during which they have been staking. This incentivizes people to stake more, and stake consistently.

In general, though, it’s estimated that over the course of year, zPIV stakers will earn roughly 6.5%, while PIV stakers will earn 5.0%.

Can I stake both?

Yes! While staking is enabled in your wallet, both your PIV and zPIV balances will be earning rewards.

If I’m staking zPIV, do I receive zPIV as a reward?

Yes, the rewards are paid anonymously in zPIV.

How do I convert my PIV to zPIV

To stake zPIV, you need to convert your exiting PIV.

  • Manually — You can convert your current balance of PIV to zPIV manually by doing clicking the “Mint Zerocoin” button within the “Privacy” tab.

  • Automatically — You can make sure future received PIV are converted automatically to zPIV by enabling this setting. This includes both PIV sent to you by others, and PIV you earn through staking. If you wish to always retain a balance of some PIV, you can set the percentage you want automatically converted.

If you’ve currently been staking PIV, you might have configured the old wallet to disable zPIV creation with the enableautomint=0 setting in the pivx.conf file. If you’ve done that, don’t forget to remove that line and restart the wallet!

What is the option for the “preferred denominations” about?

Unlike PIV, which can exist as very small fractions, like 0.054, zPIV coins can only exist in certain whole denominations, like 1, 5, 10, etc. In the PIVX wallet settings, you can specify the smallest denomination you want to hold in your wallet, and this setting will influence the staking rewards you receive.

A larger denomination has a slightly higher probability of being chosen for a staking reward than a smaller denomination. However, once an “input” has been chosen for a staking reward, it doesn’t become available again for 220 blocks. The reward amount is fixed, however, regardless of the staking size. So even a 1 zPIV input, if chosen, would receive the same reward as a 5k zPIV input.

Imagine you held 5,000 PIV, and were thinking through your options for this setting. If you chose “5000” (and ignoring that there are some fees involved in the conversion process), you’d end up with one 5k input available for staking. That input would have the highest possible probability of being selected, but once selected, you’d have to wait 220 blocks to be eligible again.

If you set the auto mint denomination to 1k, then you’d have five available inputs for staking, each of which would have a slightly lower probability of selection than a single 5k input. However, when one of your inputs gets selected for reward, you still have four available for reward while the original one is waiting 220 blocks for its availability again.

I can’t find any analysis that has been done to determine the optimal strategy. In my case, I’m going to set the denomination amount to 1,000 and see what happens. I may play around with the setting from month to month, to try to determine how it affects the rewards.

For most people, though, the “Any” option should be just fine. In any case, this setting isn’t anything to stress about. 🙂

Go download 3.1 and get started!

And with that, we bring this article to a close. Be sure to download PIVX 3.1 now, and get to earning rewards through zPIV staking today! And if you have any questions, there’s a friendly team waiting for you in the #support channel of the PIVX Discord.

An introduction to PIVX and a proposal to help its user experience

In this article, I’m going to introduce the PIVX coin, along with its associated network, and propose some ideas for helping it become a leading cryptocurrency.

The history of PIVX

As readers will know, Bitcoin has some privacy deficiencies. For example, when you make a transfer, you expose the full balance of BTC held on the source address(es) used in the transaction.

DASH forked from Bitcoin, in order to (among other reasons) introduce the masternode-facilitated PrivateSend feature, which, in mixing transactions, provides some level of privacy through obfuscation.

Concern remained among some, however, that obfuscation can’t protect your privacy if someone with the resources of a nation state wants to determine who’s behind a transaction. To address this, PIVX forked from DASH with the goal of providing for deeper anonymity.

At the time of this writing, the project is within days of releasing version 3.1 of PIVX, and achieving both the goals of providing anonymous privacy, as well as providing the incentive for people to use those facilities.

The PIV and zPIV coins

The original coin of the PIVX network is called PIV. Transacting with PIV is similarly public to Bitcoin and DASH (without PrivateSend), in that all PIV transactions can be explored and traced on its blockchain.

The PIVX project innovated in the creation of a second coin supported by the network, called zPIV, which, existing in discrete denominations like casino chips, is truly anonymous.1

Using the project’s wallet, one can privately convert PIV into zPIV, and transacting in zPIV is completely anonymous for the sender—meaning that while the blockchain reveals that a certain number of PIV arrived at a public PIVX address, no information about the sender is revealed. (And if the recipient of those PIV then converts them to zPIV, their forward-going history will also remain private.)

The incentive to be private

With the forthcoming version 3.1 release of the PIVX wallet, network users will be incentivized to maintain their PIV holdings in the private zPIV format. For those who leave their wallets open, any zPIV balance can be “staked”, and earn PIV rewards.

What does this mean? PIVX uses a consensus algorithm called “Proof-of-Stake”. Unlike the Bitcoin “Proof-of-Work” network, in which miners validate new transaction blocks, in the PIVX network, “staking wallets” are randomly chosen to validate new transaction blocks, every 60 seconds. A given wallet’s chances of being selected for validation of a given block, and earning a reward, are increased as a function of the number of coins it holds, and the time over which it’s been staking those coins.

For each block that is validated, the network creates five new coins. If the validating wallet is staking zPIV, then it will receive three PIV, and a randomly selected masternode will receive two. If the validating wallet is staking PIV, then it will receive two PIV, and the selected masternode will receive three.

(There is a possibility of a sixth coin being created and awarded to the PIVX Treasury, which we’ll get to in a minute.)

So with the release of version 3.1 of the wallet, PIV holders will be incentivized to convert to zPIV, and through staking of those zPIV, participate in securing the network and earn rewards. I’ve been staking PIV for a while, and have earned close to 5% interest—considerably better than a USD savings account—and this should only improve with the release of version 3.1.

The tendency among people, especially in the US, is to give up their privacy under the idea they have nothing to hide. Trying to mass educate is a lost cause. But incentivizing people to be truly private, without having to convince them of the need for that, is a beautiful artifact of the zPIV staking system.

The PIVX Treasury

PIVX has a governance system in which anyone can make a proposal, and if accepted by vote of the masternode operators, the proposal can get funded. If an accepted proposal exists on the network, and is not fully funded, then a sixth coin will be created during each block validation, and transferred to the PIVX Treasury. This will happen until the Treasury holds enough PIV to fund all accepted proposals.

What does this facilitate in practice? When visiting the PIVX Discord, you’ll find support staff who are paid to help users with their questions. You’ll notice ongoing marketing activities that are funded through the Treasury. The developers themselves are paid for proposals to maintain and extend the system.

The PIVX Treasury system represents an elegant, decentralized, democratic method of funding the long-term maintenance and advancement of the platform.

The PIVX economy

Each time a PIVX transaction block is validated, up to six new PIV are created. In this way, PIVX is inflationary. Each time a PIVX transaction occurs, however, the transaction fees are burned (destroyed). In this way, PIVX is deflationary.

Whether the network is in aggregate inflationary or deflationary depends on the networks transaction volume, but we can see that by design the network isn’t ever inflationary—which is a good thing economically.

Where are we, and what’s the problem?

Considering the capability of privacy and anonymity, the ability for anyone to help secure the network and earn interest, the governance system and treasury, the sound economic model and the vibrant community, I’m optimistic that PIVX has the ingredients necessary to establish itself as a leading store of value and medium of exchange.

The current market cap of DASH is $2.8 billion, while the market cap of PIVX is $211 million. Just moving closer to DASH would represent a major return for PIVX investors today.

Not only are there structural reasons to make this happen—i.e. I know of no other cryptocurrency that offers what PIVX offers—there’s also a large economic incentives.

In my view, getting from where the project is today, to where it needs to be, fundamentally depends on positioning PIVX for the coming wave of new entrants to the crypto markets. These are people without much knowledge, and possibly not much interest, in how cryptocurrencies and blockchains work. But they are very interested in the benefits that crypto offers to them.

So what are the problems? In my opinion, the following needs to happen, in order of importance:

  1. Engagement and interaction — PIVX needs to deliver an amazing user experience in the wallet for the forthcoming wave of new users, and in this regard, it needs to expose interaction concepts in familiar terms those particular users will understand, and be comfortable with, if not excited about, engaging with. In particular, and fundamentally, the wallet needs to address the confusion those new users will likely have in understanding the differences between PIV and zPIV. I’ll expand on this in the next section.

  2. Positioning and information — This pertains to the PIVX website. The current website, in my opinion, overemphasizes the technology, e.g. “Zerocoin + PIVX = Privacy Meets Proof of Stake” (unintelligible without a lot of work), “Built on Bitcoin” (confusing), “60 Second Blocktime” (unintelligible without a lot of work), and its styling is consistent with that technology focus. I believe the coming wave of new users should be greeted by a friendly website that, in a friction-free way, explains the benefit of PIVX to them, in terms they can understand, and unequivocally motivates and helps them to get hold of, and use PIV. Of course, the technology details should be discoverable, but only for those motivated to look for them. I think the Stellar project do a good of this. Finally, the current website seems to be built on WordPress, using the popular DIVI theme. For a project of this importance, and given the various purposes it will eventually serve should the currency become mainstream, I would suggest building it on the developer-friendly CraftCMS.

  3. Branding — The current PIVX logo is typeset in capital letters. Perhaps that was chosen since it’s an acronym for Private Instant Verified Transactions. I believe a friendly, warmer, more engaging feeling would be transmitted to new users if the letters were set in lower-case, i.e. pivx. That feels cute, and sticky to me, and could look beautiful with a well-designed text treatment. Secondly, I think it would be great if the project’s logo could somehow transmit the dual-coin nature of the network, in order to help users become accustomed to this core concept.

The wallet experience

The first solution that comes to mind, to provide the experience that anticipates the context, background and needs of the wave of future PIVX customers (and benefits the current ones as well), is to introduce the metaphor of two “accounts”, presented in familiar terms, like “PIV Current Account” and “zPIV Private Savings Account”. With a simple distinction like this, we can communicate the potential for earning “interest” without having to introduce complex concepts like “staking”, and communicate that interacting with that account is the “private” part of the overall system.

This is just a starting point. There will be lots of challenges to address, including:

  • The wallet should include an on-boarding experience for first-timers, helping them understand how thing work, and where to purchase PIVX if they don’t have some.

  • It should address the potential confusion users may have with the concept that an account can have multiple addresses, and nail the UX around that.

  • The wallet needs to communicate that it has to be open to earn interest. As part of that, the wallet needs to communicate that it needs to be encrypted to make earning interest something that is safe.

  • To reinforce the the above, the wallet needs to clearly indicate when the Private Savings Account is earning interest (and not with an indicator that the “wallet is staking”.)

  • The wallet needs to communicate that earned interest is a statistical event, and, while we can report an average rate they can expect, emphasize that it will fluctuate.

  • We can build on the dual accounts metaphor, emphasizing that mobile wallets are extensions of the PIV Current Account. (Color differentiation between the accounts could help with this.)

  • Anticipating that people may want to store their wealth in zPIV, we’d want to ensure a means of hiding their balance (since the wallet will always be open.)

  • The wallet needs a UI hierarchy that only exposes advanced concepts like masternodes to those specifically searching for them.

  • Lots, lots more.

How can I help?

I’m associated with a world-class group of product designers, developers, and copy-writers, that is capable of delivering on the above points 1 and 2. Most of our work is for customers in the Bay Area, and our costs are consistent with that environment.

We could definitely contribute 100x in terms of the critical wallet user experience, and associated website, from where the project is today. (And based on my experience with many Qt wallet, it would be the best crypto wallet in existence.)

If the PIVX community believe that what I’ve outlined above could help establish PIVX as a leading cryptocurrency, and believe the investment would be worthwhile, then we would make the effort to submit a proposal for funding as part of PIVX Treasury activities.

  1. The nitty-gritty of zPIV can be found here

How to calculate mining profitability

In this article, I’m going to walk through an example of how to calculate mining profitability.1 It’s important to make this calculation when considering the rental of hashpower. In this example, I’ll be looking at the Haven Protocol coin, $XHV.

Calculating our breakeven cost

Platforms that rent hashpower usually specify the price in BTC per unit-of-hashpower per day, where unit-of-hashpower is whatever makes sense for the particular coin. In the case of $XHV, which uses the cryptonight-heavy algorithm, the hashpower unit is KH/s, or kilohash per second.

So what we want to determine is the breakeven cost of mining in units of BTC per KH per day.

We start with the data available at our pool. Almost all pools operate the same user interface software, so you’ll nearly always see a screen like the following, regardless of the coin you’re mining.

Now let’s make our calculation, assuming all variables stay constant over a period of a day (which they won’t, but we’ll get to that later). Remember, what we’re trying to calculate is the revenue in BTC per KH/s per day.

  1. Blocks per day — Our pool estimates finding a block every 11 minutes. There are 1,440 minutes in a day, so our pool should find 1440/11 = 131 blocks per day .

  2. Blocks per hashpower — Our pool has a total hash rate of 872.4 KH/s, which means our pool will be finding 131 blocks/872.4 KH/s = 0.1502 blocks per day per KH/s.

  3. Reward per block — The Haven network is currently rewarding 32.6 $XHV per found block.

  4. Earned coins per day — For each KH/s of hashpower, we’ll therefore be earning 0.1502 blocks/day * 32.6 XHV/block = 4.90 XHV/day. (You can double-check this number using the pool’s calculator, but it’s good to understand how it’s determined.)

  5. Revenue per day — For each KH/s of hash power, we’ll therefore be earning 4.9 XHV/day * 0.00007329 BTC/XHV = 0.000359 BTC/day

And there we have it, our breakeven hash power cost for mining $XHV on this pool is 0.000359 BTC/day.

Should we rent hashpower?

With that figure in hand, let’s go see if it makes sense to rent hashpower to mine this coin. At one site, here are the rigs which are currently available for mining the Cryptonote-Heavy algorithm:

As we can see, the lowest cost per KH/day is 0.00049 BTC which is above our breakeven cost. Therefore, it would not be profitable to mine this coin.

So the only case in which it’d make sense to rent hashpower to mine this coin, under these conditions, would be if we couldn’t outright purchase the coin elsewhere, and we expected the price to appreciate.

What can change?

Let’s imagine you’ve made your analysis, the rental cost is below your breakeven point, and you’ve booked a day of hashpower. What can change?

  • Your pool’s net hash rate can change as other miners enter and leave. An increase in hashpower should result in more blocks being found by your pool per day. Likewise, a decrease in hashpower should result in fewer. In the former, you’ll be receiving a lower percentage of a higher number, and in the latter you’ll be receiving a higher percentage of a lower number, and hopefully the result would be net-neutral for you.

  • My understanding is that proof-of-work networks dynamically adjust the mining difficulty in order to keep the average block discovery time constant. That’s how we can pretty accurately predict when the last bitcoin will be mined, as its average block time should remain 10 minutes. In the Discord chats, some claimed to have heard of coins that change block times. If that’s the case, then such a change during your rental period could affect the breakeven cost.

  • The market value of the coin could change as well, which, everything else remaining equal, would either raise or lower your breakeven cost.

  • Finally, the value of the denominating currency bitcoin could change.

So the breakeven calculation is an initial condition that could change during the term of your rental, and so the difference between what you’re paying and your breakeven represents a margin of sensitivity to those changes.


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 mining profitability, and if you have any questions or feedback, don’t hesitate to leave a comment below or email me through the contact form.

  1. Shout out to Haven Discord user @tomfer and legendary miner @notsofast for their help with this article. 

Unchained Capital and the future of crypto lending

This morning I listened to one of the back-episodes of The Flippening Podcast during which host Clay Collins interviews Dhruv Bansal, founder of Unchained Capital.

Unchained Capital is a company that will lend you US dollars, using your bitcoin holdings as collateral. Why would you want to do that? A key motivation is to avoid the tax liabilities one faces when selling highly-appreciated bitcoin.

Unchained require you to provide twice the amount of the loan value in BTC, and charge an interest rate, including all fees, of between 10% and 14%. The default terms allow you to make interest-only payments during the loan period, with a balloon principal at the end. If the value of your BTC drops to 150% of your loan value, they ask you to provide more collateral—what they refer to as “collateral maintenance”—and if BTC drops to within 110% of your loan value, they have the right to consider the loan in default, sell your BTC, return the principal, and pay you anything left over.

So this all sounds great.

I became particularly intrigued, however, when the conversation turned to the advanced custodial systems that Unchained Capital are developing. A while back, I posted an article outlining my ideal cold storage solution—something that doesn’t exist today.

Considering those two things together, I began imagining the ideal Unchained Collateral product I’d love to have available:

  1. I would hold two wallets with Unchained, a personal wallet and a collateral wallet.

  2. The personal wallet is where I keep all my personal bitcoin holdings. It’s my cold storage solution, and checks as many of the boxes in my previous post as possible. Unchained holds one of the keys to this M-of-N multisig wallet.

  3. Based on my personal holdings, Unchained extends a pre-approved line of credit to me.

  4. Whenever I need US dollars, I simply make an online request that involves signing a transaction to transfer the required amount of bitcoin to the collateral wallet.

  5. My Unchained account is ACH linked to my bank account, so that once I complete the request process, my funds can be immediately transferred into my bank account.

  6. Since my bank account is linked, I have an option such that my interest payments are auto-debited from my account.

  7. When I want to pay off the principle of my loan, I login to my Unchained account, and can initiated a “settlement” transfer precisely for the outstanding principle and interest (the amount of which, is conveniently pre-calculated for me.)

  8. If collateral maintenance is ever required, I get an email asking me to sign into my personal wallet, and authorize the necessary transfer to the collateral wallet.

  9. As my track record on the platform builds over time, I earn improving interest rates, incentivizing me to become a long-term customer.

This would be a beautiful solution, that solves my cold storage challenges, while at the same time providing me a line of credit, the use of which couldn’t be more convenient.

My ideal personal cold storage solution

After listening to the Unchained podcast episode this week with Mike Belche of BitGo, I got to thinking about my ideal cold storage solution, which as far as I can tell, does not exist today.

Here’s how it would work:

  • Multi-sig, if possible — The solution would be built on multi-sig technology, so that I don’t have to trust the service provider. This is not a hard requirement. If to implement the other features required custodianship for technical reasons, and if I was comfortable with the provider’s security architecture, I might consider it anyway.

  • M-of-N signatures — The wallet would require m-of-n signatures for transactions. I would require two of, say, five. I would specify Friends A, B and C as signatories on the account.

  • Collusion prevention — Signatories have no account visibility, and are selected for notification only when I perform a transaction. Generally, I would only request Friend A to sign. This helps prevent collusion, as Friends A, B and C don’t know about each other’s participation in my account. In fact, Friends B and C don’t even know they are signatories on the account unless and until I choose to notify them (say, Friend A passes away.)

  • Privacy — When a signatory is notified that I’ve requested their signature on a transaction, details about the transaction are not visible to them. They never know my balance, nor the amount of transactions.

  • Time delay — I want the option that any time a transaction is authorized, there’s a 24 to 48 hour delay, during which I’m notified and have the possibility to cancel.

  • SafeSend — Above a certain threshold, the service will first make a small transfer, and wait for me to confirm before sending the rest. This prevents accidentally entering the wrong destination address.

  • Duress — Unrelated to the service, but I would establish a duress code with Friend A, in case I contacted him, well, under duress.

  • Inheritance — On each signatory, I can set a flag, “Notify on inheritance”, the use of which is explained below.

  • Dead-man’s-switch — The provider would offer a “dead-man’s-switch” service which emails me every two weeks asking if I’m alive. To respond, I just click a link; no login required (this has to be frictionless).

  • Trigger — The service continually tries to contact me for two weeks. If I don’t respond, the switch triggers and “Notify on inheritance” signatories are notified and given admin rights to the account. They also receive a pre-written message from me. (I would PGP encrypt that message, since it would be stored on the provider’s servers.)

  • Independent recovery — The service would have to provide a means by which I could recover my funds, should something happen to them. It must not be possible for the provider to freeze my funds.

  • Backup key — The system would provide for a backup key, similar to how BitGo does this today.

From what I’ve seen, BitGo is the closest today to providing something like the above, though they are still far away from providing this particular solution. Other candidates would include Xapo and Coinbase.

Fingers crossed.

Crypto Taxation

Crypto taxation is a hot topic in 2018, given the growth of the space, and dramatically appreciating prices, over the past few years.

There have been some good discussions of the topic, including Laura Shin’s Unchained podcast episode with Tyson Cross and Jason Tyra, and last week’s Crypto Street Podcast, with guest @CryptoTaxGirl. While these were both quite informative, there were some points I felt needed expansion, clarification and additional emphasis, and so I decided to finally write-up and post the general article I’ve been procrastinating on.

(Update: Don’t miss the new section added at the end, with links to good articles I’ve discovered since posting this one.)

Take crypto taxation seriously

I’ve come across two camps of people exposed to crypto taxation risks:

  1. Those banking on anonymity — Betting on staying anonymous with your crypto, or pleading ignorance as a Plan B, is a huge risk. If your anonymously-held crypto ever hits the fiat system, you will no longer be anonymous. If you purchase something conspicuous, you will no longer be anonymous. If your crypto was purchased with sources identifiable to you, it will become increasingly likely, with the emergence of better chain analysis tools, that your activities will be closely scrutinized.
  2. Those unaware they’ve had taxable events — These are the folks who didn’t realize that a crypto-to-crypto trade results in a taxable event.

In either case, if it’s discovered that you’ve failed to report taxable events, you will run the risk of costly penalties, costly professional help, costly loss of time, and even the risk of criminal prosecution for fraud or tax evasion.

You do not want to find yourself on the wrong side of an audit, so take crypto taxation seriously.

We’re flying a little blind

While there hasn’t been guidance from the IRS on crypto since 2014, the crypto space has advanced significant, and so on nascent issues like, “when did you receive your forked coins, the day the project forked, or the day you extracted them?” we simply have to take our best, informed guesses as to the approach we take on recognition.

But taking action, on your best informed guess, is far better than taking no action at all.

The IRS treats crypto as property

This means that when you sell it, you will be liable for either short-term or long-term capital gains, based on the value at which the crypto was bought and sold, and the time it was held. If you held the crypto for more than a year, you’ll pay long-term gains, which for most people will be 15% under current laws. If you held your crypto for less than one year, you’ll pay something closer to personal income tax rates.

Use an automated service to keep track of your activities

This is a no-brainer. Given the disparate export formats of the various exchanges, the need to track changes in accounting method from year to year and the need to determine the fair-market USD value of crypto-to-crypto trades, it’s essential to use an online service like or to track your crypto activities.

These services integrate via API directly to most of the common exchanges, and support manual entry and CSV data uploads for everything else.

As regards complete and accurate record-keeping, don’t forget the following:

  • Some exchanges limit records export to, say, a period of one year. It’s therefore important to be diligent about downloading and importing your records promptly, before they’re gone.
  • Some exchanges, like ShapeShift, don’t provide records at all. It’s therefore important to enter these transactions manually when you make them, including the transaction URL in the notes field to provide evidence of the transaction.
  • When considering the use of a DEX (decentralized exchange), be sure to first confirm that it supports the export of trading records, and confirm for hold long records are kept.
  • Don’t forget to report earnings from staking, masternodes and other sources of crypto passive income.

Masternode & staking rewards are income

Staking and masternode rewards are considered income at the time they are received. If you do you not immediately exchange them to fiat, then they simply are treated as property moving forward, with a cost basis equal to their income value at the time of receipt.

Cryto-to-crypto trades are taxable events

Perhaps the most widespread problem in the crypto space, as regards taxation, is lack of awareness that a direct crypto-to-crypto trade (like BTC → ETH) is a taxable event. Such a trade is treated as if you sold BTC for USD, and then bought ETH. At that point, your sale of BTC is taxable based on the amount of time you held it, and the price at which you purchased it, known as your tax basis.

This also means you need to track the fair-market value of the BTC at the time of the trade! As mentioned above, an indispensable feature of the online services is that they will automatically asses and record the fair-market value of the selling half of the traded pair.1

Like-kind exchanges

Recently, there has been much discussion about the use of “like-kind exchange” laws (also known as “1031 exchanges”) to claim that crypto-to-crypto trades can be tax-deferred. Since crypto is considered as property by the IRS, the idea is that like-kind exchange laws—that allow for the non-taxable exchange of certain kinds of property—may be applicable to crypto-to-crypto trades.

First, from 2018 onward, this is clearly disallowed, as the 2018 tax reform included clarification that like-kind exchanges are only applicable to real estate.

So the only question is whether to declare like-kind exchanges on crypto trades made in years prior to 2018. I’m not a tax professional, but I engage with some good ones, and their strong opinion is that it’s likely not a good idea, for two reasons:

  1. You can’t just declare a like-kind exchange, and be done with it. You have to present argumentation, and a like-kind exchange is anything but obvious. Just as gold and silver are not considered like-kind, bitcoin and ethereum could arguably also be considered sufficiently different to exclude them from 1031 applicability. So at minimum, you’ll be faced with the professional costs of preparing your 1031 justification.
  2. Then, if the IRS doesn’t accept your claim, you’ll be faced with the costs of defending your position, and potential penalties if you lose.

These risks have to be weighed very carefully, if deciding to claim like-exchange for years prior to 2018.

Accounting method

The only point of contention I had with the Crypto Street episode, was the statement that the coffee you buy today, is paid with the bitcoin you purchased in 2011, due to a requirement to use the FIFO (first-in-first-out) accounting method.

The reality is that, as long as you keep careful and accurate track of things, you can use any accounting method you like, and choosing one over another can have a huge impact on your current tax liabilities.

In this regard, and important feature of the online tracking services is that they will actually show you which method is optimal for the current year, highlighting it green:

And an even more important feature, is that they’ll keep track of the fact you claimed LIFO on that little BTC purchase in 2016, HPFO on that other one in 2017, and FIFO on that one in 2018.

How to treat a fork

The IRS hasn’t provided guidance on this, but there are two possibilities.

  1. Forked coins should be treated as the receipt of zero-basis property. (This is how, for example, newborns of farm animals are treated.)
  2. Forked coins should be treated as income, with a fair-market value for the basis moving forward.

It seems highly probable that the correct recognition is zero-cost basis, and that an income approach would be unfair and simply unworkable.

  • In the zero-basis approach, the question of when you received your forked coins is only relevant to the determination of long-term vs short-term applicability. If they were treated as income, the question of whether you received them at the time of fork or at the time of receipt becomes important, as it relates to the determination of the fair-market value. If at the time of fork, then all forks of a project should be treated as income, whether or not you received them, and whether or not you even knew about them.
  • In the zero-basis approach, we don’t have to answer the question of the fair-market value of the coins when they were received, since it will be zero. If they were treated as income, determining the the fair-market value would be very difficult, especially for obscure forks that aren’t quoted. Income treatment would also be unfair to the owner of a coin with a high value at inception, but dropping before the owner had a chance to sell them.

So it really seems that an income approach would be unworkable, and that a zero-basis receipt of property is the better claim to make.

(Update: Here is an interesting article analyzing the tax treatment of a fork, and leaning towards an income classification. The arguments are solid, but I still find it hard to be tenable, for the reasons listed above.)

Risk of double-taxation for expat Americans

The United States is the only country in the world that taxes its citizens regardless of residence. So if you left the US to do your crypto transacting in another county, you will be liable for both taxation in the country where you’re resident, and the United States.

And even though the USA has dual-tax treaties with most countries, you are especially at risk of double-taxation with crypto, since there is diversity among countries in the “concept” of crypto. Many countries, for example, tax crypto as currency, and may not extend double-tax protection if you’ve paid property capital gains tax in the United States.

Move to a tax haven?

If you’re American, it doesn’t matter where you move, as the US taxes its citizens regardless of residence. The exception is Puerto Rico, in which, as a resident, you are subject to Puerto Rican taxation, rather than mainland US taxation. But even then, it’s widely anticipated that the IRS will have keen interest in claiming tax on the gains one’s crypto experienced prior to the change of residence. This remains an open question.

Renouncing US citizenship is an option, but then you have to research whether you’ll be considered for the exit tax, and weigh all the non-financial trade-offs of giving up that passport forever.

And if you’re European, the situation is always much better, unless you’re lucky enough to be living in Germany, where there is no long-term capital gains tax on crypto! For other countries, some have laws stating that if you move to a country considered to be a “tax haven”, you can remain liable for taxation in the former country for up to 10 years.

A difficult future ahead

If the area of crypto taxation has some ambiguities today, the situation is likely to get even murkier in the future. How will ICOs be taxed? What about participation in synthetic products like the Prism Portfolios, or the Abra mobile app, which don’t involve directly holding crypto at all, but rather involve the collateralization of Smart Contracts that aren’t even denominated in USD? What tracking and reporting burdens will be expected of the taxpayer, when we live in a world of thousands of token-to-token exchanges happening daily in automated, machine-to-machine systems, in which the tokens serve utility but at the same time are “valued”?

One thing we can depend on is that the advancement of crypto will far outpace the tax authorities’s abilities to keep up with clear guidance. And unfortunately, that means early adopters will, as always, bear a disproportionate amount of the pain and costs, defending themselves in ambiguous situations, and establishing the case law that will benefit all those coming later.


As you’ll have noticed from my previous articles, I’m transitioning from the world of traditional investing, to the world of crypto investing. I hope to use this blog as a platform for publishing my experiences and the things I learn along the way.

Crypto taxation is like going to the dentist, something we’d like to avoid, but better addressed earlier rather than later, and in this article I hope to have provided quite some food for thought and consideration. I hope you’ve enjoyed it, and if I’ve left out anything you’d like to see included, just post a comment below.

Additional reading

  1. If you use, it is critical to understand that their tracking of daily average cost is only up-to-date as of the previous day. So if you import, today, the crypto-to-crypto trades that you made today, resulting in the sale of BTC, then the website will use yesterday’s BTC price. That can be very costly, given the volatility of the crypto market. So just remember to wait a day before importing your transactions to the service. 

Beginner’s guide to setting up and operating a masternode

In a previous article, I discussed three options for earning passive income in the crypto space, one of which was the running of a masternode.

When I first got into crypto, running a masternode seemed like something beyond my level of expertise. What I eventually discovered, though, was that the problem wasn’t my level of expertise; instead, it was knowledge assumptions made by tutorial authors, and the glossing over of important concepts and details.

In this article, I’m going to explain the basic concepts, and walk the reader through the detailed setup of a masternode, such that he or she will hopefully be able to do the same with minimal assistance.

In short, this is the article I wish I’d had, when getting started!

Fundamental concepts

A masternode provides services to its blockchain network. For example, PIVX masternodes facilitate transactions that are private. Operators of masternodes are required to stake, or lock-up, a specific number of coins. As compensation, masternode operators receive periodic rewards.

Since a masternode is an operational component, and therefore needs to be available at all times, it’s usually best to run a masternode on a virtual private server, or “VPS”.

Since storing your coins on an internet-connected server wouldn’t be a good idea, masternoding allows you to store your locked-up coins offline on your local machine, in the project’s wallet.

Overview of the process

Following is a high-level overview of the procedure for setting up a masternode:

  1. Setup a VPS — Create a VPS, and install the blockchain project’s node software.
  2. Setup a local wallet — Download and install the project’s wallet on your local computer.
  3. Send some coins to yourself — Transfer the project’s minimum required coins into the local wallet. In the case of PIVX, that’s 10,000 coins. Within the local wallet, create a new receive address, and send the required number of coins to that address. By sending precisely this number of coins to a new address in the local wallet, it will recognize the availability of those coins for masternoding.
  4. Generate a private key — Within the local wallet, generate a masternode private key.
  5. Tell the local wallet about the server — Add your masternode private key, along with some other data, to your local masternode configuration file.
  6. Tell the server about the local wallet — Add some information, including your masternode private key, to the server’s configuration file.
  7. Restart everything — Restart the server software and local wallet, and enable the masternode.

Conceptually, that’s it! We’ll now walk through the detailed process of setting up a PIVX masternode. Once you’ve done this for one project, it’s almost trivial to do it for any other.

Before moving on, here’s a couple additional points to mention:

  • While masternoding, your staked coins will be locked up in your local wallet, unavailable for spending.
  • If your project supports staking, like PIVX does, any surplus coins in your local wallet can still be used for staking. (That would require your local wallet to be permanently online, however.)
  • You can support multiple masternodes with a single local wallet, by following the same procedure outlined here, but on a new receive address, and a new VPS.

Setup a VPS

To run a masternode, you need a VPS with at least 1GB of memory, which means you can select the $5/month option at a provider like DigitalOcean.

Two important points when setting up your server:

  1. Be sure to choose Ubuntu as the OS, so we can connect it to ServerPilot.
  2. Be sure to include your SSH key in the process of creating the server, so you can later login as root without a password. (For my masternodes, I just use the root user.)
  3. Be sure to enable automatic backups. This adds about 20% to the server cost, but is worth it.

Connect the VPS to ServerPilot

ServerPilot is a great service, which connects to all your VPSs, and maintains them with security updates and patches for free, allowing people like me, with little system administration skills, to operate servers. (Beyond security updates, you can use ServerPilot to setup and mangage WordPress and PHP sites, and the paid version gets you SSL, graphs and other features.)

Although ServerPilot promotes their integration with DigitalOcean, they actually can manage any Ubuntu server, such that if you choose another VPS provider, as long as you install Ubuntu, you can have ServerPilot manage it.

When connecting a new server at ServerPilot, you’ll see the following screen. If you added your SSH key to your DigitalOcean server, then by default root password login will be disabled, so you’ll need to check that box.

Submitting the form, you’ll then see a screen containing some unix commands:

Copy the complete contents of the unix commands to your local computer’s clipboard, and then paste them into your VPS, after logging in as root:

ssh [email protected]<vps_ip_address>

After pasting in your ServerPilot commands, you’ll soon see the ServerPilot website screen come to life with an indication that your server has successfully phoned home, and you’ll watch as ServerPilot completes its setup.

BTW, if you decide to use ServerPilot, and like this article, consider signing up with my referral link, and I’ll get a small credit on my account there.

Install a local SFTP client

For local editing of the remove VPS files, we’ll want to use a local SFTP client. On my Mac, I use Transmit. Be sure to create and test a connection to your VPS, logging in as root.

Install and setup the local wallet

Download and install your project’s local wallet software, which, as a general curiosity, is usually based on the “Qt” framework. Launch it and do the following:

  • Allow it to fully synchronize with the network.

  • Encrypt your wallet by going to the menu Settings → Encrypt Wallet

  • In the wallet options area of the settings, enable the “Show Masternode Tab” and “Coin Control”:

  • Be sure to backup your wallet file with the menu File → Backup Wallet.... Remember that most Qt wallets are not hierarchically deterministic, so you’ll need to create a new backup whenever you create a new receive address.

  • Finally, be sure that your wallet has, at least, slightly more than the minimum required coins for your masternode, e.g. 10,001 for PIVX (which requires 10,000).

Setup the masternode

Now we get to the fun part! I’m going to walk you through the process of setting up a PIVX masternode. Although the terminology may slightly differ in other projects, the approach should be nearly identical.

Step 1: Generate a new receive address

In the local wallet, enter the “Receive” tab and create a new receive address by entering any label you like, and clicking the “Request Payment” button.

On the next screen, click the “Copy Address” button, to copy your new address to your clipboard.

Step 2: Send coins to yourself

In the local wallet, enter the “Send” tab, and paste your receive address into the “Pay to” field. If you copied and pasted it correctly, the label you previously created will appear in the label field.

Step 3: Generate your private key, transaction hash and index

In this step, you’re going to generate three pieces of data you’ll need related to your new masternode. For all of these, you’ll need to be in the local wallet’s “Debug Console” which you can get to from the menu, Tools → Debug Console

First, generate your masternode private key, with this command:

masternode genkey

…after which you should see a long string appear, which is your private key:

Note down the private key, as you’ll need it later.

Next, generate the transaction hash and index that serve as proof of the transfer of coins you made to yourself:

masternode outputs

You’ll then see something like this:

Note down the transaction hash and the index, as you’ll need them in the next step.

Step 4: Update your local masternode configuration file

We’re now going to enter some information into our local masternode configuration file, that will allow our wallet and the server software to recognize each other.

To open the masternode configuration file for editing, access the menu Tools → Open Masternode Configuration File. In that file, you’ll want to add a single line (for each masternode you run), in the following format, with all fields separated by a space:

<mn_name> <vps_ip>:<port> <private_key> <trans_hash> <index>


  • mn_name — is any name you want.
  • vps_ip — is the IP address of your VPS.
  • port — is the port on which your masternode will communicate with others. This will be project specific; for PIVX it’s 51472.
  • private_key — is the masternode private key you generated earlier.
  • trans_hash — is the transaction hash you generated earlier.
  • index — is the transaction index you generated earlier.

For PIVX, my masternode configuration file might have a line like this:

mn1 123.456.789.012:51472 Lkj23lkj438s9d78sdf879sd0980fsdf0s98sad9a87dadsa9ds Dfg98d7f9d7f9g79d7gd97gdfs09d8f0s8df6d876sd87fs8s8df8df8g0d8s08d 0

Before moving on to the next step, be sure to also do the following:

  • Quit and restart your local wallet.
  • Unlock your local wallet with the menu item Settings → Unlock Wallet...

Step 5: Install the project node software on your VPS

We’re now going to download the project’s node software to our VPS. After logging in as root, make sure you’re in your home directory:

cd ~

Now we need to download the software. You’ll want to find the URL to the x86_64 linux version, for the latest release of the project’s software. You can find that by visiting the project’s GitHub repository, and navigating into the “Releases” area.

Once you have the URL, use the unix wget utility to download it. The command will look something like this:


When the download finishes, unpack it with a command like this:

tar -zxvf project-x86_64-linux-gnu.tar.gz

Step 6: Understanding the project’s software

Before moving on, let’s quickly overview some relevant bits and pieces of what you just downloaded. Once you’ve unpacked and run your project’s node software—and don’t worry, I know we haven’t run it yet!—we’ll be working with the following directories, utilities and files:

  • Executables directory — This is where the project’s application software resides. For the current version of PIVX, it’s:


  • Server daemon — Located in the executables directory, this is the actual server application, and almost always end in ‘d’, since it’s known as a daemon. For PIVX, it’s:


  • Command-line interface — We’ll use this application to interact with the daemon, e.g. telling it to shut down, or asking for its status:


  • Data directory — This is where the software’s configuration files and local data are stored. For PIVX, it’s:


  • Project configuration file — Located in the data directory, this is the file that contains the configuration for the application software. For PIVX, it’s:


There are many other files in the data directory, but for masternoding according to this procedure, we won’t be interacting with them.

Step 7: Configuring the server software

We’ll now configure the server software.

Since we haven’t yet run the software, we’ll start it, so that it will create its data directory:


This should fail, since the data directory wasn’t present, and therefore no configuration file would have been found. If it doesn’t, you can quit the server software with ctrl d

We’ll now use our local SFTP clientTransmit, in my case) to connect to the server, and open the project configuration file for editing:


What goes in the configuration file might vary slightly from project to project, but here’s the PIVX contents (with some placeholders):


Here’s what you need to know:

  • rpcuser — This can be any random string, e.g. pivxmasternode
  • rpcpassword — This can be any random string, e.g. ju83FRT98Iuh64
  • masternodeaddr — Your VPS IP address is followed (after a colon) with your project’s port. This is the port on which your masternode will communicate with other members of the network.
  • masternodeprivkey — This is the masternode private key you generated earlier. It allows authentication between your local wallet and your masternode software.

Once you’ve finished editing your configuration file, save and close it.

Step 8: Start your masternode

We’ll now start the masternode on both the VPS, as well as our local wallet.

  • On the VPS, we start the daemon software:


  • In the local wallet, in the Masternodes tab, right-click on your masternode entry, and choose Start Alias.

Step 9: Check the masternode status

After step 8, you should allow some time, perhaps 20 minutes or so, for everything to sync and settle, after which you can check the status of things both on the server and the local wallet.

On the server, we’ll interact with the command-line utility:

~/pivx-3.0.6/bin/pivx-cli masternode status

If things are OK, we’ll see Masternode successfully started:

In the local wallet, in the Masternodes tab, we should see our masternode with a status of Enabled:

If everything looks good, congratulations, you’re now running a masternode!

  • You can now close your local wallet, as it doesn’t need to remain open.
  • Depending on the project, you should soon start to see rewards flowing into your local wallet. (For PIVX, it can take four or five days.)

Miscellaneous topics

Before concluding the article, here’s a couple of miscellaneous topics you should be aware of.

Remember, your coins are locked

If you click the “Coin Control” button in the “Send” tab of your local wallet, you’ll see that your masternode coins are locked, and will remain that way while your masternode is operational.

Unlocking your coins

If you want access to your coins again, you’ll need to do the following:

  • Stop the masternode software on the VPS:

~/pivx-3.0.6/bin/pivx-cli stop

  • In your local wallet, edit your masternode configuration file, removing the line you entered in step 4.
  • Restart your local wallet, at which point your coins will be available for spending.

Monitoring your masternode

I run several masternodes, and have created a Keyboard Maestro macro on my Mac that runs each 30 minutes, checking that my masternodes report correct status, and checking that they are running on the correct chain. (Chain checking is more relevant to new projects, that don’t have strong networks, and frequently fork.)

If you happen to run Keyboard Maestro, you can download my macros here. You’ll need to edit the server variable with the IP of your VPS.

If you don’t run Keyboard Maestro, and want to setup something yourself, here is the basic logic:

  • Query the server’s masternode status, and grep for the success string.

ssh [email protected]<server> "~/pivx-3.0.6/bin/pivx-cli masternode status"

  • Grab the current HTML from the PIVX block explorer:


  • Grep to extract the hash of the latest block, using this regex:

Block\ Height:</th><td>([^<]+)<([^B]+)Block\ Hash:</th><td>([^<]+)

The latest hash will be found in \1 and the hash of the latest block will be found in \3.

  • Grab the hash of the latest block from my masternode.

ssh [email protected]<server> "~/pivx-3.0.6/bin/pivx-cli getblockhash <latest_block>"

  • Compare the two hashes. If they are different, then our masternode is off-chain, and needs to be re-synchronized, which involves stopping the server, deleting some files, and restarting. (My Keyboard Maestro macro handles that task as well.)

To re-sync, between stopping and starting the node software, here’s the command for deleting the files. (Thanks to moocowmoo of the Dash project for dramatically shortening the command I previously used):

ssh [email protected]<server> "cd ~/.pivx ; mv wallet{.dat,.k} ; rm -rf *.dat *.log blocks chainstate ; mv wallet{.k,.dat} ;"

Finally, if you ever need to confirm the version you’re running:

~/pivx-3.0.6/bin/pivx-cli --version


If this is your first time setting up a masternode, you’ll probably run into some hiccups. (Hopefully less than I did, with the available of this article!). If you need help, here’s two recommendations:

  • You can feel free to contact me, either by posting a comment on this article (which might help others), or emailing me through the contact form.
  • Most projects have a Discord online chat, with a #support channel in which you can ask questions. The PIVX project have paid personnel working in theirs, which have proven tremendously helpful in my experience.


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 operating a masternode, and if you have any questions or feedback, don’t hesitate to leave a comment below or email me through the contact form.