3.5.7 Private Transactions

The following text provides a preliminary description of the approach to implementing private transac-tions in DGT, which is anticipated by Athabasca. Please note that the implementation details may be subject to further clarification and the information provided is intended for informational purposes only.

The need for privacy in blockchain transactions arises from the desire to protect sensitive information and maintain confidentiality. In traditional banking transactions, the privacy of individuals' financial activities is ensured through centralized systems and regulations. However, in blockchain transactions, the data is stored on a public ledger, making it visible to anyone with access to the blockchain.

This lack of privacy can lead to various concerns. For example, if someone exchanges money with a known exchange address and the exact sum can be traced, it becomes possible to infer details about that person's financial activities. This information can be misused for various purposes, including targeted advertising, identity theft, or even financial discrimination. In contrast, privacy-enhancing techniques, such as those employed in DGT's private transactions, aim to address these concerns by allowing users to conduct transactions without revealing sensitive information. With shielded addresses and cryptographic protocols like bulletproofs, transaction details, including sender, recipient, and transaction amounts, can be hidden while still maintaining the integrity and security of the transaction.

Bulletproofs is a non-interactive zero-knowledge proof (ZKP) method based on mathematical concepts such as inner product arguments and range proofs. It is specifically designed to provide efficient and secure privacy-preserving solutions in various cryptographic applications, including blockchain transactions. Bulletproofs are particularly well-suited for proving the correctness of range proofs, where the prover wants to demonstrate that a value falls within a specific range. They excel at proving that a value is within a certain range without revealing the exact value itself. Bulletproofs are based on mathematical concepts from the field of elliptic curve cryptography and specifically the arithmetic of elliptic curves. They rely on the properties of Pedersen commitments, which are cryptographic constructs used to hide values and their associated blinding factors. Bulletproofs utilize polynomial commitments and inner product arguments to construct zero-knowledge proofs that validate the correctness of computations without revealing any sensitive information (Bünz, et al., 2018).

Compared to other ZKP methods like ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and NIZK (non-interactive zero-knowledge proofs), Bulletproofs offer several advantages. Firstly, the Bulletproofs algorithms are non-interactive, meaning they require only a single round of communication between the prover and verifier, resulting in reduced computational overhead and improved efficiency. Another key advantage of Bulletproofs is their compact size. They produce succinct proofs, which are significantly smaller in size compared to alternative ZKP methods. This compactness translates to faster verification times and reduced storage requirements.

To support private transactions with specific addresses and utilize shielded addresses and bulletproof-based protocols, there are several technical requirements and prerequisites to consider:

• Address Management: Private transactions in the DGT system are facilitated by a dedicated transaction family extension that operates within its own address space. This extension handles the generation, storage, and retrieval of private keys associated with shielded addresses.

• Integration of Bulletproofs Protocol: The DGT system seamlessly integrates the Bulletproofs protocol, a zero-knowledge proof system, to enable efficient range proofs for verifying transaction amounts without revealing specific values.

• Cryptographic Primitives: The system employs essential cryptographic primitives, including elliptic curve cryptography (ECC) for key generation, digital signatures, and cryptographic hash functions to ensure data integrity.

• Transaction Format: The transaction format has been enhanced to accommodate the specific attributes required for private transactions, such as shielded addresses, bulletproof addresses, and other privacy-related elements. This may involve introducing new transaction structures or modifying existing ones.

• Consensus and Validation: The consensus mechanism and transaction validation process have been updated to support the validation and acceptance of private transactions. Validators and consensus nodes are equipped to handle the additional cryptographic operations involved in validating shielded addresses and bulletproof.

• Application-Level Integration: The user interface and wallet features of the DGT application are designed to seamlessly support the creation, management, and use of shielded addresses. Users can initiate private transactions and interact with the shielded address functionality effortlessly. Privacy Controls and Permissions: The system should have mechanisms to enable users to control their privacy settings and permissions. This may include options to toggle between private and public transactions for specific addresses and manage access rights to shielded address features.

• Performance Considerations: Implementing private transactions with shielded addresses and bulletproofs may introduce additional computational overhead. The system should consider optimizing performance to ensure efficient processing and validation of private transactions without significant impact on overall system performance.

The algorithm that reveals the main steps and their sequences when transferring funds from Participant A to Participant B using shielded addresses is presented in the table below.

