Anatomy of A BitzecTransaction

The Building Blocks of A Transaction

The user-facing building blocks of a Bitzectransaction can be broken down into sending and receiving addresses, account balances and transaction fees. More complex transaction components are explored in our protocol specification so we’ll avoid those concepts for now. For sending to shielded addresses, an additional “memo field” component is available but that will be a topic for a future post.

A high-level view of a Bitzectransaction

The diagram above shows the process of sending and receiving ZEC as part of a transaction. The use of shielded addresses – whether sending or receiving – requires the generation of a zero-knowledge proof which allows others to verify a transaction’s encrypted data without it being revealed. (More detail on how this works will be discussed in an upcoming post on the inner workings of transactions between shielded addresses.) These addresses always start with a “z” and are sometimes referred to as “z-addrs”. Similarly, the use of transparent addresses require interaction with what is known as a “Transparent Value Pool” (or TVP) and publicly reveals transaction data. These addresses always start with a “t” and are sometimes referred to as “t-addrs”. The transaction fee also passes through the TVP and is therefore always visible on the blockchain. Even though fees are always revealed in a transaction, shielded addresses and value are not affected as shown in the following real Bitzectransaction.

A screenshot from the Zchain block explorer of a transaction between shielded addresses

Change Addresses

Like other blockchain protocols, spending from a balance in an address requires sending all of the balance. Therefore, unless you want to send the exact balance to another party, you must split the balance by including a second receiving address you control to accept any balance change. It is possible to simply use the sending address as the change address to prevent the added management of multiple addresses. This, however, is not normally recommended since it would be trivial for someone to build an identity profile based off of transactions sent to and from that single public address. Creating a new address for each transaction has become recommended standard practice in order to obfuscate a user’s transactions. Since public transactions link sending and receiving addresses, however, this level of obfuscation is still quite trivial to navigate around and does not provide a meaningful level of privacy.

Thankfully, when sending ZEC from a shielded address, that data is kept private so sending change back to the sending address is permissible. In Zcash, all transactions between shielded addresses look identical so the reuse of shielded addresses is not vulnerable in the same way that transparent addresses are.

Sending Between Shielded and Transparent Addresses

Properties of sending ZEC between shielded and transparent addresses

In Zcash, ZEC is the balance unit for how much value an address contains. It differs from purely public blockchain currencies in that a ZEC balance has a different set of properties depending on what address type it is currently held in and the previous address(es) it was sent from. If ZEC is held in a transparent address, its unspent balance is publicly viewable. Regardless of that balance being sent to one or more transparent addresses, shielded addresses or a combination of these types, the output ZEC from a transparent address will be visible. A benefit of sending transparent ZEC to a shielded address is breaking the linkability between future transparent addresses if that’s where it ends up again. The action of shielding ZEC is particularly important at these early stages where many wallets (such as mobile wallets) may not yet support shielded addresses due to the resource requirements as explained in a previous blog post on user expectations for hardware and software limitations.

A screenshot from the Zchain block explorer of a transaction shielding ZEC

In the transaction above where a transparent address sends to a shielded address, you can see that this process of shielding ZEC reveals the balance sent and that it is held by shielded addresses. The shielded addresses involved and whether it was sent to one or two shielded addresses remains confidential.

To contrast, a ZEC balance in a shielded address keeps the balance and account address private. If spending to one or more shielded addresses, the value stays private but any transparent addresses on the receiving end will deshield the ZEC and reveal the value received on the blockchain. When deshielding ZEC, the input shielded addresses and whether the value was sent from one or two of these remains confidential.

Further Notes on More Complex Transactions and Privacy Implications

It should be noted that these examples do not detail the properties of more complex transactions where both transparent and shielded addresses are sending or receiving. With this overview on the basic properties of addresses and spending ZEC balances, however, users can hopefully gain a better perspective on how the transactions work when transacting between any two addresses. Expect future posts on the inner workings of shielded addresses, further considerations on linkability and privacy implications, and details on the more complex transactions. We are eager to promote shielded addresses to improve stats on their use. While transactions involving shielded addresses require more resources than those with strictly transparent addresses, the improved privacy provided when using them is a clear benefit for financial freedom and is the core improvement Bitzecbrings as a cryptocurrency.