Privacy Transactions on Block Lattice

Slava Gomzin

Please leave your comments and suggestions on github

July 13, 2020

Introduction

While some people still associate privacy cryptocurrencies with darknet, black market, and hacker attacks, this perception is based on the fact that such illegal applications involve payment systems with a high degree of anonymity and privacy. The reality, however, is opposite: payment systems that provide ultimate anonymity and privacy to their users perfectly serve everyone’s needs, including, unfortunately, illegal activities. Another myth states that privacy and anonymity are only required for people who have something to hide. This is a wrong assumption because anonymity and privacy are fundamental features that protect people and businesses from outrage of governments, corporations, hackers, and thieves.

This document proposes the application of Cryptonote[1] and other cryptographic techniques to a block lattice transaction ledger so it could ensure privacy of its users. Originally, Cryptonote was designed as a proof of concept for “classic” blockchain, and successfully used and enhanced by Monero cryptocurrency developers. However, block lattice design is different from a blockchain ledger used by most cryptocurrencies such as Bitcoin and Monero.

The differences in design between blockchain and block lattice allow the latter to provide its users with very important features: instant authorizations and settlements, high scalability, low hardware requirements for client (wallet) apps, non-locking wallet balances, and more. But when it comes to privacy, the existing techniques cannot be applied to block lattice just “as is”. The main difference between blockchain and block lattice is the way transactions are written into blocks.

In classic blockchain, a transaction is represented by a record within a block which contains multiple transactions. Blocks are periodically generated by miners. Transactions belonging to a particular user account (wallet) are distributed throughout different blocks on the entire blockchain. In fact, the user account is represented by various transaction “outputs” scattered throughout the blockchain, so new spending requires access to a full ledger database.

In block lattice, a funds transfer transaction is represented by two blocks: send and receive, which is similar to real-life payment processing systems' authorization and settlement transactions. Each block contains information about a single transaction (or more precisely, a “half” transaction, its send or receive portion). Transactions (send and receive blocks) belonging to a particular user account are added to an individual blockchain. Thus, block lattice is not a singleton blockchain but rather a collection of blockchains. Since send and receive blocks belonging to different accounts’ blockchains are linked to form a transaction, this structure looks more like a block lattice.

Privacy in Cryptonote and Monero

Monero uses several cryptographic techniques to enable privacy of users and their transactions.[2] While originally Monero was based on Cryptonote, their developers have made significant changes and improvements compared to the original protocol. These techniques are stealth addresses, ring signatures, amount commitments, and range proofs. Stealth addresses protect the recipient’s identity by hiding the destination address. Ring signatures protect the sender’s identity by hiding the source wallet address. And finally, amount commitments and range proofs protect both senders and recipients by hiding transaction amounts. Thus, users transacting on Monero blockchain enjoy full privacy, while the network is still able to validate transaction integrity and prevent double-spending without knowing the sender, the recipient, and the amount of the transaction.

Block lattice privacy scheme

The proposed scheme uses existing cryptographic techniques listed above and applies them to block lattice transactions to hide the sender, the recipient, the amount of the transaction, and account balances before and after transaction. The account balances and fund transfer amounts are represented as transaction “inputs” and “outputs”.

Send block always has one input and two outputs. The input is the output of the previous block on the account blockchain, it contains the current account balance. The first output is the new account balance. The second output is the amount being sent to the recipient.

Receive block always has two inputs and one output. The first input is the output of the previous block on the account blockchain, it contains the current account balance. The second input is the amount that was sent by the sender. The only output is the new balance of the account.

Since block lattice funds transfer transaction is divided into two phases (represented by two blocks: send and receive), different sets of cryptographic techniques are applied to inputs and outputs depending on the block “direction”:

• The send block does not need to hide the source of its input because by definition it is always located in the previous block on the blockchain of the same account. Therefore, the send block does not need to use ring signatures.

• The receive block does not need to hide the destination because by definition it is always the next block on the same blockchain that belongs to the same account. Therefore, the receive block does not need to use a stealth address.

• The receive block should use ring signatures on the input coming from a sender to hide the actual sender.

• The receive block does not need to hide the source of another “balance” input because by definition it is always located in the previous block on the blockchain of the same account. Therefore, the receive block does not need to use ring signatures on the “balance” input.

• The send block should use a stealth address only on the output directed to the recipient to hide the recipient.

• Both send and receive blocks should hide their transfer and balance amounts, so they both should use amount commitments.

• Since the receive block has only one output directed to the same account, it should not create a range proof.

