Authors:
(1) Hamid Bateni, Nobitex Labs (hamid@europe.com);
(2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Table of Links Abstract and 1 Introduction 2 Proof of Liability and 2.1 Commitment 2.2 Merkle Tree 2.3 Leaves Structure 2.4 Proof Statement 3 Proof of Reserve 3.1 Ethereum 3.2 Bitcoin 4 Proof of Solvency 5 Future Works and References 3.2 Bitcoin Bitcoin, the first decentralized cryptocurrency, was introduced in 2009 by an individual or group known as Satoshi Nakamoto. It operates on a peer-to-peer network where transactions are verified by network nodes through cryptography and recorded on a public ledger known as blockchain. Unlike Ethereum’s account-based model, Bitcoin uses an Unspent Transaction Output (UTXO) model for its accounting system. In this model, transactions output a certain number of bitcoins, which can be spent by future transactions. Each UTXO represents a chain of ownership encoded in the Bitcoin blockchain, and the sum of these UTXOs represents a user’s total bitcoin balance. Bitcoin nodes maintain a database of active UTXOs, also known as the chain state. This database is crucial for verifying new transactions, as it allows nodes to check whether the UTXOs a transaction wants to spend are indeed valid and have not been spent yet. By only keeping track of unspent bitcoins, the UTXO model simplifies transaction verification and improves the scalability of the Bitcoin network.[5] 3.2.1 UTXO and ChainStat At the heart of Bitcoin’s operation is the Unspent Transaction Output (UTXO) model. In this model, each transaction begins with inputs that are references to previous transaction outputs and ends with outputs that specify a new Bitcoin amount and a new owner. These outputs then become the inputs of future transactions, forming a chain of ownership. Transaction types in Bitcoin, such as Pay-to-Public-Key-Hash (P2PKH) and Payto-Script-Hash (P2SH), govern the conditions under which these UTXOs can be spent. The Chain State in Bitcoin is a key-value database that maintains a record of all active UTXOs. With the arrival of every new block, spent UTXOs are removed, and new UTXOs are added to the Chain State. This dynamic update of the Chain State ensures that it accurately reflects the current state of all transactions. The balance of a Bitcoin address is determined by the total amount of bitcoins in the UTXOs that the address owns. Each full node in the Bitcoin network independently maintains the Chain State. Every node computes its own Chain State by applying all transactions from the blockchain starting from the genesis block. This decentralized approach ensures that every node has a complete and independent verification of the state of all transactions, contributing to the security and robustness of the Bitcoin network. However, this also means that the Chain State is not directly included in the block header and varies from node to node, making it challenging to create a proof of reserve that commits to a specific number of active UTXOs owned by an address. In the next section, we will discuss a solution to this challenge. 3.2.2 Bitcoin Proof Statement The first approach to proving a Bitcoin balance might be to adopt the idea from EIP7503. This would involve transferring a specific amount of Bitcoin in a transaction, and then privately proving the transaction and the amount. This approach is feasible but involves operational costs, making it less than ideal. A more efficient approach might involve the following steps: Announce that the platform intends to commit to its Bitcoin balances up to a specific block.


Download the entire Chain State for that block from a Bitcoin node. This Chain State includes every active UTXO at the time of the block.


Insert every UTXO from the Chain State as a leaf in a Merkle tree. This process converts the Chain State into a structure that allows for efficient proofs.


Publish the root of the Merkle tree. Anyone can then verify the correctness of the published root with the help of a Bitcoin node and some additional code. With this approach, we now have a Merkle tree representing all active UTXOs at a specific block. As a business, we know which UTXOs belong to our addresses. We can then create a Zero-Knowledge Proof (ZKP) circuit to prove that we know some leaves (UTXOs) that belong to a specific address and prove their paths in the Merkle tree. This approach allows us to commit to a specific number of active UTXOs owned by an address without revealing the address itself, providing a privacy-preserving proof of reserve for Bitcoin addresses. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Hamid Bateni, Nobitex Labs (hamid@europe.com); (2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Authors: Authors: (1) Hamid Bateni, Nobitex Labs (hamid@europe.com); (2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Proof of Liability and 2.1 Commitment 2 Proof of Liability and 2.1 Commitment 2.2 Merkle Tree 2.2 Merkle Tree 2.3 Leaves Structure 2.3 Leaves Structure 2.4 Proof Statement 2.4 Proof Statement 3 Proof of Reserve 3 Proof of Reserve 3.1 Ethereum 3.1 Ethereum 3.2 Bitcoin 3.2 Bitcoin 4 Proof of Solvency 4 Proof of Solvency 5 Future Works and References 5 Future Works and References 3.2 Bitcoin Bitcoin, the first decentralized cryptocurrency, was introduced in 2009 by an individual or group known as Satoshi Nakamoto. It operates on a peer-to-peer network where transactions are verified by network nodes through cryptography and recorded on a public ledger known as blockchain. Unlike Ethereum’s account-based model, Bitcoin uses an Unspent Transaction Output (UTXO) model for its accounting system. In this model, transactions output a certain number of bitcoins, which can be spent by future transactions. Each UTXO represents a chain of ownership encoded in the Bitcoin blockchain, and the sum of these UTXOs represents a user’s total bitcoin balance. Bitcoin nodes maintain a database of active UTXOs, also known as the chain state. This database is crucial for verifying new transactions, as it allows nodes to check whether the UTXOs a transaction wants to spend are indeed valid and have not been spent yet. By only keeping track of unspent bitcoins, the UTXO model simplifies transaction verification and improves the scalability of the Bitcoin network.[5] 3.2.1 UTXO and ChainStat At the heart of Bitcoin’s operation is the Unspent Transaction Output (UTXO) model. In this model, each transaction begins with inputs that are references to previous transaction outputs and ends with outputs that specify a new Bitcoin amount and a new owner. These outputs then become the inputs of future transactions, forming a chain of ownership. Transaction types in Bitcoin, such as Pay-to-Public-Key-Hash (P2PKH) and Payto-Script-Hash (P2SH), govern the conditions under which these UTXOs can be spent. The Chain State in Bitcoin is a key-value database that maintains a record of all active UTXOs. With the arrival of every new block, spent UTXOs are removed, and new UTXOs are added to the Chain State. This dynamic update of the Chain State ensures that it accurately reflects the current state of all transactions. The balance of a Bitcoin address is determined by the total amount of bitcoins in the UTXOs that the address owns. Each full node in the Bitcoin network independently maintains the Chain State. Every node computes its own Chain State by applying all transactions from the blockchain starting from the genesis block. This decentralized approach ensures that every node has a complete and independent verification of the state of all transactions, contributing to the security and robustness of the Bitcoin network. However, this also means that the Chain State is not directly included in the block header and varies from node to node, making it challenging to create a proof of reserve that commits to a specific number of active UTXOs owned by an address. In the next section, we will discuss a solution to this challenge. 3.2.2 Bitcoin Proof Statement The first approach to proving a Bitcoin balance might be to adopt the idea from EIP7503. This would involve transferring a specific amount of Bitcoin in a transaction, and then privately proving the transaction and the amount. This approach is feasible but involves operational costs, making it less than ideal. A more efficient approach might involve the following steps: Announce that the platform intends to commit to its Bitcoin balances up to a specific block. Download the entire Chain State for that block from a Bitcoin node. This Chain State includes every active UTXO at the time of the block. Insert every UTXO from the Chain State as a leaf in a Merkle tree. This process converts the Chain State into a structure that allows for efficient proofs. Publish the root of the Merkle tree. Anyone can then verify the correctness of the published root with the help of a Bitcoin node and some additional code. Announce that the platform intends to commit to its Bitcoin balances up to a specific block. Announce that the platform intends to commit to its Bitcoin balances up to a specific block. Download the entire Chain State for that block from a Bitcoin node. This Chain State includes every active UTXO at the time of the block. Download the entire Chain State for that block from a Bitcoin node. This Chain State includes every active UTXO at the time of the block. Insert every UTXO from the Chain State as a leaf in a Merkle tree. This process converts the Chain State into a structure that allows for efficient proofs. Insert every UTXO from the Chain State as a leaf in a Merkle tree. This process converts the Chain State into a structure that allows for efficient proofs. Publish the root of the Merkle tree. Anyone can then verify the correctness of the published root with the help of a Bitcoin node and some additional code. Publish the root of the Merkle tree. Anyone can then verify the correctness of the published root with the help of a Bitcoin node and some additional code. With this approach, we now have a Merkle tree representing all active UTXOs at a specific block. As a business, we know which UTXOs belong to our addresses. We can then create a Zero-Knowledge Proof (ZKP) circuit to prove that we know some leaves (UTXOs) that belong to a specific address and prove their paths in the Merkle tree. This approach allows us to commit to a specific number of active UTXOs owned by an address without revealing the address itself, providing a privacy-preserving proof of reserve for Bitcoin addresses. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Ever Wonder How Crypto Platforms Show They're Solvent?

Navigating Ethereum's World State: The Role of Merkle Patricia Tries in Proof of Reserve

Solvency.tech

Too Long; Didn't Read

Make resilience your competitive advantage

How UTXOs Keep Your Coins Safe and Sound

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Future Directions for Proof of Solvency in Digital Assets

Blockchain’s Impact on the Global Economy and the Role of Custody

Introducing Private Proof of Solvency

The Role of Commitment in Proof of Solvency

How Merkle Trees Enhance Data Integrity in Crypto Custody

Future Directions for Proof of Solvency in Digital Assets

Blockchain’s Impact on the Global Economy and the Role of Custody

Introducing Private Proof of Solvency

The Role of Commitment in Proof of Solvency

How Merkle Trees Enhance Data Integrity in Crypto Custody

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps