> For the complete documentation index, see [llms.txt](https://ciphera.gitbook.io/zerosats-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ciphera.gitbook.io/zerosats-docs/welcome-to-zerosats/privacy-guarantees.md). # Privacy guarantees An explanation on what data is publicly available... Zerosats has very good privacy properties at the transaction level. No information about a specific user address, or amounts, is disclosed in a transaction. However, like with all privacy protocols, there is nuance to how private the network is. Additionally, certain user behaviors can assist deanonymizing a given user should someone seek to do that. First, let's cover what's available in a given transaction: ### Contents of a Zerosats transaction This is what appears after running this command: ``` curl https://mainnet.lx.dev/v0/transactions/1e47a1400bbeb5ff2f81e905c2858a715f5c47cccb0987ffafa6575b0ec55bd1 ``` ```json {"txn": {"proof": {"kind": "utxo", "proof":"AAAAAAAAAAAAAAA...4I+NQkHfQ=", "public_inputs": {"input_commitments": ["0b5e1c305fd7a2776235c92e2632c7fd92d76d52712aad8888a5bd26b2e2adaf", "0000000000000000000000000000000000000000000000000000000000000000"], "output_commitments": ["23a0faf907c1ff0ffd9fec3b855bbbb446fa8c6a7258bbb7519852335168d601", "0000000000000000000000000000000000000000000000000000000000000000"], "messages": ["0000000000000000000000000000000000000000000000000000000000000001", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000"]}}, "index_in_block":0, "hash":"1e47a1400bbeb5ff2f81e905c2858a715f5c47cccb0987ffafa6575b0ec55bd1", "block_height":357869, "time":1781029566} }% ``` 1. First is a the output of a zero-knowledge proof. It is a large blob of text that is unreadable and cannot be interpreted by anyone other than the zero-knowledge virtual machine (which can only interpret that it is valid proof). 2. Second are the input commitments for the notes (UTXOs) being spent. Every note in Zerosats is represented by a hash, not an amount. 3. Below input commitments are output commitments. These are hashes of the notes that are created in the transaction. 4. Lastly are messages. These specify what type of transaction was being spent (mints, burns, transfers, etc.) and carry additional data that may be important for external services. In Zerosats, every input creates an output. In the transaction above, `0b5e1c305fd7a2776235c92e2632c7fd92d76d52712aad8888a5bd26b2e2adaf` created the output `23a0faf907c1ff0ffd9fec3b855bbbb446fa8c6a7258bbb7519852335168d601` . When `23a0faf907c1ff0ffd9fec3b855bbbb446fa8c6a7258bbb7519852335168d601` is spent, it will be used as the input to create a new output. Let's break this down: UTXO `A` is spent to create UTXO `B` . `B` is spent to create `C` and so on. A keen observer can link that UTXO `A` is directly connected to UTXO `C`, but they cannot discern who owns `A`, `B`, or `C`, the identity of the sender or recipient, and the amounts involved in any of the transactions. The users themselves only know the amounts and potentially counterparties involved in a specific transaction, but nothing else. As long a user deposits funds and spends from the pool, they have strong privacy guarantees. However, certain behaviors can leak information. ### Main areas for data leakage #### Shielding and deshielding If a user deposits `1 BTC` into Zerosats does a few transactions to themselves, and withdraws `1 BTC` out of Zerosats, it's likely that the deposit and withdraw can be correlated. * `1 BTC` into Zerosats is public. Let's say 5 Zerosats' outputs were created around the time this deposit transaction was broadcast and confirmed. This deposit specifically creates output `A` in Zerosats. * A public observer links the 5 outputs, including `A`, as potential `1 BTC` notes in Zerosats. * The user spends output `A` to create output `B`. They do so again to create output `C`. * The user then submits a burn transaction by spending output `C`. * A `1 BTC` withdrawal is sent to the users' fresh BTC address. Because the withdrawal is linked to outputs `A`, `B`, and `C`, and the deposit and withdrawal are the same amount, the observer can be confident that it is the same user. This surveillance vector is only thwarted by users remaining in the pool after deposit. Zerosats should be used as a spend only application. Users are encouraged to deposit more funds then they need for a given transaction. #### Lightning payments When paying a Lightning invoice through Zerosats, users interact with a Lightning gateway. Some information is leaked to the gateway. When paying an invoice, the user calls the gateway to create an Escrow contract. The gateway obliges and then documents when the escrow was paid: {% code overflow="wrap" %} ``` checking EscrowRequested quote payment_hash=846161c5608119171801811bae615879bb372a80445d8483165e3892f0b7a461 committment="1cc4a28b6da49f22007c411581360eb463de846327e523223d44df249eee7c21" ``` {% endcode %} In the transaction that was spent to satisfy this escrow contract, you can see that the output commitment is the one that satisfied the escrow contract: {% code overflow="wrap" %} ``` TRANSACTION HASH: 2e34055b3d8e79bd32f15086c150f13edaa6cce1d7a43f33163488447ef502f4 INPUT_COMMITMENTS [0]: 20ee79e0869f0f47f6e97b8cd6a19f853759264a636e525dc95fabc91d6a03d2 OUTPUT_COMMITMENTS [0]: 1cc4a28b6da49f22007c411581360eb463de846327e523223d44df249eee7c21 [1]: 25b4244d801154cb113d63298dd9976680b5b0772940d55920c096c6071e078b MESSAGES [0]: 0000000000000000000000000000000000000000000000000000000000000001 ``` {% endcode %} To public observers, this looks like a normal Zerosats transaction. However, the Lightning gateway stores a specific amount of information in its database. {% code overflow="wrap" %} ``` CREATE TABLE IF NOT EXISTS quotes ( payment_hash BLOB PRIMARY KEY, bolt11 TEXT NOT NULL, preimage BLOB, note_commitment BLOB NOT NULL UNIQUE, note_kind BLOB NOT NULL, note_secret BLOB NOT NULL, amount BLOB NOT NULL, user_address BLOB NOT NULL, zero_block BLOB NOT NULL, n_blocks BLOB NOT NULL, claim_address BLOB, status TEXT NOT NULL, last_error TEXT, expires_at INTEGER NOT NULL, created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL ); ``` {% endcode %} Of this information, the `amount` is the only identifier that is made fully public to the gateway. This is because note information, such as `user_address`, is specific to each note in Zerosats. This means there is no "fixed" address that a given user has for all of its notes; each note has its own unique address. Thus, the gateway can only be sure of the amount of the payment. This privacy leakage is generally suitable for a payments application. As long as users are not spending full or close-to-full amounts that they deposit into the protocol, then the Lightning gateway would most likely be unable to discern who the Lightning payment is coming from. ### Summary Users should not use Zerosats as a pass through. It will be easy to correlate deposits and withdrawals. Users should not deposit a set amount of bitcoin to make one payment as this could link their output commitment to satisfy the LN escrow to their deposit address. The best way to user Zerosats is to deposit a small spending balance into the protocol and make payments using a percentage of that balance. In this scenario, it will be extremely difficult for malicious observers, and the Lightning gateway, to link your payments back to your deposit address.