• Token genesis blocks are not encrypted as their source and destination are obvious (by definition they belong to the same account), and the amount must be publicly verifiable.

• Transaction fee is shown in clear text so it could be validated by all authorizers and the network. The amount of the fee depends on the type of transaction and can be changed dynamically by the current authorizers by issuing a new service block. Either send block fee or receive block fee or both can be zero, depending on settings in the latest service block.

Private transaction

Below is high level definition of private transaction format, with brief description of the data fields.

Block Type: Send

Inputs: Input X (account balance) points to the output Y from the previous block (account balance)

• Pseudo output commitment: C0X

Outputs: Output Y (new account balance)

• Amount AY is encrypted with the transaction key

• Output commitment: CY

Output Z (send amount)

• Amount AZ is encrypted with recipient’s public key

• One-time “stealth” address: K

• Output commitment: CZ

Transaction Fee F

• Tx fee amount AF in clear text

• Range proof: an aggregate Bulletproof for output amounts

• Transaction public key rG

Send transaction uses transaction public key rG. It "spends" the output recorded in the previous block on this account’s blockchain as a balance of the account (note that it has a hidden amount AX, committed to in CX). The output (account balance) being spent is owned by the same account because it is signed the entire send block using the account’s private key, and hasn’t been spent before because it is recorded in the previous block of the accounts blockchain and approved (signed by the authorizers) by the network (so no key images needed to prove this). It will give it a pseudo output commitment C0X. It generates two outputs Y and Z. Output Y becomes the new account balance, and only this account can spend this output in the next transaction. Output Z may be spent by the one-time address K. It has a hidden amount AY committed to in CY, encrypted for the recipient, and proven in range with a Bulletproofs-style range proof. The transaction includes a transaction fee F. Please note that C0X − (CY + CZ + CF ) = 0, and that it has signed the commitment to zero C0X − CX = zG, which means the input amount equals the output amount (AX = A0X = AY + AZ + AF). It signes all transaction data, so observers can be sure it hasn’t been tampered with.

Block Type: Receive

Inputs:

• Input X (account balance) points to the output Y from the previous block (account balance)

• Pseudo output commitment: C0X

Input S (received funds)

• Pseudo output commitment: C0S

• Ring member block IDs: a list of block hashes indicating where a verifier can find input’s ring members in the block lattice (includes the real input)

• Ring Signature

• Key image I

Outputs: Output Y (new account balance)

• Encrypted Amount AY is encrypted with transaction key

• Output commitment: CY

Transaction Fee F

• Tx fee amount AF in clear text

• Transaction public key rG

Receive block “spends” two outputs X and S that have hidden amounts AX and AS, committed to CX and CS. The output S being spent was sent to this account in one of the send blocks in the IDs list (so it can make ring signature on the one-time address in S), and hasn’t been spent before (its key image I has not yet appeared in the block lattice). It will give it a pseudo output commitment C0S. It will make one output Y, which represents the new account balance and can be spent only by the same account as an input for the next block. It has a hidden amount AY committed to in CY, and encrypted using transaction key. The transaction includes a transaction fee F. Please note that (C0X + C0S) − (CY + CF ) = 0, and that we have signed the commitment to zero C0X − CX = zG and C0S − CS = zG, which means the input amount equals the output amount: AX + AS = AX + A0S = AY + AF. Ring signature signs the transaction data, so observers can be sure it hasn’t been tampered with.

What we achieve with the privacy scheme described above

As with the original block lattice transaction processing scheme, the funds transfer transaction between two accounts (a sender pays to a recipient) is divided into two separate phases (represented by two blocks): send (authorization) and receive (settlement). The authorization (send) operation, which is most critical from timing and resource perspective for most payment transactions, can be still processed instantly, without the need to access the entire block lattice or even the entire account’s blockchain as only the latest block from the sender’s account is needed to generate a new send block. The settlement might require more processing time and resources (from the authorizers to scan the key images) and access to a big chunk of the entire block lattice (for the client to create a ring signature that hides the sender). Such “separation of duties” between the sender and receiver, and authorization and settlement processes, perfectly fits the real-life transaction processing in retail environments, where authorization must be completed instantly (to serve customers in real time) and with least resources required for the client (to allow implementations of wallets on mobile devices and smart cards). The settlement (receive) does not have strong timing and resource limitations, so it can be processed later, by the recipient’s backend software, as a background job.

References

[1] Nicolas van Saberhagen. CryptoNote v 2.0. https://cryptonote.org/whitepaper.pdf.

[2] koe, Kurt M. Alonso, Sarang Noether. Zero to Monero. https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf.

Please leave your comments and suggestions on github