Step	Actor	Action	Description
1	Key Generation
1.1	Application A	Generate private and public keys for party A	Party A generates a private key (sk_A) and a corresponding public key (pk_A) using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve: sk_A, pk_A = generate_key_pair()
1.2	Application B	Generate private and public keys for party B	Party B generates a private key (sk_B) and a corresponding public key (pk_B) using the same ECDSA algorithm and curve: sk_B, pk_B = generate_key_pair()
2	Shielded Address Generation
2.1	Application A	Generate a shielded address for party A	Party A generates a shielded address (sa_A) by applying the SHA-256 hash function to the public key (pk_A): sa_A = sha256_hash(pk_A)
2.2	Application B	Generate a shielded address for party B	Party B generates a shielded address (sa_B) by applying the SHA-256 hash function to the public key (pk_B): sa_B = sha256_hash(pk_B)
3	Commitment Generation
3.1	Application A	Compute Pedersen's commitment to party A's shielded address	Party A computes a Pedersen commitment (C_A) of the shielded address (sa_A) using the Pedersen commitment scheme, which combines the SHA-256 hash function and elliptic curve operations: C_A = pedersen_commitment(sa_A)
3.2	Application B	Compute Pedersen's commitment to party B's shielded address	Party B computes a Pedersen commitment (C_B) of the shielded address (sa_B) using the same Pedersen commitment scheme: C_B = pedersen_commitment(sa_B)
4	Zero-Knowledge Proof Generation
4.1	Application A	Generate zero-knowledge proof for party A	Party A generates a zero-knowledge proof (zkp_A) using Bulletproofs to demonstrate knowledge of the private key (sk_A) associated with the shielded address (sa_A): zkp_A = generate_bulletproof_proof(sk_A, sa_A)
4.2	Application B	Generate zero-knowledge proof for party B	Party B generates a zero-knowledge proof (zkp_B) using Bulletproofs for the private key (sk_B) associated with the shielded address (sa_B): zkp_B = generate_bulletproof_proof(sk_B, sa_B)
5	Verification
5.1	Application B	Verify zero-knowledge proof for party A	Party B verifies the zero-knowledge proof (zkp_A) using the public key (pk_A) and the Pedersen commitment (C_A): is_valid_A = verify_bulletproof_proof(zkp_A, pk_A, C_A)
5.2	Application A	Verify zero-knowledge proof for party B	Party A verifies the zero-knowledge proof (zkp_B) using the public key (pk_B) and the Pedersen commitment (C_B): is_valid_B = verify_bulletproof_proof(zkp_B, pk_B, C_B)
6	Constructs the private transaction	Sender's shielded address, Amount
6.1	Application A (Sender)	Encryption algorithm	Encrypts the transaction payload and proof for privacy.
6.2	Application A (Sender)	Digital signature algorithm	Signs the encrypted transaction and includes the sender's public key. transaction = create_transaction(sa_A, sa_B, amount, encrypted_details)
7	Network Processing
7.1	Application (Sender)	Encrypted transaction	Sends the encrypted transaction to the Transaction Processor.
7.2	Transaction Processor	Digital signature verification	Receives the encrypted transaction and validates the sender's signature.
7.3	Transaction Processor	Bulletproofs proof verification	Verifies the Bulletproofs proof and the correctness of the transaction
7.4	Transaction Processor	Validated transaction	Forward the validated transaction to the Validator/Consensus broadcast_transaction(transaction)
7.5	Validator/Consensus	Consensus checks	Receives the validated transaction and performs consensus checks.
7.6	Validator/Consensus	Ledger update	Updates the ledger with the private transaction details.
7.7	Validator/Consensus	Committed block	Sends the committed block to the Arbitrator.
7.8	Arbitrator	Committed block	Receives the committed block from the Validator/Consensus.
7.9	Arbitrator	Block validation and approval	Validates and approves the block, including the private transaction.
7.10	Arbitrator	Block commitment	Commits the approved block to the blockchain
8	Confirmation and Decryption
8.1	Application B (Receiver)	Getting Encrypted transaction	Retrieves the encrypted transaction from the network
8.2	Application B (Receiver)	Decrypts the transaction using the receiver's private key.	Once the transaction is confirmed by the network, party B can decrypt the transaction details using their private key (sk_B) associated with the shielded address (sa_B). This allows party B to access the transferred funds and verify the transaction's validity decrypted_details = decrypt_transaction_details(transaction, sk_B)
8.3	Application B (Receiver)	Verifies the transaction payload and proof using the Bulletproofs algorithm.	Bulletproofs proof verification
8.4	Application B (Receiver)	Ledger update transaction	Updates the receiver's balance and ledger with the transaction details