From bae3e35948123b03869f41721130c6a83c4e85d9 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Thu, 11 Dec 2025 14:44:24 -0500 Subject: [PATCH 1/8] Docs: Edit Sapling docs to match style guide --- docs/alpha/sapling.rst | 70 ++++++++++++++++++---------------------- docs/tallinn/sapling.rst | 70 ++++++++++++++++++---------------------- 2 files changed, 64 insertions(+), 76 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 9b3847c39c2e..d7ff5c6648a1 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -7,37 +7,31 @@ For support in high-level smart contract languages, see the `Sapling documentati Sapling ------- -Sapling is a protocol enabling privacy-preserving transactions of fungible -tokens in a decentralised -environment. It was designed and implemented by the Electric Coin -Company as the last iteration over a series of previous protocols and -academic works starting with the `Zerocoin seminal -paper `__. +Sapling is a protocol that enhances privacy for transactions of fungible tokens. It creates a set of transactions called a *shielded set* +that can be viewed only by specific entities. It was designed and +implemented by the Electric Coin Company as the last iteration over a +series of previous protocols and academic works starting with the +`Zerocoin seminal paper `__. Keys ~~~~ -Sapling offers a rich set of keys, each allowing different operations. -A *spending key* allows to spend tokens so if it is lost or -compromised the tokens could remain locked or be stolen. -From a spending key it is possible to derive a corresponding *viewing -key* which allows to view all incoming and outgoing transactions. -The viewing key allows the owner of the tokens to check their balance -and transaction history so if compromised there is a complete loss of -privacy. -On the other hand a viewing key can willingly be shared with a third -party, for example with an auditor for regulatory compliance purposes. - -A viewing key can also derive several diversified addresses. -An address can be used to receive funds, much like the address of a -user account. +Sapling uses different kinds of keys, each allowing different operations: + +* The main keys used in Sapling transactions, sometimes referred to as *spending keys*, are ordinary keys that allow users to make transactions. + In the context of Sapling, they allow the holders to view all outgoing and incoming transactions for the related account. + As with any ordinary key, if the key is compromised, funds can be lost. + +* From a spending key, users can generate *viewing keys*, which allow the holder to view the incoming and outgoing transactions from the associated spending key but not make any transactions. + Viewing keys can be useful for spending key owners to verify their balances and transaction histories without risking their spending keys and therefore their funds. + Users can also share viewing keys with other users, such as with auditors for regulatory compliance purposes. + + Viewing keys also allow users to generate multiple recipient addresses. + Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. -Additionally *proving keys* can be used to allow the creation of proofs, -thus revealing private information, without being able to spend funds. -They are useful for example in case the spending key is stored in a -hardware wallet but we'd like to use our laptop to craft the -transaction and produce the zero-knowledge proofs, which are -computationally too intensive for an embedded device. +* From a spending key, users can also generate *proving keys*, which reveal specific private information about a spending key but not all of it. + Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. + Users can generate a proving key to use on a device with more computational power without risking their spending keys and therefore their funds. More details can be found in the `specification document `_. @@ -63,12 +57,12 @@ Transactions of this form are privacy preserving and are referred to as *shielded*, because they reveal neither the amount, the sender nor the receiver. -The existing set of transactions is referred to as the *shielded pool*. +The existing set of transactions is referred to as the *shielded set*. Unlike Bitcoin, where everybody can compute the set of unspent outputs of every user, in Sapling only the owner of a viewing key can find their outputs and verify that they are not already spent. For this reason, to an external -observer, the shielded pool is always increasing in size and the more +observer, the shielded set is always increasing in size and the more transactions are added the harder it is to pinpoint the commitments belonging to a user. @@ -79,14 +73,14 @@ This data is encrypted under a symmetric key resulting from a Diffie-Hellman key exchange using the recipient address and an ephemeral key. In principle this *ciphertext* can be transmitted off-chain as it's -not needed to verify the integrity of the pool. For convenience, in +not needed to verify the integrity of the set. For convenience, in Tezos, it is stored together with the commitment and the nullifier on chain. For reasons of efficiency the commitments are stored in an incremental `Merkle tree `_ which allows for compact proofs of membership. The root of the tree is all -that is needed to refer to a certain state of the shielded pool. +that is needed to refer to a certain state of the shielded set. In order to ensure the correctness of a transaction, given that there is information that we wish to remain secret, the spender must also @@ -120,7 +114,7 @@ account in the ``bound_data``, which is signed by the owner of the Sapling keys, and that can be used by the Smart Contract to transfer the tokens. -**All Smart Contracts managing a Sapling shielded pool must include a +**All smart contracts managing a Sapling shielded set must include a `bound_data` field in their unshield operations.** Note that the ``bound_data`` field is not encrypted and could leak @@ -132,7 +126,7 @@ linking a shielded and a transparent address. Privacy guarantees ~~~~~~~~~~~~~~~~~~ -We explained that the shielded pool contains one commitment for each +We explained that the shielded set contains one commitment for each input (spent or not), and one nullifier for each spent input. These cryptographic commitments hide the amount and the owner of the tokens they represent. @@ -144,9 +138,9 @@ transaction is public, which could help link a class of transactions. This problem can be mitigated by adding any number of dummy inputs or outputs at the cost of wasting some space. -The shielded pool communicates with the public ledger by minting and +The shielded set communicates with the public ledger by minting and burning shielded tokens in exchange for public coins. -Therefore going in and out of the shielded pool is public: we know +Therefore going in and out of the shielded set is public: we know which address shielded or unshielded and how much. We can among other things infer the total number of shielded coins. @@ -173,7 +167,7 @@ unshield 15.3 tez to tz1-bob. It's fairly clear from timing and amounts that Alice transferred 15.3 tez to Bob. To decorrelate the two transfers it is important to change the amounts, let some time pass between the two and perform the -transactions when there is traffic in the pool. +transactions when there is traffic in the set. Similar problems exist in Zcash and they are illustrated in this introductory `blog post `_. @@ -270,8 +264,8 @@ Example contracts Shielded tez ^^^^^^^^^^^^ -An example contract implementing a shielded pool of tokens with a 1 to 1 conversion rate to mutez is available in the tests of the protocol at -:src:`src/proto_alpha/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz`. +An example contract implementing a shielded set of tokens with a 1 to 1 conversion rate to mutez is available in the tests of the protocol at +:src:`src/proto_024_PtTALLiN/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz`. Simple Voting Contract ^^^^^^^^^^^^^^^^^^^^^^ @@ -308,7 +302,7 @@ Fees issue ~~~~~~~~~~ The Sapling integration in Tezos exhibits a privacy issue that Z-cash doesn't have. When -interacting with a shielded pool one interacts with a smart contract +interacting with a shielded set one interacts with a smart contract via a normal transaction and therefore have to pay fees from a user account. One could guess that private transactions whose fees are paid by the diff --git a/docs/tallinn/sapling.rst b/docs/tallinn/sapling.rst index 295cc4497ad2..a3582185e34d 100644 --- a/docs/tallinn/sapling.rst +++ b/docs/tallinn/sapling.rst @@ -1,43 +1,37 @@ Sapling support =============== -This page first give some details on Sapling and its underlying concepts, and then describes the support for Sapling in Octez and in the Michelson language (part of the Tezos protocol). +This page first gives some details on Sapling and its underlying concepts, and then describes the support for Sapling in Octez and in the Michelson language (part of the Tezos protocol). For support in high-level smart contract languages, see the `Sapling documentation in OpenTezos `__. Sapling ------- -Sapling is a protocol enabling privacy-preserving transactions of fungible -tokens in a decentralised -environment. It was designed and implemented by the Electric Coin -Company as the last iteration over a series of previous protocols and -academic works starting with the `Zerocoin seminal -paper `__. +Sapling is a protocol that enhances privacy for transactions of fungible tokens. It creates a set of transactions called a *shielded set* +that can be viewed only by specific entities. It was designed and +implemented by the Electric Coin Company as the last iteration over a +series of previous protocols and academic works starting with the +`Zerocoin seminal paper `__. Keys ~~~~ -Sapling offers a rich set of keys, each allowing different operations. -A *spending key* allows to spend tokens so if it is lost or -compromised the tokens could remain locked or be stolen. -From a spending key it is possible to derive a corresponding *viewing -key* which allows to view all incoming and outgoing transactions. -The viewing key allows the owner of the tokens to check their balance -and transaction history so if compromised there is a complete loss of -privacy. -On the other hand a viewing key can willingly be shared with a third -party, for example with an auditor for regulatory compliance purposes. - -A viewing key can also derive several diversified addresses. -An address can be used to receive funds, much like the address of a -user account. +Sapling uses different kinds of keys, each allowing different operations: + +* The main keys used in Sapling transactions, sometimes referred to as *spending keys*, are ordinary keys that allow users to make transactions. + In the context of Sapling, they allow the holders to view all outgoing and incoming transactions for the related account. + As with any ordinary key, if the key is compromised, funds can be lost. + +* From a spending key, users can generate *viewing keys*, which allow the holder to view the incoming and outgoing transactions from the associated spending key but not make any transactions. + Viewing keys can be useful for spending key owners to verify their balances and transaction histories without risking their spending keys and therefore their funds. + Users can also share viewing keys with other users, such as with auditors for regulatory compliance purposes. + + Viewing keys also allow users to generate multiple recipient addresses. + Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. -Additionally *proving keys* can be used to allow the creation of proofs, -thus revealing private information, without being able to spend funds. -They are useful for example in case the spending key is stored in a -hardware wallet but we'd like to use our laptop to craft the -transaction and produce the zero-knowledge proofs, which are -computationally too intensive for an embedded device. +* From a spending key, users can also generate *proving keys*, which reveal specific private information about a spending key but not all of it. + Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. + Users can generate a proving key to use on a device with more computational power without risking their spending keys and therefore their funds. More details can be found in the `specification document `_. @@ -63,12 +57,12 @@ Transactions of this form are privacy preserving and are referred to as *shielded*, because they reveal neither the amount, the sender nor the receiver. -The existing set of transactions is referred to as the *shielded pool*. +The existing set of transactions is referred to as the *shielded set*. Unlike Bitcoin, where everybody can compute the set of unspent outputs of every user, in Sapling only the owner of a viewing key can find their outputs and verify that they are not already spent. For this reason, to an external -observer, the shielded pool is always increasing in size and the more +observer, the shielded set is always increasing in size and the more transactions are added the harder it is to pinpoint the commitments belonging to a user. @@ -79,14 +73,14 @@ This data is encrypted under a symmetric key resulting from a Diffie-Hellman key exchange using the recipient address and an ephemeral key. In principle this *ciphertext* can be transmitted off-chain as it's -not needed to verify the integrity of the pool. For convenience, in +not needed to verify the integrity of the set. For convenience, in Tezos, it is stored together with the commitment and the nullifier on chain. For reasons of efficiency the commitments are stored in an incremental `Merkle tree `_ which allows for compact proofs of membership. The root of the tree is all -that is needed to refer to a certain state of the shielded pool. +that is needed to refer to a certain state of the shielded set. In order to ensure the correctness of a transaction, given that there is information that we wish to remain secret, the spender must also @@ -120,7 +114,7 @@ account in the ``bound_data``, which is signed by the owner of the Sapling keys, and that can be used by the Smart Contract to transfer the tokens. -**All Smart Contracts managing a Sapling shielded pool must include a +**All smart contracts managing a Sapling shielded set must include a `bound_data` field in their unshield operations.** Note that the ``bound_data`` field is not encrypted and could leak @@ -132,7 +126,7 @@ linking a shielded and a transparent address. Privacy guarantees ~~~~~~~~~~~~~~~~~~ -We explained that the shielded pool contains one commitment for each +We explained that the shielded set contains one commitment for each input (spent or not), and one nullifier for each spent input. These cryptographic commitments hide the amount and the owner of the tokens they represent. @@ -144,9 +138,9 @@ transaction is public, which could help link a class of transactions. This problem can be mitigated by adding any number of dummy inputs or outputs at the cost of wasting some space. -The shielded pool communicates with the public ledger by minting and +The shielded set communicates with the public ledger by minting and burning shielded tokens in exchange for public coins. -Therefore going in and out of the shielded pool is public: we know +Therefore going in and out of the shielded set is public: we know which address shielded or unshielded and how much. We can among other things infer the total number of shielded coins. @@ -173,7 +167,7 @@ unshield 15.3 tez to tz1-bob. It's fairly clear from timing and amounts that Alice transferred 15.3 tez to Bob. To decorrelate the two transfers it is important to change the amounts, let some time pass between the two and perform the -transactions when there is traffic in the pool. +transactions when there is traffic in the set. Similar problems exist in Zcash and they are illustrated in this introductory `blog post `_. @@ -270,7 +264,7 @@ Example contracts Shielded tez ^^^^^^^^^^^^ -An example contract implementing a shielded pool of tokens with a 1 to 1 conversion rate to mutez is available in the tests of the protocol at +An example contract implementing a shielded set of tokens with a 1 to 1 conversion rate to mutez is available in the tests of the protocol at :src:`src/proto_024_PtTALLiN/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz`. Simple Voting Contract @@ -308,7 +302,7 @@ Fees issue ~~~~~~~~~~ The Sapling integration in Tezos exhibits a privacy issue that Z-cash doesn't have. When -interacting with a shielded pool one interacts with a smart contract +interacting with a shielded set one interacts with a smart contract via a normal transaction and therefore have to pay fees from a user account. One could guess that private transactions whose fees are paid by the -- GitLab From d3bace135f976b9478b4d3a693c4ddfefb09f36e Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 08:07:04 -0500 Subject: [PATCH 2/8] Wrong protocol -- this is the alpha page --- docs/alpha/sapling.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index d7ff5c6648a1..613f8ae1e0ad 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -265,7 +265,7 @@ Shielded tez ^^^^^^^^^^^^ An example contract implementing a shielded set of tokens with a 1 to 1 conversion rate to mutez is available in the tests of the protocol at -:src:`src/proto_024_PtTALLiN/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz`. +:src:`src/proto_alpha/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz`. Simple Voting Contract ^^^^^^^^^^^^^^^^^^^^^^ -- GitLab From be1679475b97a1c4e3ee8cded1fe1a40df89a3a6 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 08:11:29 -0500 Subject: [PATCH 3/8] Suggestions --- docs/alpha/sapling.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 613f8ae1e0ad..ede8f03a4aa5 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -29,9 +29,10 @@ Sapling uses different kinds of keys, each allowing different operations: Viewing keys also allow users to generate multiple recipient addresses. Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. -* From a spending key, users can also generate *proving keys*, which reveal specific private information about a spending key but not all of it. +* From a spending key, users can also generate *proving keys*, which allow the creation of proofs, +revealing selected private information, but do not allow to spend funds. Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. - Users can generate a proving key to use on a device with more computational power without risking their spending keys and therefore their funds. + Users can generate a proving key to use on a device with more computational power without risking to reveal their spending key. More details can be found in the `specification document `_. -- GitLab From 9899611086d676be78ee0bc4489dc7f771cbbddc Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 08:13:01 -0500 Subject: [PATCH 4/8] Grammar and RST formatting --- docs/alpha/sapling.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index ede8f03a4aa5..5b3f1480ecd9 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -29,10 +29,10 @@ Sapling uses different kinds of keys, each allowing different operations: Viewing keys also allow users to generate multiple recipient addresses. Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. -* From a spending key, users can also generate *proving keys*, which allow the creation of proofs, -revealing selected private information, but do not allow to spend funds. +* From a spending key, users can also generate *proving keys*, which allow them to create proofs, + revealing selected private information, but do not allow spending funds. Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. - Users can generate a proving key to use on a device with more computational power without risking to reveal their spending key. + Users can generate a proving key to use on a device with more computational power without risking revealing their spending key. More details can be found in the `specification document `_. -- GitLab From 980e0110c778671b96ad6f6ebd33a64661f70cef Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 13:41:24 -0500 Subject: [PATCH 5/8] Grammar --- docs/alpha/sapling.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 5b3f1480ecd9..723944bc6728 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -1,7 +1,7 @@ Sapling support =============== -This page first give some details on Sapling and its underlying concepts, and then describes the support for Sapling in Octez and in the Michelson language (part of the Tezos protocol). +This page first gives some details on Sapling and its underlying concepts, and then describes the support for Sapling in Octez and in the Michelson language (part of the Tezos protocol). For support in high-level smart contract languages, see the `Sapling documentation in OpenTezos `__. Sapling -- GitLab From 562dbfb5cab4a31f529496790e5177f76dae12b7 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 13:41:45 -0500 Subject: [PATCH 6/8] Revert intro to sapling --- docs/alpha/sapling.rst | 3 ++- docs/tallinn/sapling.rst | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 723944bc6728..c0fc82d2e4f0 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -7,7 +7,8 @@ For support in high-level smart contract languages, see the `Sapling documentati Sapling ------- -Sapling is a protocol that enhances privacy for transactions of fungible tokens. It creates a set of transactions called a *shielded set* +Sapling is a protocol enabling privacy-preserving transactions for transactions of fungible tokens. +It creates a set of transactions called a *shielded set* that can be viewed only by specific entities. It was designed and implemented by the Electric Coin Company as the last iteration over a series of previous protocols and academic works starting with the diff --git a/docs/tallinn/sapling.rst b/docs/tallinn/sapling.rst index a3582185e34d..3c1244925dfd 100644 --- a/docs/tallinn/sapling.rst +++ b/docs/tallinn/sapling.rst @@ -7,7 +7,8 @@ For support in high-level smart contract languages, see the `Sapling documentati Sapling ------- -Sapling is a protocol that enhances privacy for transactions of fungible tokens. It creates a set of transactions called a *shielded set* +Sapling is a protocol enabling privacy-preserving transactions for transactions of fungible tokens. +It creates a set of transactions called a *shielded set* that can be viewed only by specific entities. It was designed and implemented by the Electric Coin Company as the last iteration over a series of previous protocols and academic works starting with the -- GitLab From 06c1cf9a3e3bb404d0571c2aeb6c1e0fe9c6ad04 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 13:42:17 -0500 Subject: [PATCH 7/8] Revert clearer explanation of keys --- docs/alpha/sapling.rst | 35 ++++++++++++++++++++--------------- docs/tallinn/sapling.rst | 34 ++++++++++++++++++++-------------- 2 files changed, 40 insertions(+), 29 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index c0fc82d2e4f0..23d48df0f42c 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -17,23 +17,28 @@ series of previous protocols and academic works starting with the Keys ~~~~ -Sapling uses different kinds of keys, each allowing different operations: - -* The main keys used in Sapling transactions, sometimes referred to as *spending keys*, are ordinary keys that allow users to make transactions. - In the context of Sapling, they allow the holders to view all outgoing and incoming transactions for the related account. - As with any ordinary key, if the key is compromised, funds can be lost. - -* From a spending key, users can generate *viewing keys*, which allow the holder to view the incoming and outgoing transactions from the associated spending key but not make any transactions. - Viewing keys can be useful for spending key owners to verify their balances and transaction histories without risking their spending keys and therefore their funds. - Users can also share viewing keys with other users, such as with auditors for regulatory compliance purposes. +Sapling offers a rich set of keys, each allowing different operations. +A *spending key* allows to spend tokens so if it is lost or +compromised the tokens could remain locked or be stolen. +From a spending key it is possible to derive a corresponding *viewing +key* which allows to view all incoming and outgoing transactions. +The viewing key allows the owner of the tokens to check their balance +and transaction history so if compromised there is a complete loss of +privacy. +On the other hand a viewing key can willingly be shared with a third +party, for example with an auditor for regulatory compliance purposes. + +A viewing key can also derive several diversified addresses. +An address can be used to receive funds, much like the address of a +user account. - Viewing keys also allow users to generate multiple recipient addresses. - Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. +Additionally *proving keys* can be used to allow the creation of proofs, +thus revealing private information, without being able to spend funds. +They are useful for example in case the spending key is stored in a +hardware wallet but we'd like to use our laptop to craft the +transaction and produce the zero-knowledge proofs, which are +computationally too intensive for an embedded device. -* From a spending key, users can also generate *proving keys*, which allow them to create proofs, - revealing selected private information, but do not allow spending funds. - Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. - Users can generate a proving key to use on a device with more computational power without risking revealing their spending key. More details can be found in the `specification document `_. diff --git a/docs/tallinn/sapling.rst b/docs/tallinn/sapling.rst index 3c1244925dfd..6abedab3aa6f 100644 --- a/docs/tallinn/sapling.rst +++ b/docs/tallinn/sapling.rst @@ -17,22 +17,28 @@ series of previous protocols and academic works starting with the Keys ~~~~ -Sapling uses different kinds of keys, each allowing different operations: - -* The main keys used in Sapling transactions, sometimes referred to as *spending keys*, are ordinary keys that allow users to make transactions. - In the context of Sapling, they allow the holders to view all outgoing and incoming transactions for the related account. - As with any ordinary key, if the key is compromised, funds can be lost. - -* From a spending key, users can generate *viewing keys*, which allow the holder to view the incoming and outgoing transactions from the associated spending key but not make any transactions. - Viewing keys can be useful for spending key owners to verify their balances and transaction histories without risking their spending keys and therefore their funds. - Users can also share viewing keys with other users, such as with auditors for regulatory compliance purposes. +Sapling offers a rich set of keys, each allowing different operations. +A *spending key* allows to spend tokens so if it is lost or +compromised the tokens could remain locked or be stolen. +From a spending key it is possible to derive a corresponding *viewing +key* which allows to view all incoming and outgoing transactions. +The viewing key allows the owner of the tokens to check their balance +and transaction history so if compromised there is a complete loss of +privacy. +On the other hand a viewing key can willingly be shared with a third +party, for example with an auditor for regulatory compliance purposes. + +A viewing key can also derive several diversified addresses. +An address can be used to receive funds, much like the address of a +user account. - Viewing keys also allow users to generate multiple recipient addresses. - Users can send funds to these recipient addresses and the funds go to the spending key without exposing its identity to the senders. +Additionally *proving keys* can be used to allow the creation of proofs, +thus revealing private information, without being able to spend funds. +They are useful for example in case the spending key is stored in a +hardware wallet but we'd like to use our laptop to craft the +transaction and produce the zero-knowledge proofs, which are +computationally too intensive for an embedded device. -* From a spending key, users can also generate *proving keys*, which reveal specific private information about a spending key but not all of it. - Proving keys are useful when the spending key is stored on a hardware wallet, which may not have the computational power to generate zero-knowledge proofs. - Users can generate a proving key to use on a device with more computational power without risking their spending keys and therefore their funds. More details can be found in the `specification document `_. -- GitLab From 6adfda28f8b8107c67bd9e23919dd03644146a55 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Dec 2025 13:43:37 -0500 Subject: [PATCH 8/8] building upon the contributions from --- docs/alpha/sapling.rst | 3 +-- docs/tallinn/sapling.rst | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 23d48df0f42c..e221960723b9 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -10,8 +10,7 @@ Sapling Sapling is a protocol enabling privacy-preserving transactions for transactions of fungible tokens. It creates a set of transactions called a *shielded set* that can be viewed only by specific entities. It was designed and -implemented by the Electric Coin Company as the last iteration over a -series of previous protocols and academic works starting with the +implemented by the Electric Coin Company, itself building upon the contributions from previous protocols and academic research, starting with the `Zerocoin seminal paper `__. Keys diff --git a/docs/tallinn/sapling.rst b/docs/tallinn/sapling.rst index 6abedab3aa6f..e8479dc337de 100644 --- a/docs/tallinn/sapling.rst +++ b/docs/tallinn/sapling.rst @@ -10,8 +10,7 @@ Sapling Sapling is a protocol enabling privacy-preserving transactions for transactions of fungible tokens. It creates a set of transactions called a *shielded set* that can be viewed only by specific entities. It was designed and -implemented by the Electric Coin Company as the last iteration over a -series of previous protocols and academic works starting with the +implemented by the Electric Coin Company, itself building upon the contributions from previous protocols and academic research, starting with the `Zerocoin seminal paper `__. Keys -- GitLab