diff --git a/_includes/content/consensus-mechanisms/03-Introduction-to-Applications-of-Byzantine-Consensus-Mechanisms.md b/_includes/content/consensus-mechanisms/03-Introduction-to-Applications-of-Byzantine-Consensus-Mechanisms.md index 45382569..82dbfa59 100644 --- a/_includes/content/consensus-mechanisms/03-Introduction-to-Applications-of-Byzantine-Consensus-Mechanisms.md +++ b/_includes/content/consensus-mechanisms/03-Introduction-to-Applications-of-Byzantine-Consensus-Mechanisms.md @@ -181,7 +181,7 @@ from the validator node and its backup(s). They do not report the validator node (PEX) and may be more strict about the quality of peers they keep. Sentry nodes belonging to validators that trust each other may wish to maintain persistent connections via Virtual -Private Network (VPN) with one another, but only report each other sparingly in the PEX [[7]]. +Private Network (VPN) with one another, but only report each other sparingly in the PEX. ## Permissionless Byzantine Fault-tolerant Protocols @@ -783,11 +783,6 @@ Date accessed: 2018‑09‑30. [6]: https://blog.cosmos.network/tendermint-explained-bringing-bft-based-pos-to-the-public-blockchain-domain-f22e274a0fdb 'Tendermint Explained - Bringing BFT-based PoS to the Public Blockchain Domain' -[[7]] "Tendermint Peer Discovery" [online]. Available: . -Date accessed: 2018‑10‑22. - -[7]: https://github.com/tendermint/tendermint/blob/master/docs/spec/p2p/node.md 'Tendermint Peer Discovery' - [[8]] Wikipedia: "Paxos" [online]. Available: . Date accessed: 2018‑10‑01. @@ -874,10 +869,10 @@ Available: . Date accesse [22]: http://www.cs.yale.edu/homes/aspnes/papers/jalg90.pdf 'Fast Randomized Consensus using Shared Memory' [[23]] "Prototol for Asynchronous, Reliable, Secure and Efficient Consensus" [online]. Available: -. +. Date accessed 2018‑10‑22. -[23]: https://github.com/maidsafe/parsec 'GitHub repository: Protocol for Asynchronous, +[23]: https://arxiv.org/abs/1907.11445 'GitHub repository: Protocol for Asynchronous, Reliable, Secure and Efficient Consensus' [[25]] "Red Belly Blockchain" [online]. Available: . Date accessed: @@ -910,10 +905,10 @@ Available: . Date acce Algorithm' [[30]] J. Kwon, "TenderMint: Consensus without Mining" [online]. -Available: . +Available: . Date accessed: 2018‑09‑20. -[30]: http://the-eye.eu/public/Books/campdivision.com/PDF/Computers%20General/Privacy/bitcoin/tendermint_v05.pdf 'Tendermint: Consensus without Mining' +[30]: https://tendermint.com/static/docs/tendermint.pdf 'Tendermint: Consensus without Mining' [[31]] Y. Yang, "LinBFT: Linear-Communication Byzantine Fault Tolerance for Public Blockchains" [online]. Available: . Date accessed: 2018‑09‑20. @@ -921,10 +916,10 @@ Available: . Date accessed: 2018‑09& [31]: https://arxiv.org/pdf/1807.01829.pdf 'LinBFT: Linear-Communication Byzantine Fault Tolerance for Public Blockchains' -[[32]] "Protocol Spotlight: Avalanche Part 1" [online]. Available: . +[[32]] "Protocol Spotlight: Avalanche Part 1" [online]. Available: . Date Accessed: 2018‑09‑09. -[32]: https://flatoutcrypto.com/home/avalancheprotocol 'Protocol Spotlight: Avalanche Part 1' +[32]: https://hackernoon.com/protocol-spotlight-avalanche-3f5dfd366a26 'Protocol Spotlight: Avalanche Part 1' [[33]] P. Chevalier, B. Kaminski, F. Hutchison, Q. Ma and S. Sharma, "Protocol for Asynchronous, Reliable, Secure and Efficient Consensus (PARSEC)". White Paper [online]. Available: . @@ -1067,7 +1062,7 @@ require three instances of reliable broadcast for a single round of communicatio As briefly mentioned in the [Introduction](#introduction), the scalability of BFT protocols considering the number of participants is highly limited and the performance of most protocols deteriorates as the number of involved replicas -increases. This effect is especially problematic for BFT deployment in permissionless blockchains [[7]]. +increases. This effect is especially problematic for BFT deployment in permissionless blockchains. The problem of BFT scalability is twofold: a high throughput, as well as a large consensus group with good reconfigurability that can tolerate a high number of failures are both desirable properties in BFT protocols. However, diff --git a/_includes/content/course1-blockchain/03-module3.md b/_includes/content/course1-blockchain/03-module3.md index a26454f3..2efe6327 100644 --- a/_includes/content/course1-blockchain/03-module3.md +++ b/_includes/content/course1-blockchain/03-module3.md @@ -42,7 +42,7 @@ Maybe I made a couple of copies of that digital apple on my computer. Maybe I pu As you see, this digital exchange is a bit of a problem. **Sending _digital_ apples doesn’t look like sending _physical_ apples.** -Some brainy computer scientists actually have a name for this problem: it’s called the [**double-spending problem**](http://blogs.cornell.edu/info4220/2013/03/29/bitcoin-and-the-double-spending-problem/){:target="_blank"}. But don’t worry about it. All you need to know is that, it’s confused them for quite some time and they’ve never solved it. +Some brainy computer scientists actually have a name for this problem: it’s called the [**double-spending problem**](https://www.sofi.com/learn/content/double-spending/){:target="\_blank"}. But don’t worry about it. All you need to know is that, it’s confused them for quite some time and they’ve never solved it. Until now. @@ -62,11 +62,11 @@ Say, just like World of Warcraft. _Blizzard_, the guys who created the online ga There’s a bit of a problem though: -1) What if some guy over at _Blizzard_ created more? He could just add a couple of digital apples to his balance whenever he wants! +1. What if some guy over at _Blizzard_ created more? He could just add a couple of digital apples to his balance whenever he wants! -2) It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through _Blizzard_ is like pulling in Uncle Tommy(_a third-party_) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way? +2. It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through _Blizzard_ is like pulling in Uncle Tommy(_a third-party_) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way? ->Is there any way to closely replicate our park bench, just you-and-me, transaction **digitally**? Seems kinda tough… +> Is there any way to closely replicate our park bench, just you-and-me, transaction **digitally**? Seems kinda tough… # The Solution @@ -76,9 +76,9 @@ What if we gave this ledger — to **everybody**? Instead of the ledger living o You can’t cheat it. I can’t send you digital apples I don’t have, because then it wouldn’t _sync up_ with everybody in the system. It’d be a tough system to beat. Especially if it got really big. -Plus it’s not controlled by _one person_, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already _defined at the beginning_. And the code and rules are [open-source](http://en.wikipedia.org/wiki/Open_source){:target="_blank"}. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on. +Plus it’s not controlled by _one person_, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already _defined at the beginning_. And the code and rules are [open-source](http://en.wikipedia.org/wiki/Open_source){:target="\_blank"}. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on. -You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like [25 digital apples](https://www.weusecoins.com/en/mining-guide){:target="_blank"} as a reward. In fact, that’s the only way to create more digital apples in the system. +You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like [25 digital apples](https://www.weusecoins.com/en/mining-guide){:target="\_blank"} as a reward. In fact, that’s the only way to create more digital apples in the system. # I simplified quite a bit @@ -86,9 +86,9 @@ You could participate in this network too and update the ledger and make sure it So, did you see what happened? **What does the public ledger enable?** -1) It’s open source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. **_Within the system,_ I know they are limited(_scarce)_**. +1. It’s open source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. **_Within the system,_ I know they are limited(_scarce)_**. -2) When I make an exchange I now know that _digital_ apple certifiably **left my possession and is now completely yours**. **I used to not be able to say that about digital things.** It will be updated and verified by the public ledger. +2. When I make an exchange I now know that _digital_ apple certifiably **left my possession and is now completely yours**. **I used to not be able to say that about digital things.** It will be updated and verified by the public ledger. 3)Because it’s a public ledger, **I didn’t need Uncle Tommy(third-party**) to make sure I didn’t cheat, or make extra copies for myself, or send apples twice, or thrice… @@ -102,18 +102,18 @@ I can even make _other digital things_ ride _on top_ of these digital apples! It So this is great! How should we treat or value these “digital apples”? They’re quite useful aren’t they? -Well, a lot of people are arguing over it now. There’s debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: [$1,300 per apple](http://www.forbes.com/sites/kashmirhill/2013/12/05/bank-of-america-analysts-say-bitcoins-value-is-1300/){:target="_blank"}. Some say it’s _digital gold_, some a _currency_. Other say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad. +Well, a lot of people are arguing over it now. There’s debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: [$1,300 per apple](http://www.forbes.com/sites/kashmirhill/2013/12/05/bank-of-america-analysts-say-bitcoins-value-is-1300/){:target="_blank"}. Some say it’s \_digital gold_, some a _currency_. Other say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad. -I have [my own opinion](http://nikcustodio.tumblr.com/post/150500263430/why-blockchains-an-eli21){:target="_blank"} about it. +I have [my own opinion](http://nikcustodio.tumblr.com/post/150500263430/why-blockchains-an-eli21){:target="\_blank"} about it. That’s a story for another time though. But kid, you now know more about Bitcoin than most. **_Recommend Reading (Updated 2017)_** -[_“You Don’t Understand Bitcoin Because You Think Money is Real”_](https://medium.com/@mariabustillos/you-dont-understand-bitcoin-because-you-think-money-is-real-5aef45b8e952?source=linkShare-2d6f142ff3cc-1512362100){:target="_blank"} _by_ +[_“You Don’t Understand Bitcoin Because You Think Money is Real”_](https://medium.com/@mariabustillos/you-dont-understand-bitcoin-because-you-think-money-is-real-5aef45b8e952?source=linkShare-2d6f142ff3cc-1512362100){:target="_blank"} \_by_ -[_Maria Bustillos_](https://medium.com/u/539043fdc07d?source=post_page-----73b4257ac833-----------------------------------){:target="_blank"} +[_Maria Bustillos_](https://medium.com/u/539043fdc07d?source=post_page-----73b4257ac833-----------------------------------){:target="\_blank"} _is a good follow-up read._ -_You can also read more about_ [_Ethereum and Smart Contracts here_](https://medium.com/free-code-camp/smart-contracts-for-dummies-a1ba1e0b9575){:target="_blank"}. _Enjoy!_ +_You can also read more about_ [_Ethereum and Smart Contracts here_](https://medium.com/free-code-camp/smart-contracts-for-dummies-a1ba1e0b9575){:target="_blank"}. \_Enjoy!_ diff --git a/_includes/content/cryptography/03-introduction-to-scriptless-scripts.md b/_includes/content/cryptography/03-introduction-to-scriptless-scripts.md index bafea7b8..2f2592b7 100644 --- a/_includes/content/cryptography/03-introduction-to-scriptless-scripts.md +++ b/_includes/content/cryptography/03-introduction-to-scriptless-scripts.md @@ -94,7 +94,7 @@ A multi-signature (multisig) has multiple participants that produce a signature. separate signature and concatenate them, forming a multisig. With Schnorr Signatures, one can have a single public key, which is the sum of many different people's public keys. The -resulting key is one against which signatures will be verifiable [[5]]. +resulting key is one against which signatures will be verifiable. The formulation of a multisig involves taking the sum of all components; thus all nonces and $s$ values result in the formulation of a multisig [[4]]: @@ -276,11 +276,6 @@ Available: . Date accessed: November 2017. - -[5]: https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/ 'Flipping the Scriptless Script on Schnorr' - [[6]] "The First Successful Zero-knowledge Contingent Payment" [online]. Available: . Date accessed: 2016‑02‑26. diff --git a/_includes/content/cryptography/04-The_MuSig_Schnorr_Signature_Scheme.md b/_includes/content/cryptography/04-The_MuSig_Schnorr_Signature_Scheme.md index 51565f51..7de14e1c 100644 --- a/_includes/content/cryptography/04-The_MuSig_Schnorr_Signature_Scheme.md +++ b/_includes/content/cryptography/04-The_MuSig_Schnorr_Signature_Scheme.md @@ -18,7 +18,7 @@ - [Notation Used](#notation-used) - [Recap on Schnorr Signature Scheme](#recap-on-schnorr-signature-scheme) - [Design of Schnorr Multi-signature Scheme](#design-of-schnorr-multi-signature-scheme) - - [Bellare and Neven Signature Scheme](#bellare-and-neven-signature-scheme) + - [Bellare and Neven Signature Scheme](#bellare-and-neven-signature-scheme) - [MuSig Signature Scheme](#musig-signature-scheme) - [Revisions](#revisions) - [Turning Bellare and Neven's Scheme into an IAS Scheme](#turning-bellare-and-nevens-scheme-into-an-ias-scheme) @@ -29,10 +29,10 @@ ## Introduction This report investigates Schnorr Multi-Signature Schemes (MuSig), which make use of key aggregation and are provably -secure in the *plain public-key model*. +secure in the _plain public-key model_. Signature aggregation involves mathematically combining several signatures into a single signature, without having to -prove Knowledge of Secret Keys (KOSK). This is known as the *plain public-key model,* where the only requirement is that +prove Knowledge of Secret Keys (KOSK). This is known as the _plain public-key model,_ where the only requirement is that each potential signer has a public key. The KOSK scheme requires that users prove knowledge (or possession) of the secret key during public key registration with a certification authority. It is one way to generically prevent rogue-key attacks. @@ -40,8 +40,6 @@ attacks. Multi-signatures are a form of technology used to add multiple participants to cryptocurrency transactions. A traditional multi-signature protocol allows a group of signers to produce a joint multi-signature on a common message. - - ### Schnorr Signatures and their Attack Vectors Schnorr signatures produce a smaller on-chain size, support faster validation and have better privacy. They natively @@ -50,7 +48,7 @@ allow for combining multiple signatures into one through aggregation, and they p Signature aggregation also has its challenges. This includes the rogue-key attack, where a participant steals funds using a specifically constructed key. Although this is easily solved for simple multi-signatures through an enrollment procedure that involves the keys signing themselves, supporting it across multiple inputs of a transaction requires -*plain public-key security*, meaning there is no setup. +_plain public-key security_, meaning there is no setup. There is an additional attack, named the Russel attack, after Russel O'Connor, who discovered that for multiparty schemes, a party could claim ownership of someone else's private key and so spend the other outputs. @@ -59,8 +57,6 @@ P. Wuille [[1]] addressed some of these issues and provided a solution that scheme. He also discussed the performance improvements that were implemented for the scaler multiplication of the BN scheme and how they enable batch validation on the blockchain [[2]]. - - ### MuSig Multi-signature protocols, introduced by [[3]], allow a group of signers (that individually possess their own private/ @@ -82,19 +78,17 @@ requirement. MuSig is a multi-signature scheme that is novel in combining: - support for key aggregation; and -- security in the *plain public-key model*. +- security in the _plain public-key model_. There are two versions of MuSig that are provably secure, and which differ based on the number of communication rounds: 1. Three-round MuSig, which only relies on the Discrete Logarithm (DL) assumption, on which Elliptic Curve Digital -Signature Algorithm (ECDSA) also relies. + Signature Algorithm (ECDSA) also relies. 2. Two-round MuSig, which instead relies on the slightly stronger One-More Discrete Logarithm (OMDL) assumption. - - ### Key Aggregation -The term *key aggregation* refers to multi-signatures that look like a single-key signature, but with respect to an +The term _key aggregation_ refers to multi-signatures that look like a single-key signature, but with respect to an aggregated public key that is a function of only the participants' public keys. Thus, verifiers do not require the knowledge of the original participants' public keys. They can just be given the aggregated key. In some use cases, this leads to better privacy and performance. Thus, MuSig is effectively a key aggregation scheme for Schnorr signatures. @@ -102,9 +96,9 @@ leads to better privacy and performance. Thus, MuSig is effectively a key aggreg To make the traditional approach more effective and without needing a trusted setup, a multi-signature scheme must provide sublinear signature aggregation, along with the following properties: -- It must be provably secure in the *plain public-key model*. +- It must be provably secure in the _plain public-key model_. - It must satisfy the normal Schnorr equation, whereby the resulting signature can be written as a function of a -combination of the public keys. + combination of the public keys. - It must allow for Interactive Aggregate Signatures (IAS), where the signers are required to cooperate. - It must allow for Non-interactive Aggregate Signatures (NAS). where the aggregation can be done by anyone. - It must allow each signer to sign the same message. @@ -115,11 +109,9 @@ of these properties. Other multi-signature schemes that already exist, provide key aggregation for Schnorr signatures. However, they come with some limitations, such as needing to verify that participants actually have the private key corresponding to the -pubic keys that they claim to have. *Security in the plain public-key model* means that no limitations exist. All that +pubic keys that they claim to have. _Security in the plain public-key model_ means that no limitations exist. All that is needed from the participants is their public keys [[1]]. - - ## Overview of Multi-signatures Recently, the most obvious use case for multi-signatures is with regard to Bitcoin, where it can function as a more @@ -147,7 +139,7 @@ Currently, standard transactions on the Bitcoin network can be referred to as si require only one signature, from the owner of the private key associated with the Bitcoin address. However, the Bitcoin network supports far more complicated transactions, which can require the signatures of multiple people before the funds can be transferred. These are often referred to as $ m-of-n $ transactions, where m represents the number of -signatures required to spend, while n represents the number of signatures possible [[5]]. +signatures required to spend, while n represents the number of signatures possible . #### Use Cases for $ m-of-n $ Multi-signatures @@ -157,7 +149,7 @@ The use cases for $ m-of-n $ multi-signatures are as follows: require much security. This is the least secure multi-signature option, because it is not multifactor. Any compromised individual would jeopardize the entire group. Examples of use cases include funds for a weekend or evening event, or a shared wallet for some kind of game. Besides being convenient to spend from, the only benefit of this setup is that - all but one of the backup/password pairs could be lost and all of the funds would be recoverable. + all but one of the backup/password pairs could be lost and all of the funds would be recoverable. - When $ m=n $, it is considered a **partner wallet**, which brings with it some nervousness, as no keys can be lost. As the number of signatures required increases, the risk also increases. This type of multi-signature can be considered to @@ -168,18 +160,18 @@ The use cases for $ m-of-n $ multi-signatures are as follows: than a shared wallet, but much more secure. - When $ m>0.5n $, it is referred to as a **consensus account**. The classic multi-signature wallet is a two of three, -and is a special case of a consensus account. A two of three scheme has the best characteristics for creating new - Bitcoin addresses, and for secure storing and spending. One compromised signatory does not compromise the funds. A - single secret key can be lost and the funds can still be recovered. If done correctly, off-site backups are created - during wallet setup. The way to recover funds is known by more than one party. The balance of power with a - multi-signature wallet can be shifted by having one party control more keys than the other parties. If one party - controls multiple keys, there is a greater risk of those keys not remaining as multiple factors. + and is a special case of a consensus account. A two of three scheme has the best characteristics for creating new + Bitcoin addresses, and for secure storing and spending. One compromised signatory does not compromise the funds. A + single secret key can be lost and the funds can still be recovered. If done correctly, off-site backups are created + during wallet setup. The way to recover funds is known by more than one party. The balance of power with a + multi-signature wallet can be shifted by having one party control more keys than the other parties. If one party + controls multiple keys, there is a greater risk of those keys not remaining as multiple factors. - When $ m=0.5n $, it is referred to as a **split account**. This is an interesting use case, as there would be three of six, where one person holds three keys and three people hold one key. In this way, one person could control their own money, but the funds could still be recoverable, even if the primary key holder were to disappear with all of their keys. As $ n $ increases, the level of trust in the secondary parties can decrease. A good use case might be a family savings - account that would automatically become an inheritance account if the primary account holder were to die [[5]]. + account that would automatically become an inheritance account if the primary account holder were to die. ### Rogue Attacks @@ -190,7 +182,7 @@ Rogue attacks are a significant concern when implementing multi-signature scheme manipulate the public keys computed as functions of the public keys of honest users, allowing them to easily produce forgeries for the set of public keys (despite them not knowing the associated secret keys). -Initial proposals from [[10]], [[11]], [[12]], [[13]], [[14]], [[15]] and [[16]] were thus undone before a formal model +Initial proposals from [[10]], [[12]], [[13]], [[14]], [[15]] and [[16]] were thus undone before a formal model was put forward along with a provably secure scheme from [[17]]. Unfortunately, despite being provably secure, their scheme is costly and an impractical interactive key generation protocol [[4]]. @@ -204,7 +196,7 @@ Infrastructure (PKI), have made this solution problematic. As it stands, [[21]] provides one of the most practical multi-signature schemes, based on the Schnorr signature scheme, which is provably secure and that does not contain any assumption on the key setup. Since the only requirement of this scheme is that each potential signer has a public key, this setting is referred to as the -*plain-key model.* +_plain-key model._ Reference [[17]] solves the rogue-key attack using a sophisticated interactive key generation protocol. @@ -224,8 +216,8 @@ cosigners are organized in a tree structure for fast signature generation. ### Interactive Aggregate Signatures In some situations, it may be useful to allow each participant to sign a different message rather than a single common -one. An IAS is one where each signer has their own message $ m_{i} $ to sign, and the joint signature proves that the -$ i $ -th signer has signed $ m_{i} ​$. These schemes are considered to be more general than multi-signature schemes. +one. An IAS is one where each signer has their own message $ m*{i} $ to sign, and the joint signature proves that the +$ i $ -th signer has signed $ m*{i} ​$. These schemes are considered to be more general than multi-signature schemes. However, they are not as flexible as non-interactive aggregate signatures ([[25]], [[26]]) and sequential aggregate signatures [[27]]. @@ -234,7 +226,7 @@ signer running the multi-signature protocol to use the tuple of all public keys/ as the message. For BN's scheme and Schnorr multi-signatures, this does not increase the number of communication rounds, as messages can -be sent together with shares $ R_{i} $. +be sent together with shares $ R\_{i} $. #### Applications of Interactive Aggregate Signatures @@ -242,7 +234,7 @@ With regard to digital currency schemes, where all participants have the ability transactions consist of outputs (which have a verification key and amount) and inputs (which are references to outputs of earlier transactions). Each input contains a signature of a modified version of the transaction to be validated with its referenced output's key. Some outputs may require multiple signatures to be spent. Transactions spending such an -output are referred to as *m*-of-*n* multi-signature transactions [[28]], and the current implementation corresponds to +output are referred to as _m_-of-_n_ multi-signature transactions [[28]], and the current implementation corresponds to the trivial way of building a multi-signature scheme by concatenating individual signatures. Additionally, a threshold policy can be enforced where only $ m $ valid signatures out of the $ n $ possible ones are needed to redeem the transaction. (Again, this is the most straightforward way to turn a multi-signature scheme into some kind of basic @@ -252,10 +244,10 @@ While several multi-signature schemes could offer an improvement over the curren increase the possible impact: - The availability of key aggregation removes the need for verifiers to see all the involved keys, improving bandwidth, -privacy and validation cost. -- Security under the *plain public-key model* enables multi-signatures across multiple inputs of a transaction, where -the choice of signers cannot be committed to in advance. This greatly increases the number of situations in which -multi-signatures are beneficial. + privacy and validation cost. +- Security under the _plain public-key model_ enables multi-signatures across multiple inputs of a transaction, where + the choice of signers cannot be committed to in advance. This greatly increases the number of situations in which + multi-signatures are beneficial. #### Native Multi-signature Support @@ -280,7 +272,7 @@ under the assumption that the sender is given a proof of knowledge/possession fo these schemes are difficult to prove secure, except by using very large proofs of knowledge. As those proofs of knowledge/possession do not need to be seen by verifiers, they are effectively certified by the sender's validation. However, passing them around to senders is inconvenient, and easy to get wrong. Using a scheme that is secure in the -*plain public-key model* categorically avoids these concerns. +_plain public-key model_ categorically avoids these concerns. Another alternative is to use an algorithm whose key generation requires a trusted setup, e.g. in the KOSK model. While many of these schemes have been proven secure, they rely on mechanisms that are usually not implemented by @@ -313,46 +305,44 @@ functionality was not restricted, as it would then interfere with fungibility im to the lack of certification, security against rogue-key attacks is of great importance. If it is assumed that transactions used a single multi-signature that was vulnerable to rogue-attacks, an attacker could -identify an arbitrary number of outputs they want to steal, with the public keys $ X_{1},...,X_{n-t} $ and then use the -rogue-key attack to determine $ X_{n-t+1},...,X_{n} $ such that they can sign for the aggregated key $ \tilde{X} $. They +identify an arbitrary number of outputs they want to steal, with the public keys $ X*{1},...,X*{n-t} $ and then use the +rogue-key attack to determine $ X*{n-t+1},...,X*{n} $ such that they can sign for the aggregated key $ \tilde{X} $. They would then send a small amount of their own money to outputs with predicates corresponding to the keys -$ X_{n-t+1},...,X_{n} $. Finally, they can create a transaction that spends all of the victims' coins together with the +$ X*{n-t+1},...,X*{n} $. Finally, they can create a transaction that spends all of the victims' coins together with the ones they have just created by forging a multi-signature for the whole transaction. It can be seen that in the case of multi-signatures across inputs, theft can occur through the ability to forge a signature over a set of keys that includes at least one key which is not controlled by the attacker. According to the -*plain public-key model*, this is considered a win for the attacker. This is in contrast to the single-input +_plain public-key model_, this is considered a win for the attacker. This is in contrast to the single-input multi-signature case, where theft is only possible by forging a signature for the exact (aggregated) keys contained in an existing output. As a result, it is no longer possible to rely on proofs of knowledge/possession that are private to the signers. - - ## Formation of MuSig ### Notation Used -This section gives the general notation of mathematical expressions when specifically referenced. This information +This section gives the general notation of mathematical expressions when specifically referenced. This information is important pre-knowledge for the remainder of the report. -- Let $ p $ be a large prime number. +- Let $ p $ be a large prime number. - Let $ \mathbb{G} $ denote cyclic group of the prime order $ p $. - Let $ \mathbb Z_p $ denote the ring of integer $ modulo \mspace{4mu} p ​$. -- Let a generator of $ \mathbb{G} $ be denoted by $ g $. Thus, there exists a number $ g \in\mathbb{G} $ such that -$ \mathbb{G} = \lbrace 1, \mspace{3mu}g, \mspace{3mu}g^2,\mspace{3mu}g^3, ..., \mspace{3mu}g^{p-1} \rbrace ​$. +- Let a generator of $ \mathbb{G} $ be denoted by $ g $. Thus, there exists a number $ g \in\mathbb{G} $ such that +$ \mathbb{G} = \lbrace 1, \mspace{3mu}g, \mspace{3mu}g^2,\mspace{3mu}g^3, ..., \mspace{3mu}g^{p-1} \rbrace ​$. - Let $ \textrm{H} $ denote the hash function. -- Let $ S= \lbrace (X_{1}, m_{1}),..., (X_{n}, m_{n}) \rbrace ​$ be the multi-set of all public key/message pairs of all -participants, where $ X_{1}=g^{x_{1}} ​$. +- Let $ S= \lbrace (X*{1}, m*{1}),..., (X*{n}, m*{n}) \rbrace ​$ be the multi-set of all public key/message pairs of all + participants, where $ X*{1}=g^{x*{1}} ​$. - Let $ \langle S \rangle $ denote a lexicographically encoding of the multi-set of public key/message pairs in $ S $. -- Let $ L= \lbrace X_{1}=g^{x_{1}},...,X_{n}=g^{x_{n}} \rbrace ​$ be the multi-set of all public keys. +- Let $ L= \lbrace X*{1}=g^{x*{1}},...,X*{n}=g^{x*{n}} \rbrace ​$ be the multi-set of all public keys. - Let $ \langle L \rangle ​$ denote a lexicographically encoding of the multi-set of public keys -$ L= \lbrace X_{1}...X_{n} \rbrace ​$. -- Let $ \textrm{H}_{com} $ denote the hash function in the commitment phase. -- Let $ \textrm{H}_{agg} $ denote the hash function used to compute the aggregated key. -- Let $ \textrm{H}_{sig} ​$ denote the hash function used to compute the signature. -- Let $ X_{1} $ and $ x_{1} $ be the public and private key of a specific signer. + $ L= \lbrace X*{1}...X*{n} \rbrace ​$. +- Let $ \textrm{H}\_{com} $ denote the hash function in the commitment phase. +- Let $ \textrm{H}\_{agg} $ denote the hash function used to compute the aggregated key. +- Let $ \textrm{H}\_{sig} ​$ denote the hash function used to compute the signature. +- Let $ X*{1} $ and $ x*{1} $ be the public and private key of a specific signer. - Let $ m $ be the message that will be signed. -- Let $ X_{2},...,X_{n} $ be the public keys of other cosigners. +- Let $ X*{2},...,X*{n} $ be the public keys of other cosigners. ### Recap on Schnorr Signature Scheme @@ -364,9 +354,9 @@ $$ (x,X) \in \lbrace 0,...,p-1 \rbrace \mspace{6mu} \mathsf{x} \mspace{6mu} \mathbb{G} $$ -where $ X=g^{x} $ +where $ X=g^{x} $ -To sign a message $ m $, the signer draws a random integer $ r \in Z_{p} $ and computes +To sign a message $ m $, the signer draws a random integer $ r \in Z\_{p} $ and computes $$ \begin{aligned} @@ -377,6 +367,7 @@ s &= r+cx $$ The signature is the pair $ (R,s) $, and its validity can be checked by verifying whether + $$ g^{s} = RX^{c} $$ @@ -401,14 +392,13 @@ $$ R_i = g^{r_{i}} $$ -Each of the cosigners then computes: - +Each of the cosigners then computes: $$ R = \prod _{i=1}^{n} R_{i} \mspace{30mu} \mathrm{and} \mspace{30mu} c = \textrm{H} (\tilde{X},R,m) $$ -where $$ \tilde{X} = \prod_{i=1}^{n}X_{i} $$ +where $$ \tilde{X} = \prod*{i=1}^{n}X*{i} $$ is the product of individual public. The partial signature is then given by @@ -422,7 +412,7 @@ $$ s = \displaystyle\sum_{i=1}^{n}s_i \mod p ​ $$ -The validity of a signature $ (R,s) $ on message $ m $ for public keys $ \lbrace X_{1},...X_{n} \rbrace $ is +The validity of a signature $ (R,s) $ on message $ m $ for public keys $ \lbrace X*{1},...X*{n} \rbrace $ is equivalent to $$ @@ -436,7 +426,7 @@ $$ $$ Note that this is exactly the verification equation for a traditional key-prefixed Schnorr signature with respect to -public key $ \tilde{X} $, a property termed *key aggregation*. +public key $ \tilde{X} $, a property termed _key aggregation_. However, these protocols are vulnerable to a rogue-key attack ([[12]], [[14]], [[15]] and [[17]]) where a corrupted signer sets its public key to @@ -444,7 +434,7 @@ $$ X_{1}=g^{x_{1}} (\prod_{i=2}^{n} X_{i})^{-1} $$ -allowing the signer to produce signatures for public keys $ \lbrace X_{1},...X_{n} \rbrace ​$ by themselves. +allowing the signer to produce signatures for public keys $ \lbrace X*{1},...X*{n} \rbrace ​$ by themselves. ### Bellare and Neven Signature Scheme @@ -477,10 +467,10 @@ $$ A preliminary round is also added to the signature protocol, where each signer commits to its share $ R_i $ by sending $ t_i = \textrm{H}^\prime(R_i) $ to other cosigners first. -This stops any cosigner from setting $ R = \prod_{i=1}^{n}R_{i} ​$ to some maliciously chosen value, and also allows the +This stops any cosigner from setting $ R = \prod*{i=1}^{n}R*{i} ​$ to some maliciously chosen value, and also allows the reduction to simulate the signature oracle in the security proof. -Bellare and Neven [[21]] showed that this yields a multi-signature scheme provably secure in the *plain public-key* +Bellare and Neven [[21]] showed that this yields a multi-signature scheme provably secure in the _plain public-key_ model under the Discrete Logarithm assumptions, modeling $ \textrm{H} $ and $ \textrm{H}^\prime $ as random oracles. However, this scheme does not allow key aggregation anymore, since the entire list of public keys is required for verification. @@ -488,8 +478,8 @@ verification. ### MuSig Signature Scheme MuSig is paramaterized by group parameters $(\mathbb{G\mathrm{,p,g)}}$ and three hash functions -$ ( \textrm{H}_{com} , \textrm{H}_{agg} , \textrm{H}_{sig} ) $ from $ \lbrace 0,1 \rbrace ^{*} $ to -$ \lbrace 0,1 \rbrace ^{l} $ (constructed from a single hash, using proper domain separation). +$ ( \textrm{H}_{com} , \textrm{H}_{agg} , \textrm{H}\_{sig} ) $ from $ \lbrace 0,1 \rbrace ^{\*} $ to +$ \lbrace 0,1 \rbrace ^{l} $ (constructed from a single hash, using proper domain separation). #### Round 1 @@ -497,7 +487,7 @@ A group of $ n $ signers want to cosign a message $ m $. Let $ X_1 $ and $ x_1 $ specific signer, let $ X_2 , . . . , X_n $ be the public keys of other cosigners and let $ \langle L \rangle $ be the multi-set of all public keys involved in the signing process. -For $ i\in \lbrace 1,...,n \rbrace ​$ , the signer computes the following +For $ i\in \lbrace 1,...,n \rbrace ​$ , the signer computes the following $$ a_{i} = \textrm{H}_{agg}(\langle L \rangle,X_{i}) @@ -505,14 +495,13 @@ $$ as well as the "aggregated" public key - $$ \tilde{X} = \prod_{i=1}^{n}X_{i}^{a_{i}} ​ $$ #### Round 2 -The signer generates a random private nonce $ r_{1}\leftarrow\mathbb{Z_{\mathrm{p}}} $, computes $ R_{1} = g^{r_{1}} $ +The signer generates a random private nonce $ r*{1}\leftarrow\mathbb{Z*{\mathrm{p}}} $, computes $ R_{1} = g^{r_{1}} $ (the public nonce) and commitment $ t_{1} = \textrm{H}_{com}(R_{1}) $ and sends $t_{1}​$ to all other cosigners. When receiving the commitments $t_{2},...,t_{n}$ from the other cosigners, the signer sends $R_{1}$ to all other @@ -524,7 +513,7 @@ The protocol is aborted if this is not the case. #### Round 3 -If all commitment and random challenge pairs can be verified with $ \textrm{H}_{agg} $, the following is computed: +If all commitment and random challenge pairs can be verified with $ \textrm{H}\_{agg} $, the following is computed: $$ \begin{aligned} @@ -535,7 +524,7 @@ s_{1} &= r_{1} + ca_{1} x_{1} \mod p $$ Signature $s_{1}​$ is sent to all other cosigners. -When receiving $ s_{2},...s_{n} ​$ from other cosigners, the signer can compute $ s = \sum_{i=1}^{n}s_{i} \mod p​$. The +When receiving $ s*{2},...s*{n} ​$ from other cosigners, the signer can compute $ s = \sum*{i=1}^{n}s*{i} \mod p​$. The signature is $ \sigma = (R,s) ​$. In order to verify the aggregated signature $ \sigma = (R,s) ​$, given a lexicographically encoded multi-set of public @@ -564,12 +553,12 @@ showed that through a meta-reduction, the initial multi-signature scheme cannot box reduction under the DL or OMDL assumption. In more detail, it was observed that in the two-round variant of MuSig, an adversary (controlling public keys -$ X_{2},...,X_{n} $) can impose the value of $ R=\Pi_{i=1}^{n}R_{i} $ used in signature protocols since they can choose -$ R_{2},...,R_{n} $ after having received $ R_{1} $ from the honest signer (controlling public key $ X_{1}=g^{x_{1}} $ ). +$ X*{2},...,X*{n} $) can impose the value of $ R=\Pi_{i=1}^{n}R_{i} $ used in signature protocols since they can choose +$ R*{2},...,R*{n} $ after having received $ R*{1} $ from the honest signer (controlling public key $ X*{1}=g^{x*{1}} $ ). This prevents one from using the initial method of simulating the honest signer in the Random Oracle model without knowing -$ x_{1} $ by randomly drawing $ s_{1} $ and $ c $, computing $ R_1=g^{s_1}(X_1)^{-a_1c}$, and later programming -$ \textrm{H}\_{sig}(\tilde{X}, R, m) \mspace{2mu} : = c_1 $ since the adversary might have made the random oracle query -$ \textrm{H}\_{sig}(\tilde{X}, R, m) $ *before* engaging the corresponding signature protocol. +$ x*{1} $ by randomly drawing $ s\_{1} $ and $ c $, computing $ R_1=g^{s_1}(X_1)^{-a_1c}$, and later programming +$ \textrm{H}\_{sig}(\tilde{X}, R, m) \mspace{2mu} : = c*1 $ since the adversary might have made the random oracle query +$ \textrm{H}\_{sig}(\tilde{X}, R, m) $ \_before* engaging the corresponding signature protocol. Despite this, there is no attack currently known against the two-round variant of MuSig and it might be secure, although this is not provable under standard assumptions from existing techniques [[4]]. @@ -598,8 +587,8 @@ $$ (X_{1}, m_{i}) = (X, m) $$ -Each signer then draws $ r_{1}\leftarrow\mathbb{Z_{\mathrm{p}}} ​$, computes $ R_{i} = g^{r_{i}} ​$ and subsequently -sends commitment $ t_{i} = H^\prime(R_{i}) ​$ in a first round and then $ R_{i} ​$ in a second round, and then computes +Each signer then draws $ r*{1}\leftarrow\mathbb{Z*{\mathrm{p}}} ​$, computes $ R_{i} = g^{r_{i}} ​$ and subsequently +sends commitment $ t*{i} = H^\prime(R*{i}) ​$ in a first round and then $ R\_{i} ​$ in a second round, and then computes $$ R = \prod_{i=1}^{n}R_{i} @@ -612,7 +601,7 @@ c_{i} = H(R, \langle S \rangle, i) \mspace{30mu} \\\\ s_{i} = r_{i} + c_{i}x_{i} \mod p $$ -and then sends $ s_{i} ​$ to other signers. All signers can compute +and then sends $ s\_{i} ​$ to other signers. All signers can compute $$ s = \displaystyle\sum_{i=1}^{n}s_{i} \mod p @@ -621,7 +610,7 @@ $$ The signature is $ \sigma = (R, s) ​$. Given an ordered set -$ \langle S \rangle \mspace{6mu} \mathrm{of} \mspace{6mu} S = \lbrace (X_{1}, m_{1}),...,(X_{n}, m_{n}) \rbrace $ +$ \langle S \rangle \mspace{6mu} \mathrm{of} \mspace{6mu} S = \lbrace (X*{1}, m*{1}),...,(X*{n}, m*{n}) \rbrace $ and a signature $ \sigma = (R, s) $ then $ \sigma $ is valid for $ S ​$ when $$ @@ -635,287 +624,236 @@ message index $ i $. **Note:** As of writing of this report, the secure IAS scheme presented here still needs to undergo a complete security analysis. - - ## Conclusions, Observations and Recommendations - MuSig leads to both native and private multi-signature transactions with signature aggregation. - Signature data for multi-signatures can be large and cumbersome. MuSig will allow users to create more complex -transactions without burdening the network and revealing compromising information. + transactions without burdening the network and revealing compromising information. - The IAS case where each signer signs their own message must still be proven by a complete security analysis. - - ## References [[1]] P. Wuille, “Key Aggregation for Schnorr Signatures”, 2018. Available: . Date accessed: 2019‑01‑20. -[1]: https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/ -"Key Aggregation for Schnorr Signatures" +[1]: https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/ 'Key Aggregation for Schnorr Signatures' [[2]] Blockstream, “Schnorr Signatures for Bitcoin - BPASE ’18”, 2018. Available: . Date accessed: 2019‑01‑20. -[2]: https://blockstream.com/2018/02/15/schnorr-signatures-bpase/ -"Schnorr Signatures for Bitcoin - BPASE '18" +[2]: https://blockstream.com/2018/02/15/schnorr-signatures-bpase/ "Schnorr Signatures for Bitcoin - BPASE '18" [[3]] K. Itakura, “A Public-key Cryptosystem Suitable for Digital Multisignatures”, NEC J. Res. Dev., Vol. 71, 1983. Available: . Date accessed: 2019‑01‑20. -[3]: https://scinapse.io/papers/200023587/ -"A Public-key Cryptosystem Suitable for -Digital Multisignatures" +[3]: https://scinapse.io/papers/200023587/ 'A Public-key Cryptosystem Suitable for +Digital Multisignatures' [[4]] G. Maxwell, A. Poelstra, Y. Seurin and P. Wuille, “Simple Schnorr Multi-signatures with Applications to Bitcoin”, pp. 1–34, 2018. Available: . Date accessed: 2019‑01‑20. -[4]: https://eprint.iacr.org/2018/068.pdf -"Simple Schnorr Multi-signatures -with Applications to Bitcoin" - -[[5]] B. W. Contributors, “Multisignature”, 2017. Available: . -Date accessed: 2019‑01‑20. - -[5]: https://wiki.bitcoin.com/w/Multisignature -"Multisignature" +[4]: https://eprint.iacr.org/2018/068.pdf 'Simple Schnorr Multi-signatures +with Applications to Bitcoin' -[[6]] C. P. Schnorr, “Efficient Signature Generation by Smart Cards”, *Journal of Cryptology*, Vol. 4, No. 3, +[[6]] C. P. Schnorr, “Efficient Signature Generation by Smart Cards”, _Journal of Cryptology_, Vol. 4, No. 3, pp. 161‑174, 1991. Available: . Date accessed: 2019‑01‑20. -[6]: https://link.springer.com/article/10.1007/BF00196725 -"Efficient Signature Generation by Smart Cards" +[6]: https://link.springer.com/article/10.1007/BF00196725 'Efficient Signature Generation by Smart Cards' -[[7]] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe and B. Yang, “High-speed High-security Signatures”, *Journal of -Cryptographic Engineering*, Vol. 2, No. 2, pp. 77‑89, 2012. Available: +[[7]] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe and B. Yang, “High-speed High-security Signatures”, _Journal of +Cryptographic Engineering_, Vol. 2, No. 2, pp. 77‑89, 2012. Available: . Date accessed: 2019‑01‑20. -[7]: https://ed25519.cr.yp.to/ed25519-20110705.pdf -"High-speed High-security Signatures" +[7]: https://ed25519.cr.yp.to/ed25519-20110705.pdf 'High-speed High-security Signatures' -[[8]] D. J. Bernstein, “Multi-user Schnorr Security, Revisited”, *IACR Cryptology ePrint Archive*, Vol. 2015, +[[8]] D. J. Bernstein, “Multi-user Schnorr Security, Revisited”, _IACR Cryptology ePrint Archive_, Vol. 2015, p. 996, 2015. Available: . Date accessed: 2019‑01‑20. -[8]: https://eprint.iacr.org/2015/996.pdf -"Multi-user Schnorr Security, Revisited" +[8]: https://eprint.iacr.org/2015/996.pdf 'Multi-user Schnorr Security, Revisited' -[[9]] E. Kiltz, D. Masny and J. Pan, “Optimal Security Proofs for Signatures from Identification Schemes”, *Annual -Cryptology Conference*, pp. 33‑61, Springer, 2016. Available: . Date +[[9]] E. Kiltz, D. Masny and J. Pan, “Optimal Security Proofs for Signatures from Identification Schemes”, _Annual +Cryptology Conference_, pp. 33‑61, Springer, 2016. Available: . Date accessed: 2019‑01‑20. -[9]: https://eprint.iacr.org/2016/191.pdf -"Optimal Security Proofs for Signatures -from Identification Schemes" +[9]: https://eprint.iacr.org/2016/191.pdf 'Optimal Security Proofs for Signatures +from Identification Schemes' [[10]] C. M. Li, T. Hwang and N. Y. Lee, “Threshold-multisignature Schemes where Suspected Forgery Implies Traceability -of Adversarial Shareholders”, *Workshop on the Theory and Application of Cryptographic Techniques*, +of Adversarial Shareholders”, _Workshop on the Theory and Application of Cryptographic Techniques_, pp. 194‑204, Springer, 1994. Available: . Date accessed: 2019‑01‑20. -[10]: https://link.springer.com/content/pdf/10.1007%2FBFb0053435.pdf -"Threshold-multisignature Schemes +[10]: https://link.springer.com/content/pdf/10.1007%2FBFb0053435.pdf 'Threshold-multisignature Schemes where Suspected Forgery Implies -Traceability of Adversarial Shareholders" - -[[11]] L. Harn, “Group-oriented (t, n) Threshold Digital Signature Scheme and Digital Multisignature”, *IEEE* -*Proceedings-Computers and Digital Techniques*, Vol. 141, No. 5, pp. 307‑313, 1994. -Available: . Date accessed: 2019‑01‑20. +Traceability of Adversarial Shareholders' -[11]: https://ieeexplore.ieee.org/abstract/document/326780 -"Group-oriented (t, n) Threshold Digital Signature Scheme and Digital Multisignature" - -[[12]] P. Horster, M. Michels and H. Petersen, “Meta-Multisignature Schemes Based on the Discrete Logarithm Problem”, *Information Security-the Next Decade*, pp. 128‑142, Springer, 1995. +[[12]] P. Horster, M. Michels and H. Petersen, “Meta-Multisignature Schemes Based on the Discrete Logarithm Problem”, _Information Security-the Next Decade_, pp. 128‑142, Springer, 1995. Available: . Date accessed: 2019‑01‑20. -[12]: https://link.springer.com/content/pdf/10.1007%2F978-0-387-34873-5_11.pdf -"Meta-Multisignature Schemes -Based on the Discrete Logarithm Problem" +[12]: https://link.springer.com/content/pdf/10.1007%2F978-0-387-34873-5_11.pdf 'Meta-Multisignature Schemes +Based on the Discrete Logarithm Problem' -[[13]] K. Ohta and T. Okamoto, “A Digital Multisignature Scheme Based on the Fiat-Shamir Scheme,” *International -Conference on the Theory and Application of Cryptology*, pp. 139‑148, Springer, 1991. +[[13]] K. Ohta and T. Okamoto, “A Digital Multisignature Scheme Based on the Fiat-Shamir Scheme,” _International +Conference on the Theory and Application of Cryptology_, pp. 139‑148, Springer, 1991. Available: . Date accessed: 2019‑01‑20. -[13]: https://link.springer.com/chapter/10.1007/3-540-57332-1_11 -"A Digital Multisignature Scheme -Based on the Fiat-Shamir Scheme" +[13]: https://link.springer.com/chapter/10.1007/3-540-57332-1_11 'A Digital Multisignature Scheme +Based on the Fiat-Shamir Scheme' -[[14]] S. K. Langford, “Weaknesses in Some Threshold Cryptosystems”, *Annual International Cryptology Conference*, +[[14]] S. K. Langford, “Weaknesses in Some Threshold Cryptosystems”, _Annual International Cryptology Conference_, pp. 74‑82, Springer, 1996. Available: . Date accessed: 2019‑01‑20. -[14]: https://link.springer.com/content/pdf/10.1007%2F3-540-68697-5_6.pdf -"Weaknesses in Some Threshold Cryptosystem" +[14]: https://link.springer.com/content/pdf/10.1007%2F3-540-68697-5_6.pdf 'Weaknesses in Some Threshold Cryptosystem' -[[15]] M. Michels and P. Horster, “On the Risk of Disruption in Several Multiparty Signature Schemes”, *International -Conference on the Theory and Application of Cryptology and Information Security*, pp. 334‑345, Springer, 1996. +[[15]] M. Michels and P. Horster, “On the Risk of Disruption in Several Multiparty Signature Schemes”, _International +Conference on the Theory and Application of Cryptology and Information Security_, pp. 334‑345, Springer, 1996. Available: . Date accessed: 2019‑01‑20. -[15]: https://pdfs.semanticscholar.org/d412/e5ab35fd397931cef0f8202324308f44e545.pdf -"On the Risk of Disruption in -Several Multiparty Signature Schemes" +[15]: https://pdfs.semanticscholar.org/d412/e5ab35fd397931cef0f8202324308f44e545.pdf 'On the Risk of Disruption in +Several Multiparty Signature Schemes' -[[16]] K. Ohta and T. Okamoto, “Multi-signature Schemes Secure Against Active Insider Attacks”, *IEICE Transactions on* -*Fundamentals of Electronics, Communications and Computer Sciences*, Vol. 82, No. 1, pp. 21‑31, 1999. +[[16]] K. Ohta and T. Okamoto, “Multi-signature Schemes Secure Against Active Insider Attacks”, _IEICE Transactions on_ +_Fundamentals of Electronics, Communications and Computer Sciences_, Vol. 82, No. 1, pp. 21‑31, 1999. Available: . Date accessed: 2019‑01‑20. -[16]: http://search.ieice.org/bin/summary.php?id=e82-a_1_21&category=A&year=1999&lang=E&abst= -"Multi-signature Schemes Secure -Against Active Insider Attacks" +[16]: http://search.ieice.org/bin/summary.php?id=e82-a_1_21&category=A&year=1999&lang=E&abst= 'Multi-signature Schemes Secure +Against Active Insider Attacks' -[[17]] S. Micali, K. Ohtaz and L. Reyzin, “Accountable-subgroup Multisignatures”, *Proceedings of the 8th ACM C -onference on Computer and Communications Security*, pp. 245#8209;254, ACM, 2001. +[[17]] S. Micali, K. Ohtaz and L. Reyzin, “Accountable-subgroup Multisignatures”, _Proceedings of the 8th ACM C +onference on Computer and Communications Security_, pp. 245#8209;254, ACM, 2001. Available: . Date accessed: 2019‑01‑20. -[17]: https://pdfs.semanticscholar.org/6bf4/f9450e7a8e31c106a8670b961de4735589cf.pdf -"Accountable-subgroup Multisignatures" +[17]: https://pdfs.semanticscholar.org/6bf4/f9450e7a8e31c106a8670b961de4735589cf.pdf 'Accountable-subgroup Multisignatures' [[18]] T. Ristenpart and S. Yilek, “The Power of Proofs-of-possession: Securing Multiparty Signatures Against Rogue-key -Attacks”, *Annual International Conference on the Theory and Applications of Cryptographic Techniques*, +Attacks”, _Annual International Conference on the Theory and Applications of Cryptographic Techniques_, pp. 228‑245, Springer, 2007. Available: . Date accessed: 2019‑01‑20. -[18]: https://link.springer.com/content/pdf/10.1007%2F978-3-540-72540-4_13.pdf -"The Power of Proofs-of-possession: +[18]: https://link.springer.com/content/pdf/10.1007%2F978-3-540-72540-4_13.pdf 'The Power of Proofs-of-possession: Securing Multiparty Signatures -Against Rogue-key Attacks" +Against Rogue-key Attacks' [[19]] A. Boldyreva, “Threshold Signatures, Multisignatures and Blind Signatures Based on the Gap-Diffie-Hellman-group -Signature Scheme”, *International Workshop on Public Key Cryptography*, pp. 31‑46, Springer, 2003. +Signature Scheme”, _International Workshop on Public Key Cryptography_, pp. 31‑46, Springer, 2003. Available: . Date accessed: 2019‑01‑20. -[19]: https://www.iacr.org/archive/pkc2003/25670031/25670031.pdf -"Threshold Signatures, Multisignatures +[19]: https://www.iacr.org/archive/pkc2003/25670031/25670031.pdf 'Threshold Signatures, Multisignatures and Blind Signatures Based on the -Gap-Diffie-Hellman-Group Signature Scheme" +Gap-Diffie-Hellman-Group Signature Scheme' [[20]] S. Lu, R. Ostrovsky, A. Sahai, H. Shacham and B. Waters, “Sequential Aggregate Signatures and Multisignatures -without Random Oracles,” *Annual International Conference on the Theory and Applications of Cryptographic Techniques*, +without Random Oracles,” _Annual International Conference on the Theory and Applications of Cryptographic Techniques_, pp. 465‑485, Springer, 2006. Available: . Date accessed: 2019‑01‑20. -[20]: https://eprint.iacr.org/2006/096.pdf -"Sequential Aggregate Signatures and -Multisignatures without Random Oracles" +[20]: https://eprint.iacr.org/2006/096.pdf 'Sequential Aggregate Signatures and +Multisignatures without Random Oracles' -[[21]] M. Bellare and G. Neven, “Multi-Signatures in the Plain Public-Key Model and a General Forking Lemma”, *Acm -Ccs*, pp. 390‑399, 2006. Available: . +[[21]] M. Bellare and G. Neven, “Multi-Signatures in the Plain Public-Key Model and a General Forking Lemma”, _Acm +Ccs_, pp. 390‑399, 2006. Available: . Date accessed: 2019‑01‑20. -[21]: https://cseweb.ucsd.edu/~mihir/papers/multisignatures-ccs.pdf -"Multi-Signatures in the Plain +[21]: https://dl.acm.org/doi/10.1145/1180405.1180453 'Multi-Signatures in the Plain Public-Key Modeland a General -Forking Lemma" +Forking Lemma' [[22]] A. Bagherzandi, J. H. Cheon and S. Jarecki, “Multisignatures Secure under the Discrete Logarithm Assumption and a -Generalized Forking Lemma”, *Proceedings of the 15th ACM Conference on Computer and Communications Security - CCS '08*, -p. 449, 2008. Available: . +Generalized Forking Lemma”, _Proceedings of the 15th ACM Conference on Computer and Communications Security - CCS '08_, +p. 449, 2008. Available: . Date accessed: 2019‑01‑20. -[22]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.544.2947&rep=rep1&type=pdf -"Multisignatures Secure under the Discrete Logarithm Assumption and a Generalized Forking Lemma" +[22]: https://www.researchgate.net/publication/221609164_Multisignatures_secure_under_the_discrete_logarithm_assumption_and_a_generalized_forking_lemma 'Multisignatures Secure under the Discrete Logarithm Assumption and a Generalized Forking Lemma' [[23]] C. Ma, J. Weng, Y. Li and R. Deng, “Efficient Discrete Logarithm Based Multi-signature Scheme in the Plain Public -Key Model”, *Designs, Codes and Cryptography*, Vol. 54, No. 2, pp. 121‑133, 2010. +Key Model”, _Designs, Codes and Cryptography_, Vol. 54, No. 2, pp. 121‑133, 2010. Available: . Date accessed: 2019‑01‑20. -[23]: https://link.springer.com/article/10.1007/s10623-009-9313-z -"Efficient Discrete Logarithm +[23]: https://link.springer.com/article/10.1007/s10623-009-9313-z 'Efficient Discrete Logarithm Based Multi-signature Scheme in the -Plain Public Key Model" +Plain Public Key Model' [[24]] E. Syta, I. Tamas, D. Visher, D. I. Wolinsky, P. Jovanovic, L. Gasser, N. Gailly, I. Khoffi and B. Ford, “Keeping -Authorities 'Honest or Bust' with Decentralized Witness Cosigning”, *Security and Privacy (SP), 2016 IEEE Symposium* +Authorities 'Honest or Bust' with Decentralized Witness Cosigning”, _Security and Privacy (SP), 2016 IEEE Symposium_ on pp. 526‑545, IEEE, 2016. Available: . Date accessed: 2019‑01‑20. -[24]: https://arxiv.org/pdf/1503.08768.pdf -"Keeping Authorities 'Honest or Bust' with Decentralized Witness Cosigning" +[24]: https://arxiv.org/pdf/1503.08768.pdf "Keeping Authorities 'Honest or Bust' with Decentralized Witness Cosigning" [[25]] D. Boneh, C. Gentry, B. Lynn and H. Shacham, “Aggregate and Verifiably Encrypted Signatures from Bilinear Maps”, -in *International Conference on the Theory and Applications of Cryptographic Techniques*, pp. 416‑432, +in _International Conference on the Theory and Applications of Cryptographic Techniques_, pp. 416‑432, Springer, 2003. Available: . Date accessed: 2019‑01‑20. -[25]: http://crypto.stanford.edu/~dabo/papers/aggreg.pdf -"Aggregate and Verifiably Encrypted -Signatures from Bilinear Maps" +[25]: http://crypto.stanford.edu/~dabo/papers/aggreg.pdf 'Aggregate and Verifiably Encrypted +Signatures from Bilinear Maps' -[[26]] M. Bellare, C. Namprempre and G. Neven, “Unrestricted Aggregate Signatures”, *International Colloquium on -Automata, Languages, and Programming*, pp. 411‑422, Springer, 2007. Available: -. +[[26]] M. Bellare, C. Namprempre and G. Neven, “Unrestricted Aggregate Signatures”, _International Colloquium on +Automata, Languages, and Programming_, pp. 411‑422, Springer, 2007. Available: +. Date accessed: 2019‑01‑20. -[26]: https://cseweb.ucsd.edu/~mihir/papers/agg.pdf -"Unrestricted Aggregate Signatures" +[26]: https://link.springer.com/chapter/10.1007/978-3-540-73420-8_37 'Unrestricted Aggregate Signatures' [[27]] A. Lysyanskaya, S. Micali, L. Reyzin and H. Shacham, “Sequential Aggregate Signatures from Trapdoor Permutations”, -in *International Conference on the Theory and Applications of Cryptographic Techniques*, pp. 74‑90, +in _International Conference on the Theory and Applications of Cryptographic Techniques_, pp. 74‑90, Springer, 2004. Available: . Date accessed: 2019‑01‑20. -[27]: https://hovav.net/ucsd/dist/rsaagg.pdf -"Sequential Aggregate Signatures -from Trapdoor Permutations" +[27]: https://hovav.net/ucsd/dist/rsaagg.pdf 'Sequential Aggregate Signatures +from Trapdoor Permutations' [[28]] G. Andersen, “M-of-N Standard Transactions”, 2011. Available: . Date accessed: 2019‑01‑20. -[28]: https://bitcoin.org/en/glossary/multisig -"M-of-N Standard Transactions" +[28]: https://bitcoin.org/en/glossary/multisig 'M-of-N Standard Transactions' -[[29]] E. Shen, E. Shi and B. Waters, “Predicate Privacy in Encryption Systems”, *Theory of Cryptography Conference*, +[[29]] E. Shen, E. Shi and B. Waters, “Predicate Privacy in Encryption Systems”, _Theory of Cryptography Conference_, pp. 457‑473, Springer, 2009. Available: . Date accessed: 2019‑01‑20. -[29]: https://www.iacr.org/archive/tcc2009/54440456/54440456.pdf -"Predicate Privacy in Encryption Systems" +[29]: https://www.iacr.org/archive/tcc2009/54440456/54440456.pdf 'Predicate Privacy in Encryption Systems' -[[30]] R. C. Merkle, “A Digital Signature Based on a Conventional Encryption Function”, *Conference on the Theory and -Application of Cryptographic Techniques*, pp. 369‑378, Springer, 1987. +[[30]] R. C. Merkle, “A Digital Signature Based on a Conventional Encryption Function”, _Conference on the Theory and +Application of Cryptographic Techniques_, pp. 369‑378, Springer, 1987. Available: . Date accessed: 2019‑01‑20. -[30]: https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf -"A Digital Signature Based on -a Conventional Encryption Function" +[30]: https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf 'A Digital Signature Based on +a Conventional Encryption Function' [[31]] G. Maxwell, “CoinJoin: Bitcoin Privacy for the Real World”, 2013. Available: . Date accessed: 2019‑01‑20. -[31]: https://bitcointalk.org/index.php?topic=279249.0 -"CoinJoin: Bitcoin Privacy for the Real World" +[31]: https://bitcointalk.org/index.php?topic=279249.0 'CoinJoin: Bitcoin Privacy for the Real World' [[32]] M. Bellare and A. Palacio, “GQ and Schnorr Identification Schemes: Proofs of Security against Impersonation under -Active and Concurrent Attacks”, *Annual International Cryptology Conference*, pp. 162–177, Springer, 2002. +Active and Concurrent Attacks”, _Annual International Cryptology Conference_, pp. 162–177, Springer, 2002. Available: . Date accessed: 2019-01-20. -[32]: https://cseweb.ucsd.edu/~mihir/papers/gq.pdf -"GQ and Schnorr Identification Schemes: +[32]: https://cseweb.ucsd.edu/~mihir/papers/gq.pdf 'GQ and Schnorr Identification Schemes: Proofs of Security Against Impersonation -Under Active and Concurrent Attacks" +Under Active and Concurrent Attacks' -[[33]] M. Bellare, C. Namprempre, D. Pointcheval and M. Semanko, “The One-More-RSA Inversion Problems and the Security -of Chaum’s Blind Signature Scheme”, *Journal of Cryptology*, Vol. 16, No. 3, 2003. Available: +[[33]] M. Bellare, C. Namprempre, D. Pointcheval and M. Semanko, “The One-More-RSA Inversion Problems and the Security +of Chaum’s Blind Signature Scheme”, _Journal of Cryptology_, Vol. 16, No. 3, 2003. Available: . Date accessed: 2019‑01‑20. -[33]: https://eprint.iacr.org/2001/002.pdf -"The One-More-RSA-Inversion Problems and the Security of Chaum’s Blind Signature Scheme*" +[33]: https://eprint.iacr.org/2001/002.pdf 'The One-More-RSA-Inversion Problems and the Security of Chaum’s Blind Signature Scheme*' [[34]] M. Drijvers, K. Edalatnejad, B. Ford, and G. Neven, “Okamoto Beats Schnorr: On the Provable Security of Multi-signatures”, Tech. Rep., 2018. Available: . Date accessed: 2019‑01‑20. -[34]: https://www.semanticscholar.org/paper/Okamoto-Beats-Schnorr%3A-On-the-Provable-Security-of-Drijvers-Edalatnejad/154938a12885ff30301129597ebe11dd153385bb -"Okamoto Beats Schnorr: On the -Provable Security of Multi-signatures" - - +[34]: https://www.semanticscholar.org/paper/Okamoto-Beats-Schnorr%3A-On-the-Provable-Security-of-Drijvers-Edalatnejad/154938a12885ff30301129597ebe11dd153385bb 'Okamoto Beats Schnorr: On the +Provable Security of Multi-signatures' ## Contributors diff --git a/_includes/content/cryptography/05-fraud-proofs.md b/_includes/content/cryptography/05-fraud-proofs.md index db5b49f9..969c4b78 100644 --- a/_includes/content/cryptography/05-fraud-proofs.md +++ b/_includes/content/cryptography/05-fraud-proofs.md @@ -34,7 +34,7 @@ by users, since not everyone can run full nodes due to the computational power, bitcoin node. SPV clients will believe everything miners or nodes tell them, as evidenced by Peter Todd in the following screenshot -of an Android client showing millions of bitcoins. The wallet was sent a transaction of 2.1 million BTC outputs [[17]]. +of an Android client showing millions of bitcoins. The wallet was sent a transaction of 2.1 million BTC outputs. Peter Todd modified the code for his node in order to deceive the bitcoin wallet, since the wallets cannot verify coin amounts [[27]] (code can be found in the "Quick-n-dirty hack to lie to SPV wallets" branch on his GitHub repository). @@ -63,14 +63,16 @@ accounting errors (whether by accident or by malicious intent). ## Full Node vs. SPV Client A full bitcoin node contains the following details: - * every block; - * every transaction that has ever been sent; - * all the unspent transaction outputs (UTXOs) [[4]]. + +- every block; +- every transaction that has ever been sent; +- all the unspent transaction outputs (UTXOs) [[4]]. An SPV client, however, contains: - * a block header with transaction data relative to the client, including other transactions required to compute the - Merkle root; or - * just a block header with no transactions. + +- a block header with transaction data relative to the client, including other transactions required to compute the + Merkle root; or +- just a block header with no transactions. ## What are Fraud Proofs? @@ -80,31 +82,37 @@ the bitcoin scaling debate, as SPV clients are easier to run and could thus help ([[6]], [[18]]). ## Fraud Proofs Possible within Existing Bitcoin Protocol + At the time of writing (February 2019), various proofs are needed to prove fraud in the bitcoin blockchain based on various actions. The following are the types of proofs needed to prove fraud based on specific fraud cases within the existing bitcoin protocol [[5]]: ### Invalid Transaction due to Stateless Criteria Violation (Correct Syntax, Input Scripts Conditions Satisfied, etc.) + In the case of an invalid transaction, the fraud proofs consist of: -* the header of invalid block; -* the invalid transaction; -* an invalid block's Merkle tree containing the minimum number of nodes needed to prove the existence of the invalid -transaction in the tree. +- the header of invalid block; +- the invalid transaction; +- an invalid block's Merkle tree containing the minimum number of nodes needed to prove the existence of the invalid + transaction in the tree. ### Invalid Transaction due to Input Already Spent + In this case, the fraud proof would consist of: -* the header of the invalid block; -* the invalid transaction; -* proof that the invalid transaction is within the invalid block; -* the header of the block containing the original spend transaction; -* the original spending transaction; -* proof showing that the spend transaction is within the header block of the spend transaction. + +- the header of the invalid block; +- the invalid transaction; +- proof that the invalid transaction is within the invalid block; +- the header of the block containing the original spend transaction; +- the original spending transaction; +- proof showing that the spend transaction is within the header block of the spend transaction. ### Invalid Transaction due to Incorrect Generation Output Value + In this case, the fraud proof consists of the block itself. ### Invalid Transaction if Input does not Exist + In this case, the fraud proof consists of the entire blockchain. ## Fraud Proofs Requiring Changes to Bitcoin Protocol @@ -112,21 +120,24 @@ In this case, the fraud proof consists of the entire blockchain. The following fraud proofs would require changes to the bitcoin protocol itself [[5]]: ### Invalid Transaction if Input does not Exist in Old Blocks + In this case, the fraud proof consists of: -* the header of the invalid block; -* the invalid transaction; -* proof that the header of the invalid block contains the invalid transaction; -* proof that the header of the invalid block contains the leaf node corresponding to the non-existent input; -* the block referenced by the leaf node, if it exists. + +- the header of the invalid block; +- the invalid transaction; +- proof that the header of the invalid block contains the invalid transaction; +- proof that the header of the invalid block contains the leaf node corresponding to the non-existent input; +- the block referenced by the leaf node, if it exists. ### Missing Proof Tree Item In this case, the fraud proof consists of: -* the header of the invalid block; -* the transaction of the missing proof tree node; -* an indication as to which input from the transaction of the missing proof tree node is missing; -* proof that the header of the invalid block contains the transition of the missing proof tree node; -* proof that the proof tree contains two adjacent leaf nodes. + +- the header of the invalid block; +- the transaction of the missing proof tree node; +- an indication as to which input from the transaction of the missing proof tree node is missing; +- proof that the header of the invalid block contains the transition of the missing proof tree node; +- proof that the proof tree contains two adjacent leaf nodes. ## Universal Fraud Proofs (Suggested Improvement) @@ -136,7 +147,7 @@ generalize the entire blockchain as a state transition system and represent the Sparse Merkle tree, with each transaction changing the state root of the blockchain. This can be simplified by this function: -* `transaction(state,tx) = State or Error` +- `transaction(state,tx) = State or Error`

@@ -146,21 +157,23 @@ Dishonest Majorities In the case of the bitcoin blockchain, representing the entire blockchain as a key-value store Sparse Merkle tree would mean: -* `Key = UTXO ID` -* `Value = 1 if unspent or 0 if spent` +- `Key = UTXO ID` +- `Value = 1 if unspent or 0 if spent` Each transaction will change the state root of the blockchain and can be represented with this function: -* `TransitionRoot(stateRoot,tx,Witnesses) = stateRoot or Error` +- `TransitionRoot(stateRoot,tx,Witnesses) = stateRoot or Error` In this proposition, a valid fraud proof construction will consist of: -* the transaction; -* the pre-state root; -* the post-state root; -* witnesses (Merkle proofs of all the parts of the state the transaction accesses/modifies). + +- the transaction; +- the pre-state root; +- the post-state root; +- witnesses (Merkle proofs of all the parts of the state the transaction accesses/modifies). Also expressed as this function: -* `rootTransition(stateRoot, tx, witnesses) != stateRoot` + +- `rootTransition(stateRoot, tx, witnesses) != stateRoot` So a full node would send a light client/SPV this data to prove a valid fraud proof. The SPV would compute this function and, if the transition root of the state root is different to the state root in the block, then the block @@ -229,6 +242,7 @@ introduces semi-trusted oracles to improve the security and privacy of SPV clien block data via any out of band method [[14]]. ## Examples of SPV Implementations + There are two well-known SPV implementations for bitcoin: bitcoinj and electrum. The latter does SPV-level validation, comparing multiple electrum servers against each other. It has very similar security to bitcoinj, but potentially better privacy [[25]] due to bitcoinj's implementation of Bloom filters [[7]]. @@ -236,6 +250,7 @@ privacy [[25]] due to bitcoinj's implementation of Bloom filters [[7]]. ## Other Suggested Fraud-proof Improvements ### Erasure Codes + Along with the proposed universal fraud-proof solution, another data availability issue with fraud proofs is erasure coding. Erasure coding allows a piece of data M chunks long to be expanded into a piece of data N chunks long (“chunks” can be of arbitrary size), such that any M of the N chunks can be used to recover the original data. Blocks are then @@ -256,8 +271,8 @@ construct and relay a specialized kind of fraud proof that shows that the erasur ### Merklix Trees Another suggested fraud proof improvement for the bitcoin blockchain is by means of block sharding and validation using -Merklix trees. Merklix trees are essentially Merkle trees that use unordered set [[22]]. This also assumes that there -is at least one honest node per shard. Using Merklix proofs, the following can be proven [[23]]: +Merklix trees. Merklix trees are essentially Merkle trees that use unordered set. This also assumes that there +is at least one honest node per shard. Using Merklix proofs, the following can be proven: 1. A transaction is in the block. 2. The transaction's inputs and outputs are or are not in the UTXO set. @@ -296,149 +311,129 @@ or more), a fraud proof will not be viable on this assumption, as the digital is ## References [[1]] "Size of the Bitcoin Blockchain from 2010 to 2018, by Quarter (in Megabytes)" [online]. -Available: . Date accessed: 2018‑09‑10. - - -[1]: https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/ -"Size of the Bitcoin Blockchain from 2010 to 2018, by Quarter (in Megabytes)" +Available: . Date accessed: 2018‑09‑10. +[1]: https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/ 'Size of the Bitcoin Blockchain from 2010 to 2018, by Quarter (in Megabytes)' [[2]] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" [online]. Available: . Date accessed: 2018‑09‑10. -[2]: https://www.bitcoin.com/bitcoin.pdf -"Bitcoin: A Peer-to-Peer Electronic Cash System" +[2]: https://www.bitcoin.com/bitcoin.pdf 'Bitcoin: A Peer-to-Peer Electronic Cash System' [[3]] "Simple Payment Verification" [online]. Available: . Date accessed: 2018‑09‑10. -[3]: http://docs.electrum.org/en/latest/spv.html "Simple Payment Verification" +[3]: http://docs.electrum.org/en/latest/spv.html 'Simple Payment Verification' [[4]] "SPV, Bloom Filters and Checkpoints" [online]. Available: . Date accessed: 2018‑09‑10. -[4]: https://multibit.org/hd0.4/how-spv-works.html "SPV, Bloom Filters and Checkpoints" +[4]: https://multibit.org/hd0.4/how-spv-works.html 'SPV, Bloom Filters and Checkpoints' [[5]] "Improving the Ability of SPV Clients to Detect Invalid Chains" [online]. Available: . Date accessed: 2018‑09‑10. -[5]: https://gist.github.com/justusranvier/451616fa4697b5f25f60 "Improving the Ability of SPV Clients to Detect Invalid Chains" +[5]: https://gist.github.com/justusranvier/451616fa4697b5f25f60 'Improving the Ability of SPV Clients to Detect Invalid Chains' [[6]] "Meditations on Fraud Proofs" [online]. Available: . Dated accessed: 2018‑09‑10. -[6]: http://www.truthcoin.info/blog/fraud-proofs/ "Meditations on Fraud Proofs" +[6]: http://www.truthcoin.info/blog/fraud-proofs/ 'Meditations on Fraud Proofs' [[7]] A. Gervais, G. O. Karame, D. Gruber and S. Capkun, "On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients" [online]. Available: . Date accessed: 2018‑09‑10. -[7]: https://eprint.iacr.org/2014/763.pdf "On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients" +[7]: https://eprint.iacr.org/2014/763.pdf 'On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients' [[8]] "SPV, Bloom Filters and Checkpoints" [online]. Available: . Date accessed: 2018‑09‑10. -[8]: https://multibit.org/hd0.4/how-spv-works.html "SPV, Bloom Filters and Checkpoints" +[8]: https://multibit.org/hd0.4/how-spv-works.html 'SPV, Bloom Filters and Checkpoints' [[9]] "A Case of False Positives in Bloom Filters" [online]. Available: https://medium.com/blockchain-musings/a-case-of-false-positives-in-bloom-filters-da09ec487ff0. Date accessed: 2018‑09‑11. -[9]: https://medium.com/blockchain-musings/a-case-of-false-positives-in-bloom-filters-da09ec487ff0 "A Case of False Positives in Bloom Filters," +[9]: https://medium.com/blockchain-musings/a-case-of-false-positives-in-bloom-filters-da09ec487ff0 'A Case of False Positives in Bloom Filters,' [[10]] "The Design of Bitcoin Merkle Trees Reduces the Security of SPV Clients" [online]. Available: . Date accessed: 2018‑09‑11. -[10]: https://media.rsk.co/the-design-of-bitcoin-merkle-trees-reduces-the-security-of-spv-clients/ "The Design of Bitcoin Merkle Trees Reduces the Security of SPV Clients" +[10]: https://media.rsk.co/the-design-of-bitcoin-merkle-trees-reduces-the-security-of-spv-clients/ 'The Design of Bitcoin Merkle Trees Reduces the Security of SPV Clients' [[11]] "Leaf-node Weakness in Bitcoin Merkle Tree Design" [online]. Available: . Date accessed: 2018‑09‑11. -[11]: https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ "Leaf-node Weakness in Bitcoin Merkle Tree Design" +[11]: https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ 'Leaf-node Weakness in Bitcoin Merkle Tree Design' [[12]] "Privacy in Bitsquare" [online]. Available: . Date accessed: 2018‑09‑11. -[12]: https://bisq.network/blog/privacy-in-bitsquare/ "Privacy in Bitsquare" +[12]: https://bisq.network/blog/privacy-in-bitsquare/ 'Privacy in Bitsquare' [[13]] "bip-0037.mediawiki" [online]. Available: . Date accessed: 2018‑09‑11. -[13]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki "bip-0037.mediawiki" +[13]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki 'bip-0037.mediawiki' [[14]] "Committed Bloom Filters for Improved Wallet Performance and SPV Security" [online]. Available: . Date accessed: 2018‑09‑11. -[14]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html "Committed Bloom Filters for Improved Wallet Performance and SPV Security" +[14]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html 'Committed Bloom Filters for Improved Wallet Performance and SPV Security' [[15]] "Bloom-io-attack" [online]. Available: . Date accessed: 2018‑09‑11. -[15]: https://github.com/petertodd/bloom-io-attack "Bloom-io-attack" +[15]: https://github.com/petertodd/bloom-io-attack 'Bloom-io-attack' [[16]] "Committed Bloom Filters versus BIP37 SPV" [online]. Available: . Date accessed: 2018‑09‑12. -[16]: https://www.newsbtc.com/2016/05/10/developers-introduce-bloom-filters-improve-bitcoin-wallet-security/ "Committed Bloom Filters versus BIP37 SPV" - -[[17]] "Fraud Proofs" [online]. Available: . -Date accessed: 2018‑09‑12. - -[17]: https://www.linkedin.com/pulse/peter-todds-fraud-proofs-talk-mit-bitcoin-expo-2016-mark-morris/ "Fraud Proofs" +[16]: https://www.newsbtc.com/2016/05/10/developers-introduce-bloom-filters-improve-bitcoin-wallet-security/ 'Committed Bloom Filters versus BIP37 SPV' [[18]] "New Satoshi Nakamoto E-mails Revealed" [online]. Available: . Date accessed: 2018‑09‑12. -[18]: https://www.trustnodes.com/2017/08/12/new-satoshi-nakamoto-e-mails-revealed "New Satoshi Nakamoto E-mails Revealed" +[18]: https://www.trustnodes.com/2017/08/12/new-satoshi-nakamoto-e-mails-revealed 'New Satoshi Nakamoto E-mails Revealed' [[19]] J. Poon and V. Buterin, "Plasma: Scalable Autonomous Smart Contracts" [online]. Available: . Date accessed: 2018‑09‑13. -[19]: https://plasma.io/plasma.pdf "Plasma: Scalable Autonomous Smart Contracts" +[19]: https://plasma.io/plasma.pdf 'Plasma: Scalable Autonomous Smart Contracts' [[20]] "A Note on Data Availability and Erasure Coding" [online]. Available: . Date accessed: 2018‑09‑13. -[20]: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding "A Note on Data Availability and Erasure Coding" +[20]: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding 'A Note on Data Availability and Erasure Coding' [[21]] "Vitalik Buterin and Peter Todd Go Head to Head in the Crypto Culture Wars" [online]. Available: . Date accessed: 2018‑09‑14. -[21]: https://www.trustnodes.com/2017/08/14/vitalik-buterin-peter-todd-go-head-head-crypto-culture-wars "Vitalik Buterin and Peter Todd Go Head to Head in the Crypto Culture Wars" - -[[22]] "Introducing Merklix Tree as an Unordered Merkle Tree on Steroid" [online]. -Available: . -Date accessed 2018‑09‑14. - -[22]: https://www.deadalnix.me/2016/09/24/introducing-merklix-tree-as-an-unordered-merkle-tree-on-steroid/ "Introducing Merklix Tree as an Unordered Merkle Tree on Steroid" - -[[23]] "Using Merklix Tree to Shard Block Validation" [online]. -Available: . Date accessed: 2018‑09‑14. - -[23]: https://www.deadalnix.me/2016/11/06/using-merklix-tree-to-shard-block-validation/ "Using Merklix Tree to Shard Block Validation" +[21]: https://www.trustnodes.com/2017/08/14/vitalik-buterin-peter-todd-go-head-head-crypto-culture-wars 'Vitalik Buterin and Peter Todd Go Head to Head in the Crypto Culture Wars' [[24]] "Fraud Proofs" [online]. Available: . Date accessed: 2018‑09‑18. -[24]: https://bitco.in/forum/threads/fraud-proofs.1617/ "Fraud Proofs" +[24]: https://bitco.in/forum/threads/fraud-proofs.1617/ 'Fraud Proofs' [[25]] "Whats the Difference between an API Wallet and a SPV Wallet?" [Online.] Available: . Date accessed: 2018‑09‑21. -[25]: https://www.reddit.com/r/Bitcoin/comments/3c3zn4/whats_the_difference_between_an_api_wallet_and_a/ "Whats the Difference between an API Wallet and a SPV Wallet?" +[25]: https://www.reddit.com/r/Bitcoin/comments/3c3zn4/whats_the_difference_between_an_api_wallet_and_a/ 'Whats the Difference between an API Wallet and a SPV Wallet?' [[26]] M. Al-Bassam, A. Sinnino and V. Butterin, "Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities" [online]. Available: . Date accessed: 2018‑10‑08. -[26]: https://arxiv.org/pdf/1809.09044.pdf "Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities" +[26]: https://arxiv.org/pdf/1809.09044.pdf 'Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities' [[27]] "Bitcoin Integration/Staging Tree" [online]. Available: . Date accessed: 2018‑10‑12. -[27]: https://github.com/petertodd/bitcoin/tree/2016-02-lie-to-spv "Bitcoin Integration/Staging Tree" +[27]: https://github.com/petertodd/bitcoin/tree/2016-02-lie-to-spv 'Bitcoin Integration/Staging Tree' ## Contributors diff --git a/_includes/content/cryptography/06-bulletproofs-and-mimblewimble.md b/_includes/content/cryptography/06-bulletproofs-and-mimblewimble.md index a5b2ac1c..486751f9 100644 --- a/_includes/content/cryptography/06-bulletproofs-and-mimblewimble.md +++ b/_includes/content/cryptography/06-bulletproofs-and-mimblewimble.md @@ -29,7 +29,7 @@ Succinct Non-Interactive ARguments of Knowledge (zk-SNARK); Succinct Transparent Knowledge Prover and Verifier for Boolean Circuits (ZKBoo). Zero-knowledge proofs are designed so that a _prover_ is able to indirectly verify that a statement is true without having to provide any information beyond the verification of the statement, e.g. to prove that a number is found that solves a cryptographic puzzle and fits the hash value -without having to reveal the _Nonce_[def][nonce~] ([[2]], [[4]]). +without having to reveal the _Nonce_[def][nonce~] ([[4]]). The Bulletproofs technology is a Non-interactive Zero-knowledge (NIZK) proof protocol for general _Arithmetic Circuits_[def][ac~] with very short proofs (_Arguments of Knowledge Systems_[def][afs~]) and without @@ -40,7 +40,7 @@ bulletproof security assumptions" ([[1]], [[29]]). Bulletproofs also implement a Multi-party Computation (MPC) protocol, whereby distributed proofs of multiple _provers_ with secret committed values are aggregated into a single proof before the Fiat-Shamir challenge is calculated and sent -to the _verifier_, thereby minimizing rounds of communication. Secret committed values will stay secret ([[1]], [[6]]). +to the _verifier_, thereby minimizing rounds of communication. Secret committed values will stay secret ([[1]]). The essence of Bulletproofs is its inner-product algorithm originally presented by Groth [[13]] and then further refined by Bootle et al. [[12]]. The latter development provided a proof (argument of knowledge) for two independent (not @@ -76,7 +76,7 @@ The _prover_ must convince the _verifier_ that commitment $ C(x,r) = xH + rG $ c $ is the vector containing the bits of $ x $, the basic idea is to hide all the bits of the amount in a single vector Pedersen Commitment. It must then be proven that each bit satisfies $ \omega(\omega-1) = 0 $, i.e. each $ \omega $ is either $ 0 $ or $ 1 $, and that they sum to $ x $. As part of the ensuing protocol, the _verifier_ sends -random linear combinations of constraints and challenges $ \in \mathbb{Z_p} $ to the _prover_. The +random linear combinations of constraints and challenges $ \in \mathbb{Z*p} $ to the \_prover*. The _prover_ is then able to construct a vectorized inner product relation containing the elements of $ \mathbf {a} $, the constraints and challenges $ \in \mathbb{Z_p} $, and appropriate blinding vectors $ \in \mathbb Z_p^n $. @@ -188,7 +188,7 @@ continue to evolve ([[1]], [[2]], [[3]], [[5]], [[6]], [[59]]).

Figure 4: Bulletproofs for Refereed Delegation Model - [

Figure 5: Bulletproofs for Verifiable Shuffles - [. Date accessed: 2018‑09‑10. - -[2]: https://diyhpl.us/wiki/transcripts/2018-02-02-andrew-poelstra-bulletproofs 'Bulletproofs (Transcript)' - [[3]] A. Poelstra, "Bulletproofs" (Slides), Bitcoin Milan Meetup 2018‑02‑02 [online]. Available: . Date accessed: 2018‑09‑10. @@ -540,16 +535,9 @@ More' [[5]] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell, "Bulletproofs: Short Proofs for Confidential Transactions and More" (Slides) [online]. Available: -. Date accessed: 2018‑09‑18. - -[5]: https://cyber.stanford.edu/sites/default/files/bpase18.pptx 'Bulletproofs: Short Proofs for Confidential Transactions and More (Slides)' +. Date accessed: 2018‑09‑18. -[[6]] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell, "Bulletproofs: Short Proofs for -Confidential Transactions and More (Transcripts)" [online]. Available: -. Date accessed: -2018‑09‑18. - -[6]: http://diyhpl.us/wiki/transcripts/blockchain-protocol-analysis-security-engineering/2018/bulletproofs 'Bulletproofs: Short Proofs for Confidential Transactions and More (Transcripts)' +[5]: https://ieeexplore.ieee.org/document/8418611 'Bulletproofs: Short Proofs for Confidential Transactions and More (Slides)' [[7]] "Merkle Root and Merkle Proofs" [online]. Available: . Date accessed: 2018‑10‑10. @@ -741,13 +729,6 @@ Institute, Queensland University of Technology [online]. Available: [39]: https://iacr.org/archive/asiacrypt2008/53500329/53500329.pdf 'Twisted Edwards Curves Revisited' -[[40]] A. Sadeghi and M. Steiner, "Assumptions Related to Discrete Logarithms: Why Subtleties Make a Real -Difference" [online]. Available: . Date accessed: -2018-09-24. - -[40]: http://www.semper.org/sirene/publ/SaSt_01.dh-et-al.long.pdf 'Assumptions Related to Discrete Logarithms: Why -Subtleties Make a Real Difference' - [[41]] Crypto Wiki: "Cryptographic Nonce" [online]. Available: . Date accessed: 2018‑10‑08. @@ -789,23 +770,11 @@ Bitcoin", 20 May 2018 [online]. Available: . Date accessed: 2018‑11‑16. - -[49]: https://github.com/b-g-goodell/research-lab/tree/master/source-code/StringCT-java 'GitHub: -b-g-goodell/research-lab' - [[50]] Wikipedia: "One-way Function" [online]. Available: . Date accessed: 2018‑11‑27. [50]: https://en.wikipedia.org/wiki/One-way_function 'Wikipedia: One-way Function' -[[51]] P. Sharma, A. K. Gupta and S. Sharma, "Intensified ElGamal Cryptosystem (IEC)", _International Journal of -Advances in Engineering & Technology_, January 2012 [online]. Available: -. Date accessed: 2018‑10‑09. - -[51]: http://www.e-ijaet.org/media/58I6-IJAET0612695.pdf 'Intensified ElGamal Cryptosystem (IEC)' - [[52]] Y. Tsiounis and M Yung, "On the Security of ElGamal Based Encryption" [online]. Available: . Date accessed: 2018‑10‑09. @@ -856,13 +825,6 @@ Rangeproofs and Much More' [60]: http://cryptonite.info/files/HMBC.pdf 'Homomorphic Mini-blockchain Scheme' -[[61]] C. Franck and J. Großschädl, "Efficient Implementation of Pedersen Commitments Using Twisted Edwards Curves", -University of Luxembourg [online]. Available: . Date -accessed: 2018‑11‑22. - -[61]: http://orbilu.uni.lu/bitstream/10993/33705/1/MSPN2017.pdf 'Efficient Implementation of Pedersen Commitments Using -Twisted Edwards Curves' - [[62]] A. Gibson, "An Investigation into Confidential Transactions", July 2018 [online]. Available: . Date accessed: 2018‑11‑22. @@ -884,10 +846,10 @@ Definitions of terms presented here are high level and general in nature. Full m in the cited references. - **Arithmetic Circuits:** An arithmetic circuit $ C $ over a field $ F $ and variables - $ (x_1, ..., x_n) $ is a directed acyclic graph whose vertices are called gates. Arithmetic circuits can alternatively be + $ (x*1, ..., x_n) $ is a directed acyclic graph whose vertices are called gates. Arithmetic circuits can alternatively be described as a list of addition and multiplication gates with a collection of linear consistency equations relating the inputs and outputs of the gates. The size of an arithmetic circuit is the number of gates in it, with the depth being - the length of the longest directed path. _Upper bounding_ the complexity of a polynomial $ f $ is to find any arithmetic + the length of the longest directed path. \_Upper bounding* the complexity of a polynomial $ f $ is to find any arithmetic circuit that can calculate $ f $, whereas *lower bounding* is to find the smallest arithmetic circuit that can calculate $ f $. An example of a simple arithmetic circuit with size six and depth two that calculates a polynomial is shown below ([[29]], [[47]]). @@ -922,7 +884,7 @@ cryptographic primitive ...' Analogously, in any group $ G $, powers $ b^k $ can be defined for all integers $ k $, and the discrete logarithm $ \log_ba $ is an integer $ k $ such that $ b^k=a $. Algorithms in public-key cryptography base their security on the assumption that the discrete logarithm problem over carefully chosen cyclic finite groups and cyclic subgroups of - elliptic curves over finite fields has no efficient solution ([[17]], [[40]]). + elliptic curves over finite fields has no efficient solution ([[17]]). [dlp~]: #dlp 'In the mathematics of the real numbers, the logarithm log_b(a) @@ -932,7 +894,7 @@ is a number x such that ...' Commitment ([[15]], [[22]]) will use secure Elliptic Curve Cryptography (ECC), which is based on the algebraic structure of elliptic curves over finite (prime) fields. Elliptic curve points are used as basic mathematical objects, instead of numbers. Note that traditionally in elliptic curve arithmetic lower case letters are used for ordinary numbers - (integers) and upper case letters for curve points ([[60]], [[61]], [[62]]). + (integers) and upper case letters for curve points ([[60]], [[62]]). - The generalized Elliptic Curve Pedersen Commitment definition follows (refer to [Appendix B: Notation Used](#appendix-b-notation-used)): @@ -974,7 +936,7 @@ Elliptic Curve Cryptography, which is ...' [[22]]) with an additional commitment $ g^r $ to the randomness used. The ElGamal encryption scheme is based on the Decisional Diffe-Hellman (DDH) assumption and the difficulty of the DLP for finite fields. The DDH assumption states that it is infeasible for a Probabilistic Polynomial-time (PPT) adversary to solve the DDH problem. **Note:** The - ElGamal encryption scheme should not be confused with the ElGamal signature scheme ([[1]], [[51]], [[52]], [[53]]). + ElGamal encryption scheme should not be confused with the ElGamal signature scheme ([[1]], [[52]], [[53]]). [egc~]: #egc 'An ElGamal Commitment is a Pedersen Commitment with @@ -1040,7 +1002,7 @@ $ g \in \mathbb G $ such that $ \mathbb G = \lbrace 1 \mspace{3mu} , \mspace{3mu g^2 \mspace{3mu} , \mspace{3mu} g^3 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} g^{p-1} \rbrace \equiv \mathbb Z_p $. Note that not every element of $ \mathbb Z_p $ is a generator of $ \mathbb G $. -- Let $ \mathbb Z_p^_ $ denote $ \mathbb Z_p \setminus \lbrace 0 \rbrace $ and $ \mathbb Z_q^_ $ denote +- Let $ \mathbb Z*p^* $ denote $ \mathbb Z*p \setminus \lbrace 0 \rbrace $ and $ \mathbb Z_q^* $ denote $ \mathbb Z_q \setminus \lbrace 0 \rbrace $, that is all invertible elements of $ \mathbb Z_p $ and $ \mathbb Z_q $ respectively. This excludes the element $ 0 $ which is not invertible. diff --git a/_includes/content/cryptography/08-the-bulletproof-protocols.md b/_includes/content/cryptography/08-the-bulletproof-protocols.md index 9522b66d..bb4399ff 100644 --- a/_includes/content/cryptography/08-the-bulletproof-protocols.md +++ b/_includes/content/cryptography/08-the-bulletproof-protocols.md @@ -29,7 +29,6 @@ - [Appendix A: Definition of Terms](#appendix-a-definition-of-terms) - [Contributors](#contributors) - ## Introduction The overview of Bulletproofs given in [Bulletproofs and Mimblewimble](/cryptography/bulletproofs-and-mimblewimble) @@ -39,7 +38,6 @@ different Bulletproof protocols as simply as possible. It also simplifies the lo mathematical concepts in more detail where prior knowledge was assumed. The report concludes with a discussion on an improved Bulletproof zero-knowledge proof protocol provided by some community members following an evolutionary approach. - ## Preliminaries ### Notation Used @@ -49,153 +47,152 @@ notation provides important pre-knowledge for the remainder of the report. - Let $ p $ and $ q ​$ be large prime numbers. - Let $ \mathbb G ​$ and $ \mathbb Q ​$ denote cyclic groups of prime order -$ p ​$ and $ q ​$ respectively. + $ p ​$ and $ q ​$ respectively. - let $ \mathbb Z_p ​$ and $ \mathbb Z_q ​$ denote the ring of integers -$ modulo \mspace{4mu} p ​$ and $ modulo \mspace{4mu} q ​$ respectively. + $ modulo \mspace{4mu} p ​$ and $ modulo \mspace{4mu} q ​$ respectively. - Let generators of $ \mathbb G $ be denoted by $ g, h, v, u \in \mathbb G $, i.e. there exists a number -$ g \in \mathbb G $ such that $ \mathbb G = \lbrace 1 \mspace{3mu} , \mspace{3mu} g \mspace{3mu} , -\mspace{3mu} g^2 \mspace{3mu} , \mspace{3mu} g^3 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} g^{p-1} -\rbrace \equiv \mathbb Z_p $. Note that not every element of $ \mathbb Z_p $ is a generator of $ \mathbb G $. -- Let $ \mathbb Z_p^* $ denote $ \mathbb Z_p \setminus \lbrace 0 \rbrace $ and $ \mathbb Z_q^* $ denote -$ \mathbb Z_q \setminus \lbrace 0 \rbrace $, i.e. all invertible elements of $ \mathbb Z_p $ and $ \mathbb Z_q $ +$ g \in \mathbb G $ such that $ \mathbb G = \lbrace 1 \mspace{3mu} , \mspace{3mu} g \mspace{3mu} , + \mspace{3mu} g^2 \mspace{3mu} , \mspace{3mu} g^3 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} g^{p-1} + \rbrace \equiv \mathbb Z_p $. Note that not every element of $ \mathbb Z_p $ is a generator of $ \mathbb G $. +- Let $ \mathbb Z*p^* $ denote $ \mathbb Z*p \setminus \lbrace 0 \rbrace $ and $ \mathbb Z_q^* $ denote + $ \mathbb Z_q \setminus \lbrace 0 \rbrace $, i.e. all invertible elements of $ \mathbb Z_p $ and $ \mathbb Z_q $ respectively. This excludes the element $ 0 ​$, which is not invertible. - Let $ \mathbb G^n $ and $ \mathbb Z^n_p $ be vector spaces of dimension -$ n $ over $ \mathbb G $ and $ \mathbb Z_p $ respectively. + $ n $ over $ \mathbb G $ and $ \mathbb Z_p $ respectively. - Let $ h^r \mathbf g^\mathbf x = h^r \prod_i g_i^{x_i} \in \mathbb G ​$ be the vector Pedersen -Commitment[def][pc~] with -$ \mathbf {g} = (g_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , -\mspace{3mu} g_n) \in \mathbb G^n ​$ and $ \mathbf {x} = (x_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , -\mspace{3mu} x_n) \in \mathbb G^n ​$. + Commitment[def][pc~] with + $ \mathbf {g} = (g_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , + \mspace{3mu} g_n) \in \mathbb G^n ​$ and $ \mathbf {x} = (x_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , + \mspace{3mu} x_n) \in \mathbb G^n ​$. - Let $ \mathbf {a} \in \mathbb F^n ​$ be a vector with elements -$ a_1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , -\mspace{3mu} a_n \in \mathbb F ​$. + $ a_1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , + \mspace{3mu} a_n \in \mathbb F ​$. - Let $ \langle \mathbf {a}, \mathbf {b} \rangle = -\sum _{i=1}^n {a_i \cdot b_i} ​$ denote the inner-product between two -vectors $ \mathbf {a}, \mathbf {b} \in \mathbb F^n ​$. + \sum \_{i=1}^n {a_i \cdot b_i} ​$ denote the inner-product between two + vectors $ \mathbf {a}, \mathbf {b} \in \mathbb F^n ​$. - Let $ \mathbf {a} \circ \mathbf {b} = -(a_1 \cdot b_1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , -\mspace{3mu} a_n \cdot b_n) \in \mathbb F^n ​$ denote the entry wise multiplication of two vectors $ \mathbf {a}, -\mathbf {b} \in \mathbb F^n ​$. + (a_1 \cdot b_1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , + \mspace{3mu} a_n \cdot b_n) \in \mathbb F^n ​$ denote the entry wise multiplication of two vectors $ \mathbf {a}, + \mathbf {b} \in \mathbb F^n ​$. - Let $ \mathbf {A} \circ \mathbf {B} = -(a_{11} \cdot b_{11} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , -\mspace{3mu} a_{1m} \cdot b_{1m} \mspace{6mu} ; \mspace{6mu} . . . \mspace{6mu} ; \mspace{6mu} a_{n1} \cdot b_{n1} -\mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_{nm} \cdot b_{nm} ) $ denote the entry wise -multiplication of two matrixes, also known as the Hadamard -Product[def][hdmp~]. + (a*{11} \cdot b*{11} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , + \mspace{3mu} a*{1m} \cdot b*{1m} \mspace{6mu} ; \mspace{6mu} . . . \mspace{6mu} ; \mspace{6mu} a*{n1} \cdot b*{n1} + \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a*{nm} \cdot b*{nm} ) $ denote the entry wise + multiplication of two matrixes, also known as the Hadamard + Product[def][hdmp~]. - Let $ \mathbf {a} \parallel \mathbf {b} ​$ denote the concatenation of two vectors; if -$ \mathbf {a} \in \mathbb Z_p^n ​$ + $ \mathbf {a} \in \mathbb Z_p^n ​$ and $ \mathbf {b} \in \mathbb Z_p^m ​$ then $ \mathbf {a} \parallel \mathbf {b} \in \mathbb Z_p^{n+m} ​$. -- Let $ p(X) = \sum _{i=0}^d { \mathbf {p_i} \cdot X^i} \in \mathbb Z_p^n [X] $ be a vector polynomial where each -coefficient $ \mathbf {p_i} $ is a vector in $ \mathbb Z_p^n $. +- Let $ p(X) = \sum \_{i=0}^d { \mathbf {p_i} \cdot X^i} \in \mathbb Z_p^n [X] $ be a vector polynomial where each + coefficient $ \mathbf {p_i} $ is a vector in $ \mathbb Z_p^n $. - Let $ \langle l(X),r(X) \rangle = -\sum _{i=0}^d { \sum _{j=0}^i { \langle l_i,r_i \rangle \cdot X^{i+j}}} \in -\mathbb Z_p [X] $ denote the inner-product between two vector -polynomials $ l(X),r(X) $. + \sum _{i=0}^d { \sum _{j=0}^i { \langle l_i,r_i \rangle \cdot X^{i+j}}} \in + \mathbb Z_p [X] $ denote the inner-product between two vector + polynomials $ l(X),r(X) $. - Let $ t(X)=\langle l(X),r(X) \rangle $, then the inner-product is defined such that $ t(x)=\langle l(x),r(x) -\rangle $ holds for all $ x \in \mathbb{Z_p} $. + \rangle $ holds for all $ x \in \mathbb{Z_p} $. - Let $ C=g^a = \prod _{i=1}^n g_i^{a_i} \in \mathbb{G} $ be a binding (but not hiding) commitment to the vector -$ \mathbf {a} \in \mathbb Z_p^n $ where $ \mathbf {g} = -(g_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , -\mspace{3mu} g_n) \in \mathbb G^n $. Given vector $ \mathbf {b} \in \mathbb Z_p^n $ with non-zero entries, + $ \mathbf {a} \in \mathbb Z_p^n $ where $ \mathbf {g} = + (g_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , + \mspace{3mu} g_n) \in \mathbb G^n $. Given vector $ \mathbf {b} \in \mathbb Z_p^n $ with non-zero entries, $ \mathbf {a} \circ \mathbf {b} $ is treated as a new commitment to $ C $. For this let $ g_i^\backprime =g_i^{(b_i^{-1})} $ such that -$ C= \prod _{i=1}^n (g_i^\backprime)^{a_i \cdot b_i} $. The binding property of this new commitment is inherited from -the old commitment. -- Let $ \mathbf a \_{[:l]} = ( a_1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_l ) \in \mathbb F ^ l$ -and $ \mathbf a \_{[l:]} = ( a_{1+1} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_n ) -\in \mathbb F ^ {n-l} $ be slices of vectors for $ 0 \le l \le n $ (using Python notation). -- Let $ \mathbf {k}^n $ denote the vector containing the first $ n $ powers of $ k \in \mathbb Z_p^* $ such that -$ \mathbf {k}^n = (1,k,k^2, \mspace{3mu} ... \mspace{3mu} ,k^{n-1}) \in (\mathbb Z_p^*)^n $. -- Let $ \mathcal{P} $ and $ \mathcal{V} $ denote the *prover* and *verifier* respectively. -- Let $ \mathcal{P_{IP}} $ and $ \mathcal{V_{IP}} ​$ denote the *prover* and *verifier* in relation to inner-product -calculations respectively. + $ C= \prod _{i=1}^n (g_i^\backprime)^{a_i \cdot b_i} $. The binding property of this new commitment is inherited from + the old commitment. +- Let $ \mathbf a \_{[:l]} = ( a*1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_l ) \in \mathbb F ^ l$ + and $ \mathbf a \_{[l:]} = ( a*{1+1} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_n ) + \in \mathbb F ^ {n-l} $ be slices of vectors for $ 0 \le l \le n $ (using Python notation). +- Let $ \mathbf {k}^n $ denote the vector containing the first $ n $ powers of $ k \in \mathbb Z*p^* $ such that + $ \mathbf {k}^n = (1,k,k^2, \mspace{3mu} ... \mspace{3mu} ,k^{n-1}) \in (\mathbb Z*p^*)^n $. +- Let $ \mathcal{P} $ and $ \mathcal{V} $ denote the _prover_ and _verifier_ respectively. +- Let $ \mathcal{P*{IP}} $ and $ \mathcal{V*{IP}} ​$ denote the _prover_ and _verifier_ in relation to inner-product + calculations respectively. ### Pedersen Commitments and Elliptic Curve Pedersen Commitments The basis of confidential transactions is the Pedersen Commitment scheme defined in [[15]]. -A commitment scheme in a Zero-knowledge Proof[def][zk~] is a cryptographic primitive that allows a *prover* $ \mathcal{P} $ to -commit to only a single chosen value/statement from a finite set without the ability to change it later (*binding* -property), while keeping it hidden from a *verifier* $ \mathcal{V} $ (*hiding* property). Both *binding* and *hiding* properties are then -further classified in increasing levels of security to be *computational*, *statistical* or *perfect*: +A commitment scheme in a Zero-knowledge Proof[def][zk~] is a cryptographic primitive that allows a _prover_ $ \mathcal{P} $ to +commit to only a single chosen value/statement from a finite set without the ability to change it later (_binding_ +property), while keeping it hidden from a _verifier_ $ \mathcal{V} $ (_hiding_ property). Both _binding_ and _hiding_ properties are then +further classified in increasing levels of security to be _computational_, _statistical_ or _perfect_: -- *Computational* means that no efficient algorithm running in a practical amount of time can reveal the commitment -amount or produce fake commitments, except with a small probability. -- *Statistical* means that the probability of an adversary doing the same in a finite amount of time is negligible. -- *Perfect* means that a quantum adversary (an attacker with infinite computing power) cannot tell what amount +- _Computational_ means that no efficient algorithm running in a practical amount of time can reveal the commitment + amount or produce fake commitments, except with a small probability. +- _Statistical_ means that the probability of an adversary doing the same in a finite amount of time is negligible. +- _Perfect_ means that a quantum adversary (an attacker with infinite computing power) cannot tell what amount has been committed to, and is unable to produce fake commitments. -No commitment scheme can simultaneously be perfectly *binding* and perfectly *hiding* ([[12]], [[13]]). +No commitment scheme can simultaneously be perfectly _binding_ and perfectly _hiding_ ([[12]], [[13]]). Two variations of the Pedersen Commitment scheme share the same security attributes: - - **Pedersen Commitment:** The Pedersen Commitment is a system for making a blinded, - non-interactive commitment to a value ([[1]], [[3]], [[8]], [[14]], [[15]]). + non-interactive commitment to a value ([[1]], [[3]], [[8]], [[15]]). + - The generalized Pedersen Commitment definition follows (refer to [Notation Used](#notation-used)): + - Let $ q $ be a large prime and $ p $ be a large safe prime such that $ p = 2q + 1 $. - Let $ h $ be a random generator of cyclic subgroup $ \mathbb Q $ of order $ q $. - Let $ a $ be a random value and element of $ \mathbb Q $ and calculate $ g $ such that $ g = h^a $. - - Let $ r $ (the blinding factor) be a random value and element of $ \mathbb Z_p^* $. + - Let $ r $ (the blinding factor) be a random value and element of $ \mathbb Z_p^\* $. - The commitment to value $ x $ is then determined by calculating $ C(x,r) = h^r g^x $, which is called the Pedersen - Commitment. + Commitment. - The generator $ h $ and resulting number $ g $ are known as the commitment bases and should be shared along with - $ C(x,r) $, with whomever wishes to open the value. + $ C(x,r) $, with whomever wishes to open the value. - Pedersen Commitments are also additionally homomorphic, such that for messages $ x_0 $ and $ x_1 $ and blinding - factors $ r_0 $ and $ r_1 $, we have $ C(x_0,r_0) \cdot C(x_1,r_1) = C(x_0+x_1,r_0+r_1) $ + factors $ r_0 $ and $ r_1 $, we have $ C(x_0,r_0) \cdot C(x_1,r_1) = C(x_0+x_1,r_0+r_1) $ -[pc~]: #pc -"The Pedersen commitment is a system +[pc~]: #pc 'The Pedersen commitment is a system for making blinded non-interactive -commitments to a value ..." - +commitments to a value ...' - **Elliptic Curve Pedersen Commitment:** An efficient implementation of the Pedersen Commitment[def][pc~] will use secure Elliptic Curve Cryptography (ECC), which is based on the algebraic structure of elliptic curves over finite (prime) fields. Elliptic curve points are used as basic mathematical objects, instead of numbers. Note that traditionally in elliptic curve arithmetic, lower-case letters are used for ordinary numbers (integers) and upper-case letters for curve points ([[26]], [[27]], [[28]]). + - The generalized Elliptic Curve Pedersen Commitment definition follows (refer to [Notation Used](#notation-used*): - - Let $ \mathbb F_p $ be the group of elliptic curve points, where $ p $ is a large prime. - - Let $ G \in \mathbb F_p $ be a random generator point (base point) and let $ H \in \mathbb F_p $ be specially - chosen so that the value $ x_H $ to satisfy $ H = x_H G $ cannot be found except if the Elliptic Curve DLP (ECDLP) - is solved. - - Let $ r $ (the blinding factor) be a random value and element of $ \mathbb Z_p $. + + - Let $ \mathbb F_p $ be the group of elliptic curve points, where $ p $ is a large prime. + - Let $ G \in \mathbb F_p $ be a random generator point (base point) and let $ H \in \mathbb F_p $ be specially + chosen so that the value $ x_H $ to satisfy $ H = x_H G $ cannot be found except if the Elliptic Curve DLP (ECDLP) + is solved. + - Let $ r $ (the blinding factor) be a random value and element of $ \mathbb Z_p $. - The commitment to value $ x \in \mathbb Z_p $ is then determined by calculating $ C(x,r) = rH + xG ​$, which is - called the Elliptic Curve Pedersen Commitment. + called the Elliptic Curve Pedersen Commitment. - Elliptic curve point addition is analogous to multiplication in the originally defined Pedersen - Commitment[def][pc~]. Thus $ g^x $, the number $ g $ multiplied by itself $ m $ times, is analogous - to $ xG $, the elliptic curve point $ G $ added to itself $ x $ times. In this context, $ xG $ is also a point - in $ \mathbb F_p $. + Commitment[def][pc~]. Thus $ g^x $, the number $ g $ multiplied by itself $ m $ times, is analogous + to $ xG $, the elliptic curve point $ G $ added to itself $ x $ times. In this context, $ xG $ is also a point + in $ \mathbb F_p $. - In the Elliptic Curve context, $ C(x,r) = rH + xG $ is then analogous to $ C(x,r) = h^r g^x $. - The number $ H $ is what is known as a Nothing Up My Sleeve (NUMS) number. With secp256k1, the value of $ H $ is the - SHA256 hash of a simple encoding of the prespecified generator point $ G $. + SHA256 hash of a simple encoding of the prespecified generator point $ G $. - Similar to Pedersen Commitments, the Elliptic Curve Pedersen Commitments are also additionally homomorphic, such - that for messages $ x $, $ x_0 $ and $ x_1 $, blinding factors $ r $, $ r_0 $ and $ r_1 $ and scalar $ k $, the + that for messages $ x $, $ x_0 $ and $ x_1 $, blinding factors $ r $, $ r_0 $ and $ r_1 $ and scalar $ k $, the following relation holds: $ C(x_0,r_0) + C(x_1,r_1) = C(x_0+x_1,r_0+r_1) $ and $ C(k \cdot x, k \cdot r) = k \cdot C(x, r) $. - In secure implementations of ECC, it is as hard to guess $ x $ from $ xG $ as it is to guess $ x $ from $g^x $. - This is called the Elliptic Curve DLP (ECDLP). + This is called the Elliptic Curve DLP (ECDLP). - Practical implementations usually consist of three algorithms: Setup() to set up the commitment - parameters; Commit() to commit to the message using the commitment parameters; and Open() to - open and verify the commitment. + parameters; Commit() to commit to the message using the commitment parameters; and Open() to + open and verify the commitment. -[ecpc~]: #ecpc -"An efficient implementation of the +[ecpc~]: #ecpc 'An efficient implementation of the Pedersen Commitment will use secure -Elliptic Curve Cryptography, which is ..." - +Elliptic Curve Cryptography, which is ...' ### Security Aspects of (Elliptic Curve) Pedersen Commitments -By virtue of their definition, Pedersen Commitments are only computationally *binding* but perfectly *hiding*. A +By virtue of their definition, Pedersen Commitments are only computationally _binding_ but perfectly _hiding_. A simplified explanation follows. If Alice wants to commit to a value $ x $ that will be sent to Bob, who will at a later stage want Alice to prove that @@ -205,14 +202,13 @@ do the calculation and see that the commitment $ C $ it produces is the same as Perhaps Alice or Bob has managed to build a computer that can solve the DLP and, given a public key, could find alternative solutions to $ C(x,r) = h^r g^x $ in a reasonable time, i.e. -$ C(x,r) = h^{r^\prime} g^{x^\prime} $. This means, even though Bob can find values for +$ C(x,r) = h^{r^\prime} g^{x^\prime} $. This means, even though Bob can find values for $ r^\prime $ and $ x^\prime $ that produce $ C $, he cannot know if those are the specific $ x $ and $ r $ that Alice -chose, because there are so many that can produce the same $ C $. Pedersen Commitments are thus perfectly *hiding*. +chose, because there are so many that can produce the same $ C $. Pedersen Commitments are thus perfectly _hiding_. -Although the Pedersen Commitment is perfectly *hiding*, it does rely on the fact that Alice has NOT cracked the DLP to be +Although the Pedersen Commitment is perfectly _hiding_, it does rely on the fact that Alice has NOT cracked the DLP to be able to calculate other pairs of input values to open the commitment to another value when challenged. The Pedersen -Commitment is thus only computationally *binding*. - +Commitment is thus only computationally _binding_. ## Bulletproof Protocols @@ -246,8 +242,8 @@ The following list links these use cases to the different Bulletproof protocols: Sigma protocols. - Batch verifications can be done using -[Optimized Verifier using Multi-exponentiation and Batch Verification](#optimized-verifier-using-multi-exponentiation-and-batch-verification), -e.g. a blockchain full node receiving a block of transactions needs to verify all transactions as well as range proofs. + [Optimized Verifier using Multi-exponentiation and Batch Verification](#optimized-verifier-using-multi-exponentiation-and-batch-verification), + e.g. a blockchain full node receiving a block of transactions needs to verify all transactions as well as range proofs. A detailed mathematical discussion of the different Bulletproof protocols follows. Protocols 1, 2 and 3 are numbered consistently with [[1]]. Refer to [Notation Used](#notation-used). @@ -255,12 +251,11 @@ consistently with [[1]]. Refer to [Notation Used](#notation-used). **Note:** Full mathematical definitions and terms not defined are available in [[1]].
- ### Inner-product Argument (Protocol 1) The first and most important building block of the Bulletproofs is its efficient algorithm to calculate an inner-product argument for two independent (not related) binding vector Pedersen Commitments[def][pc~]. -Protocol 1 is an argument of knowledge that the *prover* $ \mathcal{P} $ knows the openings of two binding Pedersen +Protocol 1 is an argument of knowledge that the _prover_ $ \mathcal{P} $ knows the openings of two binding Pedersen vector commitments that satisfy a given inner product relation. Let inputs to the inner-product argument be independent generators $ g,h \in \mathbb G^n $, a scalar $ c \in \mathbb Z_p $ and $ P \in \mathbb G $. The argument lets the *prover* $ \mathcal{P} $ convince a *verifier* $ \mathcal{V} $ that the *prover* $ \mathcal{P} $ knows two vectors @@ -282,9 +277,9 @@ $$ \tag{1} $$ -Relation (1) requires sending $ 2n $ elements to the *verifier* $ \mathcal{V} $. The inner product +Relation (1) requires sending $ 2n $ elements to the _verifier_ $ \mathcal{V} $. The inner product $ c = \langle \mathbf {a} \mspace{3mu}, \mspace{3mu} \mathbf {b} \rangle \ $ can be made part of the vector commitment -$ P \in \mathbb G $. This will enable sending only $ 2 \log 2 (n) $ elements to the *verifier* $ \mathcal{V} $ +$ P \in \mathbb G $. This will enable sending only $ 2 \log 2 (n) $ elements to the *verifier* $ \mathcal{V} $ (explained in the next section). For a given $ P \in \mathbb G $, the *prover* $ \mathcal{P} $ proves that it has vectors $ \mathbf {a}, \mathbf {b} \in \mathbb Z^n_p $ for which $ P =\mathbf{g}^\mathbf{a}\mathbf{h}^\mathbf{b} \cdot u^{ \langle \mathbf {a}, \mathbf {b} \rangle } $. @@ -302,7 +297,7 @@ A proof system for relation (2) gives a proof system for (1) with the same compl relation (2) is required. Protocol 1 is then defined as the proof system for relation (2) as shown in Figure 1. The element $ u $ is raised -to a random power $ x $ (the challenge) chosen by the *verifier* $ \mathcal{V} $ to ensure that the extracted vectors +to a random power $ x $ (the challenge) chosen by the _verifier_ $ \mathcal{V} $ to ensure that the extracted vectors $ \mathbf {a}, \mathbf {b} $ from [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2) satisfy $ c = \langle \mathbf {a} , \mathbf {b} \rangle $. @@ -314,15 +309,11 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1]
- - - The argument presented in Protocol 1 has the following Commitment Scheme properties: - **Perfect completeness (hiding):** Every validity/truth is provable. Also refer to Definition 9 in [[1]]. - **Statistical witness extended emulation (binding):** Robust against either extracting a non-trivial discrete -logarithm relation between $ \mathbf {g} , \mathbf {h} , u $ or extracting a valid witness $ \mathbf {a}, \mathbf {b} $. - + logarithm relation between $ \mathbf {g} , \mathbf {h} , u $ or extracting a valid witness $ \mathbf {a}, \mathbf {b} $. ### How Proof System for Protocol 1 Works, Shrinking by Recursion @@ -330,7 +321,7 @@ Protocol 1 uses an inner product argument of two vectors $ \mathbf a, \mathbf b The Pedersen Commitment scheme allows a vector to be cut in half and the two halves to then be compressed together. Let $ \mathrm H : \mathbb Z^{2n+1}_p \to \mathbb G $ be a hash function for commitment $ P $, with $ P = \mathrm H(\mathbf a , \mathbf b, \langle \mathbf a, \mathbf b \rangle) $. Note that commitment $ P $ and thus -$ \mathrm H $ is additively homomorphic, therefore sliced vectors of $ \mathbf a, \mathbf b \in \mathbb Z^n_p $ can be +$ \mathrm H $ is additively homomorphic, therefore sliced vectors of $ \mathbf a, \mathbf b \in \mathbb Z^n_p $ can be hashed together with inner product $ c = \langle \mathbf a , \mathbf b \rangle \in \mathbb Z_p$. If $ n ^\prime = n/2 ​$, starting with relation (2), then @@ -377,11 +368,11 @@ $$ The first reduction step is as follows: -- The *prover* $ \mathcal{P} $ calculates $ L,R \in \mathbb G $ and sends it to the *verifier* $ \mathcal{V} $. -- The *verifier* $ \mathcal{V} $ chooses a random $ x \overset{\$}{\gets} \mathbb Z _p $ and sends it to the -*prover* $ \mathcal{P} $. -- The *prover* $ \mathcal{P} ​$ calculates $ \mathbf a^\prime , \mathbf b^\prime \in \mathbb Z^{n^\prime}_p ​$ and sends -it to the *verifier* $ \mathcal{V} ​$: +- The _prover_ $ \mathcal{P} $ calculates $ L,R \in \mathbb G $ and sends it to the _verifier_ $ \mathcal{V} $. +- The _verifier_ $ \mathcal{V} $ chooses a random $ x \overset{\$}{\gets} \mathbb Z \_p $ and sends it to the + _prover_ $ \mathcal{P} $. +- The _prover_ $ \mathcal{P} ​$ calculates $ \mathbf a^\prime , \mathbf b^\prime \in \mathbb Z^{n^\prime}\_p ​$ and sends + it to the _verifier_ $ \mathcal{V} ​$: $$ \begin{aligned} @@ -390,7 +381,7 @@ $$ \end{aligned} $$ -- The *verifier* $ \mathcal{V} ​$ calculates $ P^\prime = L^{x^2} \cdot P \cdot R^{x^{-2}} ​$ and accepts (verify true) if +- The _verifier_ $ \mathcal{V} ​$ calculates $ P^\prime = L^{x^2} \cdot P \cdot R^{x^{-2}} ​$ and accepts (verify true) if $$ P^\prime = \mathrm H ( x^{-1} \mathbf a^\prime \mspace{3mu} , \mspace{3mu} x \mathbf a^\prime \mspace{6mu} , @@ -401,9 +392,10 @@ $$
-So far, the *prover* $ \mathcal{P} $ only sent $ n + 2 $ elements to the *verifier* $ \mathcal{V} $, i.e. the four +So far, the _prover_ $ \mathcal{P} $ only sent $ n + 2 $ elements to the _verifier_ $ \mathcal{V} $, i.e. the four tuple $ ( L , R , \mathbf a^\prime , \mathbf b^\prime ) $, approximately half the length compared to sending the complete -$ \mathbf a, \mathbf b \in \mathbb Z^n_p $. The test in relation (3) is the same as testing that +$ \mathbf a, \mathbf b \in \mathbb Z^n_p $. The test in relation (3) is the same as testing that + $$ P^\prime = (\mathbf g ^ {x^{-1}} _{[: n ^\prime]} \circ \mathbf g ^ x _{[n ^\prime :]})^{\mathbf a^\prime} \cdot @@ -412,7 +404,7 @@ u^{\langle \mathbf a^\prime , \mathbf b^\prime \rangle} \tag{4} $$ -Thus, the *prover* $ \mathcal{P} ​$ and *verifier* $ \mathcal{V} ​$ can recursively engage in an inner-product argument +Thus, the _prover_ $ \mathcal{P} ​$ and _verifier_ $ \mathcal{V} ​$ can recursively engage in an inner-product argument for $ P^\prime ​$ with respect to generators $$ @@ -421,39 +413,39 @@ $$ u ) $$ -which will result in a $ \log _2 n $ round protocol with $ 2 \log _2 n $ elements in $ \mathbb G $ and $ 2 $ elements in -$ \mathbb Z _p $. The *prover* $ \mathcal{P} $ ends up sending the following terms to the *verifier* $ \mathcal{V} ​$: +which will result in a $ \log \_2 n $ round protocol with $ 2 \log \_2 n $ elements in $ \mathbb G $ and $ 2 $ elements in +$ \mathbb Z \_p $. The *prover* $ \mathcal{P} $ ends up sending the following terms to the *verifier* $ \mathcal{V} ​$: + $$ (L_1 , R_1) \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} (L_{\log _2 n} , R _{\log _2 n}) \mspace{3mu} , \mspace{3mu} (a , b) $$ -where $ a,b \in \mathbb Z _p ​$ are only sent right at the end. This protocol can be made non-interactive using the +where $ a,b \in \mathbb Z \_p ​$ are only sent right at the end. This protocol can be made non-interactive using the Fiat-Shamir[def](#fsh) heuristic. - ### Inner-product Verification through Multi-exponentiation (Protocol 2) -The inner product argument to be calculated is that of two vectors $ \mathbf a, \mathbf b \in \mathbb Z^n_p $ of size -$ n $. Protocol 2 has a logarithmic number of rounds. In each round, the *prover* $ \mathcal{P} $ and -*verifier* $ \mathcal{V} $ calculate a new set of generators $ ( \mathbf g ^\prime , \mathbf h ^\prime ) $, which would +The inner product argument to be calculated is that of two vectors $ \mathbf a, \mathbf b \in \mathbb Z^n*p $ of size +$ n $. Protocol 2 has a logarithmic number of rounds. In each round, the \_prover* $ \mathcal{P} $ and +_verifier_ $ \mathcal{V} $ calculate a new set of generators $ ( \mathbf g ^\prime , \mathbf h ^\prime ) $, which would require a total of $ 4n $ computationally expensive exponentiations. Multi-exponentiation is a technique to reduce the number of exponentiations for a given calculation. In Protocol 2, the number of exponentiations is reduced to a single multi-exponentiation by delaying all the exponentiations until the last round. It can also be made non-interactive using the Fiat-Shamir[def](#fsh) heuristic, providing a further speedup. -Let $ g $ and $ h $ be the generators used in the final round of the protocol and $ x_j $ be the challenge from the -$ j _{th} $ round. In the last round, the *verifier* $ \mathcal{V} $ checks that $ g^a h^b u ^{a \cdot b} = P $, where -$ a,b \in \mathbb Z_p $ are given by the *prover* $ \mathcal{P} $. The final $ g $ and $ h $ can be expressed in terms +Let $ g $ and $ h $ be the generators used in the final round of the protocol and $ x*j $ be the challenge from the +$ j *{th} $ round. In the last round, the _verifier_ $ \mathcal{V} $ checks that $ g^a h^b u ^{a \cdot b} = P $, where +$ a,b \in \mathbb Z*p $ are given by the \_prover* $ \mathcal{P} $. The final $ g $ and $ h $ can be expressed in terms of the input generators $ \mathbf {g},\mathbf {h} \in \mathbb G^n $ as: $$ g = \prod _{i=1}^n g_i^{s_i} \in \mathbb{G}, \mspace{21mu} h=\prod _{i=1}^n h_i^{1/s_i} \in \mathbb{G} $$ -where $ \mathbf {s} = (s_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} s_n) \in \mathbb Z_p^n $ only +where $ \mathbf {s} = (s*1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} s_n) \in \mathbb Z_p^n $ only depends on the challenges $ (x_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , -\mspace{3mu} x_{\log_2(n)}) \in \mathbb Z_p^n $.  The scalars of $ \mathbf {s} $ are calculated as follows: +\mspace{3mu} x*{\log_2(n)}) \in \mathbb Z_p^n $.  The scalars of $ \mathbf {s} $ are calculated as follows: $$ s_i = \prod ^{\log _2 (n)} _{j=1} x ^{b(i,j)} _j @@ -490,20 +482,17 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1]
- - - ### Range Proof Protocol with Logarithmic Size This protocol provides short and aggregatable range proofs, using the improved inner product argument from Protocol 1. It is built up in five parts: -- how to construct a range proof that requires the *verifier* $ \mathcal{V} $ to check an inner product between two -vectors; +- how to construct a range proof that requires the _verifier_ $ \mathcal{V} $ to check an inner product between two + vectors; - how to replace the inner product argument with an efficient inner-product argument; - how to efficiently aggregate $ m $ range proofs into one short proof; - how to make interactive public coin protocols non-interactive by using the Fiat-Shamir[def](#fsh) heuristic; -and + and - how to allow multiple parties to construct a single aggregate range proof. Figure 3 gives a diagrammatic overview of a range proof protocol implementation using Elliptic Curve Pedersen @@ -514,11 +503,9 @@ Commitments[def][ecpc~]: Example [22] - - #### Inner-product Range Proof -This protocol provides the ability to construct a range proof that requires the *verifier* $ \mathcal{V} ​$ to check an +This protocol provides the ability to construct a range proof that requires the _verifier_ $ \mathcal{V} ​$ to check an inner product between two vectors. The range proof is constructed by exploiting the fact that a Pedersen Commitment $ V ​$ is an element in the same group $ \mathbb G ​$ that is used to perform the inner product argument. Let $ v \in \mathbb Z_p ​$ and let $ V \in \mathbb G ​$ be a Pedersen Commitment to $ v ​$ using randomness $ \gamma ​$. @@ -531,10 +518,10 @@ $$ $$ without revealing $ v ​$. Let $ \mathbf {a}_L = (a_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , -\mspace{3mu} a_n) \in \{0,1\}^n ​$ be the vector containing the bits of $ v, ​$ so that $ \langle \mathbf {a}_L, -\mathbf {2}^n \rangle = v ​$. The *prover* $ \mathcal{P} ​$ commits to $ \mathbf {a}_L ​$ using a constant size vector +\mspace{3mu} a_n) \in \{0,1\}^n ​$ be the vector containing the bits of $ v, ​$ so that $ \langle \mathbf {a}\_L, +\mathbf {2}^n \rangle = v ​$. The *prover* $ \mathcal{P} ​$ commits to $ \mathbf {a}\_L ​$ using a constant size vector commitment $ A \in \mathbb{G} ​$. It will convince the *verifier* $ \mathcal{V} ​$ that $ v ​$ is in $ [0,2^n - 1] ​$ by -proving that it knows an opening $ \mathbf {a}_L \in \mathbb Z_p^n ​$ of $ A ​$ and $ v, \gamma \in \mathbb{Z_p} ​$ such +proving that it knows an opening $ \mathbf {a}\_L \in \mathbb Z_p^n ​$ of $ A ​$ and $ v, \gamma \in \mathbb{Z_p} ​$ such that $ V =h^\gamma g^v ​$ and $$ @@ -544,15 +531,16 @@ $$ \tag{6} $$ -This proves that $ a_1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} a_n $ are all in $ \{0,1\} $ and that -$ \mathbf {a}_L $ is composed of the bits of $ v $. However, the $ 2n + 1 $ constraints need to be expressed as a +This proves that $ a*1 \mspace{3mu} , \mspace{3mu} ... \mspace{3mu} , \mspace{3mu} a_n $ are all in $ \{0,1\} $ and that +$ \mathbf {a}\_L $ is composed of the bits of $ v $. However, the $ 2n + 1 $ constraints need to be expressed as a single inner-product constant so that [Protocol 1](#inner-product-argument-protocol-1) can be used, by letting the *verifier* $ \mathcal{V} $ choose a random linear combination of the constraints. To prove that a committed vector $ \mathbf {b} \in \mathbb Z_p^n $ satisfies $ \mathbf {b} = \mathbf{0}^n $, it suffices for the -*verifier* $ \mathcal{V} $ to send a random $ y \in \mathbb{Z_p} $ to the *prover* $ \mathcal{P} $ and for the -*prover* $ \mathcal{P} $ to prove that $ \langle \mathbf {b}, \mathbf {y}^n \rangle = 0 $, which will convince the -*verifier* $ \mathcal{V} $ that $ \mathbf {b} = \mathbf{0}^n $. The *prover* $ \mathcal{P} $ can thus prove relation +\_verifier* $ \mathcal{V} $ to send a random $ y \in \mathbb{Z*p} $ to the \_prover* $ \mathcal{P} $ and for the +_prover_ $ \mathcal{P} $ to prove that $ \langle \mathbf {b}, \mathbf {y}^n \rangle = 0 $, which will convince the +_verifier_ $ \mathcal{V} $ that $ \mathbf {b} = \mathbf{0}^n $. The _prover_ $ \mathcal{P} $ can thus prove relation (6) by proving that + $$ \langle \mathbf {a}_L \mspace{3mu} , \mspace{3mu} \mathbf {2}^n \rangle = v \mspace{20mu} \mathrm{and} \mspace{20mu} \langle \mathbf {a}_L - 1 - \mathbf {a}_R \mspace{3mu} , \mspace{3mu} \mathbf {y}^n \rangle=0 \mspace{20mu} \mathrm{and} @@ -560,8 +548,8 @@ $$ \mathbf{0}^n \mspace{20mu} $$ -Building on this, the *verifier* $ \mathcal{V} $ chooses a random $ z \in \mathbb{Z_p} $ and lets the -*prover* $ \mathcal{P} $ prove that +Building on this, the _verifier_ $ \mathcal{V} $ chooses a random $ z \in \mathbb{Z*p} $ and lets the +\_prover* $ \mathcal{P} $ prove that $$ z^2 \cdot \langle \mathbf {a}_L \mspace{3mu} , @@ -588,12 +576,12 @@ $$ \mspace{3mu} \mathbf {2}^n\rangle \in \mathbb{Z_p} $$ -can be easily calculated by the *verifier* $ \mathcal{V} ​$. The proof that relation (6) holds was thus reduced to a +can be easily calculated by the _verifier_ $ \mathcal{V} ​$. The proof that relation (6) holds was thus reduced to a single inner-product identity. -Relation (8) cannot be used in its current form without revealing information about $ \mathbf {a}_L $. Two additional -blinding vectors $ \mathbf {s}_L , \mathbf {s}_R \in \mathbb Z_p^n $ are introduced with the *prover* $ \mathcal{P} $ -and *verifier* $ \mathcal{V} $ engaging in the zero-knowledge protocol shown in Figure 4: +Relation (8) cannot be used in its current form without revealing information about $ \mathbf {a}\_L $. Two additional +blinding vectors $ \mathbf {s}\_L , \mathbf {s}\_R \in \mathbb Z*p^n $ are introduced with the \_prover* $ \mathcal{P} $ +and _verifier_ $ \mathcal{V} $ engaging in the zero-knowledge protocol shown in Figure 4:

Figure 4: Bulletproofs Inner-product Range Proof @@ -603,10 +591,8 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1]
- - Two linear vector polynomials $ l(X), r(X) \in \mathbb Z^n_p[X] $ are defined as the inner-product terms for relation -(8), also containing the blinding vectors $ \mathbf {s}_L $ and $ \mathbf {s}_R $. A quadratic polynomial +(8), also containing the blinding vectors $ \mathbf {s}\_L $ and $ \mathbf {s}\_R $. A quadratic polynomial $ t(X) \in \mathbb Z_p[X] $ is then defined as the inner product between the two vector polynomials $ l(X), r(X) $ such that @@ -615,18 +601,18 @@ t(X) = \langle l(X) \mspace{3mu} , \mspace{3mu} r(X) \rangle = t_0 + t_1 \cdot X + t_2 \cdot X^2 \mspace{10mu} \in \mathbb {Z}_p[X] $$ -The blinding vectors $ \mathbf {s}_L ​$ and $ \mathbf {s}_R ​$ ensure that the *prover* $ \mathcal{P} ​$ can publish -$ l(x) ​$ and $ r(x) ​$ for one $ x \in \mathbb Z_p^* ​$ without revealing any information about $ \mathbf {a}_L ​$ and -$ \mathbf {a}_R ​$. The constant term $ t_0 ​$ of the quadratic polynomial $ t(X) ​$ is then the result of the inner -product in relation (8), and the *prover* $ \mathcal{P} ​$ needs to convince the *verifier* $ \mathcal{V} ​$ that +The blinding vectors $ \mathbf {s}\_L ​$ and $ \mathbf {s}\_R ​$ ensure that the _prover_ $ \mathcal{P} ​$ can publish +$ l(x) ​$ and $ r(x) ​$ for one $ x \in \mathbb Z_p^* ​$ without revealing any information about $ \mathbf {a}\_L ​$ and +$ \mathbf {a}\_R ​$. The constant term $ t_0 ​$ of the quadratic polynomial $ t(X) ​$ is then the result of the inner +product in relation (8), and the *prover* $ \mathcal{P} ​$ needs to convince the *verifier\* $ \mathcal{V} ​$ that $$ t_0 = z^2 \cdot v + \delta (y,z) $$ -In order to do so, the *prover* $ \mathcal{P} $ convinces the *verifier* $ \mathcal{V} $ that it has a commitment to the +In order to do so, the _prover_ $ \mathcal{P} $ convinces the _verifier_ $ \mathcal{V} $ that it has a commitment to the remaining coefficients of $ t(X) $, namely $ t_1,t_2 \in \mathbb Z_p $, by checking the value of $ t(X) $ at a random -point $ x \in \mathbb Z_p^* $. This is illustrated in Figure 5: +point $ x \in \mathbb Z_p^\* $. This is illustrated in Figure 5:

Figure 5: Bulletproofs Inner-product Range Proof @@ -636,14 +622,12 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1]
- - -The *verifier* $ \mathcal{V} $ now needs to check that $ l $ and $ r $ are in fact $ l(x) $ and $ r(x) $, and that +The _verifier_ $ \mathcal{V} $ now needs to check that $ l $ and $ r $ are in fact $ l(x) $ and $ r(x) $, and that $ t(x) = \langle l \mspace{3mu} , \mspace{3mu} r \rangle $. A commitment for $ \mathbf {a}_R \circ \mathbf {y}^n $ is needed and to do so, the commitment generators are switched from $ h \in \mathbb G^n $ to $ h ^\backprime = h^{(\mathbf {y}^{-1})}$. Thus $ A $ and $ S $ now become vector commitments to -$ ( \mathbf {a}_L \mspace{3mu} , \mspace{3mu} \mathbf {a}_R \circ \mathbf {y}^n ) $ and $ ( \mathbf {s}_L \mspace{3mu} , -\mspace{3mu} \mathbf {s}_R \circ \mathbf {y}^n ) $ respectively, with respect to the new generators +$ ( \mathbf {a}\_L \mspace{3mu} , \mspace{3mu} \mathbf {a}\_R \circ \mathbf {y}^n ) $ and $ ( \mathbf {s}\_L \mspace{3mu} , +\mspace{3mu} \mathbf {s}\_R \circ \mathbf {y}^n ) $ respectively, with respect to the new generators $ (g, h ^\backprime, h) ​$. This is illustrated in Figure 6.

@@ -654,39 +638,34 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1] - - - The range proof presented here has the following Commitment Scheme properties: - **Perfect completeness (hiding).** Every validity/truth is provable. Also refer to Definition 9 in [[1]]. -- **Perfect special Honest Verifier Zero-knowledge (HVZK).** The *verifier* $ \mathcal{V} $ behaves according to the protocol. -Also refer to Definition 12 in [[1]]. +- **Perfect special Honest Verifier Zero-knowledge (HVZK).** The _verifier_ $ \mathcal{V} $ behaves according to the protocol. + Also refer to Definition 12 in [[1]]. - **Computational witness extended emulation (binding).** A witness can be computed in time closely related to time - spent by the *prover* $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. - + spent by the _prover_ $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. #### Logarithmic Range Proof This protocol replaces the inner product argument with an efficient inner-product argument. In step (63) in -Figure 5, the *prover* $ \mathcal{P} $ transmits $ \mathbf {l} $ and $ \mathbf {r} $ to the *verifier* +Figure 5, the _prover_ $ \mathcal{P} $ transmits $ \mathbf {l} $ and $ \mathbf {r} $ to the _verifier_ $ \mathcal{V} $, but their size is linear in $ n $. To make this efficient, a proof size that is logarithmic in $ n $ is needed. The transfer of $ \mathbf {l} $ and $ \mathbf {r} $ can be eliminated with an inner-product argument. Checking correctness of $ \mathbf {l} $ and $ \mathbf {r} $ (step 67 in Figure 6) and $ \hat {t} $ (step 68 in Figure 6) is the same as verifying that the witness $ \mathbf {l} , \mathbf {r} $ satisfies the inner product of relation (2) on public input $ (\mathbf {g} , \mathbf {h} ^ \backprime , P \cdot h^{-\mu}, \hat t) $. Transmission of vectors $ \mathbf {l} $ and -$ \mathbf {r} $ to the *verifier* $ \mathcal{V} $ (step 63 in Figure 5) can then be eliminated and transfer -of information limited to the scalar properties $ ( \tau _x , \mu , \hat t ) $ alone, thereby archiving a proof size +$ \mathbf {r} $ to the _verifier_ $ \mathcal{V} $ (step 63 in Figure 5) can then be eliminated and transfer +of information limited to the scalar properties $ ( \tau \_x , \mu , \hat t ) $ alone, thereby archiving a proof size that is logarithmic in $ n $. - #### Aggregating Logarithmic Proofs This protocol efficiently aggregates $ m $ range proofs into one short proof with a slight modification to the protocol presented in [Inner-product Range Proof](#inner-product-range-proof). For aggregate range proofs, the inputs of one range proof do not affect the output of another range proof. Aggregating logarithmic range proofs is especially helpful -if a single *prover* $ \mathcal{P} $ needs to perform multiple range proofs at the same time. +if a single _prover_ $ \mathcal{P} $ needs to perform multiple range proofs at the same time. A proof system must be presented for the following relation: @@ -698,7 +677,7 @@ h^{\gamma_j} g^{v_j} \mspace{6mu} \wedge \mspace{6mu} v_j \in [0,2^n - 1] \mspac \tag{9} $$ -The *prover* $ \mathcal{P} $ should now compute $ \mspace{3mu} \mathbf a_L \in \mathbb Z_p^{n \cdot m} $ as the +The _prover_ $ \mathcal{P} $ should now compute $ \mspace{3mu} \mathbf a_L \in \mathbb Z_p^{n \cdot m} $ as the concatenation of all of the bits for every $ v_j $ such that $$ @@ -707,7 +686,7 @@ v_j \mspace{9mu} \forall \mspace{9mu} j \in [1,m] \mspace{3mu} $$ The quantity $ \delta (y,z) $ is adjusted to incorporate more cross-terms $ n \cdot m $ , the linear vector polynomials -$ l(X), r(X) $ are adjusted to be in $ \mathbb Z^{n \cdot m}_p[X] $ and the blinding factor $ \tau_x $ for the inner +$ l(X), r(X) $ are adjusted to be in $ \mathbb Z^{n \cdot m}\_p[X] $ and the blinding factor $ \tau_x $ for the inner product $ \hat{t} $ (step 61 in Figure 5) is adjusted for the randomness of each commitment $ V_j $. The verification check (step 65 in Figure 6) is updated to include all $ V_j $ commitments and the definition of $ P $ (step 66 in Figure 6) is changed to be a commitment to the new $ r $. @@ -720,26 +699,24 @@ $ m $ independent range proofs. The aggregate range proof presented here has the following Commitment Scheme properties: - **Perfect completeness (hiding):** Every validity/truth is provable. Also refer to Definition 9 in [[1]]. -- **Perfect special HVZK:** The *verifier* $ \mathcal{V} $ behaves according to the -protocol. Also refer to Definition 12 in [[1]]. +- **Perfect special HVZK:** The _verifier_ $ \mathcal{V} $ behaves according to the + protocol. Also refer to Definition 12 in [[1]]. - **Computational witness extended emulation (binding):** A witness can be computed in time closely related to time -spent by the *prover* $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. - + spent by the _prover_ $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. #### Non-interactive Proof through Fiat-Shamir Heuristic -So far, the *verifier* $ \mathcal{V} ​$ behaves as an honest verifier and all messages are random elements from -$ \mathbb Z_p^* ​$. These are the prerequisites needed to convert the protocol presented so far into a non-interactive +So far, the _verifier_ $ \mathcal{V} ​$ behaves as an honest verifier and all messages are random elements from +$ \mathbb Z_p^\* ​$. These are the prerequisites needed to convert the protocol presented so far into a non-interactive protocol that is secure and has full zero-knowledge in the random oracle model (thus without a trusted setup) using the Fiat-Shamir Heuristic[def][fsh~]. - #### MPC Protocol for Bulletproofs The Multi-party Computation (MPC) protocol for Bulletproofs allows multiple parties to construct a single, simple, efficient, aggregate range proof designed for Bulletproofs. This is valuable when multiple parties want to create a single joined confidential transaction, where each party knows some of the inputs and outputs, and needs to create range -proofs for their known outputs. In Bulletproofs, $ m $ parties, each having a Pedersen Commitment $ (V_k)_{k=1}^m $, can +proofs for their known outputs. In Bulletproofs, $ m $ parties, each having a Pedersen Commitment $ (V*k)*{k=1}^m $, can generate a single Bulletproof to which each $ V_k $ commits in some fixed range. Let $ k $ denote the $ k $th party's message, thus $ A^{(k)} $ is generated using only inputs of party $ k $. A set of @@ -787,7 +764,6 @@ dealer computes $ L, R $ as the homomorphic sum of the shares. In the final roun challenge and sends it to each party, who in turn send their witness to the dealer, who completes [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2). - #### MPC Protocol Security Discussion With the standard MPC protocol implementation as depicted in Figure 7, there's no guarantee that the dealer behaves @@ -801,7 +777,6 @@ HVZK implies witness-indistinguishability [[32]], but it isn't clear what the im would be on the MPC protocol in practice. It could be that there are no practical attacks possible from a malicious dealer and that witness-indistinguishability is sufficient. - ### Zero-knowledge Proof for Arithmetic Circuits Bulletproofs present an efficient zero-knowledge argument for arbitrary Arithmetic Circuits[def][ac~] with a @@ -811,11 +786,12 @@ multiplication gates) of the circuit. Bootle et al. [[2]] showed how an arbitrary arithmetic circuit with $ n $ multiplication gates can be converted into a relation containing a Hadamard Product[def][hdmp~] relation with additional linear consistency constraints. The communication cost of the addition gates in the argument was removed by providing a technique that can directly -handle a set of Hadamard products and linear relations together. For a two-input multiplication gate, let $ \mathbf a_L , +handle a set of Hadamard products and linear relations together. For a two-input multiplication gate, let $ \mathbf a*L , \mathbf a_R $ be the left and right input vectors respectively, then $ \mathbf a_O = \mathbf a_L \circ \mathbf a_R $ is the vector of outputs. Let $ Q \leqslant 2 \cdot n $ be the number of linear consistency constraints, -$ \mathbf W_{L,q} \mspace{3mu} , \mathbf W_{R,q} \mspace{3mu}, \mathbf W_{O,q} \in \mathbb Z_p^n $ be the gate weights +$ \mathbf W*{L,q} \mspace{3mu} , \mathbf W*{R,q} \mspace{3mu}, \mathbf W*{O,q} \in \mathbb Z_p^n $ be the gate weights and $ c_q \in \mathbb Z_p $ for all $ q \in [1,Q] $, then the linear consistency constraints have the form + $$ \langle \mathbf W_{L,q}, \mathbf a_L \rangle + \langle \mathbf W_{R,q}, \mathbf a_R \rangle +\langle \mathbf W_{O,q}, \mathbf a_O \rangle = c_q @@ -826,12 +802,11 @@ constraints into a single inner product relation. Pedersen Commitments $ V_j $ a arithmetic circuit, which is an important refinement, otherwise the arithmetic circuit would need to implement a commitment algorithm. The linear constraints also include openings $ v_j $ of $ V_j $. - #### Inner-product Proof for Arithmetic Circuits (Protocol 3) -Similar to [Inner-product Range Proof](#inner-product-range-proof), the *prover* $ \mathcal{P} $ produces a random linear +Similar to [Inner-product Range Proof](#inner-product-range-proof), the _prover_ $ \mathcal{P} $ produces a random linear combination of the Hadamard Product[def][hdmp~] and linear constraints to form a single inner product -constraint. If the combination is chosen randomly by the *verifier* $ \mathcal{V} $, then with overwhelming probability, +constraint. If the combination is chosen randomly by the _verifier_ $ \mathcal{V} $, then with overwhelming probability, the inner-product constraint implies the other constraints. A proof system must be presented for relation (10) below: $$ @@ -850,12 +825,11 @@ V_j =h^{\gamma_j} g^{v_j} \mspace{6mu} \forall \mspace{6mu} j \in [1,m] \mspace{ \tag{10} $$ - -Let $ \mathbf W_V \in \mathbb Z_p^{Q \times m} $ be the weights for a commitment $ V_j $. Relation (10) only holds when -$ \mathbf W_{V} $ is of rank $ m $, i.e. if the columns of the matrix are +Let $ \mathbf W*V \in \mathbb Z_p^{Q \times m} $ be the weights for a commitment $ V_j $. Relation (10) only holds when +$ \mathbf W*{V} $ is of rank $ m $, i.e. if the columns of the matrix are all linearly independent. -Figure 8 presents Part 1 of the protocol, where the *prover* $ \mathcal{P} $ commits to $ l(X),r(X),t(X) $: +Figure 8 presents Part 1 of the protocol, where the _prover_ $ \mathcal{P} $ commits to $ l(X),r(X),t(X) $:

Figure 8: Bulletproofs' Protocol 3 (Part 1) @@ -865,9 +839,8 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1]
- -Figure 9 presents Part 2 of the protocol, where the *prover* -$ \mathcal{P} ​$ convinces the *verifier* +Figure 9 presents Part 2 of the protocol, where the _prover_ +$ \mathcal{P} ​$ convinces the _verifier_ $ \mathcal{V} ​$ that the polynomials are well formed and that $ \langle l(X),r(X) \rangle = t(X) ​$:

@@ -878,24 +851,21 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1] - - The proof system presented here has the following Commitment Scheme properties: - **Perfect completeness (hiding):** Every validity/truth is provable. Also refer to Definition 9 in [[1]]. -- **Perfect HVZK:** The *verifier* $ \mathcal{V} ​$ behaves according to the protocol. Also +- **Perfect HVZK:** The _verifier_ $ \mathcal{V} ​$ behaves according to the protocol. Also refer to Definition 12 in [[1]]. - **Computational witness extended emulation (binding):** A witness can be computed in time closely related to time - spent by the *prover* $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. - + spent by the _prover_ $ \mathcal{P} $. Also refer to Definition 10 in [[1]]. #### Logarithmic-sized Non-interactive Protocol for Arithmetic Circuits Similar to [Logarithmic Range Proof](#logarithmic-range-proof), the communication cost of [Protocol 3](#inner-product-proof-for-arithmetic-circuits-protocol-3) can be reduced by using the efficient inner -product argument. Transmission of vectors $ \mathbf {l} ​$ and $ \mathbf {r} ​$ to the *verifier* $ \mathcal{V} ​$ +product argument. Transmission of vectors $ \mathbf {l} ​$ and $ \mathbf {r} ​$ to the _verifier_ $ \mathcal{V} ​$ (step 82 in Figure 9) can be eliminated, and transfer of information limited to the scalar properties -$ ( \tau _x , \mu , \hat t ) ​$ alone. The *prover* $ \mathcal{P} ​$ and *verifier* $ \mathcal{V} ​$ engage in an inner +$ ( \tau \_x , \mu , \hat t ) ​$ alone. The _prover_ $ \mathcal{P} ​$ and _verifier_ $ \mathcal{V} ​$ engage in an inner product argument on public input $ (\mathbf {g} , \mathbf {h} ^ \backprime , P \cdot h^{-\mu}, \hat t) ​$ to check correctness of $ \mathbf {l} ​$ and $ \mathbf {r} ​$ (step 92 in Figure 9) and $ \hat {t} ​$ (step 88 in Figure 9); this is the same as verifying that the witness $ \mathbf {l} , \mathbf {r} ​$ satisfies the inner product @@ -909,16 +879,15 @@ zero-knowledge in the random oracle model (thus without a trusted setup) using t The proof system presented here has the following Commitment Scheme properties: - **Perfect completeness (hiding):** Every validity/truth is provable. Also refer to Definition 9 in [[1]]. -- **Statistical zero-knowledge:** The *verifier* $ \mathcal{V} $ behaves according to the protocol and +- **Statistical zero-knowledge:** The _verifier_ $ \mathcal{V} $ behaves according to the protocol and $ \mathbf {l} , \mathbf {r} $ can be efficiently simulated. - **Computational soundness (binding):** if the generators $ \mathbf {g} , \mathbf {h} , g , h ​$ are independently generated, then finding a discrete logarithm relation between them is as hard as breaking the Discrete Log Problem. - ### Optimized Verifier using Multi-exponentiation and Batch Verification In many of the Bulletproofs' [Use Cases](/cryptography/bulletproofs-and-mimblewimble#applications-for-bulletproofs), -the *verifier's* runtime is of particular interest. This protocol presents optimizations for a single range proof that +the _verifier's_ runtime is of particular interest. This protocol presents optimizations for a single range proof that is also extendable to [aggregate range proofs](#aggregating-logarithmic-proofs) and the [arithmetic circuit protocol](#zero-knowledge-proof-for-arithmetic-circuits). @@ -926,12 +895,12 @@ is also extendable to [aggregate range proofs](#aggregating-logarithmic-proofs) In [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2), verification of the inner-product is reduced to a single multi-exponentiation. This can be extended to verify the whole range proof using a single -multi-exponentiation of size $ 2n + \log_2(n) + 7 $. In +multi-exponentiation of size $ 2n + \log*2(n) + 7 $. In [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2), the Bulletproof -*verifier* $ \mathcal{V} $ only performs two checks: step 68 in Figure 6 and +\_verifier* $ \mathcal{V} $ only performs two checks: step 68 in Figure 6 and step 16 in Figure 2. -In the protocol presented in Figure 10, which is processed by the *verifier* $ \mathcal{V} $, $ x_u $ is the +In the protocol presented in Figure 10, which is processed by the _verifier_ $ \mathcal{V} $, $ x_u $ is the challenge from [Protocol 1](#inner-product-argument-protocol-1), $ x_j $ the challenge from round $ j $ of [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2), and $ L_j , R_j $ the $ L , R $ values from round $ j $ of [Protocol 2](#inner-product-verification-through-multi-exponentiation-protocol-2). @@ -944,8 +913,6 @@ and More, Blockchain Protocol Analysis and Security Engineering 2018, Bünz B. et al.">1] - - A further idea is that multi-exponentiation (steps 98 and 105 in Figure 10) be delayed until those checks are performed, and that they are also combined into a single check using a random value $ c \xleftarrow[]{$} \mathbf Z_p ​$. This follows from the fact that if $ A^cB = 1 ​$ for a random $ c ​$, then with high probability, @@ -965,7 +932,6 @@ $ 2n ​$ exponentiations can be saved per additional proof. Verifying $ m ​$ requires a single multi-exponentiation of size $ 2n+2+m \cdot (2 \cdot \log (n) + 5 ) ​$ along with $ O ( m \cdot n ) ​$ scalar operations. - ## Evolving Bulletproof Protocols Interstellar [[24]] recently introduced the Programmable Constraint Systems for Bulletproofs [[23]], an evolution of @@ -978,19 +944,19 @@ then used as building blocks for a confidential assets protocol called Cloak. The constraint system has three kinds of variables: - High-level witness variables - - known only to the *prover* $ \mathcal{P} $, as external inputs to the constraint system; + - known only to the _prover_ $ \mathcal{P} $, as external inputs to the constraint system; - represented as individual Pedersen Commitments to the external variables in Bulletproofs. - Low-level witness variables - - known only to the *prover* $ \mathcal{P} $, as internal to the constraint system; + - known only to the _prover_ $ \mathcal{P} $, as internal to the constraint system; - representing the inputs and outputs of the multiplication gates. - Instance variables - - known to both the *prover* $ \mathcal{P} $ and the *verifier*; + - known to both the _prover_ $ \mathcal{P} $ and the _verifier_; - $ \mathcal{V} $, as public parameters; - represented as a family of constraint systems parameterized by public inputs (compatible with Bulletproofs); - folding all instance variables into a single constant parameter internally. Instance variables can select the constraint system out of a family for each proof. The constraint system becomes a -challenge from a *verifier* $ \mathcal{V} ​$ to a *prover* $ \mathcal{P} ​$, where some constraints are generated randomly +challenge from a _verifier_ $ \mathcal{V} ​$ to a _prover_ $ \mathcal{P} ​$, where some constraints are generated randomly in response to the *prover*'s $ \mathcal{P} ​$ commitments. Challenges to parametrize constraint systems make the resulting proof smaller, requiring only $ O(n) ​$ multiplications instead of $ O(n^2) ​$ in the case of verifiable @@ -998,19 +964,19 @@ shuffles when compared to a static constraint system. Merlin transcripts [[25]] employing the Fiat-Shamir Heuristic[def][fsh~] are used to generate the challenges. The challenges are bound to the high-level witness variables (the external inputs to the constraint system), which are -added to the transcript before any of the constraints are created. The *prover* $ \mathcal{P} $ and -*verifier* $ \mathcal{V} $ can then compute weights for some constraints with the use of the challenges. +added to the transcript before any of the constraints are created. The _prover_ $ \mathcal{P} $ and +_verifier_ $ \mathcal{V} $ can then compute weights for some constraints with the use of the challenges. Because the challenges are not bound to low-level witness variables, the resulting construction can be unsafe. Interstellar are working on an improvement to the protocol that would allow challenges to be bound to a subset of the low-level witness variables, and have a safer API using features of Rust’s type system. -The resulting API provides a single code path used by both the *prover* +The resulting API provides a single code path used by both the _prover_ $ \mathcal{P} ​$ and -*verifier* $ \mathcal{V} ​$ to allocate variables and define constraints. This is organized into a hierarchy of +_verifier_ $ \mathcal{V} ​$ to allocate variables and define constraints. This is organized into a hierarchy of task-specific gadgets, which manages allocation, assignment and constraints on the variables, ensuring that all variables are constrained. Gadgets interact with mutable constraint system objects, which are specific to the -*prover* $ \mathcal{P} ​$ and *verifier* $ \mathcal{V} ​$. They also receive secret variables and public parameters and +_prover_ $ \mathcal{P} ​$ and _verifier_ $ \mathcal{V} ​$. They also receive secret variables and public parameters and generate challenges. The Bulletproofs library [[22]] does not provide any standard gadgets, but only an API for the constraint system. @@ -1025,8 +991,6 @@ title="Programmable Constraint Systems for Bulletproofs, Interstellar, Cathie Yun">23] - - ## Conclusions, Observations and Recommendations - Bulletproofs have many potential use cases or @@ -1035,11 +999,9 @@ Cathie Yun">23] confidential blockchain protocol such as Tari should carefully consider expanded use of Bulletproofs to maximally leverage functionality of the code base. - - Bulletproofs are not done yet, as illustrated in [Evolving Bulletproof Protocols](#evolving-bulletproof-protocols), and their further development and efficient implementation have a lot of traction in the community. - - Bünz et al. [[1]] proposed that the switch commitment scheme defined by Ruffing et al. [[10]] can be used for Bulletproofs if doubts in the underlying cryptographic hardness (discrete log) assumption arise in future. The switch commitment scheme allows for a blockchain with proofs that are currently only computationally binding to later switch @@ -1051,341 +1013,291 @@ Cathie Yun">23] (Refer to the Grin projects' implementation [here](/cryptography/bulletproofs-and-mimblewimble#wallet-reconstruction-and-switch-commitment---grin).) - - It is important that developers understand more about the fundamental underlying mathematics when implementing something like Bulletproofs, even if they just reuse libraries developed by someone else. - - With the standard [MPC protocol](#mpc-protocol-for-bulletproofs) implementation, there is no guarantee that the dealer behaves honestly according to the protocol and generates challenges honestly. The protocol can be extended to be more secure if all parties receive partial proof elements and independently compute aggregated challenges. - ## References [[1]] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell, "Bulletproofs: Short Proofs for Confidential -Transactions and More", *Blockchain Protocol Analysis and Security Engineering 2018* [online]. +Transactions and More", _Blockchain Protocol Analysis and Security Engineering 2018_ [online]. Available: . Date accessed: 2018‑09‑18. -[1]: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf -"Bulletproofs: Short Proofs for Confidential Transactions +[1]: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf 'Bulletproofs: Short Proofs for Confidential Transactions and More, Blockchain Protocol Analysis and Security -Engineering 2018" +Engineering 2018' [[2]] J. Bootle, A. Cerulli, P. Chaidos, J. Groth and C. Petit, "Efficient Zero-knowledge Arguments for Arithmetic -Circuits in the Discrete Log Setting", *Annual International Conference on the Theory and Applications of Cryptographic* -*Techniques*, pp. 327‑357. Springer, 2016 [online]. Available: . Date accessed: +Circuits in the Discrete Log Setting", _Annual International Conference on the Theory and Applications of Cryptographic_ +_Techniques_, pp. 327‑357. Springer, 2016 [online]. Available: . Date accessed: 2018‑09‑21. -[2]: https://eprint.iacr.org/2016/263.pdf -"Efficient Zero-knowledge Arguments for Arithmetic -Circuits in the Discrete Log Setting, J. Bootle et al." +[2]: https://eprint.iacr.org/2016/263.pdf 'Efficient Zero-knowledge Arguments for Arithmetic +Circuits in the Discrete Log Setting, J. Bootle et al.' [[3]] A. Poelstra, A. Back, M. Friedenbach, G. Maxwell G. and P. Wuille, "Confidential Assets", Blockstream [online]. Available: . Date accessed: 2018‑09‑25. -[3]: https://blockstream.com/bitcoin17-final41.pdf -"Confidential Assets, +[3]: https://blockstream.com/bitcoin17-final41.pdf 'Confidential Assets, A. Poelstra et al., -Blockstream" +Blockstream' [[4]] Wikipedia: "Zero-knowledge Proof" [online]. Available: . Date accessed: 2018‑09‑18. -[4]: https://en.wikipedia.org/wiki/Zero-knowledge_proof -"Wikipedia - Zero-knowledge Proof" +[4]: https://en.wikipedia.org/wiki/Zero-knowledge_proof 'Wikipedia - Zero-knowledge Proof' [[5]] Wikipedia: "Discrete Logarithm" [online]. Available: . Date accessed: 2018‑09‑20. -[5]: https://en.wikipedia.org/wiki/Discrete_logarithm -"Wikipedia: Discrete Logarithm" +[5]: https://en.wikipedia.org/wiki/Discrete_logarithm 'Wikipedia: Discrete Logarithm' [[6]] A. Fiat and A. Shamir, "How to Prove Yourself: Practical Solutions to Identification and Signature Problems", CRYPTO 1986: pp. 186‑194 [online]. Available: . Date accessed: 2018‑09‑20. -[6]: https://link.springer.com/content/pdf/10.1007%2F3-540-47721-7_12.pdf -"How to Prove Yourself: Practical Solutions to +[6]: https://link.springer.com/content/pdf/10.1007%2F3-540-47721-7_12.pdf 'How to Prove Yourself: Practical Solutions to Identification and Signature Problems, -A. Fiat et al." +A. Fiat et al.' [[7]] D. Bernhard, O. Pereira and B. Warinschi, "How not to Prove Yourself: Pitfalls of the Fiat-Shamir Heuristic and Applications to Helios" [online]. Available: . Date accessed: 2018‑09‑20. -[7]: https://link.springer.com/content/pdf/10.1007%2F978-3-642-34961-4_38.pdf -"How not to Prove Yourself: Pitfalls of the +[7]: https://link.springer.com/content/pdf/10.1007%2F978-3-642-34961-4_38.pdf 'How not to Prove Yourself: Pitfalls of the Fiat-Shamir Heuristic and Applications to Helios, -D. Bernhard et al." +D. Bernhard et al.' [[8]] "Pedersen-commitment: An Implementation of Pedersen Commitment Schemes" [online]. Available: . Date accessed: 2018‑09‑25. -[8]: https://hackage.haskell.org/package/pedersen-commitment -"Pedersen-commitment: An Implementation -of Pedersen Commitment Schemes" +[8]: https://hackage.haskell.org/package/pedersen-commitment 'Pedersen-commitment: An Implementation +of Pedersen Commitment Schemes' [[9]] "Zero Knowledge Proof Standardization - An Open Industry/Academic Initiative" [online]. Available: -. Date accessed: 2018‑09‑26. +. Date accessed: 2018‑09‑26. -[9]: https://zkproof.org/documents.html -"Zero Knowledge Proof Standardization - -An Open Industry/Academic Initiative" +[9]: https://docs.zkproof.org/ 'Zero Knowledge Proof Standardization - +An Open Industry/Academic Initiative' [[10]] T. Ruffing and G. Malavolta, "Switch Commitments: A Safety Switch for Confidential Transactions" [online]. Available: . Date accessed: 2018‑09‑26. -[10]: https://eprint.iacr.org/2017/237.pdf -"Switch Commitments: A Safety Switch +[10]: https://eprint.iacr.org/2017/237.pdf 'Switch Commitments: A Safety Switch for Confidential Transactions, -T. Ruffing et al." +T. Ruffing et al.' [[11]] GitHub: "adjoint-io/Bulletproofs, Bulletproofs are Short Non-interactive Zero-knowledge Proofs that Require no Trusted Setup" [online]. Available: . Date accessed: 2018‑09‑10. -[11]: https://github.com/adjoint-io/bulletproofs -"GitHub: adjoint-io/Bulletproofs, Bulletproofs are Short +[11]: https://github.com/adjoint-io/bulletproofs 'GitHub: adjoint-io/Bulletproofs, Bulletproofs are Short Non-interactive Zero-knowledge Proofs that Require -no Trusted Setup" +no Trusted Setup' [[12]] Wikipedia: "Commitment Scheme" [online]. Available: . Date accessed: 2018‑09‑26. -[12]: https://en.wikipedia.org/wiki/Commitment_scheme -"Wikipedia: Commitment Scheme" +[12]: https://en.wikipedia.org/wiki/Commitment_scheme 'Wikipedia: Commitment Scheme' [[13]] Cryptography Wikia: "Commitment Scheme" [online]. Available: . Date accessed: 2018‑09‑26. -[13]: http://cryptography.wikia.com/wiki/Commitment_scheme -"Cryptography Wikia: Commitment Scheme" - -[[14]] Adjoint Inc. Documentation: "Pedersen Commitment Scheme" [online]. Available: -. Date accessed: 2018‑09‑27. - -[14]: https://www.adjoint.io/docs/cryptography.html#pedersen-commitment-scheme -"Adjoint Inc. Documentation: -Pedersen Commitment Scheme" +[13]: http://cryptography.wikia.com/wiki/Commitment_scheme 'Cryptography Wikia: Commitment Scheme' [[15]] T. Pedersen. "Non-interactive and Information-theoretic Secure Verifiable Secret Sharing" [online]. Available: . Date accessed: 2018‑09‑27. -[15]: https://www.cs.cornell.edu/courses/cs754/2001fa/129.pdf -"Non-interactive and Information-theoretic +[15]: https://www.cs.cornell.edu/courses/cs754/2001fa/129.pdf 'Non-interactive and Information-theoretic Secure Verifiable Secret Sharing, -T. Pedersen" +T. Pedersen' [[16]] A. Sadeghi and M. Steiner, "Assumptions Related to Discrete Logarithms: Why Subtleties Make a Real Difference" [online]. Available: . Date accessed: 2018‑09‑24. -[16]: http://www.semper.org/sirene/publ/SaSt_01.dh-et-al.long.pdf -"Assumptions Related to Discrete Logarithms: +[16]: http://www.semper.org/sirene/publ/SaSt_01.dh-et-al.long.pdf 'Assumptions Related to Discrete Logarithms: Why Subtleties Make a Real Difference, -A. Sadeghi et al." +A. Sadeghi et al.' -[[17]] P. Sharma P, A. Gupta and S. Sharma, "Intensified ElGamal Cryptosystem (IEC)", *International Journal of Advances -in Engineering & Technology*, January 2012 [online].* Available: . +[[17]] P. Sharma P, A. Gupta and S. Sharma, "Intensified ElGamal Cryptosystem (IEC)", _International Journal of Advances +in Engineering & Technology_, January 2012 [online].\* Available: . Date accessed: 2018‑10‑09. -[17]: http://www.e-ijaet.org/media/58I6-IJAET0612695.pdf -"Intensified ElGamal Cryptosystem (IEC), P. Sharma et al. +[17]: http://www.e-ijaet.org/media/58I6-IJAET0612695.pdf 'Intensified ElGamal Cryptosystem (IEC), P. Sharma et al. International Journal of Advances in Engineering & Technology, -Jan 2012" +Jan 2012' [[18]] Y. Tsiounis and M. Yung M, "On the Security of ElGamal Based Encryption" [online]. Available: . Date accessed: 2018‑10‑09. -[18]: https://drive.google.com/file/d/16XGAByoXse5NQl57v_GldJwzmvaQlS94/view -"On the Security of ElGamal Based Encryption, -Y. Tsiounis et al." +[18]: https://drive.google.com/file/d/16XGAByoXse5NQl57v_GldJwzmvaQlS94/view 'On the Security of ElGamal Based Encryption, +Y. Tsiounis et al.' [[19]] Wikipedia: "Decisional Diffie–Hellman Assumption" [online]. Available: . Date accessed: 2018‑10‑09. -[19]: https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption -"Wikipedia: Decisional Diffie–Hellman Assumption" +[19]: https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption 'Wikipedia: Decisional Diffie–Hellman Assumption' [[20]] Wikipedia: "Arithmetic Circuit Complexity" [online]. Available: . Date accessed: 2018‑11‑08. -[20]: https://en.wikipedia.org/wiki/Arithmetic_circuit_complexity -"Wikipedia: Arithmetic Circuit Complexity" +[20]: https://en.wikipedia.org/wiki/Arithmetic_circuit_complexity 'Wikipedia: Arithmetic Circuit Complexity' [[21]] Wikipedia: "Hadamard Product (Matrices)" [online]. Available: . Date accessed: 2018‑11‑12. -[21]: https://en.wikipedia.org/wiki/Hadamard_product_(matrices) -"Wikipedia: Hadamard Product (Matrices)" +[21]: https://en.wikipedia.org/wiki/Hadamard_product_(matrices) 'Wikipedia: Hadamard Product (Matrices)' [[22]] Dalek Cryptography - Crate Bulletproofs [online]. Available: . Date accessed: 2018‑11‑12. -[22]: https://doc.dalek.rs/bulletproofs/index.html -"Dalek Cryptography - -Crate Bulletproofs" +[22]: https://doc.dalek.rs/bulletproofs/index.html 'Dalek Cryptography - +Crate Bulletproofs' [[23]] "Programmable Constraint Systems for Bulletproofs" [online]. Available: . Date accessed: 2018‑11‑22. -[23]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 -"Programmable Constraint Systems for Bulletproofs, +[23]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 'Programmable Constraint Systems for Bulletproofs, Interstellar, -C. Yun" +C. Yun' [[24]] Inter/stellar website [online]. Available: . Date accessed: 2018‑11‑22. -[24]: https://interstellar.com -"Inter/stellar Website" +[24]: https://interstellar.com 'Inter/stellar Website' [[25]] "Dalek Cryptography - Crate Merlin" [online]. Available: . Date accessed: 2018‑11‑22. -[25]: https://doc.dalek.rs/merlin/index.html -"Dalek Cryptography - -Crate Merlin" +[25]: https://doc.dalek.rs/merlin/index.html 'Dalek Cryptography - +Crate Merlin' [[26]] B. Franca, "Homomorphic Mini-blockchain Scheme", April 2015 [online]. Available: . Date accessed: 2018‑11‑22. -[26]: http://cryptonite.info/files/HMBC.pdf -"Homomorphic Mini-blockchain Scheme, +[26]: http://cryptonite.info/files/HMBC.pdf 'Homomorphic Mini-blockchain Scheme, B. Franca, -April 2015" +April 2015' [[27]] C. Franck and J. Großschädl, "Efficient Implementation of Pedersen Commitments Using Twisted Edwards Curves", University of Luxembourg [online]. Available: . Date accessed: 2018‑11‑22. -[27]: http://orbilu.uni.lu/bitstream/10993/33705/1/MSPN2017.pdf -"Efficient Implementation of Pedersen +[27]: http://orbilu.uni.lu/bitstream/10993/33705/1/MSPN2017.pdf 'Efficient Implementation of Pedersen Commitments Using Twisted Edwards Curves, C. Franck and J. Großschädl, -University of Luxembourg" +University of Luxembourg' [[28]] A. Gibson, "An Investigation into Confidential Transactions", July 2018 [online]. Available: . Date accessed: 2018‑11‑22. -[28]: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf -"An Investigation into Confidential Transactions, +[28]: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf 'An Investigation into Confidential Transactions, A. Gibson, -July 2018" +July 2018' [[29]] "Dalek Cryptography - Module bulletproofs::range_proof_mpc" [online]. Available: . Date accessed: 2019‑07‑10. -[29]: https://doc-internal.dalek.rs/bulletproofs/range_proof_mpc/index.html -"Dalek Cryptography - -Module bulletproofs::range_proof_mpc" +[29]: https://doc-internal.dalek.rs/bulletproofs/range_proof_mpc/index.html 'Dalek Cryptography - +Module bulletproofs::range_proof_mpc' [[30]] "What is the difference between honest verifier zero knowledge and zero knowledge?" [Online]. Available: . Date accessed: 2019‑11‑12. -[30]: https://crypto.stackexchange.com/questions/40436/what-is-the-difference-between-honest-verifier-zero-knowledge-and-zero-knowledge -"Difference between honest -verifier ZK and ZK" +[30]: https://crypto.stackexchange.com/questions/40436/what-is-the-difference-between-honest-verifier-zero-knowledge-and-zero-knowledge 'Difference between honest +verifier ZK and ZK' [[31]] "600.641 Special Topics in Theoretical Cryptography - Lecture 11: Honest Verifier ZK and Fiat-Shamir" [online]. Available: . Date accessed: 2019‑11‑12. -[31]: https://www.cs.jhu.edu/~susan/600.641/scribes/lecture11.pdf -"Honest Verifier ZK and Fiat-Shamir" +[31]: https://www.cs.jhu.edu/~susan/600.641/scribes/lecture11.pdf 'Honest Verifier ZK and Fiat-Shamir' [[32]] Wikipedia: "Witness-indistinguishable proof" [online]. Available: . Date accessed: 2019‑11‑12. -[32]: https://en.wikipedia.org/wiki/Witness-indistinguishable_proof -"Wikipedia: Witness-indistinguishable proof" - +[32]: https://en.wikipedia.org/wiki/Witness-indistinguishable_proof 'Wikipedia: Witness-indistinguishable proof' ## Appendices - ### Appendix A: Definition of Terms Definitions of terms presented here are high level and general in nature. Full mathematical definitions are available in the cited references. - **Arithmetic Circuits:** An arithmetic circuit $ C $ over a field $ F $ and variables - $ (x_1, ..., x_n) $ is a directed acyclic graph whose vertices are called gates. Arithmetic circuits can alternatively + $ (x*1, ..., x_n) $ is a directed acyclic graph whose vertices are called gates. Arithmetic circuits can alternatively be described as a list of addition and multiplication gates with a collection of linear consistency equations relating the inputs and outputs of the gates. The size of an arithmetic circuit is the number of gates in it, with the depth - being the length of the longest directed path. *Upper bounding* the complexity of a polynomial $ f $ is to find any - arithmetic circuit that can calculate $ f $, whereas *lower bounding* is to find the smallest arithmetic circuit that + being the length of the longest directed path. \_Upper bounding* the complexity of a polynomial $ f $ is to find any + arithmetic circuit that can calculate $ f $, whereas _lower bounding_ is to find the smallest arithmetic circuit that can calculate $ f $. An example of a simple arithmetic circuit with size six and depth two that calculates a polynomial is shown here ([[11]], [[20]]):

-[ac~]: #ac -"An arithmetic circuit C over a +[ac~]: #ac 'An arithmetic circuit C over a field F and variables (x_1, ..., x_n) -is a directed acyclic graph ..." - +is a directed acyclic graph ...' - **Discrete Logarithm/Discrete Logarithm Problem (DLP):** In the mathematics of real -numbers, the logarithm $ \log_b^a $ is a number $ x $ such that -$ b^x=a $​, for given numbers $ a $ and $ b ​$. -Analogously, in any group $ G $ , powers $ b^k $ can be defined for all integers $ k $, and the discrete logarithm + numbers, the logarithm $ \log_b^a $ is a number $ x $ such that + $ b^x=a $​, for given numbers $ a $ and $ b ​$. + Analogously, in any group $ G $ , powers $ b^k $ can be defined for all integers $ k $, and the discrete logarithm $ \log_ba $ is an integer $ k $ such that $ b^k=a $​. Algorithms in public-key cryptography base their security on the -assumption that the discrete logarithm problem over carefully chosen cyclic finite groups and cyclic subgroups of -elliptic curves over finite fields has no efficient solution ([[5]], [[16]]). + assumption that the discrete logarithm problem over carefully chosen cyclic finite groups and cyclic subgroups of + elliptic curves over finite fields has no efficient solution ([[5]], [[16]]). -[dlp~]: #dlp -"In the mathematics of real +[dlp~]: #dlp 'In the mathematics of real numbers, the logarithm log_b(a) -is a number x such that ..." - +is a number x such that ...' - **ElGamal Commitment/Encryption:** An ElGamal commitment is a Pedersen -Commitmentdef with an additional commitment $ g^r $ to the randomness used. The ElGamal encryption -scheme is based on the Decisional Diffe-Hellman (DDH) assumption and the difficulty of the DLP for finite fields. The -DDH assumption states that it is infeasible for a Probabilistic Polynomial-time (PPT) adversary to solve the DDH -problem ([[1]], [[17]], [[18]], [[19]]). -**Note:** The ElGamal encryption scheme should not be confused with the ElGamal signature -scheme. - -[egc~]: #egc -"An ElGamal Commitment is a + Commitmentdef with an additional commitment $ g^r $ to the randomness used. The ElGamal encryption + scheme is based on the Decisional Diffe-Hellman (DDH) assumption and the difficulty of the DLP for finite fields. The + DDH assumption states that it is infeasible for a Probabilistic Polynomial-time (PPT) adversary to solve the DDH + problem ([[1]], [[17]], [[18]], [[19]]). + **Note:** The ElGamal encryption scheme should not be confused with the ElGamal signature + scheme. + +[egc~]: #egc 'An ElGamal Commitment is a Pedersen Commitment with -additional commitment ..." - +additional commitment ...' - **Fiat–Shamir Heuristic/Transformation:** The Fiat–Shamir heuristic is a technique in -cryptography to convert an interactive public-coin protocol (Sigma protocol) between a *prover* $ \mathcal{P} $ and a -*verifier* $ \mathcal{V} $ into a one-message (non-interactive) protocol using a cryptographic hash function ([[6]], [[7]]). - - The *prover* $ \mathcal{P} $ will use a Prove() algorithm to calculate a commitment $ A $ with a statement $ Y $ that - is shared with the *verifier* $ \mathcal{V} $ and a secret witness value $ w $ as inputs. The commitment $ A $ is then hashed to - obtain the challenge $ c $, which is further processed with the Prove() algorithm to calculate the - response $ f $. The single message sent to the *verifier* $ \mathcal{V} $ then contains the challenge $ c $ and response $ f $. + cryptography to convert an interactive public-coin protocol (Sigma protocol) between a _prover_ $ \mathcal{P} $ and a + _verifier_ $ \mathcal{V} $ into a one-message (non-interactive) protocol using a cryptographic hash function ([[6]], [[7]]). + + - The _prover_ $ \mathcal{P} $ will use a Prove() algorithm to calculate a commitment $ A $ with a statement $ Y $ that + is shared with the _verifier_ $ \mathcal{V} $ and a secret witness value $ w $ as inputs. The commitment $ A $ is then hashed to + obtain the challenge $ c $, which is further processed with the Prove() algorithm to calculate the + response $ f $. The single message sent to the _verifier_ $ \mathcal{V} $ then contains the challenge $ c $ and response $ f $. - - The *verifier* $ \mathcal{V} $ is then able to compute the commitment $ A $ from the shared statement $ Y $, challenge $ c $ and - response $ f $. The *verifier* $ \mathcal{V} $ will then use a Verify() algorithm to verify the combination of shared - statement $ Y $, commitment $ A $, challenge $ c $ and response $ f $. + - The _verifier_ $ \mathcal{V} $ is then able to compute the commitment $ A $ from the shared statement $ Y $, challenge $ c $ and + response $ f $. The _verifier_ $ \mathcal{V} $ will then use a Verify() algorithm to verify the combination of shared + statement $ Y $, commitment $ A $, challenge $ c $ and response $ f $. - A weak Fiat–Shamir transformation can be turned into a strong Fiat–Shamir transformation if the hashing function is - applied to the commitment $ A $ and shared statement $ Y $ to obtain the challenge $ c $ as opposed to only the - commitment $ A $. + applied to the commitment $ A $ and shared statement $ Y $ to obtain the challenge $ c $ as opposed to only the + commitment $ A $. -[fsh~]: #fsh -"The Fiat–Shamir heuristic is a +[fsh~]: #fsh 'The Fiat–Shamir heuristic is a technique in cryptography to -convert an interactive ..." - +convert an interactive ...' - **Hadamard Product:** In mathematics, the Hadamard product is a binary operation that takes -two matrices $ \mathbf {A} , \mathbf {B} $ of the same dimensions, and produces another matrix of the same dimensions -where each element $ i,j $ is the product of elements $ i,j $ of the original two matrices. The Hadamard product -$ \mathbf {A} \circ \mathbf {B} $ is different from normal matrix multiplication, most notably because it is also -commutative $ [ \mathbf {A} \circ \mathbf {B} = \mathbf {B} \circ \mathbf {A} ] $ ​along with being associative -$ [ \mathbf {A} \circ ( \mathbf {B} \circ \mathbf {C} ) = ( \mathbf {A} \circ \mathbf {B} ) \circ \mathbf {C} ] $ and -distributive over addition $ [ \mathbf {A} \circ ( \mathbf {B} + \mathbf {C} ) = \mathbf {A} \circ \mathbf {B} + -\mathbf {A} \circ \mathbf {C} ] $ ([[21]]). + two matrices $ \mathbf {A} , \mathbf {B} $ of the same dimensions, and produces another matrix of the same dimensions + where each element $ i,j $ is the product of elements $ i,j $ of the original two matrices. The Hadamard product + $ \mathbf {A} \circ \mathbf {B} $ is different from normal matrix multiplication, most notably because it is also + commutative $ [ \mathbf {A} \circ \mathbf {B} = \mathbf {B} \circ \mathbf {A} ] $ ​along with being associative + $ [ \mathbf {A} \circ ( \mathbf {B} \circ \mathbf {C} ) = ( \mathbf {A} \circ \mathbf {B} ) \circ \mathbf {C} ] $ and + distributive over addition $ [ \mathbf {A} \circ ( \mathbf {B} + \mathbf {C} ) = \mathbf {A} \circ \mathbf {B} + + \mathbf {A} \circ \mathbf {C} ] $ ([[21]]). $$ \mathbf {A} \circ \mathbf {B} = \mathbf {C} = (a_{11} \cdot b_{11} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , @@ -1393,28 +1305,25 @@ $$ \mspace{6mu} a_{n1} \cdot b_{n1} \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} a_{nm} \cdot b_{nm} ) $$ -[hdmp~]: #hdmp -"In mathematics, the Hadamard product +[hdmp~]: #hdmp 'In mathematics, the Hadamard product is a binary operation that takes two -matrices A,B of the same dimensions ..." - +matrices A,B of the same dimensions ...' - **Zero-knowledge Proof/Protocol:** In cryptography, a zero-knowledge proof/protocol is a -method by which one party (the *prover* $ \mathcal{P} $) can convince another party (the *verifier* $ \mathcal{V} $) that a statement $ Y $ is true, without -conveying any information apart from the fact that the *prover* $ \mathcal{P} $ knows the value of $ Y $. The proof system must be -complete, sound and zero-knowledge ([[4]], [[9]]). - - Complete: If the statement is true, and both the *prover* $ \mathcal{P} $ and *verifier* $ \mathcal{V} $ follow the protocol, the verifier will accept. + method by which one party (the _prover_ $ \mathcal{P} $) can convince another party (the _verifier_ $ \mathcal{V} $) that a statement $ Y $ is true, without + conveying any information apart from the fact that the _prover_ $ \mathcal{P} $ knows the value of $ Y $. The proof system must be + complete, sound and zero-knowledge ([[4]], [[9]]). - - Sound: If the statement is false, and the *verifier* $ \mathcal{V} $ follows the protocol, the *verifier* $ \mathcal{P} $ will not be convinced. + - Complete: If the statement is true, and both the _prover_ $ \mathcal{P} $ and _verifier_ $ \mathcal{V} $ follow the protocol, the verifier will accept. - - Zero-knowledge: If the statement is true, and the *prover* $ \mathcal{P} $ follows the protocol, the *verifier* $ \mathcal{V} $ will not learn any - confidential information from the interaction with the *prover* $ \mathcal{P} $ apart from the fact that the statement is true. + - Sound: If the statement is false, and the _verifier_ $ \mathcal{V} $ follows the protocol, the _verifier_ $ \mathcal{P} $ will not be convinced. -[zk~]: #zk -"In cryptography, a zero-knowledge -proof/protocol is a method by which -one party (the prover) can convince ..." + - Zero-knowledge: If the statement is true, and the _prover_ $ \mathcal{P} $ follows the protocol, the _verifier_ $ \mathcal{V} $ will not learn any + confidential information from the interaction with the _prover_ $ \mathcal{P} $ apart from the fact that the statement is true. +[zk~]: #zk 'In cryptography, a zero-knowledge +proof/protocol is a method by which +one party (the prover) can convince ...' ## Contributors diff --git a/_includes/content/cryptography/11-rank-1.md b/_includes/content/cryptography/11-rank-1.md index 1cef9169..c5c9987f 100644 --- a/_includes/content/cryptography/11-rank-1.md +++ b/_includes/content/cryptography/11-rank-1.md @@ -24,7 +24,6 @@ - [Appendix B: Notation Used](#appendix-b-notation-used) - [Contributors](#contributors) - ## Introduction This report explains the technical underpinnings of Rank-1 Constraint Systems (R1CSs) as applied @@ -51,7 +50,6 @@ The aim of this report is to: - clarify the difference R1CSs make in Bulletproofs and in range proofs; - compare ZK proofs for arithmetic circuits and programmable constraint systems. - ## Arithmetic Circuits ### Overview @@ -61,7 +59,6 @@ some polynomials. Arithmetic circuits are the most standard model for studying t ZK proofs form a core building block of many cryptographic protocols. Of special interest are ZK proof systems capable of proving the correct computation of arbitrary arithmetic circuits ([[6]], [[7]]). - ### Definition of Arithmetic Circuit An arithmetic circuit $\mathcal{A}$ over the field[def][fd~] $\mathcal{F}$ and the set of variables @@ -69,14 +66,14 @@ $X = \lbrace {x_1,\dots,x_n} \rbrace$ is a directed acyclic graph such that the _gates_, while the edges are called _wires_ [[7]]: - A gate is of in-degree $l$ if it has $l$ incoming wires, and similarly, of out-degree $k$ if - it has $k$ outgoing wires. + it has $k$ outgoing wires. - Every gate in $\mathcal{A}$ of in-degree 0 is labeled with either a variable ${x_i}$ or some field - element from $\mathcal{F}$. Such a gate is called an input gate. Every gate of out-degree 0 is called an - output gate or the root. + element from $\mathcal{F}$. Such a gate is called an input gate. Every gate of out-degree 0 is called an + output gate or the root. - Every other gate in $\mathcal{A}$ is labeled with either $\otimes$ or $\oplus$, and called a - multiplication gate or addition gate, respectively. + multiplication gate or addition gate, respectively. - An arithmetic circuit is called a formula if it is a directed tree whose edges are directed from the leaves - to the root. + to the root. - The depth of a node is the number of edges in the longest directed path between the node and the root. - The size of $A$, denoted $\|A\|$, is the number of wires, i.e. edges, in $A$. @@ -84,7 +81,6 @@ Arithmetic circuits of interest and most applicable to this report are those wit A typical multiplication gate has a left input $a_L$, a right input $a_R$ and an output $a_O$ (shown in Figure 1). Note that $ a_L \cdot a_R - a_O = 0 $. -

Figure 1: Typical Multiplication Gate
@@ -95,9 +91,9 @@ $\mathbf{a\_R} = ( a\_{R, 1}, a\_{R, 2}, \dots, a\_{R, n})$ and $\mathbf{a_O} = ( a\_{O, 1}, a\_{O, 2}, \dots, a\_{O, n})$, then multiplication of -$ \mathbf{a\_L} $ +$ \mathbf{a_L} $ and -$ \mathbf{a\_R} $ +$ \mathbf{a_R} $ is defined as an entry-wise product called the **Hadamard product**: @@ -110,17 +106,14 @@ The equation ${ \mathbf{a\_L}\circ \mathbf{a\_R} = \mathbf{a\_O} }$ is referred to as a multiplicative constraint, but is also known as the Hadamard relation [[4]]. - ### Example of Arithmetic Circuit An arithmetic circuit computes a polynomial in a natural way, as shown in this example. Consider the following arithmetic circuit $\mathcal{A}$ with inputs $\lbrace x_1, x_2, 1 \rbrace$ over some field $\mathcal{F}​$: -

Figure 2: Arithmetic Circuit
- The output of $\mathcal{A}​$ above is the polynomial $x^2\_1 \cdot x\_2 + x\_1 + 1 ​$ of total degree three. A typical computational problem would involve finding the solution to, let's say, $x^2\_1 \cdot x\_2 + x\_1 + 1 = 22​$. Or, in a proof of knowledge scenario, the prover has to prove to the verifier that they have the correct solution to such an @@ -149,7 +142,6 @@ whether the output $ a_O $ of each gate is correct with respect to the given inp $ a_L $ and $ a_R $. That is, testing if $ a_L \cdot a_R - a_O = 0 $ for each multiplication gate. - ## Rank-1 Constraint Systems ### Overview @@ -163,7 +155,6 @@ constructions of zk‑SNARKs. At times they were simply referred to as quadr refer to [[6]], [[9]] and [[10]]. - ### Definition of Constraint System A constraint system was originally defined by Bootle et al. in [[5]], who first expressed arithmetic circuit @@ -194,14 +185,13 @@ variables in the constraint system: - ${m}$ **high-level** variables, the input secrets ${ \mathbf{v}}$; - $ n$ **low-level** variables, the internal input vectors ${ \mathbf{a}_L}$ and - ${ \mathbf{a}_R},$ and output vectors ${ \mathbf{a}_O } $ of the multiplication gates. + ${ \mathbf{a}_R},$ and output vectors ${ \mathbf{a}\_O } $ of the multiplication gates. Specifically, an R1CS is a system that consists of two sets of constraints [[3]]: - ${ n}$ multiplicative constraints, $ \mathbf{ a_L \circ a_R = a_O } $; and - ${ q}$ linear constraints, $\mathbf{W_L\cdot { a_L} + W_R\cdot { a_R} + W_O\cdot { a_O } = W_V\cdot { v + c} } $. - ### R1CS Definition of zk‑SNARKs Arithmetic circuits and R1CS are more naturally applied to zk‑SNARKs, and these are implemented in @@ -225,8 +215,7 @@ $$ which is the inner product of the vectors $ \mathbf{a\_{L}} = (a\_{L,1}, a\_{L,2}, ..., a\_{L,n} )​$ and -$ {\mathbf{s}} = (s\_1, s\_2, ..., s\_n) ​$. - +$ {\mathbf{s}} = (s_1, s_2, ..., s_n) ​$. ### Example of Rank-1 Constraint System @@ -239,17 +228,14 @@ It is easy to check that the R1CS for the computation problem in the preceding e if ${ \langle {\mathbf{a_L}, \mathbf{s}} \rangle \cdot \langle {\mathbf{a_R}, \mathbf{s}} \rangle - \langle {\mathbf{a_O}, \mathbf{s}} \rangle = 0}​$ for each equation). -
Table 1: Equations and Rank-1 Constraint System Vectors
- -| Equation | Rank-1 Constraint System Vectors | -| ------------------------------- | ------------------------------------------------------------ | -| ${ u = x_1\cdot x_1}$ | $ {\bf{a_L}} = ( 0, 1, 0, 0, 0, 0, 0 ), \ \ {\bf{a_R}} = ( 0, 1, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 1, 0, 0 ) $ | -| $ { v = u\cdot x_2 }$ | $ {\bf{a_L}} = ( 0, 0, 0, 0, 1, 0, 0 ),\ \ {\bf{a_R}} = ( 0, 0, 1, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 0, 1, 0 ) $ | -| $ { y = 1\cdot( x_1 + 1 ) } $ | ${\bf{a_L}} = ( 1, 1, 0, 0, 0, 0, 0 ),\ \ {\bf{a_R}} = ( 1, 0, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 0, 0, 1 ) $ | -| $ { z = 1\cdot( v + y )} $ | ${\bf{a_L}} = ( 0, 0, 0, 0, 0, 1, 1 ),\ \ {\bf{a_R}} = ( 1, 0, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 1, 0, 0, 0 )$ | - +| Equation | Rank-1 Constraint System Vectors | +| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- | +| ${ u = x_1\cdot x_1}$ | $ {\bf{a_L}} = ( 0, 1, 0, 0, 0, 0, 0 ), \ \ {\bf{a_R}} = ( 0, 1, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 1, 0, 0 ) $ | +| $ { v = u\cdot x_2 }$ | $ {\bf{a_L}} = ( 0, 0, 0, 0, 1, 0, 0 ),\ \ {\bf{a_R}} = ( 0, 0, 1, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 0, 1, 0 ) $ | +| $ { y = 1\cdot( x_1 + 1 ) } $ | ${\bf{a_L}} = ( 1, 1, 0, 0, 0, 0, 0 ),\ \ {\bf{a_R}} = ( 1, 0, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 0, 0, 0, 1 ) $ | +| $ { z = 1\cdot( v + y )} $ | ${\bf{a_L}} = ( 0, 0, 0, 0, 0, 1, 1 ),\ \ {\bf{a_R}} = ( 1, 0, 0, 0, 0, 0, 0 ),\ \ {\bf{a_O}} = ( 0, 0, 0, 1, 0, 0, 0 )$ | In a more formal definition, an **R1CS** is a set of three matrices ${\bf{ A_L, A_R }}$ and ${\bf A_O}$, where the rows of each matrix are formed by the corresponding vectors $ {\bf{a_L }}$, ${ \bf{a_R }}$ and @@ -261,10 +247,9 @@ $$ \bf{A_O} = \bf{\begin{bmatrix} 0&0&0&0&1&0&0 \\\\ 0&0&0&0&0&1&0 \\\\ 0&0&0&0&0&0&1 \\\\ 0&0&0&1&0&0&0 \end{bmatrix}} $$ -Observe that ${ \bf{ (A_L * s^T) \cdot (A_R * s^T ) - (A_O * s^T)} = 0 }$, where "$ * $" is +Observe that ${ \bf{ (A_L * s^T) \cdot (A_R * s^T ) - (A_O * s^T)} = 0 }$, where "$ \* $" is _matrix multiplication_ and ${ \bf s^T}$ is the transpose of the solution vector ${ \bf{s}}$ [[8]]. - ## From Arithmetic Circuits to Programmable Constraint Systems for Bulletproofs Interstellar's "Programmable Constraint Systems for Bulletproofs" [[12]] @@ -276,24 +261,21 @@ between the two. Table 2 compares these three research documents. All these ZK proofs are based on the difficulty of the discrete logarithm problem. +
Table 2: Comparison of Three Research Documents on ZK Proofs
-
Table 2: Comparison of Three Research Documents on ZK Proofs
- - -| No. | Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting [[5]] (2016) | Bulletproofs: Short Proofs for Confidential Transactions and More [[4]] (2017) | Programmable Constraint Systems [[12]] (2018) | -| ---- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -| 1. | Introduces the Hadamard relation and linear constraints. | Turns the Hadamard relation and linear constraints into a single linear constraint, and these are in fact the R1CS. | Generalizes constraint systems and uses what is called gadgets as building blocks for constraint systems. | -| 2. | Improves on Groth's work [[13]] on ZK proofs. Reducing a $\sqrt{N}$ complexity to $6log_2(N) + 13$, where $N$ is the circuit size. | Improves on Bootle et al.'s work [[5]]. Reducing a $6log_2(N) + 13$ complexity to $2log_2(N) + 13$, where $N$ is the circuit size. | Adds constraint systems to Bunz et al.'s work on Bulletproofs, which are short proofs. The complexity advantage is seen in proving several statements at once. | -| 3. | Introduces logarithm-sized inner-product ZK proofs. | Introduces Bulletproofs, extending proofs to proofs of arbitrary statements. The halving method is used on the inner-products, resulting in the above reduction in complexity. | Introduces gadgets that are actually add-ons to an ordinary ZK proof. A range proof is an example of a gadget. | -| 4. | Uses Fiat-Shamir heuristics in order to achieve non-interactive ZK proofs. | Bulletproofs also use the Fiat Shamir heuristics to achieve non-interaction. | Merlin transcripts are specifically used for a Fiat-Shamir transformation to achieve non-interaction. | -| 5. | The Pedersen commitments are used in order to achieve ZK property. | Eliminates the need for a commitment algorithm by including Pedersen commitments among the inputs to the verification proof. | Low-level variables, representing inputs and outputs to multiplication gates, are computed per proof and committed using a single vector Pedersen commitment. | -| 6. | The ZK proof involves conversion of the arithmetic circuit into an R1CS. | The mathematical expression of a Hadamard relation is closely related to an arithmetic circuit. The use of this relation plus linear constraints as a single constraint amounts to using a constraint system. | Although arithmetic circuits are not explicitly used here, the Hadamard relation remains the same as first seen in Bulletproofs, more so in the inner-product proof. | +| No. | Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting [[5]] (2016) | Bulletproofs: Short Proofs for Confidential Transactions and More [[4]] (2017) | Programmable Constraint Systems [[12]] (2018) | +| --- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1. | Introduces the Hadamard relation and linear constraints. | Turns the Hadamard relation and linear constraints into a single linear constraint, and these are in fact the R1CS. | Generalizes constraint systems and uses what is called gadgets as building blocks for constraint systems. | +| 2. | Improves on Groth's work [[13]] on ZK proofs. Reducing a $\sqrt{N}$ complexity to $6log_2(N) + 13$, where $N$ is the circuit size. | Improves on Bootle et al.'s work [[5]]. Reducing a $6log_2(N) + 13$ complexity to $2log_2(N) + 13$, where $N$ is the circuit size. | Adds constraint systems to Bunz et al.'s work on Bulletproofs, which are short proofs. The complexity advantage is seen in proving several statements at once. | +| 3. | Introduces logarithm-sized inner-product ZK proofs. | Introduces Bulletproofs, extending proofs to proofs of arbitrary statements. The halving method is used on the inner-products, resulting in the above reduction in complexity. | Introduces gadgets that are actually add-ons to an ordinary ZK proof. A range proof is an example of a gadget. | +| 4. | Uses Fiat-Shamir heuristics in order to achieve non-interactive ZK proofs. | Bulletproofs also use the Fiat Shamir heuristics to achieve non-interaction. | Merlin transcripts are specifically used for a Fiat-Shamir transformation to achieve non-interaction. | +| 5. | The Pedersen commitments are used in order to achieve ZK property. | Eliminates the need for a commitment algorithm by including Pedersen commitments among the inputs to the verification proof. | Low-level variables, representing inputs and outputs to multiplication gates, are computed per proof and committed using a single vector Pedersen commitment. | +| 6. | The ZK proof involves conversion of the arithmetic circuit into an R1CS. | The mathematical expression of a Hadamard relation is closely related to an arithmetic circuit. The use of this relation plus linear constraints as a single constraint amounts to using a constraint system. | Although arithmetic circuits are not explicitly used here, the Hadamard relation remains the same as first seen in Bulletproofs, more so in the inner-product proof. | Interstellar is building an Application Programming Interface (API) that allows developers to choose their own collection of gadgets suitable for the protocol they wish to develop, as discussed in the [next section](#interstellars-bulletproof-constraint-system). - ## Interstellar's Bulletproof Constraint System ### Overview @@ -313,24 +295,22 @@ Dalek's constraint system, as defined earlier in [Definition of Constraint Syste a collection of two types of arithmetic constraints: multiplicative constraints and linear constraints, over a set of high-level and low-level variables. - ### Easy-to-build Constraint Systems In this Bulletproofs framework, a prover can build a constraint system in two steps: - Firstly, committing to secret inputs and allocating high-level variables corresponding to the inputs. - secondly, selecting a suitable combination of multiplicative constraints and linear constraints, as well as requesting a random - scalar in response to the high-level variables already committed [[3]]. + scalar in response to the high-level variables already committed [[3]]. Reference [[17]] gives an excellent outline of ZK proofs that use Bulletproofs: 1. The prover commits to a value(s) that they want to prove knowledge of. 1. The prover generates the proof by enforcing the constraints over the committed values and any additional public - values. The constraints might require the prover to commit to some additional variables. + values. The constraints might require the prover to commit to some additional variables. 1. The prover sends the verifier all the commitments made in step 1 and step 2, along with the proof from step 2. 1. The verifier now verifies the proof by enforcing the same constraints over the commitments, plus any public values. - ### About Gadgets Consider a verifiable shuffle: given two lists of committed values ${ x_1, x_2, . . ., x_n}$ and @@ -345,13 +325,11 @@ A _shuffle gadget_ (Figure 3) is any function whose outputs are but a permu permutation, the number of inputs to a shuffle gadget is always the same as the number of outputs. -

Figure 3: Simple Shuffle Gadgets with Two Inputs [2]
- The Interstellar team mentions other gadgets: “merge”, “split” and a “range proof” that are implemented in their Confidential Assets scheme called the Cloak. Just as a shuffle gadget creates constraints that prove that @@ -368,24 +346,22 @@ may allocate more variables, sometimes called auxiliary variables, for internal all these variables. The main advantage of gadgets is that they are composable, thus a more complex gadget can always be created from a number of single gadgets. Interstellar's Bulletproofs API allows developers to choose their own collection of gadgets suitable for the protocol they wish to develop. - ### Interstellar's Concluding Remarks Cathie Yun reports in [[12]] that their "work on Cloak and Spacesuit is far from complete" and mentions that they still have two goals to achieve: - Firstly, in order to "ensure that challenge-based variables cannot be inspected" and prevent the user from - accidentally breaking soundness of their gadgets, the Bulletproofs protocol needs to be slightly extended, enabling it - to commit "to a portion of low-level variables using a single vector Pedersen commitment without an overhead of - additional individual high-level Pedersen commitments" [[12]]. + accidentally breaking soundness of their gadgets, the Bulletproofs protocol needs to be slightly extended, enabling it + to commit "to a portion of low-level variables using a single vector Pedersen commitment without an overhead of + additional individual high-level Pedersen commitments" [[12]]. - Secondly, to "improve privacy in Cloak" by enabling "multi-party proving of a single constraint system". That is, - "building a joint proof of a single constraint system by multiple parties, without sharing their secret inputs with - each other". + "building a joint proof of a single constraint system by multiple parties, without sharing their secret inputs with + each other". All-in-all, Yun regards constraint systems as "very powerful because they can represent any efficiently verifiable program" [[2]]. - ### R1CS Factorization Example for Bulletproofs In [[17]], Harchandani explores the Dalek Bulletproofs API, using various examples. Of interest @@ -398,22 +374,19 @@ Table 3 gives an outline of the description and the code lines of the example. H code of this example can be found in [[18]]. Important to note is that the verifier must have an exact copy of the R1CS circuit used by the prover. +
Table 3: Example of Bulletproof Constraint
-
Table 3: Example of Bulletproof Constraint
- - -| No. | Description | Code Lines | -| ---- | :----------------------------------------------------------- | ------------------------------------------------------------ | -| 1. | Create two pairs of generators; one pair for the
Pedersen commitments and the other for the
Bulletproof. | `let pc_gens = PedersenGens::default();`
`let bp_gens = BulletproofGens::new(128, 1);` | -| 2. | Instantiate the prover using the commitment
and Bulletproofs generators of Step 1, to
produce the prover's transcript. | `let mut prover_transcript = Transcript::new(b"Factors");`
`let mut prover = Prover::new(&bp_gens, &pc_gens, &mut prover_transcript);` | -| 3. | Prover commits to variables using the Pedersen
commitments, creates variables corresponding to
each commitment and adds the variables to the
transcript. | `let x1 = Scalar::random(&mut rng);`
`let (com_p, var_p) = prover.commit(p.into(), x1);`
`let x2 = Scalar::random(&mut rng);`
`let (com_q, var_q) = prover.commit(q.into(), x2);` | -| 4. | Prover constrains the variables in two steps:
a. Prover multiplies the variables of step 3 and captures
the product in the "output" variable O.
b. Prover wants to ensure the difference of the product O and r is zero. | `let (_, _, o) = prover.multiply(var_p.into(), var_q.into());`
`let r_lc: LinearCombination = vec![(Variable::One(), r.into())].iter().collect();`
`prover.constrain(o - r_lc);` | -| 5. | Prover creates the proof. | `let proof = prover.prove().unwrap();` | -| 6. | Instantiation of the verifier using the Pedersen
commitments and Bulletproof generators. The
verifier creates its own transcript. | `let mut verifier_transcript = Transcript::new(b"Factors");`
`let mut verifier = Verifier::new(&bp_gens, &pc_gens, &mut verifier_transcript);` | -| 7. | Verifier records commitments for p and q sent by
prover in the transcript, and creates variables for
them similar to the prover's. | `let var_p = verifier.commit(commitments.0);`
`let var_q = verifier.commit(commitments.1);` | -| 8. | Verifier constrains variables corresponding to
the commitments. | `let (_, _, o) = verifier.multiply(var_p.into(), var_q.into());`
`let r_lc: LinearCombination = vec![(Variable::One(), r.into())].iter().collect();`
`verifier.constrain(o - r_lc);` | -| 9. | Verifier verifies the proof. | `verifier.verify(&proof)` | - +| No. | Description | Code Lines | +| --- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1. | Create two pairs of generators; one pair for the
Pedersen commitments and the other for the
Bulletproof. | `let pc_gens = PedersenGens::default();`
`let bp_gens = BulletproofGens::new(128, 1);` | +| 2. | Instantiate the prover using the commitment
and Bulletproofs generators of Step 1, to
produce the prover's transcript. | `let mut prover_transcript = Transcript::new(b"Factors");`
`let mut prover = Prover::new(&bp_gens, &pc_gens, &mut prover_transcript);` | +| 3. | Prover commits to variables using the Pedersen
commitments, creates variables corresponding to
each commitment and adds the variables to the
transcript. | `let x1 = Scalar::random(&mut rng);`
`let (com_p, var_p) = prover.commit(p.into(), x1);`
`let x2 = Scalar::random(&mut rng);`
`let (com_q, var_q) = prover.commit(q.into(), x2);` | +| 4. | Prover constrains the variables in two steps:
a. Prover multiplies the variables of step 3 and captures
the product in the "output" variable O.
b. Prover wants to ensure the difference of the product O and r is zero. | `let (_, _, o) = prover.multiply(var_p.into(), var_q.into());`
`let r_lc: LinearCombination = vec![(Variable::One(), r.into())].iter().collect();`
`prover.constrain(o - r_lc);` | +| 5. | Prover creates the proof. | `let proof = prover.prove().unwrap();` | +| 6. | Instantiation of the verifier using the Pedersen
commitments and Bulletproof generators. The
verifier creates its own transcript. | `let mut verifier_transcript = Transcript::new(b"Factors");`
`let mut verifier = Verifier::new(&bp_gens, &pc_gens, &mut verifier_transcript);` | +| 7. | Verifier records commitments for p and q sent by
prover in the transcript, and creates variables for
them similar to the prover's. | `let var_p = verifier.commit(commitments.0);`
`let var_q = verifier.commit(commitments.1);` | +| 8. | Verifier constrains variables corresponding to
the commitments. | `let (_, _, o) = verifier.multiply(var_p.into(), var_q.into());`
`let r_lc: LinearCombination = vec![(Variable::One(), r.into())].iter().collect();`
`verifier.constrain(o - r_lc);` | +| 9. | Verifier verifies the proof. | `verifier.verify(&proof)` | ## Conclusions, Observations and Recommendations @@ -426,193 +399,178 @@ enough room to build proof systems that have some degree of modularity. Proof sy Harchandani are valuable examples of what can be achieved with Bulletproofs and R1CSs. This framework provides great opportunities in building blockchain-enabled confidential digital asset schemes. - ## References - [[1]] A. Gabizon, "Explaining SNARKs Part V: From Computations to Polynomials" [online]. Available: . Date accessed: 2020‑01‑03. -[1]: https://electriccoin.co/blog/snark-explain5/ "Explaining SNARKs Part V: From Computations to Polynomials" +[1]: https://electriccoin.co/blog/snark-explain5/ 'Explaining SNARKs Part V: From Computations to Polynomials' [[2]] C. Yun, "Building on Bulletproofs" [online]. Available: . Date accessed: 2020‑01‑03. -[2]: https://medium.com/@cathieyun/building-on-bulletproofs-2faa58af0ba8 "Building on Bulletproofs" +[2]: https://medium.com/@cathieyun/building-on-bulletproofs-2faa58af0ba8 'Building on Bulletproofs' [[3]] Dalek's R1CS documents, "Module Bulletproofs::r1cs_proof" [online]. Available: . Date accessed: 2020‑01‑07. -[3]: https://doc-internal.dalek.rs/bulletproofs/notes/r1cs_proof/index.html "Module Bulletproofs::Notes::r1cs_proof" +[3]: https://doc-internal.dalek.rs/bulletproofs/notes/r1cs_proof/index.html 'Module Bulletproofs::Notes::r1cs_proof' [[4]] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell, "Bulletproofs: Short Proofs for Confidential Transactions and More" [online], Blockchain Protocol Analysis and Security Engineering 2018 . Available: . Date accessed: 2019‑11‑21. -[4]: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf "Bulletproofs: Short Proofs for Confidential Transactions and More" +[4]: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf 'Bulletproofs: Short Proofs for Confidential Transactions and More' [[5]] J. Bootle, A. Cerulli, P. Chaidos, J. Groth and C. Petit, "Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting" [online], Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 327‑357. Springer, 2016 . Available: Date accessed: 2019‑12‑21. -[5]: https://eprint.iacr.org/2016/263.pdf "Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete -Log Setting" +[5]: https://eprint.iacr.org/2016/263.pdf 'Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete +Log Setting' [[6]] A. Szepieniec and B. Preneel, "Generic Zero-knowledge and Multivariate Quadratic Systems" [online]. Available: . Date accessed: 2019‑12‑31. -[6]: https://pdfs.semanticscholar.org/06c8/ea507b2c4aaf7b421bd0c93e6145e3ff7517.pdf?_ga=2.124585865.240482160.1578465071-151955209.1571053591 -"Generic Zero-knowledge and MultiQuadratic Systems" +[6]: https://pdfs.semanticscholar.org/06c8/ea507b2c4aaf7b421bd0c93e6145e3ff7517.pdf?_ga=2.124585865.240482160.1578465071-151955209.1571053591 'Generic Zero-knowledge and MultiQuadratic Systems' [[7]] A. Shpilka and A. Yehudayoff, "Arithmetic Circuits: A Survey of Recent Results and Open Questions" [online], Technion-Israel Institute of Technology, Haifa, Israel, 2010 . Available: . Date accessed: 2019‑12‑21. -[7]: http://www.cs.tau.ac.il/~shpilka/publications/SY10.pdf "Arithmetic Circuits: A Survey of Recent Results and Open -Questions" +[7]: http://www.cs.tau.ac.il/~shpilka/publications/SY10.pdf 'Arithmetic Circuits: A Survey of Recent Results and Open +Questions' [[8]] A. Pinto, "Constraint Systems for ZK SNARKs" [online]. Available: -. Date accessed: 2019‑12‑23. +. Date accessed: 2019‑12‑23. -[8]: http://coders-errand.com/constraint-systems-for-zk‑SNARKs/ "Constraint Systems for ZK SNARKs" +[8]: https://coders-errand.com/constraint-systems-for-zk-snarks/ 'Constraint Systems for ZK SNARKs' [[9]] H. Wu, W. Zheng, A. Chiesa, R. Ada Popa, and I. Stoica, "DIZK: A Distributed Zero Knowledge Proof System" [online], Proceedings of the 27th USENIX Security Symposium, August 15–17, 2018. Available: . Date accessed: 2019‑12‑14. -[9]: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-wu.pdf -"DIZK: A Distributed Zero -Knowledge Proof System" +[9]: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-wu.pdf 'DIZK: A Distributed Zero +Knowledge Proof System' [[10]] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer and M. Virza, "SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge (extended version)" [online], October 2013. Available: . Date accessed: 2019‑12‑17. -[10]: https://eprint.iacr.org/2013/507.pdf "SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge -(extended version)" +[10]: https://eprint.iacr.org/2013/507.pdf 'SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge +(extended version)' [[11]] V. Buterin, "Quadratic Arithmetic Programs: from Zero to Hero" [online], 12 December 2016. Available: . Date accessed: 2019‑12‑19. -[11]: https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649 "Quadratic -Arithmetic Programs: from Zero to Hero" +[11]: https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649 'Quadratic +Arithmetic Programs: from Zero to Hero' [[12]] C. Yun, "Programmable Constraint Systems for Bulletproofs" [online]. Available: . Date accessed: 2019‑12‑04. -[12]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 "Programmable -Constraint Systems for Bulletproofs" +[12]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 'Programmable +Constraint Systems for Bulletproofs' [[13]] J. Groth, "Linear Algebra with Sub-linear Zero-knowledge Arguments" [online], Advances in Cryptology – CRYPTO 2009, pages 192–208, 2009. Available: . Date accessed: 2019‑12‑04. -[13]: https://iacr.org/archive/crypto2009/56770190/56770190.pdf "Linear Algebra with Sub-linear Zero-knowledge Arguments" +[13]: https://iacr.org/archive/crypto2009/56770190/56770190.pdf 'Linear Algebra with Sub-linear Zero-knowledge Arguments' [[14]] Dalek, "Ristretto" [online]. Available: Date accessed: 2019‑10‑17 -[14]: https://docs.rs/curve25519-dalek/0.15.1/curve25519_dalek/ristretto/index.html "Ristretto" +[14]: https://docs.rs/curve25519-dalek/0.15.1/curve25519_dalek/ristretto/index.html 'Ristretto' [[15]] H. Valence, "Bulletproofs Pre-release" [online]. Available: Date accessed: 2019‑11‑21. -[15]: https://medium.com/interstellar/bulletproofs-pre-release-fcb1feb36d4b "Bulletproofs pre-release" +[15]: https://medium.com/interstellar/bulletproofs-pre-release-fcb1feb36d4b 'Bulletproofs pre-release' [[16]] Dalek, "Bulletproofs Implementation" [online]. Available: Date accessed: 2019‑10‑02. -[16]: http://github.com/dalek-cryptography/bulletproofs/ "Dalek's Bulletproofs Implementation" +[16]: http://github.com/dalek-cryptography/bulletproofs/ "Dalek's Bulletproofs Implementation" [[17]] L. Harchandani, "Zero Knowledge Proofs using Bulletproofs" [online]. Available: . Date accessed: 2020‑01‑03. -[17]: https://medium.com/coinmonks/zero-knowledge-proofs-using-bulletproofs-4a8e2579fc82 -"Zero Knowledge Proofs -using Bulletproofs" +[17]: https://medium.com/coinmonks/zero-knowledge-proofs-using-bulletproofs-4a8e2579fc82 'Zero Knowledge Proofs +using Bulletproofs' [[18]] L. Harchandani, "Factors R1CS Bulletproofs Example" [online]. Available: . Date accessed: 2019‑10‑02. -[18]: https://github.com/lovesh/bulletproofs/blob/e477511a20bdb8de8f4fa82cb789ba71cc66afd8/tests/basic_r1cs.rs#L17 -"Factors R1CS Bulletproofs Example" +[18]: https://github.com/lovesh/bulletproofs/blob/e477511a20bdb8de8f4fa82cb789ba71cc66afd8/tests/basic_r1cs.rs#L17 'Factors R1CS Bulletproofs Example' [[19]] "Computer Algebra" [online]. Available: . Date accessed: 2020‑02‑05. -[19]: https://en.wikipedia.org/wiki/Computer_algebra "Computer Algebra - Wikipedia" +[19]: https://en.wikipedia.org/wiki/Computer_algebra 'Computer Algebra - Wikipedia' [[20]] Wikipedia: "Binary Operation" [online]. Available: . Date accessed: 2020‑02‑06. -[20]: https://en.wikipedia.org/wiki/Binary_operation "Field Theory - WolframMathWorld" +[20]: https://en.wikipedia.org/wiki/Binary_operation 'Field Theory - WolframMathWorld' [[21]] WolframMathWorld, "Field Theory" [online]. Available: . Date accessed: 2020‑02‑06. -[21]: http://mathworld.wolfram.com/FieldAxioms.html "Field Theory - WolframMathWorld" +[21]: http://mathworld.wolfram.com/FieldAxioms.html 'Field Theory - WolframMathWorld' [[22]] Wikipedia: "Finite Theory" [online]. Available: . Date accessed: 2020‑02‑06. -[22]: https://en.wikipedia.org/wiki/Finite_field "Field Theory - Wikipedia" - +[22]: https://en.wikipedia.org/wiki/Finite_field 'Field Theory - Wikipedia' ## Appendices - ### Appendix A: Definition of Terms Definitions of terms presented here are high level and general in nature. Full mathematical definitions are available in the cited references. - **Symbolic Computation:** The study and development of algorithms and software for manipulating -mathematical expressions and other mathematical objects [[19]]. - -[sc~]: #sc -"The study and development of algorithms -and software for manipulating ..." + mathematical expressions and other mathematical objects [[19]]. +[sc~]: #sc 'The study and development of algorithms +and software for manipulating ...' -- **Binary Operation:** An operation $ * $ or a calculation that combines two elements $ \mathcal{a} $ and - $ \mathcal{b}$, called operands, to produce another element $ \mathcal{a} * \mathcal{b} $ [[20]]. +- **Binary Operation:** An operation $ _ $ or a calculation that combines two elements $ \mathcal{a} $ and + $ \mathcal{b}$, called operands, to produce another element $ \mathcal{a} _ \mathcal{b} $ [[20]]. - **Field:** Any set $ \mathcal{F} $ of elements together with _Binary Operations_ $ + $ and $ \cdot $, called addition and multiplication, respectively, is a **field** if for any three elements $ \mathcal{a}, \mathcal{b} $ and $ \mathcal{c} $ in $ \mathcal{F} $ satisfy the field axioms given in the following table. A **Finite field** is any field $ \mathcal{F} $ that contains a finite number of elements ([[21]], [[22]]). -[fd~]: #fd -"Any set of elements together with binary operations 'addition' and 'multiplication' satisfying field axioms ... " - +[fd~]: #fd "Any set of elements together with binary operations 'addition' and 'multiplication' satisfying field axioms ... "
Table A.1: Axioms of a Field
- -| Name | Addition | Multiplication | -| -------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| associativity | ![(a+b)+c=a+(b+c)](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline1.gif) | ![(ab)c=a(bc)](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline2.gif) | -| commutativity | ![a+b=b+a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline3.gif) | ![ab=ba](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline4.gif) | -| distributivity | ![a(b+c)=ab+ac](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline5.gif) | ![(a+b)c=ac+bc](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline6.gif) | -| identity | ![a+0=a=0+a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline7.gif) | ![a·1=a=1·a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline8.gif) | +| Name | Addition | Multiplication | +| -------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | +| associativity | ![(a+b)+c=a+(b+c)](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline1.gif) | ![(ab)c=a(bc)](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline2.gif) | +| commutativity | ![a+b=b+a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline3.gif) | ![ab=ba](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline4.gif) | +| distributivity | ![a(b+c)=ab+ac](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline5.gif) | ![(a+b)c=ac+bc](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline6.gif) | +| identity | ![a+0=a=0+a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline7.gif) | ![a·1=a=1·a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline8.gif) | | inverses | ![a+(-a)=0=(-a)+a](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline9.gif) | ![aa^(-1)=1=a^(-1)a if a!=0](http://mathworld.wolfram.com/images/equations/FieldAxioms/Inline10.gif) | - ### Appendix B: Notation Used - Let $ \mathcal{F} $ be a field. - Let $ \mathbf{a} = (a_1, a_2, ..., a_n ) $ be a vector with $n$ components $ a_1, a_2, ..., a_n $, which -are elements of some field $ \mathcal{F} ​$. +are elements of some field $ \mathcal{F} ​$. - Let $\mathbf{s}^T​$ be the transpose of a vector $ \mathbf{s} = ( s_1, s_2, \dots, s_n )​$ of size $ n ​$ such that - $ \mathbf{s}^T = \begin{bmatrix} s_1 \\\\ s_2 \\\\ \cdot \\\\ \cdot \\\\ \cdot \\\\ s_n \end{bmatrix} ​$ - + $ \mathbf{s}^T = \begin{bmatrix} s_1 \\\\ s_2 \\\\ \cdot \\\\ \cdot \\\\ \cdot \\\\ s_n \end{bmatrix} ​$ ## Contributors diff --git a/_includes/content/cryptography/13-trustless-recursive-zero-knowledge-proofs.md b/_includes/content/cryptography/13-trustless-recursive-zero-knowledge-proofs.md index 441f027f..b918eeae 100644 --- a/_includes/content/cryptography/13-trustless-recursive-zero-knowledge-proofs.md +++ b/_includes/content/cryptography/13-trustless-recursive-zero-knowledge-proofs.md @@ -3,7 +3,7 @@ - [Introduction](#introduction) - [Notation and Preliminaries](#notation-and-preliminaries) - [Fields and Elliptic Curves](#fields-and-elliptic-curves) - - [Example 1](#example-1) + - [Example 1](#example-1) - [Arithmetic Circuits and R1CS](#arithmetic-circuits-and-r1cs) - [Recursive Proofs Composition Overview](#recursive-proofs-composition-overview) - [Verification Amortization Strategies](#verification-amortization-strategies) @@ -27,8 +27,6 @@ - [Appendix A: Pairing Cryptography](#appendix-a-pairing-cryptography) - [Contributors](#contributors) - - ## Introduction In pursuit of blockchain scalability investigation in this report focuses on @@ -44,7 +42,7 @@ verification costs are enabled by a powerful tool called a [Proof-Carrying Data](#proof-carrying-data) or PCD, first introduced by Alessandro Chiesa in his PhD thesis [[4]]. The resulting proof system is made efficient and more practical by the use of a technique that utilises [cycles of elliptic curves](#cycles-of-elliptic-curves), first realised by Eli Ben-Sasson et al [[2]]. -These two are what the report hinges around. +These two are what the report hinges around. The details of recursive proofs composition are in the mathematics. So effort is taken to simplify concepts, while keeping technical reader's interests in mind. @@ -52,7 +50,6 @@ At the end the reader will appreciate the power of recursive proofs composition, it uses PCDs and cycles of elliptic curves, as well as why it needs the two to achieve significant blockchain scalability. - ## Notation and Preliminaries Notation and terminology in this report is standard. But in order to achieve a clear understanding of @@ -69,7 +66,7 @@ $( \mathbb{F}, + )$ forms an abelian group and $( \mathbb{F} \backslash \\{ 0 \\} , * )$ also forms -an abelian group of non-zero elements with an identity $1_{\mathbb{F}}$. The most common notation for +an abelian group of non-zero elements with an identity $1_{\mathbb{F}}$. The most common notation for $ \mathbb{F} \backslash \\{ 0 \\} $ is $ \mathbb{F}^{\times}.$ A more elaborate definition of a field can be found [here](/cryptography/rank-1). @@ -77,64 +74,63 @@ Note that in blockchain research papers an elliptic curve refers to what is actu This can cause confusion especially when talking about the **scalar field** as opposed to the **base field**. - In Mathematics an **elliptic curve** $E$ over a field -$\mathbb{F}$ -generally refers to a locus, -that is -the curve formed by all the points satisfying a given equation. -For example, an equation of the form -$y^2 = x^3 - ax + b$ -where $a$ and $b$ -are elements of some field $\mathbb{F}$, -say the rationals $\mathbb{Q}$, the reals $\mathbb{R}$ or -the complex numbers $\mathbb{C}.$ -Such a field $\mathbb{F}$ is referred to as the **base field** for $E$. + $\mathbb{F}$ + generally refers to a locus, + that is + the curve formed by all the points satisfying a given equation. + For example, an equation of the form + $y^2 = x^3 - ax + b$ + where $a$ and $b$ + are elements of some field $\mathbb{F}$, + say the rationals $\mathbb{Q}$, the reals $\mathbb{R}$ or + the complex numbers $\mathbb{C}.$ + Such a field $\mathbb{F}$ is referred to as the **base field** for $E$. - The fields; $\mathbb{Q}$, $\mathbb{R}$ and $\mathbb{C}$; are infinite sets and are thus not -useful for cryptographic purposes. -In cryptography, base fields that are of practical purposes are preferably finite and -of a large prime order. -This ensures that the discrete log problem is sufficiently difficult, making the cryptosystem -secure against common cryptanalytic attacks. + useful for cryptographic purposes. + In cryptography, base fields that are of practical purposes are preferably finite and + of a large prime order. + This ensures that the discrete log problem is sufficiently difficult, making the cryptosystem + secure against common cryptanalytic attacks. - Note that all finite fields are either of prime order or power of a prime. -So then any finite field $\mathbb{F}$ is either $\mathbb{F}\_p$ -or $\mathbb{F}\_{p^n}$ for some prime number $p$. -See [[6], Lemma 3.19] for the proof of this fact. -Actually, it can be shown that the orders of -their respective multiplicative groups $\mathbb{F}\_p^{\times}$ and $\mathbb{F}\_{p^n}^{\times}$ are -$p-1$ and $p^n-1$, [[6], Proposition 6.1]. + So then any finite field $\mathbb{F}$ is either $\mathbb{F}\_p$ + or $\mathbb{F}\_{p^n}$ for some prime number $p$. + See [[6], Lemma 3.19] for the proof of this fact. + Actually, it can be shown that the orders of + their respective multiplicative groups $\mathbb{F}\_p^{\times}$ and $\mathbb{F}\_{p^n}^{\times}$ are + $p-1$ and $p^n-1$, [[6], Proposition 6.1]. - An **elliptic curve group** $E(\mathbb{F})$ is formed by first defining 'addition' of elliptic curve points, - picking a point $(x,y)$ on the curve $E$ and using it to generate a cyclic group by - doubling it, $2 \cdot (x,y)$, and forming all possible scalar multiples $\alpha \cdot (x,y)$. - The group 'addition' of points and doubling are illustrated in [Figure 1](#fig_gpa) below. - All these points generated by $(x,y)$ together with the *point at infinity*, $ \mathcal{O}$, form an algebraic group - under the defined 'addition' of points. + picking a point $(x,y)$ on the curve $E$ and using it to generate a cyclic group by + doubling it, $2 \cdot (x,y)$, and forming all possible scalar multiples $\alpha \cdot (x,y)$. + The group 'addition' of points and doubling are illustrated in [Figure 1](#fig_gpa) below. + All these points generated by $(x,y)$ together with the _point at infinity_, $ \mathcal{O}$, form an algebraic group + under the defined 'addition' of points.

-
Figure 1: Points Addition and Doubling [[17]]
- +
Figure 1: Points Addition and Doubling [[17]]
- Once an elliptic curve group $E(\mathbb{F})$ is defined, the scalar field can be described. -The **scalar field** is the field that is isomorphic to -(i.e., has the same order as) the largest cyclic subgroup of the elliptic curve group $E(\mathbb{F})$. -So then, if the order of the elliptic curve group is a prime $p$, then the scalar field is $\mathbb{F}_p$. -The order of the elliptic curve group $E(\mathbb{F})$ is denoted by $\\# E(\mathbb{F})$. + The **scalar field** is the field that is isomorphic to + (i.e., has the same order as) the largest cyclic subgroup of the elliptic curve group $E(\mathbb{F})$. + So then, if the order of the elliptic curve group is a prime $p$, then the scalar field is $\mathbb{F}_p$. + The order of the elliptic curve group $E(\mathbb{F})$ is denoted by $\\# E(\mathbb{F})$. Ultimately, unlike an elliptic curve $E$ over a general field $\mathbb{F}$, an elliptic curve group $E(\mathbb{F})$ is discrete, consisting of only a finite number of points. The sizes of these groups are bounded by what is known as -the Hasse bound [[12]]. Algorithms used to compute these sizes are also known, see [[13]]. - - #### Example 1 - - Consider the curve $E$ of points satisfying this equation - $$y^2 = x^3 - 43x + 166$$ - Pick the point - $$(x,y) = (3,8)$$ - which is on the curve $E$ because - $$y^2 = 8^2 = 64$$ - and - $$3^3 - 43(3) + 166 = 64$$ +the Hasse bound [[12]]. Algorithms used to compute these sizes are also known, see [[13]]. + +#### Example 1 + +Consider the curve $E$ of points satisfying this equation +$$y^2 = x^3 - 43x + 166$$ +Pick the point +$$(x,y) = (3,8)$$ +which is on the curve $E$ because +$$y^2 = 8^2 = 64$$ +and +$$3^3 - 43(3) + 166 = 64$$ Doubling yields $$2 \cdot (3,8) = (-5, -16)$$ and the rest of the scalar multiples are @@ -145,17 +141,17 @@ $$6\cdot (3,8) = (3, -8) $$ and $$7\cdot (3,8) = \mathcal{O} $$ Note that the entire elliptic curve group is -$$E(\mathbb{Q}) = \\{ \mathcal{O}, (3,8), (-5, -16), (11, -32), (11, 32), (-5, 16), (3, -8) \\} $$ +$$E(\mathbb{Q}) = \\{ \mathcal{O}, (3,8), (-5, -16), (11, -32), (11, 32), (-5, 16), (3, -8) \\} $$ which is a cyclic group of order $7$ generated by the point $(3,8)$. Since $7$ is a prime number, the largest subgroup of $E(\mathbb{Q})$ is of order $7$. -It follows that the scalar field of $E$ is $ \mathbb{F}_7 = \mathbb{Z}_7$ while +It follows that the scalar field of $E$ is $ \mathbb{F}\_7 = \mathbb{Z}\_7$ while $\mathbb{Q}$ is the base field. See [[10]] for full details on this example. In accordance with literature, an elliptic curve group $E(\mathbb{F})$ will henceforth be referred to as an **elliptic curve**. And unless otherwise stated, -the base field will be a field of a large prime order $p$, denoted by $\mathbb{F}_p$. +the base field will be a field of a large prime order $p$, denoted by $\mathbb{F}_p$. ### Arithmetic Circuits and R1CS @@ -172,22 +168,20 @@ The general process for a zero-knowledge proof system is to convert the set computation or statement being proved into an arithmetic circuit $\mathcal{C}$ and further encode the circuit into an equivalent constraint system. These three are all equivalent in the sense that; the proof $\pi$ satisfies the constraint system -*if and only if* +_if and only if_ it satisfies $\mathcal{C}$, and the circuit $\mathcal{C}$ is satisfied -*if and only if* +_if and only if_ the prover has the correct solution to the original computational problem. - - ## Recursive Proofs Composition Overview In their recent paper [[1]], Benedikt Buenz et al. report that, "Recursive proofs composition has been shown to lead to powerful primitives such as incrementally-verifiable computation (IVC) and proof-carrying data (PCD)." Thus recognising the two main components of recursive proofs composition, IVC and PCD. -The former was adequately investigated in [[9]], and the latter is now the focus of this report. +The former was adequately investigated in [[9]], and the latter is now the focus of this report. ### Verification Amortization Strategies @@ -195,30 +189,28 @@ These strategies are briefly mentioned here but their detailed descriptions can **Verifiable Computation** allows a verifier to delegate expensive computations to untrusted third parties and be able -to check correctness of the proofs these third parties submit. +to check correctness of the proofs these third parties submit. **Inductive proofs** take advantage of whatever recursion there may be in a computational problem. And due to the Principle of Mathematical Induction, a verifier need only check correctness of the "base step" and the "inductive step". -Making this a powerful tool when it comes to saving verification costs. +Making this a powerful tool when it comes to saving verification costs. **Incrementally Verifiable Computation** is the strategy where, in addition to delegating computations to several untrusted parties, the verifier does not execute verification as often as he receives proofs from third parties but rather collects these proofs and -only executes a single proof at the end. +only executes a single proof at the end. **Nested Amortization**, the strategy here is to reduce the cost of an expensive computation to a sub-linear cost (logarithmic relative to the cost of the original computation) by collapsing the cost of two -computations to a cost of one. - - +computations to a cost of one. ## Proof-Carrying Data -Recursive proofs composition uses an abstraction called *proof-carrying data* (PCD) when dealing with +Recursive proofs composition uses an abstraction called _proof-carrying data_ (PCD) when dealing with distributed computations. These PCDs are powerful tools that enable practical implementation of the above verification amortization strategies. @@ -227,7 +219,6 @@ of the above verification amortization strategies. **Proof-Carrying Data**, or PCD, is a cryptographic mechanism that allows proof strings $\pi_i$ to be carried along with messages $m_i$ in a distributed computation [[15]]. -

Figure 2: Distributed Computation [[3]]
@@ -247,28 +238,28 @@ compliance to a predicate specified by the proof system designer. Such a compiler is typically defined as a function $$\mathbf{\Pi}(m\_i, m\_{loc,i}, \mathbf{m}\_{inc} ) \in \\{ 0, 1 \\}$$ taking as inputs a newly formed message $m_i$ at node $i$, local data $m\_{loc,i}$ only known to -node $i$, and a vector $\mathbf{m}\_{inc}$ of all incoming messages received by node $i$. +node $i$, and a vector $\mathbf{m}\_{inc}$ of all incoming messages received by node $i$. Since a PCD is equipped with a protocol compiler $\mathbf{\Pi}$ that ensures that every message is predicate-compliant, then it enables trustless cryptographic proof systems for two reasons: + - mutually distrustful parties can perform distributed computations -that run indefinitely, and + that run indefinitely, and - due to proof strings attached to all previous messages, any node $j$ can verify any intermediate state of the computation and propagate a -new message $m_j$ with its proof string $\pi_j$ attached to it. + new message $m_j$ with its proof string $\pi_j$ attached to it. It now becomes clear how recursive proofs composition accomplishes blockchain scalability. Any new node can take advantage of IVC and a PCD to succinctly verify the current state of -the blockchain without concern about the chain's historical integrity. +the blockchain without concern about the chain's historical integrity. The PCD abstraction is no doubt the very secret to achieving blockchain scaling especially via recursive proofs composition. - ## Cycles of Elliptic Curves Given the above discussion on PCDs, note that the cryptographic technique of using -a *cycle of elliptic curves* is not much about scalability but rather about efficiency of +a _cycle of elliptic curves_ is not much about scalability but rather about efficiency of arithmetic circuits. The main trick is to exploit the proof system's field structure. ### Why Cycle of Elliptic Curves? @@ -287,14 +278,15 @@ choosing fields for the underlying Elliptic Curve Cryptosystem of a blockchain; When instantiating a proof system's arithmetic circuit using an elliptic curve $E(\mathbb{F}\_q)$, it is important to take cognizance of the two types of field arithmetic involved: -the *base field* arithmetic and the *scalar field* arithmetic. +the _base field_ arithmetic and the _scalar field_ arithmetic. For an elliptic curve $E(\mathbb{F}_p)$ where $p$ is a prime for simplicity, + - the base field is $\mathbb{F}\_p$ and so its arithmetic consists of addition modulo $p$ -and multiplication modulo $p$, + and multiplication modulo $p$, - the scalar field is $\mathbb{F}\_r$, where $r$ is the prime order of the largest -subgroup of $E(\mathbb{F}\_p)$, so in this case the arithmetic consists of addition modulo $r$ -and multiplication modulo $r$. + subgroup of $E(\mathbb{F}\_p)$, so in this case the arithmetic consists of addition modulo $r$ + and multiplication modulo $r$. The question now is which arithmetic is better to use in a circuit instantiated with $E(\mathbb{F}_p)$? The next example makes the choice obvious. @@ -310,7 +302,7 @@ $$\ \ \alpha \cdot (3,8) + \beta \cdot (3,8) = ((\alpha + \beta) \text{ mod } 7) For example, if $\alpha = 5$ and $\beta = 6$, group addition of two points is carried out as follows $$\ \ 5 \cdot (3,8) + 6 \cdot (3,8) = ( 11 \text{ mod } 7) \cdot (3,8) = 4 \cdot (3,8)$$ It follows then that when instantiating any circuit using $E(\mathbb{Q})$, the arithmetic of the scalar field -$ \mathbb{F}_7 $ is more natural to use than the base field's. +$ \mathbb{F}\_7 $ is more natural to use than the base field's. **Remark:** For practical purposes the order of the base field is always a large prime, and thus the infinite field of rationals $\mathbb{Q}$ is never used. @@ -341,7 +333,6 @@ It is thus mathematically impossible for the scalar field $\mathbb{F}\_r$ of the elliptic curve $E(\mathbb{F}_q)$ to have the same order as the base field $\mathbb{F}_q$. - #### No Prover-Verifier Dichotomy In the envisaged proof-of-proofs system using recursive proofs composition, the tremendous @@ -349,11 +340,12 @@ accomplishment is to allow every participant to simultaneously be a prover and a However, this presents a serious practical problem. Note the following common practices when implementing proof systems (gleaning information from [[15]]); + - The proof system is instantiated with an elliptic curve $E$ over a base field $\mathbb{F}_q$ - The most natural field arithmetic for the arithmetic circuit is the scalar field's, -$\mathbb{F}_r$-arithmetic + $\mathbb{F}_r$-arithmetic - When computing operations on elliptic curve points inside the proof system verifier, the -base field arithmetic is used. i.e., verifier uses $\mathbb{F}_q$-arithmetic. + base field arithmetic is used. i.e., verifier uses $\mathbb{F}_q$-arithmetic. Normally, when there is a clear dichotomy between a prover and a verifier, the use of two distinct field arithmetics would not be an issue. @@ -376,8 +368,7 @@ come to be deployed in zero-knowledge proof systems such as zkSNARKs. The proof system aimed at is illustrated in [Figure 3](#fig_app) below.

-
Figure 3: Amicable Pair-based Proof System
- +
Figure 3: Amicable Pair-based Proof System
### Pairing-friendly Elliptic Curves @@ -389,11 +380,11 @@ who first presented a practical recursive proofs composition that uses a cycle o **Definition 1:** Given an elliptic curve $E$ over a field $\mathbb{F}$, the **embedding degree** of an elliptic curve $E(\mathbb{F}_q)$ is the smallest positive integer $k$ such that $r\$ divides $p^k - 1$, where $r$ is the order -of the largest cyclic subgroup of the elliptic curve $E(\mathbb{F}_q)$. +of the largest cyclic subgroup of the elliptic curve $E(\mathbb{F}_q)$. **Definition 2:** For secure implementation of pairing-based cryptographic systems, elliptic curves with small embedding degree $k$ -and large prime-order subgroups are used. Such elliptic curves are called **pairing-friendly**. +and large prime-order subgroups are used. Such elliptic curves are called **pairing-friendly**. According to Freeman et al [[14]], "pairing-friendly curves are rare and thus require specific constructions." In the same paper, the authors furnish what they call a "single coherent framework" of constructions of pairing-friendly @@ -402,7 +393,6 @@ elliptic curves. The Coda blockchain [[19]] is an example of a deployed protocol using the Ben-Sasson approach in [[2]]. It uses pairing-friendly MNT curves of embedding degrees 4 and 6. - ### Amicable Pairs of Elliptic Curves According to Bowe et al in [[8]], pairing-based curves of small embedding degree like @@ -411,7 +401,7 @@ approaching 800 bits for 128-bit security level. Previously, constructions of pairing-friendly curves were mostly restricted to embedding degrees $k \leq 6$, until Barreto and Naehrig constructed curves of prime order and -embedding degree $k = 12$ in [[20]]. +embedding degree $k = 12$ in [[20]]. Some researchers, such as Chiesa et al [[21]], do not make much distinction between a cycle of pairing-friendly elliptic curves and Aliquot cycle of elliptic curves (to be defined below). @@ -420,10 +410,11 @@ with elliptic curves of prime orders. Minimum required properties for a second elliptic curve that forms an Amicable Pair with the elliptic curve group $E(\mathbb{F}_q)$ are, + - the second curve must also be of a large prime order, - it must be compatible with the first curve in the sense that the verifier operations can be -efficiently carried out in it, and -- its Discrete Log Problem must be comparably as difficult as in the first curve $E(\mathbb{F}_q)$. + efficiently carried out in it, and +- its Discrete Log Problem must be comparably as difficult as in the first curve $E(\mathbb{F}_q)$. An elliptic curve $E$ over a field $\mathbb{F}$ has a **good reduction** at a prime $p$ if the elliptic curve group $E(\mathbb{F}_p)$ has all the above mentioned properties. @@ -442,7 +433,7 @@ An Aliquot cycle as defined above has length $l$. **Definition 4:** [[16]] An **Amicable Pair** of an elliptic curve $E$ over $\mathbb{Q}$ is any pair of primes $(p, q)$ such that $E$ has good reduction at $p$ and $q$ such that - $$\\# E(\mathbb{F}\_p) = q \text{ } \text{ and } \text{ } \\# E(\mathbb{F}\_q) = p $$ +$$\\# E(\mathbb{F}\_p) = q \text{ } \text{ and } \text{ } \\# E(\mathbb{F}\_q) = p $$ Thus an Amicable pair is basically an Aliquot cycle of length $l = 2$. That is, an Aliquot cycle of only two elliptic curves. @@ -453,7 +444,6 @@ more than $800$ amicable pairs using prime numbers that are less than $10^6$. See [Figure 3](#fig_apps) above for a simplified depiction of a recursive proofs system using an Amicable pair of elliptic curves. - ## Brief Survey: Recursive Proofs Protocols There are two recursive proofs protocols using amicable pairs of elliptic curves @@ -469,13 +459,13 @@ architecture, a **decentralized ledger** instead of a typical blockchain. Coda follows Ben-Sasson et al's approach to cycle of curves by constructing two SNARKs, Tic and Toc, that verify each other. Note that this means the recursive proofs composition circuit, as seen in -[Figure 3](#fig_apps), is actually a two-way circuit. +[Figure 3](#fig_apps), is actually a two-way circuit. The main disadvantage of Coda is that it uses a trusted setup. But also, to achieve 128-bit security at low embedding degrees it requires 750-bit-sized curves.

-
Figure 4: MNT4/MNT6: Coda Protocol's Pair of Elliptic Curves [[22]]
+
Figure 4: MNT4/MNT6: Coda Protocol's Pair of Elliptic Curves [[22]]
### Sonic Protocol @@ -491,13 +481,13 @@ Unlike the SRS used in Groth's scheme [[18]] which grows quadratically with the of its arithmetic circuit, Sonic's only grows linearly. Sonic is built from a polynomial commitment scheme and -a *signature of correct computation*. +a _signature of correct computation_. The latter primitive seems to achieve what a PCD does, allowing a third party helper to provide solutions to a computation as well as proof that the computation was correctly carried out. Lastly, Sonic makes use of an elliptic curve construction known as BLS12-381 in order to achieve -128-bit security at the minimum [[23]]. +128-bit security at the minimum [[23]]. ### Halo Protocol @@ -523,7 +513,6 @@ Halo is no doubt the closest recursive proofs protocol to Bulletproofs, and henc of keen interest to Tari for possibly developing a recursive proofs system that achieves scaling of the Tari Blockchain. - ## Conclusion Recursive proofs composition is not only fascinating but also powerful, even as @@ -550,175 +539,125 @@ with messages passed along directed edges" [[1]]. This together with the Coda example imply that an ingenious combination of a DLT and a PCD for Layer 2 could achieve immense blockchain scalability. - - ## References [[1]] B. Buenz, P. Mishra, A. Chiesa and N. Spooner, "Proof-Carrying Data from Accumulation Schemes", May 25, 2020 [online]. Available: . Date accessed: 2020‑07‑01. -[1]: https://eprint.iacr.org/2020/499.pdf "Proof-Carrying Data from Accumulation Schemes" - - +[1]: https://eprint.iacr.org/2020/499.pdf 'Proof-Carrying Data from Accumulation Schemes' [[2]] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, "Scalable Zero Knowledge via Cycles of Elliptic Curves", September 18, 2016 [online]. Available: . -Date accessed: 2020‑07‑01. - -[2]: https://eprint.iacr.org/2014/595.pdf "Scalable Zero Knowledge via Cycles of Elliptic Curves" - +Date accessed: 2020‑07‑01. +[2]: https://eprint.iacr.org/2014/595.pdf 'Scalable Zero Knowledge via Cycles of Elliptic Curves' [[3]] A. Chiesa and E. Tromer, "Proof-Carrying Data and Hearsay Arguments from Signature Cards", ICS 2010 [online]. Available: . Date accessed: 2020‑07‑01. -[3]: https://people.eecs.berkeley.edu/~alexch/docs/CT10.pdf "Proof-Carrying Data and Hearsay Arguments from Signature Cards" - - +[3]: https://people.eecs.berkeley.edu/~alexch/docs/CT10.pdf 'Proof-Carrying Data and Hearsay Arguments from Signature Cards' [[4]] A. Chiesa, "Proof-Carrying Data," PhD Thesis, MIT, June 2010. [online]. Available: -. Date accessed: 2020‑07‑01. - -[4]: https://pdfs.semanticscholar.org/6c6b/bf89c608c74be501a6c6406c976b1cf1e3b4.pdf "Proof-Carrying Data" - - +. Date accessed: 2020‑07‑01. -[[5]] E. Ben-Sasson, A. Chiesa, P. Mishra and N. Spooner, "Proof-Carrying Data from Accumulation Schemes", May 25, 2020 [online]. Available: . Date accessed: 2020‑07‑06. +[4]: https://pdfs.semanticscholar.org/6c6b/bf89c608c74be501a6c6406c976b1cf1e3b4.pdf 'Proof-Carrying Data' -[5]: https://eprint.iacr.org/2020/499.pdf "Proof-Carrying Data from Accumulation Schemes" +[[5]] E. Ben-Sasson, A. Chiesa, P. Mishra and N. Spooner, "Proof-Carrying Data from Accumulation Schemes", May 25, 2020 [online]. Available: . Date accessed: 2020‑07‑06. +[5]: https://eprint.iacr.org/2020/499.pdf 'Proof-Carrying Data from Accumulation Schemes' +[[6]] A. Landesman, "NOTES ON FINITE FIELDS", [online]. Available: . Date accessed: 2020‑07‑06. -[[6]] A. Landesman, "NOTES ON FINITE FIELDS", [online]. Available: . Date accessed: 2020‑07‑06. - -[6]: https://web.stanford.edu/~aaronlan/assets/finite-fields.pdf "NOTES ON FINITE FIELDS" - - +[6]: https://www.scribd.com/document/516186827/Finite-Fields-Stanford 'NOTES ON FINITE FIELDS' [[7]] E. Ben-Sasson, "The ZKP Cambrian Explosion and STARKs" November 2019 -[online]. Available: . +[online]. Available: . Date accessed: 2020‑07‑05. -[7]: https://starkware.co/decks/cambrian_explosion_nov19.pdf "The ZKP Cambrian Explosion and STARKs" - - +[7]: https://medium.com/starkware/the-cambrian-explosion-of-crypto-proofs-7ac080ac9aed 'The ZKP Cambrian Explosion and STARKs' [[8]] S. Bowe, J. Grigg and D. Hopwood, "Halo: Recursive Proof Composition without a Trusted Setup" [online]. Available: . Date accessed: 2020‑07‑05. -[8]: https://pdfs.semanticscholar.org/83ac/e8f26e6c57c6c2b4e66e5e81aafaadd7ca38.pdf "Halo: Recursive Proof Composition without a Trusted Setup" - - +[8]: https://pdfs.semanticscholar.org/83ac/e8f26e6c57c6c2b4e66e5e81aafaadd7ca38.pdf 'Halo: Recursive Proof Composition without a Trusted Setup' [[9]] Tari Labs University, "Amortization of Bulletproofs Inner-product Proof", May 2020 [online]. Available: . Date accessed: 2020‑07‑06. -[9]: https://tlu.tarilabs.com/cryptography/amortization-of-bulletproof-inner-product-proof "Amortization of Bulletproofs Inner-product Proof" - - +[9]: https://tlu.tarilabs.com/cryptography/amortization-of-bulletproof-inner-product-proof 'Amortization of Bulletproofs Inner-product Proof' [[10]] P. Bartlett, "Lecture 9: Elliptic Curves, CCS Discrete Math I", 2014 [online]. Available: . Date accessed: 2020‑07‑06. -[10]: http://web.math.ucsb.edu/~padraic/ucsb_2014_15/ccs_discrete_f2014/ccs_discrete_f2014_lecture9.pdf "Lecture 9: Elliptic Curves, CCS Discrete Math I" +[10]: http://web.math.ucsb.edu/~padraic/ucsb_2014_15/ccs_discrete_f2014/ccs_discrete_f2014_lecture9.pdf 'Lecture 9: Elliptic Curves, CCS Discrete Math I' - - -[[11]] S. Bowe, J. Grigg and D. Hopwood, "Halo: Recursive Proof Composition without a +[[11]] S. Bowe, J. Grigg and D. Hopwood, "Halo: Recursive Proof Composition without a Trusted Setup", Electric Coin Company, 2019 [online]. Available: . Date accessed: 2020‑07‑06. -[11]: https://pdfs.semanticscholar.org/83ac/e8f26e6c57c6c2b4e66e5e81aafaadd7ca38.pdf "Halo: Recursive Proof Composition without a Trusted Setup" - - +[11]: https://pdfs.semanticscholar.org/83ac/e8f26e6c57c6c2b4e66e5e81aafaadd7ca38.pdf 'Halo: Recursive Proof Composition without a Trusted Setup' [[12]] M.C. Welsh, "ELLIPTIC CURVE CRYPTOGRAPHY" REUpapers, 2017, [online]. Available: . Date accessed: 2020‑07‑07. -[12]: http://math.uchicago.edu/~may/REU2017/REUPapers/CoatesWelsh.pdf "ELLIPTIC CURVE CRYPTOGRAPHY" - +[12]: http://math.uchicago.edu/~may/REU2017/REUPapers/CoatesWelsh.pdf 'ELLIPTIC CURVE CRYPTOGRAPHY' - -[[13]] A.V. Sutherland, "Elliptic Curves, Lecture 9 Schoof's Algorithm", Spring 2015, [online]. Available: -. Date accessed: 2020‑07‑07. +[[13]] A.V. Sutherland, "Elliptic Curves, Lecture 9 Schoof's Algorithm", Spring 2015, [online]. Available: +. Date accessed: 2020‑07‑07. [13]: https://math.mit.edu/classes/18.783/2015/LectureNotes9.pdf "Elliptic Curves, Lecture 9 Schoof's Algorithm" - - [[14]] D. Freeman, M. Scott and E. Teske, "A TAXONOMY OF PAIRING-FRIENDLY ELLIPTIC CURVES", [online]. Available: . Date accessed: 2020‑07‑07. -[14]: https://eprint.iacr.org/2006/372.pdf "A TAXONOMY OF PAIRING-FRIENDLY ELLIPTIC CURVES" - - +[14]: https://eprint.iacr.org/2006/372.pdf 'A TAXONOMY OF PAIRING-FRIENDLY ELLIPTIC CURVES' [[15]] M. Straka, "Recursive Zero-knowledge Proofs: A Comprehensive Primer" [online], 2019‑12‑08. Available: . Date accessed: 2020‑07‑07. -[15]: https://www.michaelstraka.com/posts/recursivesnarks "Recursive Zero-knowledge Proofs: A Comprehensive Primer" - - +[15]: https://www.michaelstraka.com/posts/recursivesnarks 'Recursive Zero-knowledge Proofs: A Comprehensive Primer' [[16]] J.H. Silverman and K.E. Stange, "Amicable pairs and aliquot cycles for elliptic curves" [online], 2019‑12‑08. Available: . Date accessed: 2020‑07‑08. -[16]: https://arxiv.org/pdf/0912.1831.pdf "Amicable pairs and aliquot cycles for elliptic curves" - - +[16]: https://arxiv.org/pdf/0912.1831.pdf 'Amicable pairs and aliquot cycles for elliptic curves' [[17]] A. Menezes, "An Introduction to Pairing-Based Cryptography" [online]. Available: . Date accessed: 2020‑07‑11. -[17]: https://www.math.uwaterloo.ca/~ajmeneze/publications/pairings.pdf "An Introduction to Pairing-Based Cryptography" - - +[17]: https://www.math.uwaterloo.ca/~ajmeneze/publications/pairings.pdf 'An Introduction to Pairing-Based Cryptography' [[18]] E. Groth, "On the Size of Pairing-based Non-interactive Arguments" [online]. Available: . Date accessed: 2020‑07‑12. -[18]: https://eprint.iacr.org/2016/260.pdf "On the Size of Pairing-based Non-interactive Arguments" - - - -[[19]] I. Meckler and E. Shapiro, "Coda: Decentralized cryptocurrency at scale" O(1) Labs whitepaper. May 10, 2018. [online]. Available: . Date accessed: 2020‑07‑12. - -[19]: https://cdn.codaprotocol.com/v2/static/coda-whitepaper-05-10-2018-0.pdf "Coda: Decentralized cryptocurrency at scale" +[18]: https://eprint.iacr.org/2016/260.pdf 'On the Size of Pairing-based Non-interactive Arguments' +[[19]] I. Meckler and E. Shapiro, "Coda: Decentralized cryptocurrency at scale" O(1) Labs whitepaper. May 10, 2018. [online]. Available: . Date accessed: 2020‑07‑12. +[19]: https://eprint.iacr.org/2020/352 'Coda: Decentralized cryptocurrency at scale' [[20]] P.L.M.N. Barreto, M. Naehrig, "Pairing-Friendly Elliptic Curves of Prime Order" [online]. Available: . Date accessed: 2020‑07‑12. -[20]: https://eprint.iacr.org/2005/133.pdf "Pairing-Friendly Elliptic Curves of Prime Order" - - +[20]: https://eprint.iacr.org/2005/133.pdf 'Pairing-Friendly Elliptic Curves of Prime Order' [[21]] A. Chiesa, L. Chua and M. Weidner, "On cycles of pairing-friendly elliptic curves" [online]. Available: . Date accessed: 2020‑07‑12. -[21]: https://arxiv.org/pdf/1803.02067.pdf "On cycles of pairing-friendly elliptic curves" - - +[21]: https://arxiv.org/pdf/1803.02067.pdf 'On cycles of pairing-friendly elliptic curves' [[22]] S. Bowe, "Halo: Recursive Proofs without Trusted Setups (video)", Zero Knowledge Presentations Nov 15, 2019 [online]. Available: . Date accessed: 2020‑07‑13. -[22]: https://www.youtube.com/watch?v=OhkHDw54C04 "Halo: Recursive Proofs without Trusted Setups (video)" - - +[22]: https://www.youtube.com/watch?v=OhkHDw54C04 'Halo: Recursive Proofs without Trusted Setups (video)' [[23]] M. Maller, S. Bowe, M. Kohlweiss and S. Meiklejohn, "Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updateable Structured Reference Strings," Cryptology ePrint Archive: Report 2019/099. Last revised July 8, 2019. [online]. Available: -[23]: https://eprint.iacr.org/2019/099 "Sonic: Zero-Knowledge SNARKs -from Linear-Size Universal and Updateable Structured Reference Strings" - - +[23]: https://eprint.iacr.org/2019/099 'Sonic: Zero-Knowledge SNARKs +from Linear-Size Universal and Updateable Structured Reference Strings' [[24]] J. Bootle, A. Cerulli, P. Chaidos, J. Groth and C. Petit, "Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting" [online]. Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 327‑357. Springer, 2016. Available: . Date accessed: 2019‑12‑21. -[24]: https://eprint.iacr.org/2016/263.pdf "Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting" - - +[24]: https://eprint.iacr.org/2016/263.pdf 'Efficient Zero-knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting' ## Appendix A: Pairing Cryptography @@ -730,17 +669,17 @@ Although applications of pairing-based cryptography were known for a long time i one-round three-party key agreements, they became more popular with the emergence of identity-based encryption. -Let $n$ be a prime number, $P$ a generator of an additively-written group $G_1 = ⟨P⟩$ with identity $\mathcal{O}$, +Let $n$ be a prime number, $P$ a generator of an additively-written group $G_1 = ⟨P⟩$ with identity $\mathcal{O}$, and $G_T$ a multiplicatively-written group of order $n$ with identity $1$. **Definition A1:** [[17]] -A **bilinear pairing** on $(G_1, G_T)$ is a map -$$ \hat{e} : G_1 \times G_1 \to G_T$$ +A **bilinear pairing** on $(G_1, G_T)$ is a map +$$ \hat{e} : G*1 \times G_1 \to G_T$$ satisfying the following properties, (a) (*bilinear*) For all $R$, $S$, $T \in G_1$, $\ \ \hat{e} (R + S,T) = \hat{e} (R,T) \hat{e}(S,T)\ \ $ and -$\ \ \hat{e} ( R , S + T ) = \hat{e} ( R , S ) \hat{e} ( R , T )$ -(b) (*non-degeneracy*) $\hat{e} (P, P ) \not= 1$ -(c) (*computability*) The map $ \hat{e}$ can be efficiently computed. +$\ \ \hat{e} ( R , S + T ) = \hat{e} ( R , S ) \hat{e} ( R , T )$ +(b) (\_non-degeneracy*) $\hat{e} (P, P ) \not= 1$ +(c) (_computability_) The map $ \hat{e}$ can be efficiently computed. One of the most important properties of the bilinear map $\hat{e}$ is that, for all $a$,$b$ $\in \mathbb{Z}$, $$ \hat{e}(aS,bT) = \hat{e}(S,T)^{ab}\ \$$ @@ -751,13 +690,15 @@ pairing-based cryptographic primitive. **Example A1** The **BLS-signature** uses a bilinear map $\hat{e}$ on $(G_1, G_T)$ for which the Diffie-Hellman Problem is intractable. -Say, Alice wants to send a message to Bob with an attached signature. +Say, Alice wants to send a message to Bob with an attached signature. + - Alice randomly selects an integer $a \in \[ 1, n-1 \]$ and creates a public key $A = aP$ where $P$ -is generator of the group $G_1$. + is generator of the group $G_1$. - Alice's BLS-signature on a message $m \in \\{ 0, 1 \\}^n$ is $S = aM$ where $M = H(m)$ and $H$ a -hash function $H : \\{ 0, 1 \\}^n \to G_1 \backslash \mathcal{O}$. + hash function $H : \\{ 0, 1 \\}^n \to G_1 \backslash \mathcal{O}$. How can Bob or any party verify Alice's signature? + - By first computing $M = H(m)$ and then check if $\hat{e}(P,S) = \hat{e}(A,M)$ This is why the verification works, @@ -769,7 +710,6 @@ See the diagram below that illustrates the verification.

Figure A1: BLS Signature Verification
- ## Contributors -- +- diff --git a/_includes/content/digital-assets/03-confidential-assets.md b/_includes/content/digital-assets/03-confidential-assets.md index 5aab3bed..00a1b61e 100644 --- a/_includes/content/digital-assets/03-confidential-assets.md +++ b/_includes/content/digital-assets/03-confidential-assets.md @@ -21,8 +21,6 @@ - [Appendix B: Ricardian Contracts vs. Smart Contracts](#appendix-b-ricardian-contracts-vs-smart-contracts) - [Contributors](#contributors) - - ## Introduction Confidential assets, in the context of blockchain technology and blockchain-based cryptocurrencies, can have different @@ -35,7 +33,7 @@ with regard to whether they are fungible (interchangeable) or non-fungible (uniq assets can only exist in the form of a cryptographic token or derivative thereof that is also cryptographically secure, at least under the Discrete Logarithmic Problem[def][dlp~] (DLP) assumption. -The basis of confidential assets is confidential transactions as proposed by Maxwell [[4]] and Poelstra et al. [[5]], +The basis of confidential assets is confidential transactions as proposed by Maxwell and Poelstra et al. [[5]], where the amounts transferred are kept visible only to participants in the transaction (and those they designate). Confidential transactions succeed in making the transaction amounts private, while still preserving the ability of the public blockchain network to verify that the ledger entries and Unspent Transaction Output (UTXO) set still add up. All @@ -45,8 +43,6 @@ single transactions on the same blockchain. This report investigates confidential assets as a natural progression of confidential transactions. - - ## Preliminaries This section gives the general notation of mathematical expressions when specifically referenced in the report. @@ -59,8 +55,6 @@ important pre-knowledge for the remainder of the report. - Let $ \mathbb F_p $ be a group of elliptic curve points over a finite (prime) field. - All references to Pedersen Commitment will imply Elliptic Curve Pedersen Commitment. - - ## Basis of Confidential Assets Confidential transactions, asset commitments and Asset Surjection Proofs (ASPs) are really the basis of confidential @@ -86,10 +80,10 @@ C(x,r) = xH + rG \tag{1} $$ -where $ r \in \mathbb Z_p $ is a random blinding factor, $ G \in \mathbb F_p $ is a random generator point and -$ H \in \mathbb F_p $ is specially chosen so that the value $ x_H $ satisfying $ H = x_H G $ cannot be found, except +where $ r \in \mathbb Z_p $ is a random blinding factor, $ G \in \mathbb F_p $ is a random generator point and +$ H \in \mathbb F_p $ is specially chosen so that the value $ x_H $ satisfying $ H = x_H G $ cannot be found, except if the Elliptic Curve DLP[def][dlp~] (ECDLP) is solved. The number $ H $ is what is known as a Nothing Up -My Sleeve (NUMS) number. With secp256k1, the value of $ H $ is the SHA256 hash of a simple encoding of the $ x $-coordinate +My Sleeve (NUMS) number. With secp256k1, the value of $ H $ is the SHA256 hash of a simple encoding of the $ x $-coordinate of the generator point $ G $. The Pedersen Commitment scheme is implemented with three algorithms: Setup() to set up the commitment parameters $ G $ and $ H $; Commit() to commit to the message $ x $ using the commitment parameters $ r $, $ H $ and $ G $; and Open() to open and verify @@ -99,8 +93,6 @@ the commitment ([[5]], [[6]], [[7]], [[8]]). confidentiality using these confidential transaction primitives. If confidentiality is not sought, inputs may be given as explicit amounts, in which case the homomorphic commitment to the given amount will have a blinding factor $ r = 0 ​$. - - ### Asset Commitments and Surjection Proofs The different assets need to be identified and transacted with in a confidential manner, and proven to not be @@ -145,10 +137,10 @@ H_{0_A} = H_A + rG $$ Blinding of the asset tag is necessary to make transactions in the asset, i.e. which asset was transacted in, -confidential. The blinded asset tag $ H\_{0\_A} $ will then be used in place of the generator $ H $ in the Pedersen +confidential. The blinded asset tag $ H\_{0_A} $ will then be used in place of the generator $ H $ in the Pedersen Commitments. Such Pedersen Commitments thus commit to the committed amount as well as to the underlying asset tag. -Inspecting the Pedersen Commitment, it is evident that a commitment to the value $ x_1 $ using the blinded asset -tag $ H_{0_A} $ is also a commitment to the same value using the asset tag $ H_A $: +Inspecting the Pedersen Commitment, it is evident that a commitment to the value $ x*1 $ using the blinded asset +tag $ H*{0_A} $ is also a commitment to the same value using the asset tag $ H_A $: $$ x_1H_{0_A} + r_{A_1}G = x_1(H_A + rG) + r_{A_1}G = x_1H_A + (r_{A_1} + x_1r)G @@ -184,17 +176,17 @@ H_{0_A} = -H_A + rG \tag{8} $$ -Any amount of blinded asset tag $ H_{0_A} $ will correspond to a negative amount of asset $ A $, thereby inflating its +Any amount of blinded asset tag $ H\_{0_A} $ will correspond to a negative amount of asset $ A $, thereby inflating its supply. To solve this problem, an ASP is introduced, which is a cryptographic proof. In mathematics, a surjection function simply means that for every element $ y $ in the codomain $ Y $ of function $ f $, there is at least one element $ x $ in the domain $ X $ of function $ f $ such that $ f(x) = y$. -An ASP scheme provides a proof $ \pi ​$ for a set of input asset commitments $ [ H_i ] ^n_{i=1} ​$, an output -commitment $ H = H_{\hat i} + rG ​$ for $ \hat i = 1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} n ​$ +An ASP scheme provides a proof $ \pi ​$ for a set of input asset commitments $ [ H_i ] ^n*{i=1} ​$, an output +commitment $ H = H*{\hat i} + rG ​$ for $ \hat i = 1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} n ​$ and blinding factor $ r ​$. It proves that every output asset type is the same as some input asset type, while blinding which outputs correspond to which inputs. Such a proof $ \pi ​$ is secure if it is a zero-knowledge proof of knowledge -for the blinding factor $ r ​$. Let $ H\_{0\_{A1}} ​$ and $ H\_{0\_{A2}} ​$ be blinded asset tags that commit to the same -asset tag $ H\_A ​$: +for the blinding factor $ r ​$. Let $ H\_{0\_{A1}} ​$ and $ H\_{0\_{A2}} ​$ be blinded asset tags that commit to the same +asset tag $ H_A ​$: $$ H_{0_{A1}} = H_A + r_1G \mspace{15mu} \mathrm{and} \mspace{15mu} H_{0_{A2}} = H_A + r_2G @@ -208,24 +200,22 @@ H_{0_{A1}} - H_{0_{A2}} = (H_A + r_1G) - (H_A + r_2G) = (r_1 - r_2)G \tag{10} $$ -will be a signature key with secret key $ r_1 - r_2 $. Thus for an $ n $ distinct multiple asset type transaction, -differences can be calculated between each output and all inputs, e.g. $ (out_A - in_A) , (out_A - in_B) \mspace{3mu} , - \mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} (out_A - in_n) $, and so on for all outputs. This has the form of a - ring signature, and if $ out_A $ has the same asset tag as one of the inputs, the transaction signer will know the - secret key corresponding to one of these differences, and be able to produce the ring signature. The ASP is based on - the *Back-Maxwell* range proof (refer to Definition 9 of [[1]]), which uses a variation of Borromean ring signatures [[18]]. - The Borromean ring signature, in turn, is a variant of the Abe-Ohkubo-Suzuki (AOS) ring signature [[19]]. An AOS ASP - computes a ring signature that is equal to the proof $ \pi $ as follows: - -- Calculate $ n $ differences $ H - H_{\hat i } $ for $ \hat i = 1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , -\mspace{3mu} n $, one of which will be equal to the blinding factor $ r $. +will be a signature key with secret key $ r*1 - r_2 $. Thus for an $ n $ distinct multiple asset type transaction, +differences can be calculated between each output and all inputs, e.g. $ (out_A - in_A) , (out_A - in_B) \mspace{3mu} , +\mspace{3mu} . . . \mspace{3mu} , \mspace{3mu} (out_A - in_n) $, and so on for all outputs. This has the form of a +ring signature, and if $ out_A $ has the same asset tag as one of the inputs, the transaction signer will know the +secret key corresponding to one of these differences, and be able to produce the ring signature. The ASP is based on +the \_Back-Maxwell* range proof (refer to Definition 9 of [[1]]), which uses a variation of Borromean ring signatures [[18]]. +The Borromean ring signature, in turn, is a variant of the Abe-Ohkubo-Suzuki (AOS) ring signature [[19]]. An AOS ASP +computes a ring signature that is equal to the proof $ \pi $ as follows: + +- Calculate $ n $ differences $ H - H\_{\hat i } $ for $ \hat i = 1 \mspace{3mu} , \mspace{3mu} . . . \mspace{3mu} , + \mspace{3mu} n $, one of which will be equal to the blinding factor $ r $. - Calculate a ring signature $ S $ of an empty message using the $ n $ differences. The resulting ring signature $ S $ is equal to the proof $ \pi $, and the ASP consists of this ring signature $ S ​$ ([[1]], [[14]]). - - ## Confidential Asset Scheme Using the building blocks discussed in [Basis of Confidential Assets](#basis-of-confidential-assets), asset @@ -250,17 +240,19 @@ asset type, thus preserving privacy. Payment authorization is achieved by means asset transaction consists of the following data: - A list of inputs, each of which can have one of the following forms: + - a reference to an output of another transaction, with a signature using that output's verification key; or - an asset issuance input, which has an explicit amount and asset tag. - A list of outputs that contains: + - a signature verification key; - an asset commitment $ H_0 $ with an ASP from all input asset commitments to $ H_0 $; - - Pedersen commitment to an amount using generator $ H_0 $ in place of $ H $, with the associated *Back-Maxwell* - range proof. + - Pedersen commitment to an amount using generator $ H*0 $ in place of $ H $, with the associated \_Back-Maxwell* + range proof. -- A fee, listed explicitly as $ \{ (f_i , H_i) \}_{i=1}^n $, where $ f_i $ is a non-negative scalar amount denominated -in the asset with tag $ H_i $. +- A fee, listed explicitly as $ \{ (f*i , H_i) \}*{i=1}^n $, where $ f_i $ is a non-negative scalar amount denominated + in the asset with tag $ H_i $. Every output has a range proof and ASP associated with it, which are proofs of knowledge of the Pedersen commitment opening information and asset commitment blinding factor. Every range proof can be considered as being with respect to @@ -272,8 +264,6 @@ However, confidential assets come at an additional data cost. For a transaction relation to the units of space used for confidential transactions, the asset commitment has size $ 1$, the ASP has size $ n + 1 $ and the entire transaction therefore has size $ m(n + 2) $ [[1]]. - - ### Asset Issuance It is important to ensure that any auxiliary input $ A $ used to create asset tag $ H_A \in \mathbb G $ only be used @@ -305,13 +295,11 @@ asset definition) transaction input then consists of the UTXO being spent, the R issuance explicit value or a Pedersen commitment, a range proof and a Boolean field indicating whether reissuance is allowed ([[1]], [[13]]). - - ### Asset Reissuance The confidential asset scheme allows the asset owner to later increase or decrease the amount of the asset in circulation, given that an asset reissuance token is generated together with the initial asset issuance. Given an asset -entropy $ E $, the asset reissuance capability is the element (asset tag) $ H_{\hat A} \in \mathbb G $ obtained using +entropy $ E $, the asset reissuance capability is the element (asset tag) $ H\_{\hat A} \in \mathbb G $ obtained using an alternative auxiliary input $ \hat A $ defined as $$ @@ -319,7 +307,7 @@ $$ \tag{13} $$ -The resulting asset tag $ H_{\hat A} \in \mathbb G $ is linked to its reissuance capability, and the asset owner can +The resulting asset tag $ H\_{\hat A} \in \mathbb G $ is linked to its reissuance capability, and the asset owner can assert their reissuance right by revealing the blinding factor $ r $ for the reissuance capability along with the original asset entropy $ E $. An asset reissuance (or asset definition) transaction input then consists of the spend of a UTXO containing an asset reissuance capability, the original asset entropy, the blinding factor for the asset @@ -330,8 +318,6 @@ to destroy the asset, or to make the commitment generator the hash of a script t It is also possible to change the name of the default asset that is created upon blockchain initialization and the default asset used to pay fees on the network ([[1]], [[13]]). - - ### Flexibility ASPs prove that the asset commitments associated with outputs commit to legitimately issued asset tags. This feature @@ -345,8 +331,6 @@ development of this scheme were based on the Back-Maxwell range proof scheme (re et al. [[1]] suggest more efficient range proofs, ASPs and use of aggregate range proofs. It is thus an open question whether Bulletproofs could fulfill this requirement. - - ## Confidential Asset Implementations Three independent implementations of confidential assets are summarized here. The first two implementations closely @@ -364,11 +348,11 @@ and is based on its formal publication in [[1]]. The Elements project hosts a working demonstration (shown in [Figure 2](#fig_eca)) of confidential asset transfers involving five parties in `Github: ElementsProject/confidential-assets-demo` [[17]]. The demonstration depicts a scenario -where a coffee shop owner, *Dave,* charges a customer, *Alice,* for coffee in an asset called MELON. *Alice* does not hold -enough MELON and needs to convert some AIRSKY into MELON, making use of an exchange operated by *Charlie*. The coffee -shop owner, *Dave,* has a competitor, *Bob*, who is trying to gather information about *Dave's* sales. Due to the +where a coffee shop owner, _Dave,_ charges a customer, _Alice,_ for coffee in an asset called MELON. _Alice_ does not hold +enough MELON and needs to convert some AIRSKY into MELON, making use of an exchange operated by _Charlie_. The coffee +shop owner, _Dave,_ has a competitor, _Bob_, who is trying to gather information about _Dave's_ sales. Due to the blockchain's confidential transactions and assets features, he will not be able to see anything useful by processing -transactions on the blockchain. *Fred* is a miner and does not care about the detail of the transactions, but he makes +transactions on the blockchain. _Fred_ is a miner and does not care about the detail of the transactions, but he makes blocks on the blockchain when transactions enter his miner mempool. The demonstration also includes generating the different types of assets. @@ -378,8 +362,6 @@ different types of assets. [17]

- - ### Chain Core Confidential Assets Chain Core [[20]] is a shared, multi-asset, cryptographic ledger, designed for enterprise financial infrastructure. It @@ -393,8 +375,6 @@ Chain Core implements all native features as defined in [[1]]. It was also worki commitments into Chain Core to make its Confidential Assets framework quantum secure, but it is unclear if this effort was concluded at the time the project was archived ([[24]], [[25]]). - - ### Cloak Chain/Interstellar [[26]] introduced Cloak [[29]], a redesign of Chain Core's Confidential Assets framework to make use @@ -406,264 +386,223 @@ quantities do not overflow, and that both quantities and asset types are kept se A traditional Bulletproofs implementation converts an arithmetic circuit into a Rank-1 Constraint System (R1CS); Cloak bypasses arithmetic circuits and provides an Application Programmers Interface (API) for building a [constraint system](/cryptography/the-bulletproof-protocols#evolving-bulletproof-protocols) directly. -The R1CS API consists of a hierarchy of task-specific “gadgets”, and is used by the *Prover* and *Verifier* alike to +The R1CS API consists of a hierarchy of task-specific “gadgets”, and is used by the _Prover_ and _Verifier_ alike to allocate variables and define constraints. Cloak uses a collection of gadgets such as “shuffle”, “merge”, “split” and “range proof” to build a constraint system for cloaked transactions. All transactions of the same size are indistinguishable, because the layout of all the gadgets is only determined by the number of inputs and outputs. At the time of writing this report, the Cloak development was still ongoing. - - ## Conclusions, Observations and Recommendations - The idea to embed a Ricardian contract in the asset tag creation as suggested by Poelstra et al. [[1]] warrants more -investigation for a new confidential blockchain protocol such as Tari. Ricardian contracts could be used in asset -generation in the probable second layer. + investigation for a new confidential blockchain protocol such as Tari. Ricardian contracts could be used in asset + generation in the probable second layer. - Asset commitments and ASPs are important cryptographic primitives for confidential asset transactions. - The Elements project implemented a range of useful confidential asset framework features and should be critically -assessed for usability in a probable Tari second layer. + assessed for usability in a probable Tari second layer. - Cloak has the potential to take confidential assets implementation to the next level in efficiency and should be -closely monitored. Interstellar is in the process of fully implementing and extending Bulletproofs for use in confidential -assets. + closely monitored. Interstellar is in the process of fully implementing and extending Bulletproofs for use in confidential + assets. - If confidential assets are to be implemented in a Mimblewimble blockchain, all asset tags must be defined at their -instantiation, otherwise they will not be compatible. - - + instantiation, otherwise they will not be compatible. ## References [[1]] A. Poelstra, A. Back, M. Friedenbach, G. Maxwell and P, Wuille, "Confidential Assets", Blockstream [online]. Available: . Date accessed: 2018‑12‑25. -[1]: https://blockstream.com/bitcoin17-final41.pdf -"Confidential Assets, +[1]: https://blockstream.com/bitcoin17-final41.pdf 'Confidential Assets, A. Poelstra et al., -Blockstream" +Blockstream' [[2]] Wikipedia: "Discrete Logarithm" [online]. Available: . Date accessed: 2018‑12‑20. -[2]: https://en.wikipedia.org/wiki/Discrete_logarithm -"Wikipedia: Discrete Logarithm" +[2]: https://en.wikipedia.org/wiki/Discrete_logarithm 'Wikipedia: Discrete Logarithm' [[3]] A. Sadeghi and M. Steiner, "Assumptions Related to Discrete Logarithms: Why Subtleties Make a Real Difference" [online]. Available: . Date accessed: 2018‑12‑24. -[3]: http://www.semper.org/sirene/publ/SaSt_01.dh-et-al.long.pdf -"Assumptions Related to Discrete Logarithms: +[3]: http://www.semper.org/sirene/publ/SaSt_01.dh-et-al.long.pdf 'Assumptions Related to Discrete Logarithms: Why Subtleties Make a Real Difference, -A. Sadeghi et al." - -[[4]] G. Maxwell, "Confidential Transactions Write up" [online]. -Available: . Date accessed: 2018‑12‑10. - -[4]: https://people.xiph.org/~greg/confidential_values.txt -"Confidential Transactions Write up, -G. Maxwell" +A. Sadeghi et al.' [[5]] A. Gibson, "An Investigation into Confidential Transactions", July 2018 [online]. Available: . Date accessed: 2018‑12‑22. -[5]: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf -"An Investigation into Confidential Transactions, +[5]: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf 'An Investigation into Confidential Transactions, A. Gibson, -July 2018" +July 2018' [[6]] Pedersen-commitment: An Implementation of Pedersen Commitment Schemes [online]. Available: . Date accessed: 2018‑12‑25. -[6]: https://hackage.haskell.org/package/pedersen-commitment -"Pedersen-commitment: An Implementation -of Pedersen Commitment Schemes" +[6]: https://hackage.haskell.org/package/pedersen-commitment 'Pedersen-commitment: An Implementation +of Pedersen Commitment Schemes' [[7]] B. Franca, "Homomorphic Mini-blockchain Scheme", April 2015 [online]. Available: . Date accessed: 2018‑12‑22. -[7]: http://cryptonite.info/files/HMBC.pdf -"Homomorphic Mini-blockchain Scheme, +[7]: http://cryptonite.info/files/HMBC.pdf 'Homomorphic Mini-blockchain Scheme, B. Franca, -April 2015" +April 2015' [[8]] C. Franck and J. Großschädl, "Efficient Implementation of Pedersen Commitments Using Twisted Edwards Curves", University of Luxembourg [online]. Available: . Date accessed: 2018‑12‑22. -[8]: http://orbilu.uni.lu/bitstream/10993/33705/1/MSPN2017.pdf -"Efficient Implementation of Pedersen +[8]: http://orbilu.uni.lu/bitstream/10993/33705/1/MSPN2017.pdf 'Efficient Implementation of Pedersen Commitments Using Twisted Edwards Curves, C. Franck and J. Großschädl, -University of Luxembourg" +University of Luxembourg' [[9]] A. Poelstra, "Mimblewimble", October 2016 [online]. Available: . Date accessed: 2018‑12‑13. -[9]: http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble-andytoshi-draft-2016-10-20.pdf -"Mimblewimble, +[9]: http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble-andytoshi-draft-2016-10-20.pdf 'Mimblewimble, A. Poelstra, -October 2016" +October 2016' [[10]] A. Poelstra, "Mimblewimble Explained", November 2016 [online]. Available: . Date accessed: 2018‑12‑10. -[10]: https://www.weusecoins.com/mimble-wimble-andrew-poelstra -"Mimblewimble Explained, +[10]: https://www.weusecoins.com/mimble-wimble-andrew-poelstra 'Mimblewimble Explained, A. Poelstra, -November 2016" +November 2016' -[[11]] I. Grigg, "The Ricardian Contract", *First IEEE International Workshop on Electronic Contracting.* IEEE (2004) +[[11]] I. Grigg, "The Ricardian Contract", _First IEEE International Workshop on Electronic Contracting._ IEEE (2004) [online]. Available: . Date accessed: 2018‑12‑13. -[11]: http://iang.org/papers/ricardian_contract.html -"The Ricardian Contract, +[11]: http://iang.org/papers/ricardian_contract.html 'The Ricardian Contract, First IEEE International Workshop on Electronic Contracting. IEEE (2004), -I. Grigg" +I. Grigg' [[12]] D. Koteshov, "Smart vs. Ricardian Contracts: What’s the Difference?" February 2018 [online]. Available: . Date accessed: 2018‑12‑13. -[12]: https://www.elinext.com/industries/financial/trends/smart-vs-ricardian-contracts/ -"Smart vs. Ricardian Contracts: +[12]: https://www.elinext.com/industries/financial/trends/smart-vs-ricardian-contracts/ 'Smart vs. Ricardian Contracts: What’s the Difference?, D. Koteshov, -February 2018" +February 2018' [[13]] Elements by Blockstream: "Issued Assets - You can Issue your own Confidential Assets on Elements" [online]. Available: . Date accessed: 2018‑12‑14. -[13]: https://elementsproject.org/features/issued-assets -"Issued Assets - You can Issue your +[13]: https://elementsproject.org/features/issued-assets 'Issued Assets - You can Issue your own Confidential Assets on Elements, -Elements by Blockstream" +Elements by Blockstream' [[14]] Elements by Blockstream: "Issued Assets - Investigation, Principal Investigator: Andrew Poelstra" [online]. Available: . Date accessed: 2018‑12‑14. -[14]: https://elementsproject.org/features/issued-assets/investigation -"Issued Assets - Investigation, +[14]: https://elementsproject.org/features/issued-assets/investigation 'Issued Assets - Investigation, Principal Investigator: Andrew Poelstra, -Elements by Blockstream" +Elements by Blockstream' [[15]] Elements by Blockstream: "Elements Code Tutorial - Issuing your own Assets" [online]. Available: . Date accessed: 2018‑12‑14. -[15]: https://elementsproject.org/elements-code-tutorial/issuing-assets -"Elements Code Tutorial - Issuing your own Assets, -Elements by Blockstream" +[15]: https://elementsproject.org/elements-code-tutorial/issuing-assets 'Elements Code Tutorial - Issuing your own Assets, +Elements by Blockstream' [[16]] Github: ElementsProject/elements [online]. Available: . Date accessed: 2018‑12‑18. -[16]: https://github.com/ElementsProject/elements -"Github: ElementsProject/elements" +[16]: https://github.com/ElementsProject/elements 'Github: ElementsProject/elements' [[17]] Github: ElementsProject/confidential-assets-demo [online]. Available: . Date accessed: 2018‑12‑18. -[17]: https://github.com/ElementsProject/confidential-assets-demo -"ElementsProject/confidential-assets-demo" +[17]: https://github.com/ElementsProject/confidential-assets-demo 'ElementsProject/confidential-assets-demo' [[18]] G. Maxwell and A. Poelstra, "Borromean Ring Signatures" (2015) [online]. Available: . Date accessed: 2018‑12‑18. -[18]: http://diyhpl.us/~bryan/papers2/bitcoin/Borromean%20ring%20signatures.pdf -"Borromean Ring Signatures (2015), -G. Maxwell and A. Poelstra" +[18]: http://diyhpl.us/~bryan/papers2/bitcoin/Borromean%20ring%20signatures.pdf 'Borromean Ring Signatures (2015), +G. Maxwell and A. Poelstra' [[19]] M. Abe, M. Ohkubo and K. Suzuki, "1-out-of-n Signatures from a Variety of Keys" [online]. Available: . Date accessed: 2018‑12‑18. -[19]: https://www.iacr.org/cryptodb/archive/2002/ASIACRYPT/50/50.pdf -"1-out-of-n Signatures from a Variety of Keys, -M. Abe, M. Ohkubo and K. Suzuki" +[19]: https://www.iacr.org/cryptodb/archive/2002/ASIACRYPT/50/50.pdf '1-out-of-n Signatures from a Variety of Keys, +M. Abe, M. Ohkubo and K. Suzuki' -[[20]] Chain Core [online]. Available: . +[[20]] Chain Core [online]. Available: . Date accessed: 2018‑12‑18. -[20]: https://chain.com/docs/1.2/core/get-started/introduction -"Chain Core" +[20]: https://chain.com 'Chain Core' [[21]] Github: chain/chain [online]. Available: . Date accessed: 2018‑12‑18. -[21]: https://github.com/chain/chain -"Github: chain/chain" +[21]: https://github.com/chain/chain 'Github: chain/chain' [[22]] Chain: "Sequence" [online]. Available: . Date accessed: 2018‑12‑18. -[22]: https://chain.com/sequence -"Chain: Sequence" +[22]: https://chain.com/sequence 'Chain: Sequence' -[[23]] Sequence Documentation [online]. Available: . Date accessed: 2018‑12‑18. +[[23]] Sequence Documentation [online]. Available: . Date accessed: 2018‑12‑18. -[23]: https://dashboard.seq.com/docs -"Sequence Documentation" +[23]: https://docs.chain.com/docs/sequence/get-started/introduction 'Sequence Documentation' [[24]] O Andreev: "Hidden in Plain Sight: Transacting Privately on a Blockchain - Introducing Confidential Assets in the Chain Protocol", Chain [online]. Available: . Date accessed: 2018‑12‑18. -[24]: https://blog.chain.com/hidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb -"Hidden in Plain Sight: +[24]: https://blog.chain.com/hidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb 'Hidden in Plain Sight: Transacting Privately on a Blockchain - Introducing Confidential Assets in the Chain Protocol -O. Andreev" +O. Andreev' [[25]] Blockchains in a Quantum Future - Protecting Against Post-Quantum Attacks on Cryptography [online]. Available: . Date accessed: 2018‑12‑18. -[25]: https://blog.chain.com/preparing-for-a-quantum-future-45535b316314 -"Blockchains in a Quantum Future - +[25]: https://blog.chain.com/preparing-for-a-quantum-future-45535b316314 'Blockchains in a Quantum Future - Protecting Against Post-Quantum -Attacks on Cryptography" +Attacks on Cryptography' [[26]] Inter/stellar website [online]. Available: . Date accessed: 2018‑12‑22. -[26]: https://interstellar.com -"Inter/stellar Website" +[26]: https://interstellar.com 'Inter/stellar Website' [[27]] C. Yun, "Programmable Constraint Systems for Bulletproofs" [online]. Available: . Date accessed: 2018‑12‑22. -[27]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 -"Programmable Constraint Systems for Bulletproofs, +[27]: https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 'Programmable Constraint Systems for Bulletproofs, Interstellar, -C. Yun" +C. Yun' [[28]] Github: interstellar/spacesuit [online]. Available: . Date accessed: 2018‑12‑18. -[28]: https://github.com/interstellar/spacesuit/blob/master/spec.md -"Github: interstellar/spacesuit" +[28]: https://github.com/interstellar/spacesuit/blob/master/spec.md 'Github: interstellar/spacesuit' [[29]] Github: interstellar/spacesuit/spec.md [online]. Available: . Date accessed: 2018‑12‑18. -[29]: https://github.com/interstellar/spacesuit/blob/master/spec.md -"Github: interstellar/spacesuit/spec.md" +[29]: https://github.com/interstellar/spacesuit/blob/master/spec.md 'Github: interstellar/spacesuit/spec.md' [[30]] Wikipedia: "Ricardian Contract" [online]. Available: . Date accessed: 2018‑12‑21. -[30]: https://en.wikipedia.org/wiki/Ricardian_contract -"Wikipedia: Ricardian Contract" +[30]: https://en.wikipedia.org/wiki/Ricardian_contract 'Wikipedia: Ricardian Contract' [[31]] Wikipedia: "Elements by Blockstream" [online]. Available: . Date accessed: 2018‑12‑21. -[31]: https://elementsproject.org/ -"Elements by Blockstream" +[31]: https://elementsproject.org/ 'Elements by Blockstream' ## Appendices @@ -673,18 +612,15 @@ Definitions of terms presented here are high level and general in nature. Full m in the cited references. - **Discrete Logarithm/Discrete Logarithm Problem (DLP):** In the mathematics of real -numbers, the logarithm $ \log_b^a $ is a number $ x $ such that $ b^x=a $, for given numbers $ a $ and $ b $. + numbers, the logarithm $ \log_b^a $ is a number $ x $ such that $ b^x=a $, for given numbers $ a $ and $ b $. Analogously, in any group $ G $, powers $ b^k $ can be defined for all integers $ k $, and the discrete logarithm $ \log_ba $ is an integer $ k $ such that $ b^k=a $. Algorithms in public-key cryptography base their security on the -assumption that the discrete logarithm problem over carefully chosen cyclic finite groups and cyclic subgroups of -elliptic curves over finite fields has no efficient solution ([[2]], [[3]]). + assumption that the discrete logarithm problem over carefully chosen cyclic finite groups and cyclic subgroups of + elliptic curves over finite fields has no efficient solution ([[2]], [[3]]). -[dlp~]: #dlp -"In the mathematics of real +[dlp~]: #dlp 'In the mathematics of real numbers, the logarithm log_b(a) -is a number x such that ..." - - +is a number x such that ...' ### Appendix B: Ricardian Contracts vs. Smart Contracts @@ -700,7 +636,7 @@ a Ricardian contract are (also refer to [Figure 1](#fig_rc)): - all forms (displayed, printed and parsed) are manifestly equivalent; - signed by issuer; - can be identified securely, where security means that any attempts to change the linkage between a reference and the -contract are impractical. + contract are impractical.

@@ -715,7 +651,7 @@ Ricardian contracts are robust (due to identification by cryptographic hash func text for legal prose) and efficient (due to computer markup language to extract essential information [[30]]. A **smart contract** is “a computerized transaction protocol that executes the terms of a contract. The general objectives -are to satisfy common contractual conditions” [[12]]. With smart contracts, digital assets can be exchanged in a +are to satisfy common contractual conditions” [[12]]. With smart contracts, digital assets can be exchanged in a transparent and non-conflicting way. They provide trust. The main properties of a smart contract are: - self-executing (it doesn't run unless someone initiates it); @@ -733,9 +669,6 @@ documents or executable code ([[12]], [[30]]). The Ricardian contract design pattern has been implemented in several projects and is free of any intellectual property restrictions [[30]]. - - - ## Contributors - diff --git a/_includes/content/mining/02-MergedMiningIntroduction.md b/_includes/content/mining/02-MergedMiningIntroduction.md index d2b5ae5e..b3d07ef7 100644 --- a/_includes/content/mining/02-MergedMiningIntroduction.md +++ b/_includes/content/mining/02-MergedMiningIntroduction.md @@ -59,13 +59,13 @@ located [[25]]. ### Namecoin (#307) with Bitcoin (#1) - Namecoin, the first fork of Bitcoin, introduced merged mining with Bitcoin [[1]] from block 19,200 onwards [[3]]. At - the time of writing (May 2018), the block height of Namecoin was greater than 400,500 [[4]]. + the time of writing (May 2018), the block height of Namecoin was greater than 400,500. - Over the five-day period from 23 May 2018 to 27 May 2018, only 226 out of 752 blocks posted transaction values over - and above the block reward of 25 NMC, with an average transaction value of 159.231 NMC including the block reward. [[4]] + and above the block reward of 25 NMC, with an average transaction value of 159.231 NMC including the block reward. - Slush Pool merged mining Namecoin with Bitcoin rewards all miners with BTC equivalent to NMC via an external exchange service [[5]]. -- P2pool, Multipool, Slush Pool, Eligius and F2pool are cited as top Namecoin merged mining pools [[6]]. +- P2pool, Multipool, Slush Pool, Eligius and F2pool are cited as top Namecoin merged mining pools. | @ 2018-05-30 | Bitcoin [[16]] | Namecoin [[16]] | Ratio | | --------------------- | -------------- | --------------- | ------- | @@ -254,22 +254,11 @@ Available: . Date accessed: 2018‑05‑28. - -[4]: https://bchain.info/NMC 'Bchain.info - Blockchain Explorer (NMC)' - [[5]] "SlushPool Merged Mining" [online]. Available: . Date accessed: 2018‑05‑28. [5]: https://slushpool.com/help/first-aid/faq-merged-mining 'SlushPool Merged Mining' -[[6]] "5 Best Namecoin Mining Pools of 2018 (Comparison)" [online]. -Available: . Date accessed: 2018‑05‑28. - -[6]: https://www.prooworld.com/namecoin/best-namecoin-mining-pools '5 Best Namecoin Mining Pools -of 2018 (Comparison)' - [[7]] "Alternative Chain" [online]. Available: . Date accessed: 2018‑05‑28. diff --git a/_includes/content/network-analysis/02-byzantine_takeover_of_the_DAN.md b/_includes/content/network-analysis/02-byzantine_takeover_of_the_DAN.md index 442298eb..b77f40a5 100644 --- a/_includes/content/network-analysis/02-byzantine_takeover_of_the_DAN.md +++ b/_includes/content/network-analysis/02-byzantine_takeover_of_the_DAN.md @@ -26,15 +26,15 @@ - [Normal Distribution](#normal-distribution) - [Histogram and Visualization of Distribution](#histogram-and-visualization-of-distribution) - [Statistical Calculation](#statistical-calculation) - - [Variation of Total Nodes](#variation-of-total-nodes) - - [Variation of Byzantine Fault-tolerance Threshold](#variation-of-byzantine-fault-tolerance-threshold) - - [Variation of Total Number of Nodes with Committee Size 10](#variation-of-total-number-of-nodes-with-committee-size-10) - - [Variation of Total Number of Nodes with Committee Size 100](#variation-of-total-number-of-nodes-with-committee-size-100) - - [Variation of Bad Nodes with Committee Size 10 and 100](#variation-of-bad-nodes-with-committee-size-10-and-100) + - [Variation of Total Nodes](#variation-of-total-nodes) + - [Variation of Byzantine Fault-tolerance Threshold](#variation-of-byzantine-fault-tolerance-threshold) + - [Variation of Total Number of Nodes with Committee Size 10](#variation-of-total-number-of-nodes-with-committee-size-10) + - [Variation of Total Number of Nodes with Committee Size 100](#variation-of-total-number-of-nodes-with-committee-size-100) + - [Variation of Bad Nodes with Committee Size 10 and 100](#variation-of-bad-nodes-with-committee-size-10-and-100) - [Conclusions and Remarks](#conclusions-and-remarks) - [References](#references) - [Appendices](#appendices) - - [Appendix A: Definitions of Terms](#appendix-a-definitions-of-terms) + - [Appendix A: Definitions of Terms](#appendix-a-definitions-of-terms) - [Contributors](#contributors) ## Introduction @@ -44,8 +44,8 @@ environment. It covers probabilistic attack vector with regard to the total node Byzantine Fault-tolerance (BFT) threshold. The investigation attempts to answer the following question: -*What is the percentage chance of controlling the majority of nodes in a random sample with varying quantities of the total -number of nodes, committee size, bad nodes and BFT threshold?* +_What is the percentage chance of controlling the majority of nodes in a random sample with varying quantities of the total +number of nodes, committee size, bad nodes and BFT threshold?_ ## Tari Digital Assets Network @@ -91,7 +91,7 @@ node bootstrapping process is as follows: - The process continues until the joining node is unable to locate any closer nodes. This -*self-lookup* has two effects: +_self-lookup_ has two effects: - it allows the node to learn about nodes closer to itself; and - it populates other nodes' @@ -153,7 +153,7 @@ In each graph, the cumulative probabilities calculated for normal, uniform, Pois plotted against the number of experiments. The bold blue line represents the mean calculated from theoretical data. In the first graph, where the experiments and draws are equal to $10$, there is weak convergence. In the second graph, where the -experiments and draws are equal to $1,000$, the Law of Large Numbers (LLN) is proved; as the sample size grows, convergence +experiments and draws are equal to $1,000$, the Law of Large Numbers (LLN) is proved; as the sample size grows, convergence with the statistical mean is achieved. #### Individual Probabilities @@ -172,10 +172,10 @@ not returned to the pool of total nodes. ##### Uniform Distribution -| Statistical Information | | Comparison with
Theoretical Mean |   Difference Calculated | -| ----------------------- | -------------------- | -------------------------------------- | ---------------------------------- | -| Intercept | 0.6497887492507493 | 0.649474335188621 | 3.14414E-4 | -| Standard Deviation | 0.015438728229013219 | | | +| Statistical Information | | Comparison with
Theoretical Mean |   Difference Calculated | +| ----------------------- | -------------------- | -------------------------------------- | --------------------------------- | +| Intercept | 0.6497887492507493 | 0.649474335188621 | 3.14414E-4 | +| Standard Deviation | 0.015438728229013219 | | | ##### Hypergeometric Distribution @@ -248,7 +248,6 @@ The above graph was calculated using Python ([variations of N](https://github.co | 100 | 60 | 14 | 10 | 0.2623321970180976 | | 100 | 60 | 15 | 10 | 0.39288184738975973 | -

From a plot of committee size versus probability with a change in $N$, the total number of nodes, it can be seen that the probability is lower with respect to the committee size when $N$ is smaller. @@ -257,10 +256,10 @@ the probability is lower with respect to the committee size when $N$ is smaller. The variables and results are below: - - N (total number of nodes in the network) = $100$ - - m (number of bad actors) = $60$% of N - - T (BFT threshold) = $50$%, $55$%, $60$%, $67$% of N - - n (committee size) = ranging from $1$ to $100$ +- N (total number of nodes in the network) = $100$ +- m (number of bad actors) = $60$% of N +- T (BFT threshold) = $50$%, $55$%, $60$%, $67$% of N +- n (committee size) = ranging from $1$ to $100$

@@ -339,7 +338,7 @@ probability plateaus is used to construct the following graph for both committee The above graph was calculated using Excel ([bad node percentage at 10 and 100](https://github.com/tari-labs/modelling/blob/master/other/bad_node_percentage_10_100.xlsx)). The -graph shows changes in the probability due to changes in percentage of bad nodes when the committee size is $10$ and $100$. When +graph shows changes in the probability due to changes in percentage of bad nodes when the committee size is $10$ and $100$. When the committee size is $10$, there is a change in probability when the bad node percentage is between $30$ and $80$. When the committee size is $100$, there is a steep increase in the probability when the bad node percentage is between $50$ and $80$. When the committee size is $100$, the probability remains lower as the bad node percentage increases and @@ -354,39 +353,35 @@ distributions of nodes within the network illustrated. With regard to the statistical calculation, comments can be made for each of the varied parameters. - Total nodes in the network: The smaller the pool of total nodes in the network, the lower the probability of bad -actors controlling the network. However, the probability difference is near negligible if the committee size is large. -This parameter will also be difficult to control, and the network will be ever-increasing. This can be seen in the -graph in [Variation of Total Nodes](#variation-of-total-nodes). -- BFT threshold: This threshold should be at least $\frac{2}{3} \cdot n+1$ as per literature. This can be seen in the -graph in [Variation of Byzantine Fault-tolerance Threshold](#variation-of-byzantine-fault-tolerance-threshold). + actors controlling the network. However, the probability difference is near negligible if the committee size is large. + This parameter will also be difficult to control, and the network will be ever-increasing. This can be seen in the + graph in [Variation of Total Nodes](#variation-of-total-nodes). +- BFT threshold: This threshold should be at least $\frac{2}{3} \cdot n+1$ as per literature. This can be seen in the + graph in [Variation of Byzantine Fault-tolerance Threshold](#variation-of-byzantine-fault-tolerance-threshold). - Committee size: The larger the committee size, the lower the probability of bad actors controlling the network. This can -be seen in the graph in -[Variation of Total Number of Nodes with Committee Size 10](#variation-of-total-number-of-nodes-with-committee-size-10) -and [Variation of Total Number of Nodes with Committee Size 100](#variation-of-total-number-of-nodes-with-committee-size-100). + be seen in the graph in + [Variation of Total Number of Nodes with Committee Size 10](#variation-of-total-number-of-nodes-with-committee-size-10) + and [Variation of Total Number of Nodes with Committee Size 100](#variation-of-total-number-of-nodes-with-committee-size-100). - Bad nodes: While this variable cannot be controlled, the probability of bad actors controlling the network can remain -low, as the percentage of bad nodes increases if the committee size is approximately $100$ or larger. This can be seen in the -graphs in [Variation of Bad Nodes with Committee Size 10 and 100](#variation-of-bad-nodes-with-committee-size-10-and-100) - - + low, as the percentage of bad nodes increases if the committee size is approximately $100$ or larger. This can be seen in the + graphs in [Variation of Bad Nodes with Committee Size 10 and 100](#variation-of-bad-nodes-with-committee-size-10-and-100) ## References -[[1]] C. Sharrock [online]. Available: . +[[1]] C. Sharrock [online]. Available: . Date accessed: 2019‑07‑18. -[1]: https://rfc.tari.com/RFC-0300_DAN.html -"Tari RFC" +[1]: https://rfc.tari.com/RFCD-0300_DAN.html 'Tari RFC' [[2]] P. Maymounkov and D. Mazières, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric" [online]. Available: . Date accessed: 2019‑07‑18. -[2]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf "Kademlia" +[2]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf 'Kademlia' [[3]] S. Bondi, "Distributed Hash Tables" [online]. Available: . Date accessed: 2019‑07‑18. -[3]: https://tlu.tarilabs.com/protocols/dht/MainReport.html -"Distributed Hash Tables" +[3]: https://tlu.tarilabs.com/protocols/dht/MainReport.html 'Distributed Hash Tables' ## Appendices @@ -395,19 +390,17 @@ Date accessed: 2019‑07‑18. Definitions of terms presented here are high level and general in nature. - **Asset Issuer (AI):** An entity that creates digital assets on the Tari Digital Asset Network (DAN). The Asset Issuer will -specify the parameters of the contract template that defines the rules that govern the asset and the number and nature -of its constituent tokens on issuance. The AI will, generally, be the initial owner of the tokens [[1]]. + specify the parameters of the contract template that defines the rules that govern the asset and the number and nature + of its constituent tokens on issuance. The AI will, generally, be the initial owner of the tokens [[1]]. -[ai~]: #ai -" An entity that creates -digital assets..." +[ai~]: #ai ' An entity that creates +digital assets...' - **Validator Node (VN):** Validator nodes make up the Tari second layer, or Digital Asset Network (DAN). VNs -are responsible for creating and updating digital asset living on the Tari network [[1]]. + are responsible for creating and updating digital asset living on the Tari network [[1]]. -[vn~]: #vn -" Validator nodes make up -the Tari second layer..." +[vn~]: #vn ' Validator nodes make up +the Tari second layer...' ## Contributors diff --git a/_includes/content/protocols/02-mimblewimble-transactions-explained.md b/_includes/content/protocols/02-mimblewimble-transactions-explained.md index c7217a2b..4ded9b13 100644 --- a/_includes/content/protocols/02-mimblewimble-transactions-explained.md +++ b/_includes/content/protocols/02-mimblewimble-transactions-explained.md @@ -13,15 +13,14 @@ - [References](#references) - [Contributors](#contributors) - ## High-level Overview Mimblewimble is a privacy-oriented, cryptocurrency technology. It differs from Bitcoin in some key areas: -* No addresses. The concept of Mimblewimble addresses does not exist. -* Completely private. Every transaction is confidential. -* Compact blockchain. Mimblewimble uses a different set of security guarantees to Bitcoin, which leads to a far more -compact blockchain. +- No addresses. The concept of Mimblewimble addresses does not exist. +- Completely private. Every transaction is confidential. +- Compact blockchain. Mimblewimble uses a different set of security guarantees to Bitcoin, which leads to a far more + compact blockchain. ## Transactions Explained @@ -35,7 +34,6 @@ This doesn't necessarily mean that recipients have to be online. However, they d whether it be by email, Instant Messaging (IM) or carrier pigeon. - ### Basic Transaction We'll explain how Alice can send Tari to Bob using a two-party protocol for Mimblewimble. Multiparty transactions are @@ -45,10 +43,10 @@ Let's say Alice has 300 µT and she wants to send 200 µT to Bob. Here’s the basic transaction: -| Inputs | Outputs | | | -|:-------------|:------- |:-------|:-----| -| 300 | 200 | 90 | 10 | -| Alice's UTXO | To Bob | Change | fee | +| Inputs | Outputs | | | +| :----------- | :------ | :----- | :-- | +| 300 | 200 | 90 | 10 | +| Alice's UTXO | To Bob | Change | fee | If we write this as a mathematical equation, where outputs are positive and inputs are negative, we should be able to balance things out so that there's no creation of coins out of thin air: @@ -79,7 +77,6 @@ reasonable values of _n_ and scan the blockchain for those public keys?[^a] In short, _yes_. So we’re not done yet. - [^a]: "This is called a pre-image attack." ### Blinding Factors @@ -99,17 +96,16 @@ The two generators, _H_ and _G_ must be selected in a way that it's impossible t the other [[2]]. Specifically, if _G_ is the base generator, then there exists some _k_ where $ H = kG $.
If anyone is able to figure out this _k_, the whole security of Confidential Transactions falls apart. It's left as an exercise for the reader to figure out why.
For a semi-gentle introduction to these concepts, Adam Gibson's paper on the subject is excellent [[5]]. - ### Alice Prepares a Transaction Alice can now start to build a transaction. | Type | Formula | Name | -|:--------------|:------------------------|:-----| +| :------------ | :---------------------- | :--- | | Input | $$ -300.H - k_1.G $$ | C1 | | Change output | $$ 90.H + k_2.G $$ | C2 | | Fee | $$ 10.H + 0.G $$ | f | -| Total spent | $$ 200.H + 0.G $$ | C* | +| Total spent | $$ 200.H + 0.G $$ | C\* | | _Sum_ | $$ 0.H + (k_2-k_1).G $$ | X | The \\( k_i \\)-values, \\(k_1, k_2\\) are the spending keys for those outputs. @@ -165,7 +161,7 @@ $$ R_a = r_a.G $$ Alice then sends the following information to Bob: | Field | Value | -|:-------------------|:----------| +| :----------------- | :-------- | | Inputs | C1 | | Outputs | C2 | | Fee | 10 | @@ -206,7 +202,7 @@ $$ s_b = r_b + ek_b $$ Bob sends back | Field | Value | -|:------------------------------------|:--------| +| :---------------------------------- | :------ | | Output (commitment and range proof) | $$C_b$$ | | Public nonce | $$R_b$$ | | Signature | $$s_b$$ | @@ -228,15 +224,15 @@ and the combined aggregate signature, $$ s = s_a + s_b, R = R_a + R_b $$. Alice can now broadcast this transaction to the network. The final transaction looks as follows: -| Transaction Kernel | | -|:--------------------------|:---------------| -| Public excess | $$ X + P_b $$ | -| Signature | $$ (s, R) $$ | -| Fee | 10 | -| Transaction metadata | m | +| Transaction Kernel | | +| :------------------- | :------------ | +| Public excess | $$ X + P_b $$ | +| Signature | $$ (s, R) $$ | +| Fee | 10 | +| Transaction metadata | m | | Transaction Body | | -|:--------------------------|:---------------| +| :------------------------ | :------------- | | Inputs with range proofs | $$[C_1]$$ | | Outputs with range proofs | $$[C_2, C_B]$$ | @@ -265,7 +261,7 @@ peers. The node wants to check the following: The summed public nonces, _R_ are also stored in the kernel, so this allows the node to verify the signature by checking the following, where the challenge _e_ is calculated as before: -$$ s.G \stackrel{?}{=} R + e(X + P_b) $$ +$$ s.G \stackrel{?}{=} R + e(X + P_b) $$ 4. The signature in the kernel is valid @@ -280,7 +276,7 @@ be added to the blockchain. ## Stopping Fraud -Now let's say Alice tried to be sneaky and used \\( X^* \\) as her excess; the one where she gave herself 100 µT change +Now let's say Alice tried to be sneaky and used \\( X^\* \\) as her excess; the one where she gave herself 100 µT change instead of 90 µT. Now the values won't balance. The sum of outputs, inputs and fees will look something like this: $$ 10.H + (x_s + k_b).G ​$$ @@ -303,37 +299,42 @@ up, and so it will just drop the transaction silently and get on with its life. To sum up: a Tari/MimbleWimble transaction includes the following: -* From Alice, a set of inputs that reference and spend a set of previous outputs. -* From Alice and Bob, a set of new outputs, including: - * A value and a blinding factor (which is just a new private key). - * A range proof that shows that the value is non-negative. -* The transaction fee, in cleartext, -* The public excess, which is the sum of all blinding factors used in the transaction. -* Transaction metadata. -* The excess blinding value used as the private key to sign a message attesting to the transaction metadata, and the +- From Alice, a set of inputs that reference and spend a set of previous outputs. +- From Alice and Bob, a set of new outputs, including: + - A value and a blinding factor (which is just a new private key). + - A range proof that shows that the value is non-negative. +- The transaction fee, in cleartext, +- The public excess, which is the sum of all blinding factors used in the transaction. +- Transaction metadata. +- The excess blinding value used as the private key to sign a message attesting to the transaction metadata, and the public excess. ## References -[1]: https://www.mycryptopedia.com/what-are-confidential-transactions/ "What are Bitcoin Confidential Transactions?" +[1]: https://www.mycryptopedia.com/what-are-confidential-transactions/ 'What are Bitcoin Confidential Transactions?' + [[1]] "What are Bitcoin Confidential Transactions?" [Online.] Available: Date accessed: 2019‑04‑09. -[2]: https://en.wikipedia.org/w/index.php?title=Nothing-up-my-sleeve_number&oldid=889582749 "Nothing-Up-My_Sleeve Number" +[2]: https://en.wikipedia.org/w/index.php?title=Nothing-up-my-sleeve_number&oldid=889582749 'Nothing-Up-My_Sleeve Number' + [[2]] "Nothing-Up-My_Sleeve Number" [online].
Available: . Date accessed: 2019‑04‑09. -[3]: https://en.wikipedia.org/wiki/Commitment_scheme "Commitment Scheme" +[3]: https://en.wikipedia.org/wiki/Commitment_scheme 'Commitment Scheme' + [[3]] Wikipedia: "Commitment Scheme" [online]. Available: . Date accessed: 2019‑04‑09. -[4]: https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets "Kernel Offsets" +[4]: https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets 'Kernel Offsets' + [[4]] "Kernel Offsets, in Introduction to MimbleWimble and Grin" [online]. Available: . Date accessed: 2019‑04‑09. -[5]: https://joinmarket.me/static/FromZK2BPs_v1.pdf "From Zero (Knowledge) to BulletProofs" +[5]: https://moodle.unige.ch/pluginfile.php/309148/mod_folder/content/0/From%20zero%20knowledge%20to%20bulletproofs%20-%20Gibson.pdf 'From Zero (Knowledge) to BulletProofs' + [[5]] A. Gibson, "From Zero (Knowledge) to BulletProofs" [online]. -Available: . +Available: . Date accessed: 2019‑04‑10. ## Contributors diff --git a/_includes/content/protocols/03-grin-protocol-overview.md b/_includes/content/protocols/03-grin-protocol-overview.md index abb0a516..052ad91a 100644 --- a/_includes/content/protocols/03-grin-protocol-overview.md +++ b/_includes/content/protocols/03-grin-protocol-overview.md @@ -19,8 +19,6 @@ - [Appendix A: Example of Grin Block](#appendix-a-example-of-grin-block) - [Contributors](#contributors) - - ## Introduction Depending on whom you ask, Mimblewimble is either a tongue-tying curse or a blockchain protocol designed to be private @@ -30,8 +28,6 @@ on the tor network describing how Mimblewimble could work. As the potential for this a reality. One of these projects is Grin, which is a minimalistic implementation of Mimblewimble. Further information can be found in [[2]] and [[3]]. - - ## Mimblewimble Protocol Overview ### Commitments @@ -39,30 +35,30 @@ information can be found in [[2]] and [[3]]. Mimblewimble publishes all transactions as confidential transactions. All inputs, outputs and change are expressed in the following form: -​ $ r \cdot G + v \cdot H $ +​ $ r \cdot G + v \cdot H $ where $ G $ and $ H $ are elliptic curves, $ r $ a private key used as a blinding factor, $ v $ the value and -"$ \cdot $" is Elliptic-curve cryptography (ECC) multiplication. +"$ \cdot $" is Elliptic-curve cryptography (ECC) multiplication. An example transaction can be expressed as input = output + change. -​ $ (r_i \cdot G + v_i \cdot H) = (r_o \cdot G + v_o \cdot H) + (r_c \cdot G + v_c + \cdot H) $ +​ $ (r_i \cdot G + v_i \cdot H) = (r_o \cdot G + v_o \cdot H) + (r_c \cdot G + v_c + \cdot H) $ But this requires that -​ $ r_i = r_o + r_c $ +​ $ r_i = r_o + r_c $ A more detailed explanation of how Mimblewimble works can be found in the Grin GitHub documents [[4]]. ### Cut-through and Pruning -#### Cut-through +#### Cut-through Grin includes something called "cut-through" in the transaction pool. Cut-through removes outputs from the transaction pool, which have already been spent as new inputs, using the fact that every transaction in a block should sum to zero. This is shown below: -​ $ output - inputs = kernel_-excess +(part \mspace{3mu} of)kernel_- offset $ +​ $ output - inputs = kernel*-excess +(part \mspace{3mu} of)kernel*- offset $ The kernel offset is used to hide which kernel belongs to which transaction and we only have a summed kernel offset stored in the header of each block. @@ -70,7 +66,7 @@ stored in the header of each block. We don't have to record these transactions inside the block, although we still have to record the kernel as the kernel proof transfer of ownership to make sure that the whole block sums to zero, as expressed in the following formula: -​ $ sum(ouputs) - sum(inputs) = sum(kernel_-excess) + kernel_-offset $ +​ $ sum(ouputs) - sum(inputs) = sum(kernel*-excess) + kernel*-offset $ An example of cut-through follows: @@ -99,7 +95,7 @@ This causes Mimblewimble blocks to be much smaller than normal bitcoin blocks, a no longer listed under inputs and outputs. In practice, after this we can still see there was a transaction, because the kernel excess still remains, but the actual hidden values are not recorded. -#### Pruning +#### Pruning Pruning takes this same concept but goes into past blocks. Therefore, if an output in a previous block gets spent, it will be removed from that block. Pruning removes the leaves from the Merkle Mountain Range (MMR) as well. Thus, it @@ -150,8 +146,6 @@ The Grin header: The rest of the block contains a list of kernels, inputs and outputs. [Appendix A](#appendix-a-example-of-grin-block) contains an example of a grin block. - - ## Trustless Transactions Schnorr signatures have been done in Tari Labs University (TLU). Please look @@ -166,39 +160,38 @@ When Alice wants to pay Bob, the transaction will be performed using the followi 1. Alice selects her inputs and her change. The sum of all blinding factors (change output minus inputs) is $ r_s $. 2. Alice picks a random nonce ks and sends her partial transaction, $ k_s\cdot G $ and $ r_s\cdot G $ to Bob. 3. Bob picks his own random nonce $ k_r $ and the blinding factor for his output $ r_r $. Using $ r_r $, Bob adds his - output to the transaction. + output to the transaction. 4. Bob computes the following: - - message $ m = fee \Vert lock_-height $; - - Schnorr challenge $ e = SHA256(m \Vert k_r \cdot G + k_s\cdot G \Vert r_r\cdot G + r_s\cdot G) $; and + - message $ m = fee \Vert lock\_-height $; + - Schnorr challenge $ e = SHA256(m \Vert k_r \cdot G + k_s\cdot G \Vert r_r\cdot G + r_s\cdot G) $; and - his side of the signature, $ s_r = k_r + e\cdot G $. -5. Bob sends $ s_r $ and $ k_r\cdot G $ and $ r_r\cdot G $ to Alice. +5. Bob sends $ s_r $ and $ k_r\cdot G $ and $ r_r\cdot G $ to Alice. 6. Alice computes $ e $, just like Bob did, and can check that $ s_r\cdot G = k_r\cdot G + e\cdot r_r \cdot G $. 7. Alice sends her side of the signature, $ s_s = k_s + e\cdot r_s $, to Bob. 8. Bob validates $ s_s\cdot G $, just like Alice did for $ s_r\cdot G $ in step 5, and can produce the final signature $ sig = (s_s + s_r , \mspace{6mu} k_s\cdot G + k_s\cdot G) $ as well as the final transaction kernel, including $ sig $ and the public key - $ r_r\cdot G + r_s\cdot G$. - + $ r_r\cdot G + r_s\cdot G$. ## Contracts ### Time-locked -#### Absolute +#### Absolute In a normal Grin transaction, the signature [[4]], just the normal fee, gets signed as the message. But to get an absolute time-locked transaction, the message can be modified taking the block height and appending the fee to that. A block with a kernel that includes a lock height greater than the current block height is then rejected. -​ $ m = fee \Vert h $ +​ $ m = fee \Vert h $ -#### Relative +#### Relative Taking into account how an absolute time-locked transaction is constructed, the same idea can be extended by taking the relative block height and not the absolute height, but also adding a specific kernel commitment. In this way, the signature references a specific block as height. The same principle counts as with absolute time-locked transactions in that a block with a kernel containing a relative time-locked transaction that has not passed, is rejected. -​ $ m = fee \Vert h \Vert c $ +​ $ m = fee \Vert h \Vert c $ ### Multisig @@ -210,13 +203,13 @@ steps: 1. Bob picks a blinding factor $ r_b $ and sends $ r_b\cdot G $ to Alice. 2. Alice picks a blinding factor $ r_a $ and builds the commitment $ C= r_a\cdot G + r_b\cdot G + v\cdot H $; she -sends the commitment to Bob. + sends the commitment to Bob. 3. Bob creates a range proof for $ v $ using $ C $ and $ r_b $, and sends it to Alice. -4. Alice generates her own range proof and aggregates it with Bob, finalizing the multiparty output $ O_{ab} $. +4. Alice generates her own range proof and aggregates it with Bob, finalizing the multiparty output $ O\_{ab} $. 5. The kernel is built following the same procedure as used with [Trustless Transactions](#trustless-transactions). -We observe that the output $ O_{ab} $ is unknown to both parties, because neither knows the whole blinding factor. To be -able to build a transaction spending $ O_{ab} $, someone would need to know $ r_a + r_b $ to produce a kernel +We observe that the output $ O*{ab} $ is unknown to both parties, because neither knows the whole blinding factor. To be +able to build a transaction spending $ O*{ab} $, someone would need to know $ r_a + r_b $ to produce a kernel signature. To produce the original spending kernel, Alice and Bob need to collaborate. ## Atomic Swaps @@ -243,13 +236,13 @@ to Bob and execute the swap, Alice and Bob start as if they were building a norm 1. Alice picks a random nonce $ k_s $ and her blinding sum $ r_s $ and sends $ k_s\cdot G $ and $ r_s\cdot G $ to Bob. 2. Bob picks a random blinding factor $ r_r $ and a random nonce $ k_r $. However, this time, instead of simply sending $ s_r = k_r + e\cdot r_r $ with his $ r_r\cdot G $ and $ k_r\cdot G $, Bob sends $ s_r' = k_r + x + e\cdot r_r $ as -well as $ x\cdot G $. + well as $ x\cdot G $. 3. Alice can validate that $ s_r'\cdot G = k_r\cdot G + x\cdot G + r_r\cdot G $. She can also check that Bob has money -locked with $ x\cdot G $ on the other chain. + locked with $ x\cdot G $ on the other chain. 4. Alice sends back her $ s_s = k_s + e\cdot x_s $ as she normally would, now that she can also compute -$ e = SHA256(m \Vert k_s\cdot G+k_r\cdot G) $. + $ e = SHA256(m \Vert k_s\cdot G+k_r\cdot G) $. 5. To complete the signature, Bob computes $ s_r = k_r + e\cdot r_r $ and the final signature is -$ (s_r + s_s, \mspace{6mu} k_r\cdot G + k_s\cdot G) $. + $ (s_r + s_s, \mspace{6mu} k_r\cdot G + k_s\cdot G) $. 6. As soon as Bob broadcasts the final transaction to get his Grin, Alice can compute $ s_r' - s_r $ to get $ x $. Prior to completing the atomic swap, Bob needs to know Alice's public key. Bob would then create an output on the @@ -265,119 +258,105 @@ to spend the 2‑of‑2, having both private keys, and get her bitcoin. ## References -[[1]] G. Maxwell, "Confidential Transactions", 2017 [online]. Available: +[[1]] G. Maxwell, "Confidential Transactions", 2017 [online]. Available: . Accessed: 2018‑10‑24. -[1]: https://people.xiph.org/~greg/confidential_values.txt -"Original confidential transaction paper" +[1]: https://people.xiph.org/~greg/confidential_values.txt 'Original confidential transaction paper' [[2]] P. Robinson, H. Odendaal, S. W. van Heerden and A. Zaidelson, "Grin vs. BEAM, a Comparison", 2018 [online]. -Available: . +Available: . Accessed: 2018‑10‑08. -[2]: https://tari-labs.github.io/tari-university/protocols/grin-beam-comparison/MainReport.html#grin-vs-beam-a-comparison -"Grin vs. BEAM, a Comparison" +[2]: https://tlu.tarilabs.com/protocols/grin-vs-beam-comparison 'Grin vs. BEAM, a Comparison' [[3]] Y. Roodt, H. Odendaal, S. W. van Heerden, R. Robinson and A. Kamal, "Grin Design Choice Criticisms - Truth or Fiction", 2018 [online]. Available: -. +. Accessed: 2018‑10‑08. -[3]: https://tari-labs.github.io/tari-university/protocols/grin-design-choice-criticisms/MainReport.html -"Grin Design Choice Criticisms" +[3]: https://tlu.tarilabs.com/protocols/grin-design-choice-algorithms 'Grin Design Choice Criticisms' [[4]] B. Simon et al., "Grin Document Structure", 2018 [online]. Available: . Accessed: 2018‑10‑24). -[4]: https://github.com/mimblewimble/grin/blob/master/doc/table_of_contents.md -"Main Grin Document Structure" +[4]: https://github.com/mimblewimble/grin/blob/master/doc/table_of_contents.md 'Main Grin Document Structure' [[5]] I. Peverell et al., "Pruning Blockchain Data", 2016 [online]. Available: . Accessed: 2018‑10‑26. -[5]: https://github.com/mimblewimble/grin/blob/master/doc/pruning.md -"Grin Pruning" +[5]: https://github.com/mimblewimble/grin/blob/master/doc/pruning.md 'Grin Pruning' [[6]] I. Peverell et al., "Contracts", 2018 [online]. Available: . Accessed: 2018‑10‑26. -[6]: https://github.com/mimblewimble/grin/blob/master/doc/contracts.md -"Grin Contracts" +[6]: https://github.com/mimblewimble/grin/blob/master/doc/contracts.md 'Grin Contracts' -[[7]] "Tari Labs University". Tari Labs, 2018 [online]. Available: . +[[7]] "Tari Labs University". Tari Labs, 2018 [online]. Available: . Accessed: 2018‑10‑27. -[7]: https://tari-labs.github.io/tari-university/ -"Tari Labs University" +[7]: https://tlu.tarilabs.com/ 'Tari Labs University' [[8]] Q. Le Sceller, "Contract Ideas", 2018 [online]. Available: . (Accessed: 2018‑10‑27.) -[8]: https://github.com/mimblewimble/grin/blob/master/doc/contract_ideas.md -"Grin Contract Ideas Discussion Document" +[8]: https://github.com/mimblewimble/grin/blob/master/doc/contract_ideas.md 'Grin Contract Ideas Discussion Document' [[9]] Jasper, "First Grin Atomic Swap!" (2018) [online]. Available: . Accessed: 2018‑10‑27. -[9]: https://medium.com/grinswap/first-grin-atomic-swap-a16b4cc19196 -"First ever Grin atomic swap" - - +[9]: https://medium.com/grinswap/first-grin-atomic-swap-a16b4cc19196 'First ever Grin atomic swap' ## Appendices ### Appendix A: Example of Grin Block | Hash | 02cb5e810857266609511699c8d222ed4e02883c6b6d3405c05a3caea9bb0f64 | -| ------------------- | ------------------------------------------------------------ | -| Version | 1 | -| Previous Block | [0343597fe7c69f497177248913e6e485f3f23bb03b07a0b8a5b54f68187dbc1d](https://grinexplorer.net/block/0343597fe7c69f497177248913e6e485f3f23bb03b07a0b8a5b54f68187dbc1d) | -| Age | 2018-10-23, 08:03:46 UTC | -| Cuckoo Solution | Size: | -| Difficulty | 37,652 | -| Target Difficulty | 17,736 | -| Total Difficulty | 290,138,524 | +| ------------------- | ---------------------------------------------------------------- | +| Version | 1 | +| Previous Block | 0343597fe7c69f497177248913e6e485f3f23bb03b07a0b8a5b54f68187dbc1d | +| Age | 2018-10-23, 08:03:46 UTC | +| Cuckoo Solution | Size: | +| Difficulty | 37,652 | +| Target Difficulty | 17,736 | +| Total Difficulty | 290,138,524 | | Total Kernel Offset | b52ccdf119fe18d7bd12bcdf0642fcb479c6093dca566e0aed33eb538f410fb5 | -| Nonce | 7262225957146290317 | -| Block Reward | 60 grin | -| Fees | 14 mg | +| Nonce | 7262225957146290317 | +| Block Reward | 60 grin | +| Fees | 14 mg | `4 x Inputs` -| No. | Commit | -| ---- | ------------------------------------------------------------------ | -| 1 | 0898a4b53964ada66aa16de3d44ff02228c168a23c0bd71b162f4366ce0dae24b0 | -| 2 | 09a173023e9c39c923e626317ffd384c7bce44109fea91a9c142723bfa700fce27 | -| 3 | 086e0d164fe92d837b5365465a6b37af496a4f8520a2c1fccbb9f736521631ba96 | -| 4 | 087a00d61f8ada399f170953c6cc7336c6a0b22518a8b02fd8dd3e28c01ee51fdb | +| No. | Commit | +| --- | ------------------------------------------------------------------ | +| 1 | 0898a4b53964ada66aa16de3d44ff02228c168a23c0bd71b162f4366ce0dae24b0 | +| 2 | 09a173023e9c39c923e626317ffd384c7bce44109fea91a9c142723bfa700fce27 | +| 3 | 086e0d164fe92d837b5365465a6b37af496a4f8520a2c1fccbb9f736521631ba96 | +| 4 | 087a00d61f8ada399f170953c6cc7336c6a0b22518a8b02fd8dd3e28c01ee51fdb | `5 x Outputs` - -| No. | Output Type |Commit | Spent | -| ---- | ---------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------- | -| 1 | Transaction |09eac33dfdeb84da698c6c17329e4a06020238d9bb31435a4abd9d2ffc122f6879|False| -| 2 | Transaction |0860e9cf37a94668c842738a5acc8abd628c122608f48a50bbb7728f46a3d50673|False| -| 3 | Coinbase |08324cdbf7443b6253bb0cdf314fce39117dcafbddda36ed37f2c209fc651802d6|False| -| 4 | Transaction |0873f0da4ce164e2597800bf678946aad1cd2d7e2371c4eed471fecf9571942b4f|False| -| 5 | Transaction |09774ee77edaaa81b3c6ee31f471f014db86c4b3345f739472cb12ecc8f40401df|False| +| No. | Output Type | Commit | Spent | +| --- | ----------- | ------------------------------------------------------------------ | ----- | +| 1 | Transaction | 09eac33dfdeb84da698c6c17329e4a06020238d9bb31435a4abd9d2ffc122f6879 | False | +| 2 | Transaction | 0860e9cf37a94668c842738a5acc8abd628c122608f48a50bbb7728f46a3d50673 | False | +| 3 | Coinbase | 08324cdbf7443b6253bb0cdf314fce39117dcafbddda36ed37f2c209fc651802d6 | False | +| 4 | Transaction | 0873f0da4ce164e2597800bf678946aad1cd2d7e2371c4eed471fecf9571942b4f | False | +| 5 | Transaction | 09774ee77edaaa81b3c6ee31f471f014db86c4b3345f739472cb12ecc8f40401df | False | `3 x Kernels` -| No. | Features |Fee | Lock Height | -| ---- | ---------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------- | -| 1 | DEFAULT_KERNEL |6 mg|7477| -| 2 | DEFAULT_KERNEL |8 mg|7477| -| 3 | COINBASE_KERNEL |0 grin|7482| +| No. | Features | Fee | Lock Height | +| --- | --------------- | ------ | ----------- | +| 1 | DEFAULT_KERNEL | 6 mg | 7477 | +| 2 | DEFAULT_KERNEL | 8 mg | 7477 | +| 3 | COINBASE_KERNEL | 0 grin | 7482 | Apart from the header information, we can only see that this block contains two transactions from the two kernels present. Between these two transactions, we only know that there were four inputs and four outputs. Because of the way in which Mimblewimble obfuscates the transaction, we don't know the values or which input and output belong to which transaction. - - ## Contributors - diff --git a/_includes/content/protocols/04-grin-vs-beam-comparison.md b/_includes/content/protocols/04-grin-vs-beam-comparison.md index 5e6f8ee2..4985e65d 100644 --- a/_includes/content/protocols/04-grin-vs-beam-comparison.md +++ b/_includes/content/protocols/04-grin-vs-beam-comparison.md @@ -410,9 +410,9 @@ Date accessed: 2018‑09‑30. [23]: https://www.grin-forum.org/t/meeting-notes-governance-sep-25-2018/874 'Meeting Notes: Governance, Sep 25 2018' -[[24]] "BEAM Features" [online]. Available: . Date accessed: 2018‑09‑30. +[[24]] "BEAM Features" [online]. Available: . Date accessed: 2018‑09‑30. -[24]: https://www.beam-mw.com/features 'BEAM Features' +[24]: https://www.beam.mw 'BEAM Features' [[25]] "Grin's Community Funding Principles" [online]. Available: . Date accessed: 2018‑09‑28. diff --git a/_includes/content/protocols/05-grin-design-choice-algorithms.md b/_includes/content/protocols/05-grin-design-choice-algorithms.md index 3b3c60c9..86a1cb7b 100644 --- a/_includes/content/protocols/05-grin-design-choice-algorithms.md +++ b/_includes/content/protocols/05-grin-design-choice-algorithms.md @@ -9,8 +9,6 @@ - [References](#references) - [Contributors](#contributors) - - ## Introduction Grin is a cryptocurrency, implemented in Rust, that makes use of Mimblewimble transactions and the Cuckatoo algorithm to @@ -23,7 +21,7 @@ and determine if there is any truth to these concerns, or if they are unwarrante will be made as to how these problems could be mitigated or addressed. This report will also investigate Grin's selected emission scheme, PoW algorithm, choice of cryptographic curve used for - signatures, and selection of key-store library. Each of these topics will be discussed in detail. +signatures, and selection of key-store library. Each of these topics will be discussed in detail.

@@ -71,7 +69,7 @@ that a high inflation rate will produce natural pricing and limit price manipula Most economists for traditional fiat systems agree that deflation is bad, as it increases debt; and some inflation is good, as it stimulates the economy of a country [[9]]. With inflation, the purchasing power of savings decreases over time. This encourages the purchasing of goods and services, resulting in the currency being used as an MoE rather than -as an SoV. People with debt such as study loans, vehicle loans and home loans also benefit from inflation, as it +as an SoV. People with debt such as study loans, vehicle loans and home loans also benefit from inflation, as it produces an eroding effect on the total debt for long periods of repayment. Currently, this benefit does not apply to cryptocurrencies, as not much debt exists. This is because it is difficult to maintain successful borrower-lender relationships due to the anonymous nature of cryptocurrencies [[10]]. @@ -97,7 +95,6 @@ currency. A low inflationary model where inflation is algorithmically maintained authority seems to be the safest choice. However, only time will tell if the high inflation model proposed by Grin will have the desired effect. - ## Proof-of-Work Algorithm - from ASIC Resistant to ASIC Friendly Initially, the Grin team proposed using two Application-Specific Integrated Circuit (ASIC) resistant algorithms: @@ -139,7 +136,6 @@ Selecting to be ASIC resistant or ASIC friendly is an important decision that ca The Grin team's choice to support the ASIC community and try to balance an ASIC-friendly and an ASIC-resistant PoW algorithm will be interesting, with many potential pitfalls. - ## Choice of Cryptographic Elliptic-curve - secp256k1 Elliptic curve cryptography is used for generating Private and Public key pairs that can be used for digital signatures @@ -165,7 +161,6 @@ Many additional alternatives exist, and platforms such as SafeCurves, maintained can help with the investigation and selection of an alternative security curve. The SafeCurves platform will make it easier to evaluate the security properties and potential vulnerabilities of many cryptographic curves [[25]]. - ## Selection of Key-store Library Grin originally made use of RocksDB [[26]] as an internal key-value store, but received some criticism for this @@ -185,252 +180,216 @@ benchmarks performed by Symas Corp support this claim, where LMDB outperformed a Grin later replaced RocksDB with LMDB to maintain the state of Grin Wallets [[34]]. This switch appears to be a good idea, as LMDB seem to be the best key-value store library for blockchain-related applications. - ## Conclusions, Observations and Recommendations - Selecting the correct emission rate to create a sustainable monetary policy is an important decision. Care should -be taken to ensure that the right balance is found between being an SoV and/or an MoE. + be taken to ensure that the right balance is found between being an SoV and/or an MoE. - Weighing the benefits and potential issues of being ASIC friendly compared to ASIC resistant needs to be carefully -evaluated. + evaluated. - Tools such as SafeCurves can be used to select a secure elliptic curve for an application. Cryptographic curves with -even potential security vulnerabilities should rather be ignored. + even potential security vulnerabilities should rather be ignored. - Care should be taken when using online benchmarks to help select libraries for a project, as the results might be -misleading. - + misleading. ## References -[[1]] M. Franzoni, "Grin: a Lightweight Implementation of the MimbleWimble Protocol" [online]. +[[1]] M. Franzoni, "Grin: a Lightweight Implementation of the MimbleWimble Protocol" [online]. Available: . Date accessed: 2018‑10‑05. -[1]: https://medium.com/novamining/grin-testnet-is-live-98b0f8cd135d -"Grin: A Lightweight Implementation of -the MimbleWimble Protocol, Mattia Franzoni" +[1]: https://medium.com/novamining/grin-testnet-is-live-98b0f8cd135d 'Grin: A Lightweight Implementation of +the MimbleWimble Protocol, Mattia Franzoni' [[2]] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" [online]. Available: <. Date accessed: 2018‑10‑05. -[2]: https://bitcoin.org/bitcoin.pdf -"Bitcoin: A Peer-to-Peer Electronic -Cash System, Satoshi Nakamoto" +[2]: https://bitcoin.org/bitcoin.pdf 'Bitcoin: A Peer-to-Peer Electronic +Cash System, Satoshi Nakamoto' [[3]] A. Barone, "What Happens to Bitcoin after all 21 Million are Mined?" [Online.] Available: . Date accessed: 2018‑10‑07. -[3]: https://www.investopedia.com/tech/what-happens-bitcoin-after-21-million-mined/ -"What Happens to Bitcoin after -all 21 Million are Mined? Adam Barone" +[3]: https://www.investopedia.com/tech/what-happens-bitcoin-after-21-million-mined/ 'What Happens to Bitcoin after +all 21 Million are Mined? Adam Barone' [[4]] "Emission Rate of Grin" [online]. Available: . Date accessed: 2018‑10‑15. -[4]: https://www.grin-forum.org/t/emmission-rate-of-grin/171 -"Emission Rate of Grin" +[4]: https://www.grin-forum.org/t/emmission-rate-of-grin/171 'Emission Rate of Grin' [[5]] "Coin Emission and Block Reward Schedules: Bitcoin vs. Monero" [online]. Available: . Date accessed: 2018‑10‑15. -[5]: https://www.reddit.com/r/Monero/comments/512kwh/useful_for_learning_about_monero_coin_emission/d78tpgi -"Coin Emission and Block Reward -Schedules: Bitcoin vs. Monero" +[5]: https://www.reddit.com/r/Monero/comments/512kwh/useful_for_learning_about_monero_coin_emission/d78tpgi 'Coin Emission and Block Reward +Schedules: Bitcoin vs. Monero' [[6]] "On Grin, MimbleWimble, and Monetary Policy" [online]. Available: . Date accessed: 2018‑10‑07. -[6]: https://www.reddit.com/r/grincoin/comments/91g1nx/on_grin_mimblewimble_and_monetary_policy/ -"On Grin, MimbleWimble, and Monetary Policy" +[6]: https://www.reddit.com/r/grincoin/comments/91g1nx/on_grin_mimblewimble_and_monetary_policy/ 'On Grin, MimbleWimble, and Monetary Policy' [[7]] "Grin - Monetary Policy" [online]. Available: . Date accessed: 2018‑10‑08. -[7]: https://github.com/mimblewimble/docs/wiki/Monetary-Policy -"Grin - Monetary Policy" +[7]: https://github.com/mimblewimble/docs/wiki/Monetary-Policy 'Grin - Monetary Policy' [[8]] J. J. Roberts and N. Rapp, "Exclusive: Nearly 4 Million Bitcoin Lost Forever, New Study Says" [online]. -Available: . Date accessed: 2018‑10‑08. +Available: . Date accessed: 2018‑10‑08. -[8]: http://fortune.com/2017/11/25/lost-bitcoins/ -"Exclusive: Nearly 4 Million Bitcoin +[8]: https://fortune.com/crypto/2017/11/25/lost-bitcoins/ 'Exclusive: Nearly 4 Million Bitcoin Lost Forever, New Study Says, -Jeff J. Roberts and Nicolas Rapp" +Jeff J. Roberts and Nicolas Rapp' [[9]] Andrew Ancheta, "How Inflationary should Cryptocurrency really be?" [Online.]. Available: . Date accessed: 2018‑11‑06. -[9]: https://cryptobriefing.com/how-inflationary-should-cryptocurrency-be/ -"How Inflationary should -Cryptocurrency really be? Andrew Ancheta" +[9]: https://cryptobriefing.com/how-inflationary-should-cryptocurrency-be/ 'How Inflationary should +Cryptocurrency really be? Andrew Ancheta' [[10]] L. Mutch, "Debtcoin: Credit, Debt, and Cryptocurrencies" [online]. Available: . Date accessed: 2018‑11‑06. -[10]: https://web.archive.org/web/20180917125549/https://cryptoinsider.21mil.com/debtcoin-credit-debt-and-cryptocurrencies/ -"Debtcoin: Credit, Debt, -and Cryptocurrencies, Landon Mutch" +[10]: https://web.archive.org/web/20180917125549/https://cryptoinsider.21mil.com/debtcoin-credit-debt-and-cryptocurrencies/ 'Debtcoin: Credit, Debt, +and Cryptocurrencies, Landon Mutch' [[11]] Brian Curran, "Inflation vs Deflation: A Guide to Bitcoin & Cryptocurrencies Deflationary Nature" [online]. Available: . Date accessed: 2018‑11‑06. -[11]: https://blockonomi.com/bitcoin-deflation/ -"Inflation vs Deflation: +[11]: https://blockonomi.com/bitcoin-deflation/ 'Inflation vs Deflation: A Guide to Bitcoin & Cryptocurrencies -Deflationary Nature, Brian Curran" +Deflationary Nature, Brian Curran' [[12]] A. Hayes, "Why is Deflation Bad for the Economy?" [Online.] Available: . Date accessed: 2018‑11‑06. -[12]: https://www.investopedia.com/articles/personal-finance/030915/why-deflation-bad-economy.asp -"Why is Deflation Bad -for the Economy? Adam Hayes" +[12]: https://www.investopedia.com/articles/personal-finance/030915/why-deflation-bad-economy.asp 'Why is Deflation Bad +for the Economy? Adam Hayes' [[13]] J. H. Cochrane, "Inflation and Debt" [online]. Available: . Date accessed: 2018‑11‑07. -[13]: https://www.nationalaffairs.com/publications/detail/inflation-and-debt -"Inflation and Debt, -John H. Cochrane" +[13]: https://www.nationalaffairs.com/publications/detail/inflation-and-debt 'Inflation and Debt, +John H. Cochrane' [[14]] L. Ziyuan, "Think Piece: Fighting Hyperinflation with Cryptocurrencies" [online]. Available: . Date accessed: 2018‑11‑07. -[14]: https://medium.com/@Digix/think-piece-fighting-hyperinflation-with-cryptocurrencies-a08fe86bb66a -"Think Piece: Fighting Hyperinflation -with Cryptocurrencies, Lucia Ziyuan" +[14]: https://medium.com/@Digix/think-piece-fighting-hyperinflation-with-cryptocurrencies-a08fe86bb66a 'Think Piece: Fighting Hyperinflation +with Cryptocurrencies, Lucia Ziyuan' [[15]] "Grin - Proof of Work Update" [online]. Available: . Date accessed: 2018‑10‑15. -[15]: https://www.grin-forum.org/t/proof-of-work-update/713 -"Grin - Proof of Work Update" +[15]: https://www.grin-forum.org/t/proof-of-work-update/713 'Grin - Proof of Work Update' [[16]] "Grin - Meeting Notes: Governance, Sep 25 2018" [online]. Available: . Date accessed: 2018‑10‑15. -[16]: https://www.grin-forum.org/t/meeting-notes-governance-sep-25-2018/874 -"Grin - Meeting Notes: -Governance, Sep 25 2018" +[16]: https://www.grin-forum.org/t/meeting-notes-governance-sep-25-2018/874 'Grin - Meeting Notes: +Governance, Sep 25 2018' [[17]] "Cuck(at)oo Cycle" [online]. Available: . Date accessed: 2018‑10‑15. -[17]: https://github.com/tromp/cuckoo -"Cuck(at)oo Cycle" +[17]: https://github.com/tromp/cuckoo 'Cuck(at)oo Cycle' [[18]] "51% Attack" [online]. Available: . Date accessed: 2018‑10‑11. -[18]: https://www.investopedia.com/terms/1/51-attack.asp -"51% Attack" +[18]: https://www.investopedia.com/terms/1/51-attack.asp '51% Attack' [[19]] H. Knutson, "What is the Math behind Elliptic Curve Cryptography?" [Online.] Available: . Date accessed: 2018‑10‑14. -[19]: https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3 -"What is the Math behind -Elliptic Curve Cryptography? Hans Knutson" +[19]: https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3 'What is the Math behind +Elliptic Curve Cryptography? Hans Knutson' [[20]] "Standards for Efficient Cryptography Group" [online]. Available: . Date accessed: 2018‑10‑11. -[20]: http://www.secg.org/ -"Standards for Efficient -Cryptography Group" +[20]: http://www.secg.org/ 'Standards for Efficient +Cryptography Group' [[21]] "Secp256k1" [online]. Available: . Date accessed: 2018‑10‑15. -[21]: https://en.bitcoin.it/wiki/Secp256k1 -"Secp256k1" +[21]: https://en.bitcoin.it/wiki/Secp256k1 'Secp256k1' [[22]] "Grin - Schnorr Signatures in Grin & Information" [online]. Available: . Date accessed: 2018‑10‑08. -[22]: https://www.grin-forum.org/t/schnorr-signatures-in-grin-information/730 -"Grin - Schnorr Signatures -in Grin & Information" +[22]: https://www.grin-forum.org/t/schnorr-signatures-in-grin-information/730 'Grin - Schnorr Signatures +in Grin & Information' [[23]] "SafeCurves - CM Field Discriminants" [online]. Available: . Date accessed: 2018‑10‑15. -[23]: http://safecurves.cr.yp.to/disc.html -"SafeCurves - CM Field Discriminants" +[23]: http://safecurves.cr.yp.to/disc.html 'SafeCurves - CM Field Discriminants' [[24]] D. J. Bernstein, "Curve25519: New Diffie-Hellman Speed Records" [online]. Available: . Date accessed: 2018‑10‑15. -[24]: https://cr.yp.to/ecdh/curve25519-20060209.pdf -"Curve25519: New Diffie-Hellman -Speed Records, Daniel J. Bernstein" +[24]: https://cr.yp.to/ecdh/curve25519-20060209.pdf 'Curve25519: New Diffie-Hellman +Speed Records, Daniel J. Bernstein' [[25]] "SafeCurves - Choosing Safe Curves for Elliptic-curve Cryptography" [online]. Available: . Date accessed: 2018‑10‑10. -[25]: http://safecurves.cr.yp.to/ -"SafeCurves - Choosing Safe Curves -for Elliptic-curve Cryptography" +[25]: http://safecurves.cr.yp.to/ 'SafeCurves - Choosing Safe Curves +for Elliptic-curve Cryptography' [[26]] "RocksDB" [online]. Available: . Date accessed: 2018‑10‑10. -[26]: https://rocksdb.org/ -"RocksDB" +[26]: https://rocksdb.org/ 'RocksDB' [[27]] "LevelDB" [online]. Available: . Date accessed: 2018‑10‑15. -[27]: https://web.archive.org/web/20180917125549/https://cryptoinsider.21mil.com/debtcoin-credit-debt-and-cryptocurrencies/ -"LevelDB" +[27]: https://web.archive.org/web/20180917125549/https://cryptoinsider.21mil.com/debtcoin-credit-debt-and-cryptocurrencies/ 'LevelDB' [[28]] "HyperLevelDB" [online]. Available: . Date accessed: 2018‑10‑15. -[28]: http://hyperdex.org/ -"HyperLevelDB" +[28]: http://hyperdex.org/ 'HyperLevelDB' [[29]] "LMDB" [online]. Available: . Date accessed: 2018‑10‑29. -[29]: https://github.com/LMDB -"LMDB" +[29]: https://github.com/LMDB 'LMDB' [[30]] P. Dix, "Benchmarking LevelDB vs. RocksDB vs. HyperLevelDB vs. LMDB Performance for InfluxDB" [online]. Available: Date accessed: 2018‑10‑15. -[30]: https://www.influxdata.com/blog/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/ -"Benchmarking LevelDB vs. RocksDB +[30]: https://www.influxdata.com/blog/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/ 'Benchmarking LevelDB vs. RocksDB vs. HyperLevelDB vs. LMDB -Performance for InfluxDB, Paul Dix" +Performance for InfluxDB, Paul Dix' [[31]] B. Alex, "Lmdbjava - Benchmarks" [online]. Available: . Date accessed: 2018‑10‑14. -[31]: https://github.com/lmdbjava/benchmarks/blob/master/results/20160630/README.md -"Lmdbjava - Benchmarks, Ben Alex" +[31]: https://github.com/lmdbjava/benchmarks/blob/master/results/20160630/README.md 'Lmdbjava - Benchmarks, Ben Alex' [[32]] H. Chu, "Lies, Damn Lies, Statistics, and Benchmarks" [online]. Available: . Date accessed: 2018‑10‑29. -[32]: https://www.linkedin.com/pulse/lies-damn-statistics-benchmarks-howard-chu -"Lies, Damn Lies, Statistics, -and Benchmarks, Howard Chu" +[32]: https://www.linkedin.com/pulse/lies-damn-statistics-benchmarks-howard-chu 'Lies, Damn Lies, Statistics, +and Benchmarks, Howard Chu' [[33]] "HyperDex Benchmark, Symas Corp" [online]. Available: . Date accessed: 2018‑10‑29. -[33]: http://www.lmdb.tech/bench/hyperdex/ -"HyperDex Benchmark, Symas Corp" +[33]: http://www.lmdb.tech/bench/hyperdex/ 'HyperDex Benchmark, Symas Corp' -[[34]] Yeastplume, "Progress Update May - Sep 2018" [online]. +[[34]] Yeastplume, "Progress Update May - Sep 2018" [online]. Available: . Date accessed: 2018‑10‑28. -[34]: https://www.grin-forum.org/t/yeastplume-progress-update-thread-may-sept-2018/361/12 -"Progress Update May - Sep 2018, Yeastplume" +[34]: https://www.grin-forum.org/t/yeastplume-progress-update-thread-may-sept-2018/361/12 'Progress Update May - Sep 2018, Yeastplume' ## Contributors diff --git a/_includes/content/protocols/06-AtomicSwaps.md b/_includes/content/protocols/06-AtomicSwaps.md index 3f86ee4d..33d55f42 100644 --- a/_includes/content/protocols/06-AtomicSwaps.md +++ b/_includes/content/protocols/06-AtomicSwaps.md @@ -11,7 +11,6 @@ - [References](#references) - [Contributors](#contributors) - ## What are Atomic Swaps? Atomic swaps or cross-chain atomic swaps [[1]], in a nutshell, are decentralized @@ -36,7 +35,7 @@ open channel to Bart, who does have an open channel to Carla. 1. Carla generates a random number and gives the hash of the number to Alex. 2. Alex pays Bart, but adds the condition that if Bart wants to claim the payment, he has to provide the random number -that generated the hash Carla gave to Alex. + that generated the hash Carla gave to Alex. 3. Bart pays Carla, but he adds the same condition to the payment. 4. Carla claims the payment by providing the random number, thus exposing the random number to Bart. 5. Bart uses the random number to claim the payment from Alex. @@ -50,7 +49,9 @@ for HTLC to function. Etomic swaps were created in an attempt to make atomic swa Ethereum-based tokens. ## Examples of Current Atomic Swaps and Implementations + ### #1 Manual Method + An article was posted on Hackernoon [[4]] giving the exact steps that are required for doing an atomic swap using cli. The requirements for this method are: @@ -80,10 +81,11 @@ exchange. It also uses a security deposit in the form of Zcredits to do swaps wi BarterDEX also supports Etomic swaps. These work by keeping the payments locked in an etomic blockchain that will act as a third party. Although swaps have been done, it is stated as not yet being production ready [[8]]. Currently -(July 2018), it is only possible to use Barterdex out of the Command Line Interface (CLI) [[9]]. Barterdex charges +(July 2018), it is only possible to use Barterdex out of the Command Line Interface (CLI). Barterdex charges a 0.1287% fee for a swap [[10]]. ### #4 COMIT + Cryptographically-secure Off-chain Multi-asset Instant Transaction (COMIT) is an open-source protocol for cross-blockchain applications, like peer-to-peer atomic swaps, and does not feature another blockchain nor token. It is powered by simple cryptographic principles such as HTLCs and enables users to trustlessly exchange one digital asset @@ -92,91 +94,67 @@ Graphical User Interface (GUI) are available on GitHub. At the time of writing, assets from the Bitcoin blockchain (e.g. BTC) and from the Ethereum blockchain (e.g. ETH and ERC20 tokens) ([[11], [[12]], [[13]]). - ## References -[[1]] S. Khatwani (2018), "What is Atomic Swap and Why it Matters?" *Coinsutra*. [Online.] +[[1]] S. Khatwani (2018), "What is Atomic Swap and Why it Matters?" _Coinsutra_. [Online.] Available: . Date accessed: 2018‑07‑12. -[1]: https://coinsutra.com/atomic-swap/ -"What is Atomic Swap and Why it Matters?" +[1]: https://coinsutra.com/atomic-swap/ 'What is Atomic Swap and Why it Matters?' [[2]] A. Vohra (2016), "What are Hashed Timelock Contracts (HTLCs)? Application in Lightning Network & Payment Channels", -*Hackernoon* [online] Available: . +_Hackernoon_ [online] Available: . Date accessed: 2018‑07‑12. -[2]: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345 -"What are Hashed Timelock Contracts (HTLCs)? Application in Lightning Network & Payment Channels" +[2]: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345 'What are Hashed Timelock Contracts (HTLCs)? Application in Lightning Network & Payment Channels' [[3]] J. Poon and T. Dryja (2016), "The Bitcoin Lightning Network: Scalable Off-chain Instant Payments v0.5.9.2" [online]. Available: . Date accessed: 2018‑07‑13. -[3]: https://lightning.network/lightning-network-paper.pdf -"The Bitcoin Lightning Network: Scalable Off-chain Instant Payments v0.5.9.2" +[3]: https://lightning.network/lightning-network-paper.pdf 'The Bitcoin Lightning Network: Scalable Off-chain Instant Payments v0.5.9.2' -[[4]] Hotshot (2018), "So how do I really do an Atomic Swap", *Hackernoon* [online] +[[4]] Hotshot (2018), "So how do I really do an Atomic Swap", _Hackernoon_ [online] Available: . Date accessed: 2018‑07‑13. -[4]: https://hackernoon.com/so-how-do-i-really-do-an-atomic-swap-f797852c7639 -"So how do I really do an Atomic Swap" +[4]: https://hackernoon.com/so-how-do-i-really-do-an-atomic-swap-f797852c7639 'So how do I really do an Atomic Swap' [[5]] Open Source (ISC) (2018), "viacoin/atomicswap", GitHub [online]. Available: . Date accessed: 2018‑07‑13. -[5]: https://github.com/viacoin/atomicswap -"viacoin/atomicswap" +[5]: https://github.com/viacoin/atomicswap 'viacoin/atomicswap' [[6]] Atomic (2018), "Atomic Wallet" [online]. Available: . Date accessed: 2018‑07‑13. -[6]: https://atomicwallet.io/ -"Atomic Wallet" +[6]: https://atomicwallet.io/ 'Atomic Wallet' [[7]] Komodo (2018), "BarterDEX" [online]. Available: . Date accessed: 2018‑07‑13. -[7]: https://komodoplatform.com/decentralized-exchange/ -"BarterDEX" +[7]: https://komodoplatform.com/decentralized-exchange/ 'BarterDEX' [[8]] Artemii235 (2018), "etomic-swap", GitHub [online]. Available: . Date accessed: 2018‑07‑13. -[8]: https://github.com/artemii235/etomic-swap -"etomic-swap" - -[[9]] Komodo (2018), "Barterdex", GitHub [online]. Available: -. -Date accessed: 2018‑07‑13. - -[9]: https://github.com/KomodoPlatform/KomodoPlatform/wiki/Installing-and-Using-Komodo-Platform-(barterDEX -"Barterdex" +[8]: https://github.com/artemii235/etomic-swap 'etomic-swap' [[10]] Komodo and S. Hossain (2017), "barterDEX Whitepaper v2" [online]. -Available: . Date accessed: 2018‑07‑13. +Available: . Date accessed: 2018‑07‑13. -[10]: https://github.com/KomodoPlatform/KomodoPlatform/wiki/barterDEX-Whitepaper-v2 -"barterDEX Whitepaper v2" +[10]: https://github.com/SuperNETorg/komodo/wiki/barterDEX-Whitepaper-v2 'barterDEX Whitepaper v2' [[11]] GitHub: "comit-network, COMIT is an open protocol facilitating trustless cross-blockchain applications." [online]. Available: . Date accessed: 2019‑10‑16. -[11]: https://github.com/comit-network -"GitHub: comit-network" +[11]: https://github.com/comit-network 'GitHub: comit-network' [[12]] CoBloX (2018), "Connect all the Blockchains!!!" [online] Available: -. Date accessed: 2019‑10‑16. +. Date accessed: 2019‑10‑16. -[12]: https://blog.coblox.tech/2018/06/23/connect-all-the-blockchains.html -"CoBloX Connect all the Blockchains!!!" +[12]: https://medium.com/coblox/connect-all-the-blockchains-atomic-swap-78b38fff42e 'CoBloX Connect all the Blockchains!!!' [[13]] "COMIT is an open protocol facilitating trustless cross-blockchain applications" [online] Available: . Date accessed: 2019‑10‑16. -[13]: https://comit.network/ -"COMIT Website" - - - - +[13]: https://comit.network/ 'COMIT Website' ## Contributors diff --git a/_includes/content/protocols/10-intro-to-tor-and-i2p.md b/_includes/content/protocols/10-intro-to-tor-and-i2p.md index 35dbbe17..e7da73ca 100644 --- a/_includes/content/protocols/10-intro-to-tor-and-i2p.md +++ b/_includes/content/protocols/10-intro-to-tor-and-i2p.md @@ -2,31 +2,31 @@ - [Introduction](#introduction) - [I2P Network](#i2p-network) - - [What is I2P?](#what-is-i2p) - - [How does I2P Work?](#how-does-i2p-work) - - [I2P Infrastructure](#i2p-infrastructure) - - [Routing Infrastructure and Anonymity](#routing-infrastructure-and-anonymity) - - [Distributed Network Database](#distributed-network-database) - - [Floodfill Routers](#floodfill-routers) - - [Garlic Routing](#garlic-routing) - - [I2P Threats, Security and Vulnerability](#i2p-threats-security-and-vulnerability) - - [Sybil Attacks](#sybil-attacks) - - [Eclipse Attacks](#eclipse-attacks) - - [Brute Force Attacks](#brute-force-attacks) - - [Intersection Attacks](#intersection-attacks) - - [Denial of Service Attacks](#denial-of-service-attacks) - - [Greedy User Attack](#greedy-user-attack) - - [Starvation Attack](#starvation-attack) - - [Flooding Attack](#flooding-attack) + - [What is I2P?](#what-is-i2p) + - [How does I2P Work?](#how-does-i2p-work) + - [I2P Infrastructure](#i2p-infrastructure) + - [Routing Infrastructure and Anonymity](#routing-infrastructure-and-anonymity) + - [Distributed Network Database](#distributed-network-database) + - [Floodfill Routers](#floodfill-routers) + - [Garlic Routing](#garlic-routing) + - [I2P Threats, Security and Vulnerability](#i2p-threats-security-and-vulnerability) + - [Sybil Attacks](#sybil-attacks) + - [Eclipse Attacks](#eclipse-attacks) + - [Brute Force Attacks](#brute-force-attacks) + - [Intersection Attacks](#intersection-attacks) + - [Denial of Service Attacks](#denial-of-service-attacks) + - [Greedy User Attack](#greedy-user-attack) + - [Starvation Attack](#starvation-attack) + - [Flooding Attack](#flooding-attack) - [Tor Network](#tor-network) - [What is Tor?](#what-is-tor) - [How does Tor Work](#how-does-tor-work) - [How does Onion Routing Work?](#how-does-onion-routing-work) - [Types of Tor Relays/Nodes Routing](#types-of-tor-relaysnodes-routing) - - [Guard or Entry Relay (Non-exit Relay) Nodes](#guard-or-entry-relay-non-exit-relay-nodes) - - [Middle Relay Nodes](#middle-relay-nodes) - - [Exit Relay Nodes](#exit-relay-nodes) - - [Bridge Relay Nodes](#bridge-relay-nodes) + - [Guard or Entry Relay (Non-exit Relay) Nodes](#guard-or-entry-relay-non-exit-relay-nodes) + - [Middle Relay Nodes](#middle-relay-nodes) + - [Exit Relay Nodes](#exit-relay-nodes) + - [Bridge Relay Nodes](#bridge-relay-nodes) - [Pitfalls of Using Tor Anonymously - is it Broken?](#pitfalls-of-using-tor-anonymously---is-it-broken) - [Advantages and Disadvantages](#advantages-and-disadvantages) - [Differences between I2P and Tor](#differences-between-i2p-and-tor) @@ -80,7 +80,7 @@ which use a standard web server, can be used to create such sites. I2P works by installing an I2P routing service within a client's device. This router creates temporary, encrypted, one-way connections with I2P routers on other devices. Connections are referred to as one way because they are made up -of an *Outbound Tunnel* and an *Inbound Tunnel*. During any communication, data leaves the client's devices via the +of an _Outbound Tunnel_ and an _Inbound Tunnel_. During any communication, data leaves the client's devices via the outbound tunnels and is received on other devices through their inbound tunnels. This means that messages do not travel in two directions within the same tunnel. Therefore, a single round-trip request message and its response between two parties needs four tunnels [[4]], as shown in Figure 1. Messages sent from one device do not travel directly to @@ -96,8 +96,6 @@ long-lived tunnels from becoming a threat to anonymity [[3]].

Figure 1: Network Topology [6]

- - #### Distributed Network Database The Network Database (NetDB) is implemented as a DHT and is propagated via nodes known as @@ -110,13 +108,15 @@ the router can reach at least one other participant in the network, the router w it does not have itself [[12]]. The NetDB stores two types of data: + 1. **RouterInfo.** - When a message is leaving one router, it needs to know some key pieces of data (known as *RouterInfo*) about the - other router. The destination RouterInfo is stored in the NetDB with the router's identity as the key. To request a - resource (or RouterInfo), a client requests the desired key from the node considered to be closest to the key. If - the piece of data is located at the node, it is returned to the client. Otherwise, the node uses its local knowledge - of participating nodes and returns the node it considers to be nearest to the key [[3]]. The RouterInfo in the NetDB - is made up of ([[4]], [[6]]): + When a message is leaving one router, it needs to know some key pieces of data (known as _RouterInfo_) about the + other router. The destination RouterInfo is stored in the NetDB with the router's identity as the key. To request a + resource (or RouterInfo), a client requests the desired key from the node considered to be closest to the key. If + the piece of data is located at the node, it is returned to the client. Otherwise, the node uses its local knowledge + of participating nodes and returns the node it considers to be nearest to the key [[3]]. The RouterInfo in the NetDB + is made up of ([[4]], [[6]]): + - The router's identity - an encryption key, a signing key and a certificate. - The contact addresses at which it can be reached - protocol, IP and port. - When this was created or published. @@ -124,8 +124,8 @@ The NetDB stores two types of data: - The signature of the above, generated by the identity's signing key. 2. **LeaseSets.** - The LeaseSet specifies a tunnel entry point to reach an endpoint. This specifies the routers that can directly - contact the desired destination. It contains the following data: + The LeaseSet specifies a tunnel entry point to reach an endpoint. This specifies the routers that can directly + contact the desired destination. It contains the following data: - Tunnel gateway router - given by specifying its identity. - Tunnel ID - tunnel used to send messages. - Tunnel expiration - when the tunnel will expire. @@ -134,7 +134,7 @@ The NetDB stores two types of data: #### Floodfill Routers -Special routers, referred to as *floodfill routers*, are responsible for storing the NetDB. Participation in the floodfill +Special routers, referred to as _floodfill routers_, are responsible for storing the NetDB. Participation in the floodfill pool can be automatic or manual. Automatic participation occurs whenever the number of floodfill routers drops below a certain threshold, which is currently 6% of all nodes in the network ([[6]], [[7]]). When this happens, a node is selected to participate as a floodfill router based on criteria such as uptime and bandwidth. It should be noted that @@ -156,10 +156,10 @@ things: - bundles multiple messages together. Figure 2 illustrates the end-to-end message bundling: +

Figure 2: Garlic Routing

- ### I2P Threats, Security and Vulnerability The I2P project has no specific threat model, but rather talks about common attacks and existing defenses. @@ -182,7 +182,6 @@ the malicious user will need substantial resources to create multiple identities

Figure 3: Sybil Attack [5]

- #### Eclipse Attacks In eclipse attacks, a set of malicious and colluding nodes arranges that a good node can @@ -253,16 +252,16 @@ Tor uses a unique system that was originally developed by the US Navy to protect Naval Research Laboratory released the Tor code under a free license and the Tor Project was founded in 2006. With the help of the Electronic Frontier Foundation (EFF), further research and development of Tor have continued as a Free and Open Source Project. The Tor network service is run by a worldwide community of volunteers and are not controlled by any -corporate or government agencies. +corporate or government agencies. The Tor network service is the heart of the Tor project. The Tor Browser and other tools, such as OnionShare, run on top -of or via the Tor network. These tools are meant to make using the Tor network as simple and secure as possible. +of or via the Tor network. These tools are meant to make using the Tor network as simple and secure as possible. Some tools, such as the Tor Browser Bundle, come as a single downloadable and installable package containing everything -needed to use the Tor network and be anonymous. +needed to use the Tor network and be anonymous. Almost any network tool or application that can be configured to use a Socket Secure (SOCKS) proxy can be set up to use -the Tor network service. +the Tor network service. ### How does Tor Work? @@ -282,10 +281,6 @@ earlier actions to new actions. This process is also known as Onion Routing [[14

Figure 4: How Tor Works [13]

- - - - ### How does Onion Routing Work? Onion Routing is essentially a distributed overlay network designed to anonymize Transmission Control Protocol (TCP) @@ -307,14 +302,14 @@ non-mnemonic, 16- or 56-character alpha-semi-numerical strings that are generate key. The Top Level Domain (TLD) `.onion` is not a true domain and cannot be found or queried on the Internet, but only inside the Tor network ([[19]]], [[23]], [[24]]). - The designated use of relay nodes in the Tor network gives the network the following important characteristics [[13]]: + - The stability of the network is proportional to the number of relay nodes in the network. The fewer the number of relay nodes, the less stable the network becomes. - The security of the network is also proportional to the number of relay nodes. A network with more active relay nodes is less vulnerable to attacks. - Finally, the speed of the network is proportional to the number of relay nodes. The more nodes there are, the faster -the network becomes. + the network becomes. ### Types of Tor Relays/Nodes Routing @@ -324,8 +319,6 @@ entry or guard relay node, a middle relay node, an exit relay node and a bridge

Figure 5: Tor Circuit [14]

- - #### Guard or Entry Relay (Non-exit Relay) Nodes A guard relay node is the first relay node in the Tor circuit. Each client that wants to connect to the Tor network will @@ -374,7 +367,7 @@ in order to use Tor services. This was very easy to get wrong or incomplete, and could be leaked. For example, Domain Name System (DNS) requests intended for the Tor network, i.e. `.onion` address, might be sent -directly to the public DNS server, if the ```network.proxy.socks_remote_dns``` was not set to true in FireFox. These DNS +directly to the public DNS server, if the `network.proxy.socks_remote_dns` was not set to true in FireFox. These DNS requests could be used to track where a user might be surfing and thus deanonymize the user. Tor is not broken if Tor services are correctly set up or if the Tor Browser is used correctly. It is very easy to do @@ -417,21 +410,18 @@ Advantages of Tor: Disadvantages of Tor: - It can be slow. -- It does not necessarily encrypt data leaving ```Exit Node```. This data can be intercepted. +- It does not necessarily encrypt data leaving `Exit Node`. This data can be intercepted. - It does not stop somebody from deanonymizing themselves. - It does not stop interceptors from knowing you are using Tor. - Its network is not user-friendly, due to its secure and hidden nature. - Its nodes (relay/bridge) are run by volunteers, who can sometimes be unreliable. - - ## Differences between I2P and Tor - | I2P | Tor | -|------------------------------------------------------------|----------------------------------------------------------------------------| +| ---------------------------------------------------------- | -------------------------------------------------------------------------- | | Fully peer to peer: self-organizing nodes | Fully peer to peer: volunteer relay nodes | | Queries NetDB to find destination’s inbound tunnel gateway | Relays data to the closest relay | | Limited to no exit nodes; internal communication only | Designed and optimized for exit traffic, with a large number of exit nodes | @@ -463,199 +453,169 @@ of privacy or denial of service. [[1]] B. Mann, "What Is I2P & How Does It Compare vs. Tor Browser?" [Online.] Available: . Date accessed: 2019‑06‑18. -[1]: https://blokt.com/guides/what-is-i2p-vs-tor-browser#How_does_I2P_work -"What Is I2P & +[1]: https://blokt.com/guides/what-is-i2p-vs-tor-browser#How_does_I2P_work 'What Is I2P & How Does It Compare vs. -Tor Browser?" +Tor Browser?' [[2]]: I2P: "I2PTunnel" [online]. Available: . Date accessed: 2019‑06‑18. -[2]: https://geti2p.net/en/docs/api/i2ptunnel -"I2PTunnel" +[2]: https://geti2p.net/en/docs/api/i2ptunnel 'I2PTunnel' [[3]]: C. Egger, J. Schlumberger, C. Kruegel and G. Vigna, "Practical Attacks Against the I2P Network" - Paper [online]. Available: . Date accessed: 2019‑06‑18. -[3]: https://sites.cs.ucsb.edu/~chris/research/doc/raid13_i2p.pdf -"Practical Attacks Against -the I2P Network" +[3]: https://sites.cs.ucsb.edu/~chris/research/doc/raid13_i2p.pdf 'Practical Attacks Against +the I2P Network' [[4]] N. P. Hoang, P. Kintis, M. Antonakakis and M. Polychronakis, "An Empirical Study of the I2P Anonymity Network and its Censorship Resistance" [online]. Available: . Date accessed: 2019‑06‑18. -[4]: https://censorbib.nymity.ch/pdf/Hoang2018a.pdf -"An Empirical Study +[4]: https://censorbib.nymity.ch/pdf/Hoang2018a.pdf 'An Empirical Study of the I2P Anonymity Network and its -Censorship Resistance" +Censorship Resistance' [[5]] K. Alachkar and D. Gaastra, "Mitigating Sybil Attacks on the I2P Network Using Blockchain" - Presentation [online]. Available: . Date accessed: 2019‑06‑20. -[5]: https://www.delaat.net/rp/2017-2018/p97/presentation.pdf -"Mitigating Sybil Attacks +[5]: https://www.delaat.net/rp/2017-2018/p97/presentation.pdf 'Mitigating Sybil Attacks on the I2P Network -Using Blockchain" +Using Blockchain' [[6]] K. Alachkar and D. Gaastra, "Blockchain-based Sybil Attack Mitigation: A Case Study of the I2P Network" - Report -[online]. Available: . Date accessed: 2019‑06‑20. +[online]. Available: . Date accessed: 2019‑06‑20. -[6]: https://delaat.net/rp/2017-2018/p97/report.pdf -"Blockchain-based Sybil +[6]: https://www.os3.nl/_media/2017-2018/courses/rp2/p97_report.pdf 'Blockchain-based Sybil Attack Mitigation: A Case Study of the -I2P Network" +I2P Network' [[7]] I2P: "The Network Database" [online]. Available: . Date accessed: 2019‑06‑20. -[7]: https://geti2p.net/en/docs/how/network-database -"The Network Database" +[7]: https://geti2p.net/en/docs/how/network-database 'The Network Database' [[8]] H. Vhora and G. Khilari, "Defending Eclipse Attack in I2P using Structured Overlay Network" [online]. Available: . Date accessed: 2019‑06‑20. -[8]: http://ijsetr.org/wp-content/uploads/2015/05/IJSETR-VOL-4-ISSUE-5-1515-1518.pdf -"Defending Eclipse Attack +[8]: http://ijsetr.org/wp-content/uploads/2015/05/IJSETR-VOL-4-ISSUE-5-1515-1518.pdf 'Defending Eclipse Attack in I2P using Structured -Overlay Network" +Overlay Network' [[9]] M. Ehlert, "I2P Usability vs. Tor Usability - A Bandwidth and Latency Comparison" [online]. Available: . Date accessed: 2019‑06‑20. -[9]: https://pdfs.semanticscholar.org/aa81/79d3da24b643a4d004c44ebe543000295d51.pdf -"I2P Usability vs. +[9]: https://pdfs.semanticscholar.org/aa81/79d3da24b643a4d004c44ebe543000295d51.pdf 'I2P Usability vs. Tor Usability - A Bandwidth and Latency -Comparison" +Comparison' [[10]] I2P: "I2P Compared to Tor" [online]. Available: . Date accessed: 2019‑06‑20. -[10]: https://geti2p.net/en/comparison/tor -"I2P Compared to Tor" +[10]: https://geti2p.net/en/comparison/tor 'I2P Compared to Tor' [[11]] I2P: "I2P Compared to Tor and Freenet" [online]. Available: . Date accessed: 2019‑06‑20. -[11]: http://www.geti2p.org/how_networkcomparisons.html -"I2P Compared to Tor -and Freenet" +[11]: http://www.geti2p.org/how_networkcomparisons.html 'I2P Compared to Tor +and Freenet' [[12]] T. de Boer and V. Breider: "Invisible Internet Project - MSc Security and Network Engineering Research Project." [online]. -Available: Date accessed: 2019‑07‑10. +Available: Date accessed: 2019‑07‑10. -[12]: https://www.delaat.net/rp/2018-2019/p63/report.pdf -"Invisible Internet Project - MSc Security and Network Engineering Research Project" +[12]: https://www.os3.nl/_media/2018-2019/courses/rp1/p63_report.pdf 'Invisible Internet Project - MSc Security and Network Engineering Research Project' [[13]] Tor, "Tor Project: How it works" [online]. Available: Date accessed: 2019‑08‑05. -[13]:https://2019.www.torproject.org/about/overview.html.en -"Tor Project: How it works" +[13]: https://2019.www.torproject.org/about/overview.html.en 'Tor Project: How it works' [[14]] R. Dingledine, N Mathewson and P. Syverson, "Tor: The Second-Generation Onion Router" [online] Available: Date accessed: 2019‑08‑05. -[14]:https://svn.torproject.org/svn/projects/design-paper/tor-design.html -"Tor: The Second-Generation Onion Router" +[14]: https://svn.torproject.org/svn/projects/design-paper/tor-design.html 'Tor: The Second-Generation Onion Router' [[15]] Tor, "Tor Network Status" [online] Available: Date accessed: 2019‑08‑05. -[15]: https://torstatus.blutmagie.de/ -"Tor Network Status" +[15]: https://torstatus.blutmagie.de/ 'Tor Network Status' [[16]] A. Kwon, M. AlSabah, D. Lazar, M. Dacier and S. Devadas, "Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Service" [online] Available: Date accessed: 2019‑08‑05. -[16]: https://people.csail.mit.edu/devadas/pubs/circuit_finger.pdf -"Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Service" +[16]: https://people.csail.mit.edu/devadas/pubs/circuit_finger.pdf 'Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Service' [[17]] Tor Project: "Download for Tor Browser" [online]. Available: . Date accessed: 2019‑05‑16. -[17]: https://www.torproject.org/ -"Tor Project: Download for Tor Browser" +[17]: https://www.torproject.org/ 'Tor Project: Download for Tor Browser' [[18]] Wikipedia: "Tor (Anonymity Network)" [online]. Available: . Date accessed: 2019‑05‑16. -[18]: https://en.wikipedia.org/wiki/Tor_(anonymity_network) -"Wikipedia: Tor (Anonymity Network)" +[18]: https://en.wikipedia.org/wiki/Tor_(anonymity_network) 'Wikipedia: Tor (Anonymity Network)' [[19]] DuckDuckGo Search Engine inside Tor [online]. Available: . **Note:** This link will not work unless Tor or the Tor Browser is used. Date accessed: 2019‑05‑16. -[19]: https://3g2upl4pq6kufc4m.onion/ -"DuckDuckGo Search Engine - +[19]: https://3g2upl4pq6kufc4m.onion/ 'DuckDuckGo Search Engine - link will not work unless -Tor or Tor Browser is used" +Tor or Tor Browser is used' [[20]] Tor Project: "Check" [online]. Available: . **Note:** This link will help the user identify if Tor or the Tor Browser is been used. Date accessed: 2019‑05‑16 -[20]: https://check.torproject.org/ -"Tor Project: Check - +[20]: https://check.torproject.org/ 'Tor Project: Check - link will help user identify -Tor or Tor Browser is been used" +Tor or Tor Browser is been used' [[21]] Tor Project: "Overview" [online]. Available: . Date accessed: 2019‑05‑16. -[21]: https://2019.www.torproject.org/about/overview.html.en -"Tor Project: Overview" +[21]: https://2019.www.torproject.org/about/overview.html.en 'Tor Project: Overview' [[22]] Tor Project: "The Tor Relay Guide" [online]. Available: . Date accessed: 2019‑08‑14. -[22]: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide -"Tor Project: The Tor Relay Guide" +[22]: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide 'Tor Project: The Tor Relay Guide' [[23]] Wikipedia: ".onion" [online]. Available: . Date accessed: 2019‑08‑22. -[23]: https://en.wikipedia.org/wiki/.onion -"Wikipedia: .onion" +[23]: https://en.wikipedia.org/wiki/.onion 'Wikipedia: .onion' [[24]] Tor Project: "How do I access onion services?" [online]. Available: . Date accessed: 2019‑08‑22. -[24]: https://2019.www.torproject.org/docs/faq#AccessOnionServices -"Tor Project: How do I access onion services?" +[24]: https://2019.www.torproject.org/docs/faq#AccessOnionServices 'Tor Project: How do I access onion services?' [[25]] R. Heaton: "How Does Online Tracking Actually Work?" [online]. Available: . Date accessed: 2019‑07‑25. -[25]: https://robertheaton.com/2017/11/20/how-does-online-tracking-actually-work/ -"Robert Heaton: How does online -tracking actually work?" +[25]: https://robertheaton.com/2017/11/20/how-does-online-tracking-actually-work/ 'Robert Heaton: How does online +tracking actually work?' [[26]] YouTube: "DEF CON 22 - Adrian Crenshaw - Dropping Docs on Darknets: How People Got Caught" [online]. Available: . Date accessed: 2019‑06‑18. -[26]: https://www.youtube.com/watch?v=eQ2OZKitRwc -"YouTube: DEF CON 22 - Adrian Crenshaw - +[26]: https://www.youtube.com/watch?v=eQ2OZKitRwc 'YouTube: DEF CON 22 - Adrian Crenshaw - Dropping Docs on Darknets: -How People Got Caught" +How People Got Caught' [[27]] Ars Technica: "Use of Tor helped FBI ID suspect in bomb hoax case" [online]. Available: . Date accessed: 2019‑07‑11. -[27]: https://arstechnica.com/security/2013/12/use-of-tor-helped-fbi-finger-bomb-hoax-suspect/ -"Ars Technica: Use of Tor helped -FBI ID suspect in bomb hoax case" +[27]: https://arstechnica.com/security/2013/12/use-of-tor-helped-fbi-finger-bomb-hoax-suspect/ 'Ars Technica: Use of Tor helped +FBI ID suspect in bomb hoax case' [[28]] Ars Technica: "Stakeout: How the FBI tracked and busted a Chicago Anon" [online]. Available: . Date accessed: 2019‑07‑11. -[28]: https://arstechnica.com/tech-policy/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon/ -"Ars Technica: Stakeout: How the -FBI tracked and busted a Chicago Anon" - - +[28]: https://arstechnica.com/tech-policy/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon/ 'Ars Technica: Stakeout: How the +FBI tracked and busted a Chicago Anon' ## Appendices @@ -673,9 +633,6 @@ Onion Services - Tor services that don’t leave the Tor network: and diff --git a/_includes/content/protocols/11-distributed-hash-tables.md b/_includes/content/protocols/11-distributed-hash-tables.md index 23def9ed..e9aa71b3 100644 --- a/_includes/content/protocols/11-distributed-hash-tables.md +++ b/_includes/content/protocols/11-distributed-hash-tables.md @@ -113,13 +113,13 @@ of all transactions and blocks for verification. The following graph is replicated and simplified from [[8]]. Degree is the number of neighbors with which a node must maintain contact. -| Parameter | CAN | CHORD | Kademlia | Koord | Pastry | Tapestry | Viceroy | -| -------------------------------------- | --------------------------------------- | ----------------------- | --------------------------------------------------------- | ---------------------------------------- | ---------------------------------- | ------------------------- | ------------------------------- | -| Foundation | d-dimensional torus | Circular space | XOR metric | de Bruijn graph | Plaxton-style mesh | Plaxton-style mesh | Butterfly network | -| Routing function | Map key-value pairs to coordinate space | Matching key to node ID | Matching key to node ID | Matching key to node ID | Matching key and prefix in node ID | Suffix matching | Levels of tree, vicinity search | -| Routing performance (network size $n$) | $O(dn^{(2/d)})$ | $O(log(n))$ | $O(log(n)) + c$ $c$ is small | Between $O(log(log(n)))$ and $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | -| Degree | $2d$ | $O(log(n))$ | $O(log(n))$ | Between constant to $log(n)$ | $O(2log(n))$ | $O(log(n))$ | Constant | -| Join/Leaves | $2d$ | $log(n)^2$ | $O(log(n)) + c$ $c$ is small | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | +| Parameter | CAN | CHORD | Kademlia | Koord | Pastry | Tapestry | Viceroy | +| -------------------------------------- | --------------------------------------- | ----------------------- | ----------------------------------------------------------- | ---------------------------------------- | ---------------------------------- | --------------------------- | ------------------------------- | +| Foundation | d-dimensional torus | Circular space | XOR metric | de Bruijn graph | Plaxton-style mesh | Plaxton-style mesh | Butterfly network | +| Routing function | Map key-value pairs to coordinate space | Matching key to node ID | Matching key to node ID | Matching key to node ID | Matching key and prefix in node ID | Suffix matching | Levels of tree, vicinity search | +| Routing performance (network size $n$) | $O(dn^{(2/d)})$ | $O(log(n))$ | $O(log(n)) + c$ $c$ is small | Between $O(log(log(n)))$ and $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | +| Degree | $2d$ | $O(log(n))$ | $O(log(n))$ | Between constant to $log(n)$ | $O(2log(n))$ | $O(log(n))$ | Constant | +| Join/Leaves | $2d$ | $log(n)^2$ | $O(log(n)) + c$ $c$ is small | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | $O(log(n))$ | | Implementations | \-\- | OpenChord, OverSIM | Ethereum [[3]], Mainline DHT (BitTorrent), I2P, Kad Network | \-\- | FreePastry | OceanStore, Mnemosyne [[4]] | \-\- | The popularity of Kademlia over other DHTs is likely due to its relative simplicity and performance. The rest of this @@ -177,9 +177,9 @@ There are a number of ways that bootstrap nodes can be obtained, including addin 2. It contacts a few nodes it knows about. 3. It sends a `FIND_NODE` lookup request of its newly generated node ID. 4. The contacted nodes return the closest nodes they know about. The newly discovered nodes are added to the joining -node's routing table. + node's routing table. 5. The joining node then contacts some of the new nodes it knows about. The process then continues iteratively until -the joining node is unable to locate any closer nodes. + the joining node is unable to locate any closer nodes. This _self-lookup_ has two effects: it allows the node to learn about nodes closer to itself; and it populates other nodes' routing tables with the node's ID [[1]]. @@ -215,7 +215,7 @@ The following RPC messages are part of the Kademlia protocol: - Data storage and retrieval - `STORE` - request to store a $\langle key, value \rangle$ pair. - `FIND_VALUE` - behaves the same as `FIND_NODE` by returning closer nodes. If a node has the requested - $\langle key, value \rangle​$ pair, it will instead return the stored value. + $\langle key, value \rangle​$ pair, it will instead return the stored value. Notably, there is no `JOIN` message. This is because there is no explicit join in Kademlia. Each peer has a chance of being added to a routing table of another node whenever an RPC message is sent/received between them [[2]]. In this @@ -241,7 +241,6 @@ retrieved by participants in the network: - The retrieval procedure follows the same logic as storage, except a `FIND_VALUE` RPC is issued and the data received. - ##### Routing Table Each node organizes contacts into a list called a routing table. A routing table is a binary tree where the leaves are @@ -325,7 +324,7 @@ Mitigations include [[12]]: - Associating a cost with adding new identifiers to the network. - Reliably joining real-world identifiers (IP address, MAC address, etc.) to the node identifier, and rejecting a -threshold of duplicates. + threshold of duplicates. - Having a trusted central authority or secure decentralized scheme that issues identities. - Using social information and trust relationships. @@ -406,61 +405,61 @@ becomes especially important when control of a network may mean monetary losses, [[1]] Wikipedia: "Distributed Hash Table" [online]. Available: . Date accessed: 2019‑03‑08. -[1]: https://en.wikipedia.org/wiki/Distributed_hash_table. "Wikipedia: Distributed Hash Table" +[1]: https://en.wikipedia.org/wiki/Distributed_hash_table. 'Wikipedia: Distributed Hash Table' [[2]] "Kademlia: A Peer-to-Peer Information System" [online]. Available: . Date accessed: 2019‑03‑08. -[2]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf "Original Kademlia paper" +[2]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf 'Original Kademlia paper' [[3]] Ethereum/Wiki: "Kademlia Peer Selection' [online]. Available: . Date accessed: 2019‑03‑12. -[3]: https://github.com/ethereum/wiki/wiki/Kademlia-Peer-Selection "Kademlia Peer Selection" +[3]: https://github.com/ethereum/wiki/wiki/Kademlia-Peer-Selection 'Kademlia Peer Selection' [[4]] Wikipedia: "Tapestry (DHT)" [online]. Available: . Date accessed: 2019‑03‑12. -[4]: https://www.wikiwand.com/en/Tapestry_(DHT) "Tapestry (DHT)" +[4]: https://www.wikiwand.com/en/Tapestry_(DHT) 'Tapestry (DHT)' [[5]] "Towards a Scalable and Robust DHT" [online]. Available: . Date accessed: 2019‑03‑12. -[5]: http://www.cs.jhu.edu/~baruch/RESEARCH/Research_areas/Peer-to-Peer/2006_SPAA/virtual5.pdf "Towards a Scalable and Robust DHT" +[5]: http://www.cs.jhu.edu/~baruch/RESEARCH/Research_areas/Peer-to-Peer/2006_SPAA/virtual5.pdf 'Towards a Scalable and Robust DHT' [[6]] "Low-resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network" [online]. Available: . Date accessed: 2019‑03‑15. -[6]: https://www.cs.bu.edu/~goldbe/projects/eclipseEth.pdf "Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network" +[6]: https://www.cs.bu.edu/~goldbe/projects/eclipseEth.pdf 'Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network' [[7]]: "Commensal Cuckoo: Secure Group Partitioning for Large-scale Services" [online]. Available: . Date accessed: 2019‑03‑15. -[7]: https://web.archive.org/web/20180729064433/http://sns.cs.princeton.edu/docs/ccuckoo-ladis11.pdf "Commensal Cuckoo: Secure Group Partitioning for Large-Scale Services" +[7]: https://web.archive.org/web/20180729064433/http://sns.cs.princeton.edu/docs/ccuckoo-ladis11.pdf 'Commensal Cuckoo: Secure Group Partitioning for Large-Scale Services' [[8]]: "Overlay and P2P Networks" [online]. Available: . Date accessed: 2019‑04‑04. -[8]: https://www.cs.helsinki.fi/webfm_send/1339 "Overlay and P2P networks" +[8]: https://www.cs.helsinki.fi/webfm_send/1339 'Overlay and P2P networks' -[[9]]: "Poisoning the Kad Network" [online]. Available: . +[[9]]: "Poisoning the Kad Network" [online]. Available: . Date accessed: 2019‑04‑04. -[9]: https://www.net.t-labs.tu-berlin.de/~stefan/icdcn10.pdf "Poisoning the Kad Network" +[9]: https://link.springer.com/chapter/10.1007/978-3-642-11322-2_22 'Poisoning the Kad Network' [[10]]: "BitTorrent" [online]. . Date accessed: 2019‑04‑04. -[10]: https://en.wikipedia.org/wiki/BitTorrent "BitTorrent" +[10]: https://en.wikipedia.org/wiki/BitTorrent 'BitTorrent' [[11]]: "Servers - Tor Metrics" [online]. . Date accessed: 2019‑04‑29. -[11]: https://en.wikipedia.org/wiki/BitTorrent "Servers - Tor Metrics" +[11]: https://en.wikipedia.org/wiki/BitTorrent 'Servers - Tor Metrics' [[12]]: "A Survey of DHT Security Techniques" [online]. . Date accessed: 2019‑04‑29. -[12]: https://www.researchgate.net/publication/220566526_A_survey_of_DHT_security_techniques "A Survey of DHT Security Techniques" +[12]: https://www.researchgate.net/publication/220566526_A_survey_of_DHT_security_techniques 'A Survey of DHT Security Techniques' ## Contributors diff --git a/_includes/content/protocols/12-mimblewimble-mb-bp-utxo.md b/_includes/content/protocols/12-mimblewimble-mb-bp-utxo.md index 48461872..d7add013 100644 --- a/_includes/content/protocols/12-mimblewimble-mb-bp-utxo.md +++ b/_includes/content/protocols/12-mimblewimble-mb-bp-utxo.md @@ -42,8 +42,6 @@ div.mywrap { - [Appendix C: Shamir's Secret Sharing Example](#appendix-c-shamirs-secret-sharing-example) - [Contributors](#contributors) - - ## Introduction In [Mimblewimble](/protocols/mimblewimble), the concept of a Bitcoin-type multi-signature (multisig) applied to @@ -63,12 +61,8 @@ that contains the tokens; it does not require an "owner" signature. A typical Mi Another fundamental difference is that for any Mimblewimble transaction, all parties, i.e. all senders and all receivers, must interact to conclude the transaction. - - ## Background - - ### Bitcoin $ m\text{-of-}n $ Multisig in a Nutshell Multiple use cases of $ m\text{-of-}n $ multisig applications exist, e.g. a $ 1\text{-of-}2 $ petty cash account, @@ -115,7 +109,7 @@ from the stack if equal. The top of the stack then contains ``, wh top of that, `` and ``. The last value in the stack, `OP_0`, is needed for a glitch in the `OP_CHECKMULTISIG` opcode implementation, which makes it pop one more item than those that are available on the stack ([[1]], [[5]]). -*What is signed?* +_What is signed?_ Partial signatures are created in the same sequence in which the public keys are defined in `redeemScript`. A simplified serialized hexadecimal version of the transaction - consisting of the input transaction ID and UTXO index, amount to be @@ -124,7 +118,7 @@ of the previous partial signature with the simplified transaction data to be sig in the signed data. This, combined with the public keys, proves the transaction was created by the real owners of the bitcoins in question ([[4]], [[5]], [[6]]). -*How is change redirected to the multisig P2SH?* +_How is change redirected to the multisig P2SH?_ Bitcoin transactions can have multiple recipients, and one of the recipients of the funds from a P2SH multisig transaction can be the original `P2SHAddress`, thus sending change back to itself. Circular payments to the same @@ -132,8 +126,6 @@ addresses are allowed, but they will suffer from a lack of confidentiality. Anot new `redeemScript` with a new set of public keys every time a P2SH multisig transaction is done to collect the change, but this would be more complex to manage [[4]]. - - ### Security of the Mimblewimble Blockchain A [Mimblewimble](/protocols/mimblewimble) blockchain relies on two complementary aspects to provide security: @@ -154,16 +146,14 @@ Mimblewimble commitments are totally confidential and ownership cannot be proved unspent coins embedded in those commitments. Fortunately, any new UTXO requires a range proof, and this is impossible to create if the input commitment cannot be opened. - - ### The importance of Range Proofs The role that Bulletproof range proofs play in securing the blockchain can be demonstrated as follows. Let -$ C_a(v_1 , k_1) $ be the "closed" input UTXO commitment from Alice that a bad actor, Bob, is trying to lock away. +$ C*a(v_1 , k_1) $ be the "closed" input UTXO commitment from Alice that a bad actor, Bob, is trying to lock away. Bob knows that all commitments in a Mimblewimble blockchain are additionally homomorphic. This means that he can theoretically use Alice's commitment as input and create a new opposing output in a transaction that sums to a commitment of the value $ 0 $, i.e. $ (\mathbf{0}) $. For this opposing output, Bob will attempt to add an additional -blinding factor $ k_{x} $ to the commitment in such a way that the miners validating the transactions will not complain. +blinding factor $ k*{x} $ to the commitment in such a way that the miners validating the transactions will not complain. A valid Mimblewimble transaction would have the following form: @@ -188,8 +178,6 @@ If Bob can convince Alice that she must create a fund over which both of them ha multisig), it would theoretically be possible to create the required Bulletproof range proof for relation (1) if they work together to create it. - - ### Secure Sharing Protocol Multiple parties working together to create a single transaction that involves multiple steps, need to share information @@ -198,16 +186,12 @@ to replay an individual step's proof in a different context. Merlin transcripts protocol implementation that achieves this. For the purposes of this report, a simple information sharing protocol is proposed that can be implemented with Merlin transcripts [[7]]. - - ## Mimblewimble $ n\text{-of-}n $ Multiparty Bulletproof UTXO - - ### Simple Sharing Protocol Alice, Bob and Carol agree to set up a multiparty $ 3\text{-of-}3 $ multisig fund that they can control together. They -decide to use a sharing hash function $ val_H = \text{H}_{s}(arg) $ as a handshaking mechanism for all information +decide to use a sharing hash function $ val*H = \text{H}*{s}(arg) $ as a handshaking mechanism for all information they need to share. The first step is to calculate the hash $ val_H $ for the value $ arg $ they want to commit to in sharing, and to distribute it to all parties. They then wait until all other parties' commitments have been received. The second step is to send the actual value they committed to all parties, to then verify each @@ -218,8 +202,6 @@ This ensures that public values for each step are not exposed until all commitme this simple sharing protocol to all information they need to share with each other. This will be denoted by $ \text{share:} $. - - ### Setting up the Multiparty Funding Transaction In the transaction Alice, Bob and Carol want to set up, $ C_m $ is the multiparty shared commitment that contains the @@ -233,7 +215,6 @@ C_m(v_1, \sum _{j=1}^3 k_jG) - C_a(v_a, k_a) - C_b(v_b, k_b) - C_c(v_c, k_c) + \ \tag{2} $$ - In order for this scheme to work, they must be able to jointly sign the transaction with a Schnorr signature, while keeping their portion of the shared blinding factor secret. Each of them creates their own private blinding factor $ k_n $ for the multiparty shared commitment and shares the public blinding factor $ k_nG $ with the group: @@ -244,7 +225,7 @@ $$ $$ They proceed to calculate their own total excess blinding factors as -$ x_{sn} = \sum k_{n(change)} - \sum k_{n(inputs)} - \phi_n $, with $ \phi_n\ $ being a random offset of their own +$ x*{sn} = \sum k*{n(change)} - \sum k\_{n(inputs)} - \phi_n $, with $ \phi_n\ $ being a random offset of their own choosing (in this example there is no change): $$ @@ -256,9 +237,9 @@ x_{sc} &= 0 - k_c - \phi_c \tag{4} $$ -The offset $ \phi_n $ is introduced to prevent someone else linking this transaction's inputs and outputs when +The offset $ \phi*n $ is introduced to prevent someone else linking this transaction's inputs and outputs when analyzing the Mimblewimble block, and will be used later on to balance the transaction. They consequently share the -public value of the excess $ x_{sn}G $ with each other: +public value of the excess $ x*{sn}G $ with each other: $$ \text{share:} \mspace{9mu} \lbrace x_{sa}G, x_{sb}G, x_{sc}G \rbrace @@ -296,7 +277,7 @@ e = \text{Hash}(R_{agg} \| P_{agg} \| m) \mspace{18mu} \text{ with } \mspace{18m \tag{9} $$ -Each party now uses their private nonce $ r_n $, secret blinding factor $ k_n $ and excess $ x_{sn} $ to calculate a +Each party now uses their private nonce $ r*n $, secret blinding factor $ k_n $ and excess $ x*{sn} $ to calculate a partial Schnorr signature $ s_n $: $$ @@ -322,8 +303,8 @@ s_{agg} = s_a + s_b + s_c \tag{12} $$ -The resulting signature for the transaction is the tuple $ (s_{agg},R_{agg}) $. To validate the signature, publicly -shared aggregated values $ R_{agg} $ and $ P_{agg} $ will be needed: +The resulting signature for the transaction is the tuple $ (s*{agg},R*{agg}) $. To validate the signature, publicly +shared aggregated values $ R*{agg} $ and $ P*{agg} $ will be needed: $$ s_{agg}G \overset{?}{=} R_{agg} + e \cdot P_{agg} @@ -349,8 +330,6 @@ $$ \tag{15} $$ - - ### Creating the Multiparty Bulletproof Range Proof One crucial aspect in validating the transaction is still missing, i.e. each new UTXO must also include a Bulletproof @@ -359,8 +338,6 @@ secret. The new combined commitment they created $ (v_1H + (k_1 + k_2 + k_3)G) $ the Bulletproof range proof, otherwise the three parties would have to give up their portion of the shared blinding factor. Now they need to use a secure method to calculate their combined Bulletproof range proof. - - #### Utilizing Bulletproofs MPC Protocol This scheme involves coloring the UTXO to enable attachment of additional proof data, a flag to let the miners know that @@ -395,14 +372,14 @@ C_m(v_1, k_1 + k_2 + k_3) &= C_1(\frac{v_1}3,k_1) + C_2(\frac{v_1}3,k_2) + C_3(\ \tag{17} $$ -and that rounding implementation of $ ^{v_1} / _3 $ can ensure that adding these components for all parties will +and that rounding implementation of $ ^{v_1} / \_3 $ can ensure that adding these components for all parties will produce the original value $ v_1 $. Running the Bulletproof MPC range proof will result in a proof share for each party for their fake commitments, which will be aggregated by the dealer according to the MPC protocol. Any one of the party members can be the dealer, as the objective here is just to create the aggregated range proof. Let the aggregated range proof for the set -$ \lbrace C_1, C_2, C_3 \rbrace $ be depicted by $ RP_{agg} $. The UTXO will then consist of the tuple -$ (C_m , RP_{agg}) $ and metadata $ \lbrace flag, C_1, C_2, C_3, hash_{C_{m}} \rbrace $. The hash that will secure +$ \lbrace C*1, C_2, C_3 \rbrace $ be depicted by $ RP*{agg} $. The UTXO will then consist of the tuple +$ (C*m , RP*{agg}) $ and metadata $ \lbrace flag, C*1, C_2, C_3, hash*{C\_{m}} \rbrace $. The hash that will secure the metadata is proposed as: $$ @@ -428,8 +405,6 @@ $$ \tag{20} $$ - - #### Utilizing Grin's Shared Bulletproof Computation Grin extended the @@ -438,8 +413,8 @@ implementation to allow for multiple parties to jointly construct a single Bulle value $ v $, where each party can keep their partial blinding factor secret. The parties must share committed values deep within the inner-product range proof protocol ([[12]], [[13]], [[14]]). -In order to construct the shared Bulletproof range proof $ RP_m $, each party starts to calculate their own range proof -for commitment $ C_m(v_1, \sum _{j=1}^3 k_jG) $ as follows: +In order to construct the shared Bulletproof range proof $ RP*m $, each party starts to calculate their own range proof +for commitment $ C_m(v_1, \sum *{j=1}^3 k_jG) $ as follows: $$ \begin{aligned} @@ -453,13 +428,13 @@ $$ With this implementation, Alice needs to act as the dealer. When they get to [steps (53) to (61) in Figure 5](/cryptography/the-bulletproof-protocols#inner-product-range-proof) of the inner-product range proof protocol, they introduce the following changes: -1. Each party shares $ T\_{1\_j} $ and $ T\_{2\_j} $ with all other parties. -1. Each party calculates $ T\_1 = \sum\_{j=1}^k T\_{1\_j} $ and $ T_2 = \sum\_{j=1}^k T\_{2\_j} $. -1. Each party calculates $ \tau\_{x\_j} $ based on $ T\_1 $ and $ T\_2 $. -1. Each party shares $ \tau\_{x\_j} $ with the dealer. -1. The dealer calculates $\tau\_x = \sum\_{j=1}^k \tau\_{x\_j} $. -1. The dealer completes the protocol, using their own private $ k\_1 $, where a further blinding factor is required, and -calculates $ RP\_m $. +1. Each party shares $ T\_{1_j} $ and $ T\_{2_j} $ with all other parties. +1. Each party calculates $ T_1 = \sum\_{j=1}^k T\_{1_j} $ and $ T_2 = \sum\_{j=1}^k T\_{2_j} $. +1. Each party calculates $ \tau\_{x_j} $ based on $ T_1 $ and $ T_2 $. +1. Each party shares $ \tau\_{x_j} $ with the dealer. +1. The dealer calculates $\tau_x = \sum\_{j=1}^k \tau\_{x_j} $. +1. The dealer completes the protocol, using their own private $ k_1 $, where a further blinding factor is required, and + calculates $ RP_m $. Using this approach, the resulting shared commitment for Alice, Bob and Carol is @@ -471,23 +446,17 @@ $$ with the UTXO tuple being $ (C_m , RP_m) $. Range proof validation by miners will involve verifying $ RP_m $ for $ C_m $. - - #### Comparison of the Two Bulletproof Methods - - -| Consideration | Using Dalek's Bulletproofs MPC Protocol | Using Grin's Multiparty Bulletproof | -| ----------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| Rounds of communication | Three | Two | -| Information sharing security | Use of Merlin transcripts, combined with the MPC protocol, makes this method more secure against replay attacks. | No specific sharing protocol suggested, but potentially easy to implement, as described [here](#simple-sharing-protocol). | -| Guarantee of honest dealer | With the standard MPC protocol implementation, there is no guarantee that the dealer behaves honestly according to the protocol and generates challenges honestly, but this aspect could be improved [as suggested](/cryptography/the-bulletproof-protocols#mpc-protocol-security-discussion) in that report. | Although each party independently computes challenges themselves, it isn't clear what the implications of a dishonest dealer would be in practice. | -| Size of the Bulletproof | Logarithmic Bulletproof range proof size, i.e. 672 bytes up to 928 bytes for 16 range proofs. | Single Bulletproof range proof size of 672 bytes. | -| Colored coin | Coins are colored, i.e. distinguishable from normal commitments in the blockchain due to additional metadata. | Coins do not need to be colored, i.e. it may look exactly like any other commitment. | +| Consideration | Using Dalek's Bulletproofs MPC Protocol | Using Grin's Multiparty Bulletproof | +| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Rounds of communication | Three | Two | +| Information sharing security | Use of Merlin transcripts, combined with the MPC protocol, makes this method more secure against replay attacks. | No specific sharing protocol suggested, but potentially easy to implement, as described [here](#simple-sharing-protocol). | +| Guarantee of honest dealer | With the standard MPC protocol implementation, there is no guarantee that the dealer behaves honestly according to the protocol and generates challenges honestly, but this aspect could be improved [as suggested](/cryptography/the-bulletproof-protocols#mpc-protocol-security-discussion) in that report. | Although each party independently computes challenges themselves, it isn't clear what the implications of a dishonest dealer would be in practice. | +| Size of the Bulletproof | Logarithmic Bulletproof range proof size, i.e. 672 bytes up to 928 bytes for 16 range proofs. | Single Bulletproof range proof size of 672 bytes. | +| Colored coin | Coins are colored, i.e. distinguishable from normal commitments in the blockchain due to additional metadata. | Coins do not need to be colored, i.e. it may look exactly like any other commitment. | | Wallet reconstructability | Each individual range proof's data is accessible within the aggregated range proof. It is possible to identify the colored coin and then to reconstruct the wallet if the initial blinding factor seed is remembered in conjunction with [Bulletproof range proof rewinding](/cryptography/bulletproofs-and-mimblewimble#improved-implementation). | The wallet cannot be reconstructed, as a single party's blinding factor cannot be distinguished from the combined range proof. Even if these coins were colored with a flag to make them identifiable, it would not help. | -| Hiding and binding commitment | The main commitment and additional commitments in the UTXO's metadata retain all hiding and binding security aspects of the Pederson Commitment. | The commitment retains all hiding and binding security aspects of the Pederson Commitment. | - - +| Hiding and binding commitment | The main commitment and additional commitments in the UTXO's metadata retain all hiding and binding security aspects of the Pederson Commitment. | The commitment retains all hiding and binding security aspects of the Pederson Commitment. | ### Spending the Multiparty UTXO @@ -502,9 +471,9 @@ C^{'}_c(v^{'}_c, k^{'}_c) + C^{'}_m(v^{'}_1, \sum _{j=1}^3 k^{'}_{j}G) - C_m(v_1 \tag{23} $$ -Similar to the initial transaction, they each create their own private blinding factor $ k^{'}_n $ for the new -multiparty UTXO and share the public blinding factor $ k^{'}_nG $ with the group. Carol also shares the public -blinding factor $ k^{'}_cG $ for her winnings: +Similar to the initial transaction, they each create their own private blinding factor $ k^{'}\_n $ for the new +multiparty UTXO and share the public blinding factor $ k^{'}\_nG $ with the group. Carol also shares the public +blinding factor $ k^{'}\_cG $ for her winnings: $$ \begin{aligned} @@ -515,7 +484,7 @@ $$ $$ As before, they calculate their own total excess blinding factors as -$ x^{'}\_{sn} = \sum k^{'}\_{n(change)} - \sum k^{'}_{n(inputs)} - \phi^{'}_n $: +$ x^{'}\_{sn} = \sum k^{'}\_{n(change)} - \sum k^{'}\_{n(inputs)} - \phi^{'}\_n $: $$ \begin{aligned} @@ -526,7 +495,7 @@ x^{'}_{sc} &= 0 - k_3 - \phi^{'}_c \tag{25} $$ -They share the public value of the excess $ x^{'}_{sn}G $ with each other: +They share the public value of the excess $ x^{'}\_{sn}G $ with each other: $$ \text{share:} \mspace{9mu} \lbrace x^{'}_{sa}G, x^{'}_{sb}G, x^{'}_{sc}G \rbrace @@ -543,7 +512,7 @@ P^{'}_{agg} = (k^{'}_1G - (k_1 + \phi^{'}_a)G) + (k^{'}_2G - (k_2 + \phi^{'}_a)G \tag{27} $$ -Each party again selects a private nonce $ r^{'}_n $, shares the public value $ r^{'}_nG $ with the group, +Each party again selects a private nonce $ r^{'}\_n $, shares the public value $ r^{'}\_nG $ with the group, $$ \text{share:} \mspace{9mu} \lbrace r^{'}_aG, r^{'}_bG, r^{'}_cG \rbrace @@ -564,8 +533,8 @@ e^{'} = \text{Hash}(R^{'}_{agg} \| P^{'}_{agg} \| m) \mspace{18mu} \text{ with } \tag{30} $$ -Each party now calculates their partial Schnorr signature $ s^{'}_n $ as before, except that Carol also adds her -winnings' blinding factor $ k^{'}_c $ to her signature: +Each party now calculates their partial Schnorr signature $ s^{'}\_n $ as before, except that Carol also adds her +winnings' blinding factor $ k^{'}\_c $ to her signature: $$ \begin{aligned} @@ -614,8 +583,6 @@ $$ \tag{36} $$ - - ## Mimblewimble $ m\text{-of-}n $ Multiparty Bulletproof UTXO As mentioned in the [Introduction](#introduction), Mimblewimble transactions cannot utilize a smart/redeem script in the @@ -635,8 +602,6 @@ the SSSS, where the dealer commits to the secret $ s $ itself and the coefficien This is broadcast to all parties, with each receiving a blinding factor shard $ g(i) $ corresponding to their secret shard $ f(i) $. This will enable each party to verify that their shard is correct. - - ### Secret Sharing Our friends Alice, Bob and Carol decide to set up a $ 2\text{-of-}3 $ scheme, whereby any two of them can authorize a @@ -645,26 +610,22 @@ of spending, with the last round being the closing round. Something they were al of their blinding factor with each other in a secure and reconstructable fashion. They have heard of Pedersen's VSS scheme and decide to use that. - - ### Multiple Rounds' Data -The parties will each pre-calculate $ three $ private blinding factors $ k_{n\text{-}i} $ and shard it according to +The parties will each pre-calculate $ three $ private blinding factors $ k*{n\text{-}i} $ and shard it according to [Pedersen's VSS][pvss~] scheme. The scheme requires $ three $ shard tuples -$ (k_{n\text{-}party\text{-}i}, b_{n\text{-}party\text{-}i}) $ and $ three $ vectors of commitments -$\mathbf{C}\_{2}( k_{party\text{-}1})$ for each round. ([Appendix C](#appendix-c-shamirs-secret-sharing-example) +$ (k*{n\text{-}party\text{-}i}, b*{n\text{-}party\text{-}i}) $ and $ three $ vectors of commitments +$\mathbf{C}\_{2}( k*{party\text{-}1})$ for each round. ([Appendix C](#appendix-c-shamirs-secret-sharing-example) shows an example of Alice's sharing shards for one private blinding factor.) Whenever a set of information for each blinding factor is shared, the parties immediately verify the correctness of the shards they received by following the verification step in Pedersen's VVS protocol. They continue to do this until they have all their information set up, ready and stored in their wallets. -| Round | Blinding
Factor | Vectors of
Commitments | Alice's
Shards | Bob's
Shards | Carol's
Shards | -| ----- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -| 1 | Alice: $ (k_{1\text{-}1}, b_{1\text{-}1}) $
Bob:   $ (k_{2\text{-}1}, b_{2\text{-}1}) $
Carol: $ (k_{3\text{-}1}, b_{3\text{-}1})$ | $\mathbf{C_{2}}( k_{1\text{-}1})$
$ \mathbf{C_{2}}( k_{2\text{-}1}) $
$\mathbf{C_{2}}( k_{3\text{-}1}) $ | $ (k_{1\text{-}a1}, b_{1\text{-}a1}) $
$ (k_{2\text{-}a1}, b_{2\text{-}a1}) $
$ (k_{3\text{-}a1}, b_{3\text{-}a1}) $ | $ (k_{1\text{-}b1}, b_{1\text{-}b1}) $
$ (k_{2\text{-}b1}, b_{2\text{-}b1}) $
$ (k_{3\text{-}b1}, b_{3\text{-}b1}) $ | $ (k_{1\text{-}c1}, b_{1\text{-}c1}) $
$ (k_{2\text{-}c1}, b_{2\text{-}c1}) $
$ (k_{3\text{-}c1}, b_{3\text{-}c1}) $ | -| 2 | Alice: $ (k_{1\text{-}2}, b_{1\text{-}2}) $
Bob:   $ (k_{2\text{-}2}, b_{2\text{-}2}) $
Carol: $ (k_{3\text{-}2}, b_{3\text{-}2}) $ | $ \mathbf{C_{2}}( k_{1\text{-}2}) $
$ \mathbf{C_{2}}( k_{2\text{-}2}) $
$ \mathbf{C_{2}}( k_{3\text{-}2}) $ | $ (k_{1\text{-}a2}, b_{1\text{-}a2}) $
$ (k_{2\text{-}a2}, b_{2\text{-}a2}) $
$ (k_{3\text{-}a2}, b_{3\text{-}a2}) $ | $ (k_{1\text{-}b2}, b_{1\text{-}b2}) $
$ (k_{2\text{-}}b2, b_{2\text{-}b2}) $
$ (k_{3\text{-}},b2 b_{3\text{-}b2}) $ | $ (k_{1\text{-}c2}, b_{1\text{-}c2}) $
$ (k_{2\text{-}}c2, b_{2\text{-}c2}) $
$ (k_{3\text{-}},c2 b_{3\text{-}c2}) $ | -| 3 | Alice: $ (k_{1\text{-}3}, b_{1\text{-}3}) $
Bob:   $ (k_{2\text{-}3}, b_{2\text{-}3}) $
Carol: $ (k_{3\text{-}3}, b_{3\text{-}3}) $ | $ \mathbf{C_{2}}( k_{1\text{-}3}) $
$ \mathbf{C_{2}}( k_{2\text{-}3}) $
$ \mathbf{C_{2}}( k_{3\text{-}3}) $ | $ (k_{1\text{-}a3}, b_{1\text{-}a3}) $
$ (k_{2\text{-}a3}, b_{2\text{-}a3}) $
$ (k_{3\text{-}a3}, b_{3\text{-}a3}) $ | $ (k_{1\text{-}b3}, b_{1\text{-}b3}) $
$ (k_{2\text{-}}b3, b_{2\text{-}b3}) $
$ (k_{3\text{-}},b3 b_{3\text{-}b3}) $ | $ (k_{1\text{-}c3}, b_{1\text{-}c3}) $
$ (k_{2\text{-}}c3, b_{2\text{-}c3}) $
$ (k_{3\text{-}},c3 b_{3\text{-}c3}) $ | - - +| Round | Blinding
Factor | Vectors of
Commitments | Alice's
Shards | Bob's
Shards | Carol's
Shards | +| ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | +| 1 | Alice: $ (k*{1\text{-}1}, b*{1\text{-}1}) $
Bob:   $ (k*{2\text{-}1}, b*{2\text{-}1}) $
Carol: $ (k*{3\text{-}1}, b*{3\text{-}1})$ | $\mathbf{C_{2}}( k_{1\text{-}1})$
$ \mathbf{C*{2}}( k*{2\text{-}1}) $
$\mathbf{C*{2}}( k*{3\text{-}1}) $ | $ (k*{1\text{-}a1}, b*{1\text{-}a1}) $
$ (k*{2\text{-}a1}, b*{2\text{-}a1}) $
$ (k*{3\text{-}a1}, b*{3\text{-}a1}) $ | $ (k*{1\text{-}b1}, b*{1\text{-}b1}) $
$ (k*{2\text{-}b1}, b*{2\text{-}b1}) $
$ (k*{3\text{-}b1}, b*{3\text{-}b1}) $ | $ (k*{1\text{-}c1}, b*{1\text{-}c1}) $
$ (k*{2\text{-}c1}, b*{2\text{-}c1}) $
$ (k*{3\text{-}c1}, b*{3\text{-}c1}) $ | +| 2 | Alice: $ (k*{1\text{-}2}, b*{1\text{-}2}) $
Bob:   $ (k*{2\text{-}2}, b*{2\text{-}2}) $
Carol: $ (k*{3\text{-}2}, b*{3\text{-}2}) $ | $ \mathbf{C*{2}}( k*{1\text{-}2}) $
$ \mathbf{C*{2}}( k*{2\text{-}2}) $
$ \mathbf{C*{2}}( k*{3\text{-}2}) $ | $ (k*{1\text{-}a2}, b*{1\text{-}a2}) $
$ (k*{2\text{-}a2}, b*{2\text{-}a2}) $
$ (k*{3\text{-}a2}, b*{3\text{-}a2}) $ | $ (k*{1\text{-}b2}, b*{1\text{-}b2}) $
$ (k*{2\text{-}}b2, b*{2\text{-}b2}) $
$ (k*{3\text{-}},b2 b*{3\text{-}b2}) $ | $ (k*{1\text{-}c2}, b*{1\text{-}c2}) $
$ (k*{2\text{-}}c2, b*{2\text{-}c2}) $
$ (k*{3\text{-}},c2 b*{3\text{-}c2}) $ | +| 3 | Alice: $ (k*{1\text{-}3}, b*{1\text{-}3}) $
Bob:   $ (k*{2\text{-}3}, b*{2\text{-}3}) $
Carol: $ (k*{3\text{-}3}, b*{3\text{-}3}) $ | $ \mathbf{C*{2}}( k*{1\text{-}3}) $
$ \mathbf{C*{2}}( k*{2\text{-}3}) $
$ \mathbf{C*{2}}( k*{3\text{-}3}) $ | $ (k*{1\text{-}a3}, b*{1\text{-}a3}) $
$ (k*{2\text{-}a3}, b*{2\text{-}a3}) $
$ (k*{3\text{-}a3}, b*{3\text{-}a3}) $ | $ (k*{1\text{-}b3}, b*{1\text{-}b3}) $
$ (k*{2\text{-}}b3, b*{2\text{-}b3}) $
$ (k*{3\text{-}},b3 b*{3\text{-}b3}) $ | $ (k*{1\text{-}c3}, b*{1\text{-}c3}) $
$ (k*{2\text{-}}c3, b*{2\text{-}c3}) $
$ (k*{3\text{-}},c3 b*{3\text{-}c3}) $ | ### How it Works @@ -698,8 +659,8 @@ $$ $$ For this round they choose Bob to play Alice's part when they set up and conclude the transaction. Bob is able to do -this, because he now has Alice's private blinding factors $ k_{1\text{-}1} $ and $ k_{1\text{-}2} $. When constructing -the signature on Alice's behalf, he chooses a private nonce $ r^{'}_n $ she does not know, as it will only be used to +this, because he now has Alice's private blinding factors $ k*{1\text{-}1} $ and $ k*{1\text{-}2} $. When constructing +the signature on Alice's behalf, he chooses a private nonce $ r^{'}\_n $ she does not know, as it will only be used to construct the signature and then never again. Bob and Carol conclude the transaction, let Alice know this and inform her that a consecutive multi-spend needs to start at round 2. @@ -707,30 +668,24 @@ The next time two of our friends want to spend some or all of the remainder of t repeat these steps, starting at round 2. The only thing that will be different will be the person nominated to play the part of the party that is absent; they have to take turns at this. - - ### Spending Protocol Alice, Bob and Carol are now seasoned at setting up their $ 2\text{-of-}3 $ scheme and spending the UTXO until all funds are depleted. They have come to an agreement on a simple spending protocol, something to help keep all of them honest: - All parties must always know who shared shards and who played the missing party's role for each round. Therefore, all -parties must always be included in all sharing communication, even if they are offline. They can then receive those -messages when they become available again. + parties must always be included in all sharing communication, even if they are offline. They can then receive those + messages when they become available again. - The spend is aborted if any verification step does not complete successfully. To recommence, the parties have to -cancel all unused shards, calculate new shards for the remainder and start again. For this, all parties need to be -present. + cancel all unused shards, calculate new shards for the remainder and start again. For this, all parties need to be + present. - No party may play the role of an absent party twice in a row. If Alice is absent, which usually happens, Bob and Carol -must take turns. - - + must take turns. ## Conclusions, Observations and Recommendations - - ### Comparison to Bitcoin Given the basic differences between Bitcoin and Mimblewimble as mentioned in the [Introduction](#introduction), and the @@ -759,8 +714,6 @@ multiparty payment scheme introduced here, the following observations can be mad Implementing $ m\text{-of-}n $ multiparty transactions in Mimblewimble will involve wallets to store more data and implement more functionality than when compared to Bitcoin, e.g. Pedersen's VSS scheme. - - ### General 1. Bulletproof Range Proof @@ -784,160 +737,134 @@ multiparty payment scheme introduced here, the following observations can be mad Although all examples presented here were for three parties, this could easily be generalized. - - ## References [[1]] "The Best Step-by-Step Bitcoin Script Guide Part 2" [online]. Available: . Date accessed: 2019‑05‑02. -[1]: https://blockgeeks.com/guides/bitcoin-script-guide-part-2 -"The Best Step-by-Step Bitcoin Script Guide Part 2" +[1]: https://blockgeeks.com/guides/bitcoin-script-guide-part-2 'The Best Step-by-Step Bitcoin Script Guide Part 2' [[2]] "Script" [online]. Available: . Date accessed: 2019‑05‑06. -[2]: https://en.bitcoin.it/wiki/Script -"Script" +[2]: https://en.bitcoin.it/wiki/Script 'Script' [[3]] "Multisignature" [online]. Available: . Date accessed: 2019‑05‑06. -[3]: https://en.bitcoin.it/wiki/Multisignature -"Multisignature" +[3]: https://en.bitcoin.it/wiki/Multisignature 'Multisignature' [[4]] "Transaction" [online]. Available: . Date accessed: 2019‑05‑06. -[4]: https://en.bitcoin.it/wiki/Transaction -"Transaction" +[4]: https://en.bitcoin.it/wiki/Transaction 'Transaction' [[5]] S. Pour, "Bitcoin Multisig the Hard Way: Understanding Raw P2SH Multisig Transactions" [online]. Available: . Date accessed: 2019‑05‑06. -[5]: https://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions -"Bitcoin Multisig the Hard Way: -Understanding Raw P2SH Multisig Transactions" +[5]: https://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions 'Bitcoin Multisig the Hard Way: +Understanding Raw P2SH Multisig Transactions' [[6]] GitHub: "gavinandresen/TwoOfThree.sh" [online]. Available: . Date accessed: 2019‑05‑06. -[6]: https://gist.github.com/gavinandresen/3966071 -"GitHub: gavinandresen/TwoOfThree.sh" +[6]: https://gist.github.com/gavinandresen/3966071 'GitHub: gavinandresen/TwoOfThree.sh' [[7]] H.de Valence, I. Lovecruft and O. Andreev, "Merlin Transcripts" [online]. Available: and . Date accessed: 2019‑05‑10. -[7]: https://doc-internal.dalek.rs/merlin/index.html -"Merlin Transcripts" +[7]: https://doc-internal.dalek.rs/merlin/index.html 'Merlin Transcripts' [[8]] T. Pedersen, "Non-interactive and Information-theoretic Secure Verifiable Secret Sharing" [online]. Available: . Date accessed: 2019‑05‑10. -[8]: https://www.cs.cornell.edu/courses/cs754/2001fa/129.pdf -"Non-interactive and Information-theoretic -Secure Verifiable Secret Sharing" +[8]: https://www.cs.cornell.edu/courses/cs754/2001fa/129.pdf 'Non-interactive and Information-theoretic +Secure Verifiable Secret Sharing' [[9]] "GrinExplorer, Block 164,690" [online]. Available: . Date accessed: 2019‑05‑10. -[9]: https://grinexplorer.net/block/0000016c1ceb1cf588a45d0c167dbfb15d153c4d1d33a0fbfe0c55dbf7635410 -"GitHub: gavinandresen/TwoOfThree.sh" +[9]: https://grinexplorer.net/block/0000016c1ceb1cf588a45d0c167dbfb15d153c4d1d33a0fbfe0c55dbf7635410 'GitHub: gavinandresen/TwoOfThree.sh' [[10]] "Dalek Cryptography - Crate Bulletproofs - Module bulletproofs::range_proof_mpc" [online]. Available: . Date accessed: 2019‑05‑10. -[10]: https://doc-internal.dalek.rs/bulletproofs/range_proof_mpc/index.html -"Dalek Cryptography - Crate Bulletproofs -Module bulletproofs::range_proof_mpc" +[10]: https://doc-internal.dalek.rs/bulletproofs/range_proof_mpc/index.html 'Dalek Cryptography - Crate Bulletproofs +Module bulletproofs::range_proof_mpc' [[11]] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell, "Bulletproofs: Short Proofs for Confidential Transactions and More" (Slides) [online]. Available: . Date accessed: 2019‑05‑11. -[11]: https://cyber.stanford.edu/sites/default/files/bpase18.pptx -"Bulletproofs: Short Proofs for Confidential Transactions and More (Slides)" +[11]: https://cyber.stanford.edu/sites/default/files/bpase18.pptx 'Bulletproofs: Short Proofs for Confidential Transactions and More (Slides)' [[12]] "Grin Multiparty Bulletproof - jaspervdm" [online]. Available: . Date accessed: 2019‑05‑10. -[12]: https://i.imgur.com/s7exNSf.png -"Grin Multiparty Bulletproof - jaspervdm" +[12]: https://i.imgur.com/s7exNSf.png 'Grin Multiparty Bulletproof - jaspervdm' [[13]] GitHub: "Multi-party bulletproof PR#24" [online]. Available: . Date accessed: 2019‑05‑10. -[13]: https://github.com/mimblewimble/secp256k1-zkp/pull/24 -"GitHub: Multi-party bulletproof PR#24" +[13]: https://github.com/mimblewimble/secp256k1-zkp/pull/24 'GitHub: Multi-party bulletproof PR#24' [[14]] GitHub: "secp256k1-zkp/src/modules/bulletproofs/tests_impl.h, test_multi_party_bulletproof" [online]. Available: . Date accessed: 2019‑05‑10. -[14]: https://github.com/mimblewimble/secp256k1-zkp/blob/master/src/modules/bulletproofs/tests_impl.h -"GitHub: secp256k1-zkp/src/modules/bulletproofs/tests_impl.h, -test_multi_party_bulletproof" +[14]: https://github.com/mimblewimble/secp256k1-zkp/blob/master/src/modules/bulletproofs/tests_impl.h 'GitHub: secp256k1-zkp/src/modules/bulletproofs/tests_impl.h, +test_multi_party_bulletproof' [[15]] "MATH3024 Elementary Cryptography and Protocols: Lecture 11, Secret Sharing", University of Sydney, School of Mathematics and Statistics [online]. Available: . Date accessed: 2018‑09‑18. -[15]: http://iml.univ-mrs.fr/~kohel/tch/MATH3024/Lectures/lectures_11.pdf -"MATH3024 Elementary Cryptography and Protocols: -Lecture 11, Secret Sharing" +[15]: http://iml.univ-mrs.fr/~kohel/tch/MATH3024/Lectures/lectures_11.pdf 'MATH3024 Elementary Cryptography and Protocols: +Lecture 11, Secret Sharing' [[16]] I. Coleman, "Online Tool: Shamir Secret Sharing Scheme" [online]. Available: . Date accessed: 2019‑05‑27. -[16]: https://iancoleman.io/shamir -"Online Tool: Shamir Secret Sharing Scheme" +[16]: https://iancoleman.io/shamir 'Online Tool: Shamir Secret Sharing Scheme' [[17]] P. Laud, "Cryptographic Protocols (MTAT.07.005): Secret Sharing", Cybernetica [online]. Available: . Date accessed: 2019‑05‑29. -[17]: https://research.cyber.ee/~peeter/teaching/krprot07s/ss.pdf -"Cryptographic Protocols (MTAT.07.005): Secret Sharing" +[17]: https://research.cyber.ee/~peeter/teaching/krprot07s/ss.pdf 'Cryptographic Protocols (MTAT.07.005): Secret Sharing' [[18]] T. Pedersen, "Distributed Provers and Verifiable Secret Sharing Based on the Discrete Logarithm Problem", DPB, vol. 21, no. 388, Mar. 1992 [online]. Available: . Date accessed: 2019‑06‑03. -[18]: https://doi.org/10.7146/dpb.v21i388.6621 -"Distributed Provers and Verifiable Secret Sharing -Based on the Discrete Logarithm Problem" +[18]: https://doi.org/10.7146/dpb.v21i388.6621 'Distributed Provers and Verifiable Secret Sharing +Based on the Discrete Logarithm Problem' [[19]] Wikipedia: "Shamir's Secret Sharing" [online]. Available: . Date accessed: 2019‑05‑06. -[19]: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing -"Wikipedia: Shamir's Secret Sharing" - - +[19]: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing "Wikipedia: Shamir's Secret Sharing" ## Appendices - - ### Appendix A: Notation Used This section gives the general notation of mathematical expressions used. It provides important pre-knowledge for the remainder of the report. -- All Pedersen Commitments will be of the [elliptic derivative]((/cryptography/the-bulletproof-protocols#pedersen-commitments-and-elliptic-curve-pedersen-commitments)) -depicted by $ C(v,k) = (vH + kG) $ with $ v $ being the value committed to and $ k $ being the blinding factor. +- All Pedersen Commitments will be of the elliptic derivative + depicted by $ C(v,k) = (vH + kG) $ with $ v $ being the value committed to and $ k $ being the blinding factor. - Scalar multiplication will be depicted by "$ \cdot $", e.g. $ e \cdot (vH + kG) = e \cdot vH + e \cdot kG $. - A Pedersen Commitment to the value of $ 0 $ will be depicted by $ C(0,k) = (0H + kG) = (kG) = (\mathbf{0}) $. -- Let $ \text{H}_{s}(arg) $ be a collision-resistant hash function used in an information sharing protocol where -$ arg $ is the value being committed to. +- Let $ \text{H}\_{s}(arg) $ be a collision-resistant hash function used in an information sharing protocol where + $ arg $ is the value being committed to. - Let $ RP_n $ be Bulletproof range proof data for commitment $ C_n $. -- Let $ RP_{agg} $ be aggregated Bulletproof range proof data for a set of commitments -$ \lbrace C_1, C_2, ... , C_n \rbrace $. - -- Let $ \mathbf {C_{m}}(v) $ be a vector of commitments $ (C_0 , \ldots , C_{m-1}) $ for value $ v $. +- Let $ RP\_{agg} $ be aggregated Bulletproof range proof data for a set of commitments + $ \lbrace C_1, C_2, ... , C_n \rbrace $. +- Let $ \mathbf {C*{m}}(v) $ be a vector of commitments $ (C_0 , \ldots , C*{m-1}) $ for value $ v $. ### Appendix B: Definition of Terms @@ -945,13 +872,13 @@ Definitions of terms presented here are high level and general in nature. Full m the cited references. - **Shamir's Secret Sharing Scheme:** A $ (m, n) $ threshold secret sharing scheme is a method for -$ n $ parties to carry shards/shares of a secret message $ s $ such that any $ m $ of them can reconstruct the message. -The threshold scheme is perfect if knowledge of $ m − 1 $ or fewer shards provides no information regarding $ s $. -Shamir's Secret Sharing Scheme provides a perfect $ (m, n) $ threshold scheme using Lagrange interpolation -([[15]], [[17], [[19]]). + $ n $ parties to carry shards/shares of a secret message $ s $ such that any $ m $ of them can reconstruct the message. + The threshold scheme is perfect if knowledge of $ m − 1 $ or fewer shards provides no information regarding $ s $. + Shamir's Secret Sharing Scheme provides a perfect $ (m, n) $ threshold scheme using Lagrange interpolation + ([[15]], [[17], [[19]]). - Given $ m $ distinct points $ (x_i, y_i) $ of the form $ (x_i, f(x_i)) $, where $ f(x) $ is a polynomial of - degree less than $ m $, then according to the Lagrange interpolation formula $ f(x) $ and $ f(0) $ is determined by + degree less than $ m $, then according to the Lagrange interpolation formula $ f(x) $ and $ f(0) $ is determined by $$ f(x) = \sum _{i=1}^{m} y _{i} \prod _{1 \leq j \leq m \atop i \neq j} \frac{x - x _{j}}{x _{i} - x _{j}} \\\\ @@ -964,8 +891,8 @@ Shamir's Secret Sharing Scheme provides a perfect $ (m, n) $ threshold scheme us $$ - Shamir’s scheme is defined for a secret message $ s \in \mathbb{Z}/p\mathbb{Z} $ with prime $ p $, by setting - $ a_0 = f(0) = s$ for a polynomial $ f(x) $, and choosing the other coefficients $ a_1, \ldots , a_{m−1} $ at - random in $ \mathbb{Z}/p\mathbb{Z} $. The trusted party computes $ f(i) $ for all $ 1 \leq i \leq n $, where + $ a*0 = f(0) = s$ for a polynomial $ f(x) $, and choosing the other coefficients $ a_1, \ldots , a*{m−1} $ at + random in $ \mathbb{Z}/p\mathbb{Z} $. The trusted party computes $ f(i) $ for all $ 1 \leq i \leq n $, where $$ f(x) = \sum _{k=0}^{m - 1} a _{k} x^{k} = a_0x^0 + a_1x^1 + a_2x^2 + \ldots + a_{m-1}x^{m-1} @@ -973,46 +900,45 @@ Shamir's Secret Sharing Scheme provides a perfect $ (m, n) $ threshold scheme us $$ - The shards $ (i, f(i)) $ are distributed to the $ n $ distinct parties. Since the secret is the constant term - $ s = a_0 = f(0) $, it is recovered from any $ m $ shards $ (i, f(i)) $ for $ I \subset \lbrace 1, \ldots, n \rbrace $ - by + $ s = a_0 = f(0) $, it is recovered from any $ m $ shards $ (i, f(i)) $ for $ I \subset \lbrace 1, \ldots, n \rbrace $ + by $$ s = \sum _{i \in I} f(i) \prod _{j \in I \atop j \neq i} \frac{i}{j - i} \tag{B4} $$ -[ssss~]: #ssss -"Appendix B: +[ssss~]: #ssss "Appendix B: Shamir's Secret Sharing Scheme is an (m, n) threshold scheme for n parties to carry shares of a secret message such that any m of them can reconstruct the message." - **Pedersen Verifiable Secret Sharing:** The Pedersen Verifiable Secret Sharing scheme is a -non-interactive $ (m, n) $ threshold VSS scheme that combines -[Pedersen Commitments](/cryptography/the-bulletproof-protocols#pedersen-commitments-and-elliptic-curve-pedersen-commitments) -and [Shamir's Secret Sharing Scheme][ssss~] ([[8]], [[17]], [[18]). This is to ensure the dealer gives consistent shares -to all parties and that any party can know that the recovered secret is correct. + non-interactive $ (m, n) $ threshold VSS scheme that combines + [Pedersen Commitments](/cryptography/the-bulletproof-protocols#pedersen-commitments-and-elliptic-curve-pedersen-commitments) + and [Shamir's Secret Sharing Scheme][ssss~] ([[8]], [[17]], [[18]). This is to ensure the dealer gives consistent shares + to all parties and that any party can know that the recovered secret is correct. - The dealer creates a commitment to the secret $ s $ for a randomly chosen blinding factor $ r $ as - $ C_0(s,r) = (sH + rG) $. + $ C_0(s,r) = (sH + rG) $. - - The dealer constructs the SSSS sharing polynomial $ f(x) $ as before by setting $ a_0 = s $, and randomly - choosing $ a_1, \ldots , a_{m−1} $. + - The dealer constructs the SSSS sharing polynomial $ f(x) $ as before by setting $ a*0 = s $, and randomly + choosing $ a_1, \ldots , a*{m−1} $. - The dealer also constructs a blinding factor polynomial $ g(x) $, similar to the SSSS polynomial, by setting - $ b_0 = r $, and randomly choosing $ b_1, \ldots , b_{m−1} $. + $ b*0 = r $, and randomly choosing $ b_1, \ldots , b*{m−1} $. - The dealer constructs commitments to the secret coefficients of $ f(x) $ as $ C_i(a_i,b_i) = (a_iH + b_iG) $ - for $ i \in \lbrace 1, \ldots, m-1 \rbrace $. + for $ i \in \lbrace 1, \ldots, m-1 \rbrace $. - - The dealer broadcasts the vector of commitments $ \mathbf {C_{m}} = (C_0 , \ldots , C_{m-1}) $ to all parties. + - The dealer broadcasts the vector of commitments $ \mathbf {C*{m}} = (C_0 , \ldots , C*{m-1}) $ to all parties. - The dealer calculates $ (f(i), g(i)) $ from polynomials $ f(x), g(x) $ for $ i \in \lbrace 1, \ldots, n \rbrace $ - and distributes the individual shards $ (i, f(i), g(i)) $ to the $ n $ distinct parties. + and distributes the individual shards $ (i, f(i), g(i)) $ to the $ n $ distinct parties. - Upon receipt of their shard $ (i, f(i), g(i)) $, each party calculates their own commitment $ (f(i)H + g(i)G) $ and - verifies that: + verifies that: $$ \begin{aligned} @@ -1035,24 +961,21 @@ to all parties and that any party can know that the recovered secret is correct. \tag{B6} $$ - - Since $ C_0 $ is the first entry in the vector of commitments $ \mathbf {C_{m}} $, the parties can verify the - correctness of the original secret $ s $ that was committed to in the first place when the shards have been shared - among the parties as: + - Since $ C*0 $ is the first entry in the vector of commitments $ \mathbf {C*{m}} $, the parties can verify the + correctness of the original secret $ s $ that was committed to in the first place when the shards have been shared + among the parties as: $$ C_0(s,r) \overset{?}{=} (sH + rG) \tag{B7} $$ -[pvss~]: #pvss -"Appendix B: +[pvss~]: #pvss "Appendix B: The Pedersen Verifiable Secret Sharing scheme is a non-interactive (m, n) threshold scheme that combines Pedersen commitments and Shamir's Secret Sharing Scheme." - - ### Appendix C: Shamir's Secret Sharing Example One of the private blinding factors Alice calculated and wants to share with Bob and Carol is @@ -1081,8 +1004,6 @@ Using any two of these shards with the tool provided in [[16]], Alice's original **Note:** This example shows blinding factor shards created with the SSSS tool developed by Coleman [[16]]. It was merely developed for demonstration purposes and does not make any claims to meet cryptographic security rules other than using secure randomness. - - ## Contributors - diff --git a/_includes/content/scaling/01-layer2scaling-survey.md b/_includes/content/scaling/01-layer2scaling-survey.md index f7c53866..3930f9a9 100644 --- a/_includes/content/scaling/01-layer2scaling-survey.md +++ b/_includes/content/scaling/01-layer2scaling-survey.md @@ -199,7 +199,7 @@ _Who uses them?_ **On NEO:** -Trinity ([[3]], [[17]], [[18]]) +Trinity ([[3]], [[18]]) - Trinity is an open-source network protocol based on NEP-5 smart contracts. - Trinity for NEO is the same as the Raiden Network for Ethereum. @@ -596,19 +596,16 @@ state or division keeps some internal autonomy" ([[97]], [[98]], [[71]]). _Who uses it?_ The most notable projects built on top of Counterparty are [Age of Chains](https://www.ageofchains.com), -[Age of Rust](http://spacepirate.io), [Augmentors](https://www.augmentorsgame.com/), [Authparty](http://authparty.io/), -[Bitcorns](https://bitcorns.com/), [Blockfreight™](http://blockfreight.com/), -[Blocksafe](http://www.blocksafefoundation.com), [BTCpaymarket.com](http://btcpaymarket.com), [CoinDaddy](http://coindaddy.io), -[COVAL](https://coval.readme.io), [FoldingCoin](http://foldingcoin.net/), [FootballCoin](https://www.footballcoin.io/), -[GetGems](http://getgems.org/#/), -[IndieBoard](https://indiesquare.me/), [LTBCoin - Letstalkbitcoin.com](https://letstalkbitcoin.com/), +[Age of Rust](http://spacepirate.io), [Augmentors](https://www.augmentorsgame.com/), +[Bitcorns](https://bitcorns.com/), +[Blocksafe](http://www.blocksafefoundation.com), [CoinDaddy](http://coindaddy.io), +[FoldingCoin](http://foldingcoin.net/), [FootballCoin](https://www.footballcoin.io/), +[LTBCoin - Letstalkbitcoin.com](https://letstalkbitcoin.com/), [Mafia Wars](https://mafiawars.io/), [Proof of Visit](https://proofofvisit.com/), -[Rarepepe.party](http://rarepepe.party), [SaruTobi Island](http://mandelduck.com/sarutobiisland/), +[SaruTobi Island](http://mandelduck.com/sarutobiisland/), [Spells of Genesis](http://www.spellsofgenesis.com), [Takara](https://mandelduck.com/#portfolio), -[The Scarab Experiment](https://www.thescarabexperiment.org/), -[Tokenly](http://tokenly.com/), [TopCoin](https://topcoin.com/) and [XCP DEX](https://XCPDEX.COM) [[75]]. In the past, -projects such as [Storj](https://storj.io/) and [SWARM](https://counterparty.io/news/swarm-crowdfunding/) -also built on Counterparty. +[The Scarab Experiment](https://www.thescarabexperiment.org/) and [XCP DEX](https://XCPDEX.COM) [[75]]. +In the past, projects such as [Storj](https://storj.io/) and [SWARM](https://counterparty.io/news/swarm-crowdfunding/) also built on Counterparty. COVAL is being developed with the primary purpose of moving value using “off-chain” methods. It uses its own set of node runners to manage various "off-chain" distributed ledgers and ledger assigned wallets to implement an extended @@ -751,7 +748,7 @@ _What is it?_ _Scriptless Scripts_ was coined and invented by mathematician Andrew Poelstra. It entails offering scripting functionality without actual scripts on the blockchain to implement smart contracts. At the time of writing (July 2018) -it can only work on the Mimblewimble blockchain and makes use of a specific Schnorr signature scheme [[81]] that allows +it can only work on the Mimblewimble blockchain and makes use of a specific Schnorr signature scheme that allows for signature aggregation, mathematically combining several signatures into a single signature, without having to prove Knowledge of Secret Keys (KOSK). This is known as the _plain public-key model_, where the only requirement is that each potential signer has a public key. The KOSK scheme requires that users prove knowledge (or possession) of the secret key @@ -950,10 +947,10 @@ Date accessed: 2018‑06‑14. [4]: http://plasma.io/plasma.pdf 'Plasma: Scalable Autonomous Smart Contracts' [[5]] "NEX: A High Performance Decentralized Trade and Payment Platform" [online]. Available: -. +. Date accessed: 2018‑06‑11. -[5]: https://nash.io/pdfs/whitepaper_v2.pdf 'NEX: A High Performance Decentralized Trade and Payment Platform' +[5]: https://pdf4pro.com/cdn/nex-a-high-performance-decentralized-trade-and-payment-4cca97.pdf 'NEX: A High Performance Decentralized Trade and Payment Platform' [[6]] J. Poon and OmiseGO Team, "OmiseGO: Decentralized Exchange and Payments Platform" [online]. Available: . Date accessed: 2018‑06‑14. @@ -1021,11 +1018,6 @@ Date accessed: 2018‑06‑14. Layer 2 Scaling Solutions: State Channels, Plasma, and Truebit" -[[17]] "Trinity: Universal Off-chain Scaling Solution" [online]. Available: . Date accessed: -2018‑06‑14. - -[17]: https://trinity.tech 'Trinity: Universal Off-chain Scaling Solution' - [[18]] "Trinity White Paper: Universal Off-chain Scaling Solution" [online]. Available: . Date accessed: 2018‑06‑14. @@ -1033,10 +1025,10 @@ Date accessed: 2018‑06‑14. Off-chain Scaling Solution' [[19]] J. Coleman, L. Horne, and L. Xuanji, "Counterfactual: Generalized State Channels" [online]. -Available at: and . Date accessed: +Available at: and . Date accessed: 2018‑06‑15. -[19]: https://counterfactual.com/statechannels 'Counterfactual: Generalized State Channels' +[19]: https://www.bgp4.com/wp-content/uploads/2019/05/statechannels.pdf 'Counterfactual: Generalized State Channels' [[20]] "The Raiden Network" [online]. Available: . Date accessed: 2018‑06‑15. @@ -1128,10 +1120,10 @@ accessed: 2018‑07‑02. [38]: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/16cb30b4b92fd4989b8619a61752a2387c6dd474.pdf 'MapReduce: Simplified Data Processing on Large Clusters' -[[39]] "The Golem WhitePaper (Future Integrations)" [online]. Available: . +[[39]] "The Golem WhitePaper (Future Integrations)" [online]. Available: . Date accessed: 2018‑06‑22. -[39]: https://golem.network/crowdfunding/Golemwhitepaper.pdf 'The Golem WhitePaper (Future Integrations)' +[39]: https://whitepaper.io/coin/golem 'The Golem WhitePaper (Future Integrations)' [[40]] J. Teutsch, and C. Reitwiessner, "A Scalable Verification Solution for Block Chains" [online]. Available: . Date accessed: 2018‑06‑22. @@ -1153,9 +1145,9 @@ Date accessed: 2018‑06‑22. [43]: https://truebit.io 'TruBit Website' [[44]] "TumbleBit: An Untrusted Bitcoin-compatible Anonymous Payment Hub" [online]. Available: -. Date accessed: 2018‑07‑12. +. Date accessed: 2018‑07‑12. -[44]: http://cs-people.bu.edu/heilman/tumblebit 'TumbleBit: An Untrusted Bitcoin-compatible Anonymous Payment Hub' +[44]: https://eprint.iacr.org/2016/575.pdf 'TumbleBit: An Untrusted Bitcoin-compatible Anonymous Payment Hub' [[45]] E. Heilman, L. AlShenibr, F. Baldimtsi, A. Scafuro and S. Goldberg, "TumbleBit: An Untrusted Bitcoin-compatible Anonymous Payment Hub" [online].Available: . Date accessed: 2018‑07‑08. @@ -1163,10 +1155,10 @@ Anonymous Payment Hub" [online].Available: . +. Date accessed: 2018‑07‑08. -[46]: https://medium.com/@Stratisplatform/anonymous-transactions-coming-to-stratis-fced3f5abc2e 'Anonymous Transactions Coming to Stratis' +[46]: https://www.stratisplatform.com/2016/12/07/anonymous-transactions-coming-to-stratis/ 'Anonymous Transactions Coming to Stratis' [[47]] "TumbleBit Proof of Concept GitHub Repository" [online]. Available: . Date accessed: 2018‑07‑08. @@ -1342,11 +1334,6 @@ Date accessed: 2018‑07‑24. [80]: https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf 'Scriptless Scripts' -[[81]] "bip-schnorr.mediawiki" [online]. Available: . -Date accessed: 2018‑07‑26. - -[81]: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki 'bip-schnorr.mediawiki' - [[82]] "If There is an Answer to Selfish Mining, Braiding could be It" [online]. Available: . Date accessed: 2018‑07‑27. diff --git a/_includes/content/scaling/04-laser-beam.md b/_includes/content/scaling/04-laser-beam.md index 12d6f37e..43660258 100644 --- a/_includes/content/scaling/04-laser-beam.md +++ b/_includes/content/scaling/04-laser-beam.md @@ -36,7 +36,7 @@ implementations that support Bitcoin exist and, with small tweaks, some of them Laser Beam is an adaptation of the Lightning Network for the [Mimblewimble](/protocols/mimblewimble) protocol, to be implemented for Beam ([[5]], [[6]], [[7]]). At the time of writing of this report (November 2019), the specifications were far advanced, but still work in progress. Beam has a working demonstration in its mainnet -repository, which at this stage demonstrates off-chain transactions in a single channel between two parties [[8]]. +repository, which at this stage demonstrates off-chain transactions in a single channel between two parties. According to the Request for Comment (RFC) documents, Beam plans to implement routing across different payment channels in the Lightning Network style. @@ -455,12 +455,6 @@ position paper. (v 1.0)' [7]: https://github.com/fjahr/lightning-mw 'GitHub: fjahr/lightning-mw, Lightning Network Specifications' -[[8]] The Beam Team, "GitHub: beam/node/laser_beam_demo at master - BeamMW/beam" \[online\]. Available: -. Date accessed: 2019‑07‑05. - -[8]: https://github.com/BeamMW/beam/tree/master/node/laser_beam_demo 'GitHub: beam/node/laser_beam_demo -at master - BeamMW/beam' - [[9]] The Beam Team, "GitHub: beam/ecc_bulletproof.cpp at mainnet - BeamMW/beam" \[online\]. Available: . Date accessed: 2019‑07‑05. diff --git a/_includes/content/style-guide/01-style-guide.md b/_includes/content/style-guide/01-style-guide.md index 6c9d3c51..4363b03f 100644 --- a/_includes/content/style-guide/01-style-guide.md +++ b/_includes/content/style-guide/01-style-guide.md @@ -32,8 +32,6 @@ - [Appendix B: Tari Labs University Terminology Conventions](#appendix-b-tari-labs-university-terminology-conventions) - [Contributors](#contributors) - - ## Purpose The purpose of this Style Guide is to provide contributors to the Tari Labs University (TLU) reports with standards for @@ -41,14 +39,10 @@ content and layout. The intention is to improve communication and provide a high Use of this Style Guide can assist in ensuring consistency in the content and layout of TLU reports. TLU content is created in [Markdown](https://www.markdownguide.org/) format and is rendered using -[mdBook](https://github.com/rust-lang-nursery/mdBook). - - +[Jekyll](https://jekyllrb.com/). ## Standards for Content - - ### Spelling As per the United States (US) spelling standard. The applicable dictionary is Merriam-Webster Online [[1]]. @@ -67,7 +61,7 @@ advised in [[4]]. Use the internationally agreed ISO standards [[3]] for expressing units of measure. -*Example* +_Example_ min = minute, s = second, h = hour, g = gram. @@ -80,15 +74,15 @@ min = minute, s = second, h = hour, g = gram. ### Abbreviations - If it is necessary to use abbreviations in a report, write the abbreviation out in full at its first occurrence in -the text, followed by the abbreviation in parentheses. Thereafter, use the abbreviation only. + the text, followed by the abbreviation in parentheses. Thereafter, use the abbreviation only. - *Example* + _Example_ Tari Labs University (TLU), graphical user interface (GUI). - Abbreviations of units should be consistent and not changed in the plural. - *Example* + _Example_ 10h and not 10hrs; 5min and not 5mins. @@ -97,30 +91,30 @@ the text, followed by the abbreviation in parentheses. Thereafter, use the abbre **Note:** Due to limitations in Markdown, we deviate from the ISO convention, which requires a space between numbers and units of measure, and also as a thousands separator. -- Use of a non-breaking space (` `) can improve readability in the rendered mdbook where required. +- Use of a non-breaking space (` `) can improve readability where required. - Indicate clearly to which unit a number belongs: - *Incorrect* + _Incorrect_ 11 x 11 x 11mm - *Correct* + _Correct_ 11mm x 11mm x 11mm - Use 'to' rather than a dash to indicate a range of values: - *Incorrect* + _Incorrect_ 1 - 10cm - *Correct* + _Correct_ 1cm to 10cm - Use a comma to indicate thousands. - *Example* + _Example_ 1,000; 20,000,000; 250,000. @@ -142,7 +136,7 @@ TLU uses unordered lists (refer to the first example under [List Punctuation](#l Where a list is a continuation of the preceding text, which is followed by a colon, use a semicolon between each bullet point and end the list with a full stop. -*Example* +_Example_ Their primary motivations for selecting a static emission rate are: @@ -153,7 +147,7 @@ Their primary motivations for selecting a static emission rate are: Where a list contains complete sentences, each item in the list is followed by a full stop. -*Example* +_Example_ According to the proposed solution, one of three conditions will be true to the SPV client when using erasure codes: @@ -163,7 +157,7 @@ According to the proposed solution, one of three conditions will be true to the Where a list is not a sentence and does not complete a preceding part of a sentence, use no punctuation. -*Example* +_Example_ Refer to the list of contents at the start of this Style Guide. @@ -173,9 +167,9 @@ Refer to the list of contents at the start of this Style Guide. - Text references appear in square brackets in the text and are listed under "References" at the end of each chapter. - If a text reference appears at the end of a paragraph, it appears after the full stop at the end of the paragraph. - Please be specific when referring to figures, tables and sections of text. For clarity, if using figure and table -numbering, avoid referring to "below" or "above". Rather give a specific figure or table number. In the case of text -references, include a link. For more information, please refer to the [Markdown Links](#markdown-links) section in this -Style Guide. + numbering, avoid referring to "below" or "above". Rather give a specific figure or table number. In the case of text + references, include a link. For more information, please refer to the [Markdown Links](#markdown-links) section in this + Style Guide. ### Case Formatting @@ -191,51 +185,53 @@ With new concepts being formed daily and words changing over time, it is useful ### Proposed Layout This section gives the proposed layout for TLU reports. The following headings are provided as a guide to heading -levels and content: +levels and content: - **Title (as heading level 1)** - Contents List (as embedded links). - - **Introduction/Purpose/Background/Overview (as heading level 2)** + Contents List (as embedded links). + + - **Introduction/Purpose/Background/Overview (as heading level 2)** + + This section explains the aim of the report and prepares the reader for the content. - This section explains the aim of the report and prepares the reader for the content. + - **Other headings as appropriate (as heading level 2 and lower)** - - **Other headings as appropriate (as heading level 2 and lower)** + Structure the body of your report by using headings and subheadings. Ordering these headings logically helps you - Structure the body of your report by using headings and subheadings. Ordering these headings logically helps you -to present your information effectively. Headings make it easier for -readers to find specific information. + to present your information effectively. Headings make it easier for + readers to find specific information. - - **Numbered Lists:** Use numbered lists when the order of the items in the list is important, such as in procedures. + - **Numbered Lists:** Use numbered lists when the order of the items in the list is important, such as in procedures. - - **Bulleted Lists:** Use bulleted lists when the order of the items in the list is not important. + - **Bulleted Lists:** Use bulleted lists when the order of the items in the list is not important. - - **Conclusions, Observations, Recommendations (as heading level 2)** + - **Conclusions, Observations, Recommendations (as heading level 2)** - The conclusion complements the purpose of the report. It concisely summarizes the findings of the report and - gives a future strategy, if required. + The conclusion complements the purpose of the report. It concisely summarizes the findings of the report and + gives a future strategy, if required. - - **References (as heading level 2)** + - **References (as heading level 2)** - References acknowledge the work of others and help readers to find sources. Refer to - [Referencing of Source Material](#referencing-of-source-material). + References acknowledge the work of others and help readers to find sources. Refer to + [Referencing of Source Material](#referencing-of-source-material). - - **Appendices (as heading level 2)** + - **Appendices (as heading level 2)** - Appendices contain supplementary information that supports the main report. + Appendices contain supplementary information that supports the main report. - - **Appendix A: Name (as heading level 3)** + - **Appendix A: Name (as heading level 3)** - Rather than inserting an entire supporting document into an appendix, provide a text reference and list the - reference in the references section. + Rather than inserting an entire supporting document into an appendix, provide a text reference and list the + reference in the references section. - - **Appendix B: Name (as heading level 3)** + - **Appendix B: Name (as heading level 3)** - If figure and table numbers are used in the report, the figure and table numbering in the appendices follows on - from the figure and table numbers used in the report. + If figure and table numbers are used in the report, the figure and table numbering in the appendices follows on + from the figure and table numbers used in the report. - - **Contributors (as heading level 2)** + - **Contributors (as heading level 2)** - Refer to [List of Contributors](#list-of-contributors). + Refer to [List of Contributors](#list-of-contributors). ### Line Widths @@ -246,10 +242,10 @@ _Example_ This text, which is split over four lines: - `Probatum fuit hujusmodi Testamentum apud London decimo Octavo die mensis Septembris Anno Domini Millesimo` - `Septingentesimo vicesimo tertio Coram venerabili viro Gulielmo Strahan. In cuius rei testimonium sigillum nostrum` - `presentibus apposuimus ad duos anni terminos videlicet ad festa Sancti Michaelis Archangeli et Annunciationis beate` - `Marie virginis.` +`Probatum fuit hujusmodi Testamentum apud London decimo Octavo die mensis Septembris Anno Domini Millesimo` + `Septingentesimo vicesimo tertio Coram venerabili viro Gulielmo Strahan. In cuius rei testimonium sigillum nostrum` + `presentibus apposuimus ad duos anni terminos videlicet ad festa Sancti Michaelis Archangeli et Annunciationis beate` + `Marie virginis.` will look like a single paragraph, as follows: @@ -263,7 +259,7 @@ Marie virginis. Every chapter in a TLU report should start with a bulleted list of all the headings in that chapter (with embedded links), for quick reference and consistency. This is optional for chapters that have five or fewer lower-level headings. -*Example* +_Example_ Refer to the contents listed at the start of this [Style Guide](#style-guide). The heading "Contents" is not inserted before this list. @@ -273,15 +269,15 @@ before this list. - Do not include paragraph numbers in headings. - For consistency, upper and lower-case (title case) letters are used for headings at all levels. -*Incorrect* +_Incorrect_ - \## 2. OVERVIEW +\## 2. OVERVIEW - *Correct* +_Correct_ - \## Overview +\## Overview - Also refer to [Appendix A](#appendix-a-lower-case-words-used-in-title-case-formatting). +Also refer to [Appendix A](#appendix-a-lower-case-words-used-in-title-case-formatting). ### Figures and Tables @@ -289,34 +285,31 @@ The use of captions, as well as figure and table numbering, is optional. If you these guidelines will help to promote consistency in TLU layout: - Number figures and tables in each section sequentially, with the table caption above the table and the figure caption -below the figure. + below the figure. - Type figure and table captions in upper and lower-case (title case). - Type Figure x: or Table X: before the caption, as applicable. - Center figures and tables on the page. - Place figures and tables as soon as possible after they are first referred to in the text. The text reference, if -figure and table numbering is not used, would then be "the following figure..." or "the following table...". This helps -to avoid confusion. + figure and table numbering is not used, would then be "the following figure..." or "the following table...". This helps + to avoid confusion. ### Equations -mdBook has optional support for math -[equations](https://github.com/rust-lang-nursery/mdBook/blob/master/book-example/src/format/mathjax.md) +TLU has optional support for math +[equations](https://www.mathjax.org/) through MathJax. In addition to the delimiters `\[` and `\[`, TLU also supports delimiters `$` and `$$`. - - -*Examples* +_Examples_ - Example of an inline equation: $ h \in \mathbb G $ - Example of a display equation: - $$ \mathbb s = \prod _{i=0}^n s(i) $$ -**Note:** MathJax rendering in mdBook has some caveats to take note of: +**Note:** MathJax rendering has some caveats to take note of: - Subscripts @@ -325,27 +318,29 @@ $$ text in italics. The way around this is to escape each underscore used in the equation as follows: (`\_`). An example of this is: - - *Rendering correctly* + - _Rendering correctly_ - $ \mathbf a \_{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} - \mspace{12mu} \mathbf a \_{[l:]} = ( a_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $ + $ \mathbf a \_{[:l]} = ( a*1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} + \mspace{12mu} \mathbf a \_{[l:]} = ( a*{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $ - as + as - `$ \mathbf a \_{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} - \mathbf a \_{[l:]} = ( a_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $` + `$ \mathbf a \_{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} - - *Rendering incorrectly* + \mathbf a \_{[l:]} = ( a\_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $` - $ \mathbf a _{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} - \mathbf a _{[l:]} = ( a_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $ + - _Rendering incorrectly_ - as + $ \mathbf a _{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} + \mathbf a _{[l:]} = ( a\_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $ - `$ \mathbf a _{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} - \mathbf a _{[l:]} = ( a_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $` + as - Notice that this part of the (failed) formula, `_{[l:]} = ( a_`, is rendered in italics. + `$ \mathbf a _{[:l]} = ( a_1 , ... , a_n ) \in \mathbb F ^ n \mspace{12mu} \text{and} \mspace{12mu} + + \mathbf a _{[l:]} = ( a_{1+1} , ... , a_n ) \in \mathbb F ^ {n-l} $` + + Notice that this part of the (failed) formula, `_{[l:]} = ( a_`, is rendered in italics. - Superscripts and subscripts order @@ -354,11 +349,10 @@ $$ - `$ s_i = \prod ^{\log _2 (n)} _{j=1} x ^{b(i,j)} _j $` - vs. + vs. `$ s_i = \prod _{j=1} ^{\log _2 (n)} x _j ^{b(i,j)} $` - ### Referencing of Source Material #### Referencing Standard @@ -369,14 +363,14 @@ List references in the following order, as applicable: 1. Author(s) initials or first name and surname (note punctuation in the following example). 2. Title of the report, between double quotation marks. If it is an online report, state this in square brackets, as -shown in the following example. + shown in the following example. 3. Title of journal, in italics (if applicable). 4. Publication information (volume, number, etc.). 5. Page range (if applicable). 6. URL address if an online publication. Provide this information as shown in the following example: "Available: ..". 7. Date you accessed the article if it is an online publication (yyyy-mm-dd), as shown in the following example. -*Example* +_Example_ \[1\] M. Abe, M. Ohkubo and K. Suzuki, "1-out-of-n Signatures from a Variety of Keys" [online]. Available: https://www.iacr.org/cryptodb/archive/2002/ASIACRYPT/50/50.pdf. Date accessed: 2018-12-18. @@ -391,18 +385,18 @@ The **inline link** under the [Equations](#Equations) heading was created as fol 1. Insert identifying link text within a set of square brackets (refer to the following example). 1. Create an inline link by placing a set of parentheses (round brackets) immediately after the closing square bracket -of the link text (refer to the following example). + of the link text (refer to the following example). 1. Insert the relevant URL link inside the parentheses (round brackets) (refer to the following example). -mdBook has optional support for math -[equations](https://github.com/rust-lang-nursery/mdBook/blob/master/book-example/src/format/mathjax.md) through MathJax. +TLU has optional support for math +[equations](https://www.mathjax.org/) through MathJax. -*Example* +_Example_ A **reference link** has two parts. The first part of a reference link has two sets of square brackets. Inside the inner (second) set of square brackets, insert a label to identify the link. -*Example* +_Example_ Under the heading [Spelling](#spelling), the text reference is "The applicable dictionary is Merriam-Webster Online [[1]]". In the markdown text, note the double square brackets and the label 1. The rendered text shows [1]. @@ -412,8 +406,7 @@ The second part of a reference link is inserted under the heading [References](# [[1]] Merriam-Webster Online Dictionary [online]. Available: https://www.merriam-webster.com/. Date accessed: 2019-02-01. -[1]: https://www.merriam-webster.com -"Merriam-Webster Online Dictionary" +[1]: https://www.merriam-webster.com 'Merriam-Webster Online Dictionary' The full online reference is inserted after `[[1]]`; and the pop-up text link (which can be seen by hovering your cursor over the text reference in [Spelling](#spelling)) is inserted after `[1]:`. @@ -431,36 +424,27 @@ Refer to [Contributors](#contributors) for an example. [[1]] Merriam-Webster Online Dictionary [online]. Available: https://www.merriam-webster.com/. Date accessed: 2019-02-01. -[1]: https://www.merriam-webster.com -"Merriam-Webster Online Dictionary" +[1]: https://www.merriam-webster.com 'Merriam-Webster Online Dictionary' [[2]] Citing and Referencing: IEEE [online]. Available: https://guides.lib.monash.edu/citing-referencing/ieee. Date accessed: 2019-02-01. -[2]: https://guides.lib.monash.edu/citing-referencing/ieee -"Citing and Referencing: IEEE" +[2]: https://guides.lib.monash.edu/citing-referencing/ieee 'Citing and Referencing: IEEE' [[3]] A. Thompson and B. N. Taylor, " Guide for the Use of the International System of Units (SI)", (1995) – NIST Special Publication 811 - 2008 Edition [online]. Available: https://physics.nist.gov/cuu/pdf/sp811.pdf. Date accessed: 2019-02-04. -[3]: https://physics.nist.gov/cuu/pdf/sp811.pdf -"Guide for the Use of the International System of Units (SI)" +[3]: https://physics.nist.gov/cuu/pdf/sp811.pdf 'Guide for the Use of the International System of Units (SI)' [[4]] The Oxford Guide to Style [online]. Available: http://www.eng-lang.co.uk/ogs.htm. Date accessed: 2019-02-04. -[4]: http://www.eng-lang.co.uk/ogs.htm -"The Oxford Guide to Style" - - +[4]: http://www.eng-lang.co.uk/ogs.htm 'The Oxford Guide to Style' ## Appendices ### Appendix A: Lower-case Words used in Title Case Formatting - - - | Case Word | Case Word | Case Word | Case Word | | ------------ | --------- | --------- | ---------- | | a | each | less | therefore | @@ -498,10 +482,6 @@ Available: http://www.eng-lang.co.uk/ogs.htm. Date accessed: 2019-02-04. | down | its | then | worst | | e.g. | least | there | | - - - - ### Appendix B: Tari Labs University Terminology Conventions With new concepts being formed daily and words changing over time, it is useful to establish terminology conventions. @@ -511,7 +491,6 @@ contains suggested terminology for use in TLU reports. - blockchain - Mimblewimble - ## Contributors - [https://github.com/anselld](https://github.com/anselld) diff --git a/_includes/content/tari/01-TariScript_for_dummies.md b/_includes/content/tari/01-TariScript_for_dummies.md index 086c2039..410a2c5e 100644 --- a/_includes/content/tari/01-TariScript_for_dummies.md +++ b/_includes/content/tari/01-TariScript_for_dummies.md @@ -85,7 +85,7 @@ This is just a convenient metaphor for us greybeards who grew up in a time when In fact, what you are doing is locking up a UTXO with a _script_ that effectively says, "Anyone who can prove that they know the private key of the public key that when hashed gives you `1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy`, can have this bitcoin". -[Chapter 6 of _Mastering Bitcoin_](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc#tx_script) +[Chapter 6 of _Mastering Bitcoin_](https://www.google.co.za/books/edition/Mastering_Bitcoin/MpwnDwAAQBAJ?hl=en&gbpv=0) dives into Bitcoin transactions and script in great detail, and I strongly recommend you read it. It is this ability to assign funds to small pieces of code, rather than just an account number, that opens up diff --git a/_pages/glossary.html b/_pages/glossary.html index da6edbd2..f4da2b1d 100644 --- a/_pages/glossary.html +++ b/_pages/glossary.html @@ -90,7 +90,7 @@

Current head

Cut-Through

Cut-through is the process where outputs spent within a single block may be removed without breaking the standard MimbleWimble validation rules. Simplistically, Alice -> Bob -> Carol may be "cut-through" to Alice -> Carol. Bob's commitments may be removed.

-

On Tari, for reasons described in RFC-0201_TariScript, cut-through is prevented from ever happening.

+

On Tari, for reasons described in RFC-0201_TariScript, cut-through is prevented from ever happening.

Digital asset

Digital assets (DAs) are the sets or collections of native digital tokens (both fungible and non-fungible) that are created by asset issuers on the Tari 2nd layer. For example, a promoter might create a DA for a music concert event. @@ -236,7 +236,7 @@

Token Wallet

instructions for transferring and receiving Assets and Tokens on the Digital Asset Network.

Transaction Weight

The weight of a transaction / block measured in "grams". -See Block / Transaction weight for more details.

+See Block / Transaction weight for more details.

Unspent transaction outputs

An unspent transaction output (UTXO) is a discrete number of Tari that are available to be spent. The sum of all UTXOs represents all the Tari currently in circulation. In addition, the sum of all UTXO values equals the sum of the diff --git a/_posts/course2-money/2021-02-03-module3.md b/_posts/course2-money/2021-02-03-module3.md index f88f31de..670b25dd 100644 --- a/_posts/course2-money/2021-02-03-module3.md +++ b/_posts/course2-money/2021-02-03-module3.md @@ -1,16 +1,16 @@ --- layout: module -title: The history of Money -date: 2021-02-03 13:00:00 +0300 +title: The history of Money +date: 2021-02-03 13:00:00 +0300 postid: 203 -image: '/images/banner-01.jpg' +image: '/images/banner-01.jpg' category: the-history-of-money course: the-history-of-money time: 60 format: article level: beginner modno: 3 -tags: [blockchain, money, history] +tags: [blockchain, money, history] author: Nick Szabo sourcename: Nakamoto Institute sourceurl: https://nakamotoinstitute.org/shelling-out/ @@ -33,19 +33,19 @@ The precursors of money, along with language, enabled early modern humans to sol ## Table of Contents -* [Money](#money) -* [Collectibles](#collectibles) -* [Evolution, Cooperation, and Collectibles](#evolution-cooperation-and-collectibles) -* [Gains From Wealth Transfers](#gains-from-wealth-transfers) -* [Starvation Insurance](#starvation-insurance) -* [Kin Altruism Beyond the Grave](#kin-altruism-beyond-the-grave) -* [The Family Trade](#the-family-trade) -* [The Spoils of War](#the-spoils-of-war) -* [Disputes and Remedies](#disputes-and-remedies) -* [Attributes of Collectibles](#attributes-of-collectibles) -* [Conclusion](#conclusion) -* [References](#references) -* [Acknowledgements](#acknowledgements) +- [Money](#money) +- [Collectibles](#collectibles) +- [Evolution, Cooperation, and Collectibles](#evolution-cooperation-and-collectibles) +- [Gains From Wealth Transfers](#gains-from-wealth-transfers) +- [Starvation Insurance](#starvation-insurance) +- [Kin Altruism Beyond the Grave](#kin-altruism-beyond-the-grave) +- [The Family Trade](#the-family-trade) +- [The Spoils of War](#the-spoils-of-war) +- [Disputes and Remedies](#disputes-and-remedies) +- [Attributes of Collectibles](#attributes-of-collectibles) +- [Conclusion](#conclusion) +- [References](#references) +- [Acknowledgements](#acknowledgements) ## Money @@ -89,9 +89,9 @@ _Detail of necklace from a burial at Sungir, Russia, 28,000 BP. Interlocking and ## Evolution, Cooperation, and Collectibles -Evolutionary psychology starts with a key mathematical discovery of John Maynard Smith[[D89]](#fnD89). Using models of populations of co-evolving genes, from the well-developed area of population genetics, Smith posited genes that can code for strategies, good or bad, used in simple strategic problems (the "games" of game theory). Smith proved that these genes, competing to be propagated into future generations, will evolve strategies that are [Nash equilibria](http://web.archive.org/web/20021028220635/http://www.chass.utoronto.ca/~osborne/2x3/tutorial/SGAME.HTM) to the strategic problems presented by the competition. These games include the [prisoner's dilemma](http://www.chass.utoronto.ca/~osborne/2x3/tutorial/SGAME.HTM), a prototypical problem of cooperation, and [hawk/dove](http://web.archive.org/web/20020828234922/http://www.ucl.ac.uk/~ucbhdjm/courses/b242/Tuts/Tut2-02.html), a prototypical problem of aggression and its mitigation. +Evolutionary psychology starts with a key mathematical discovery of John Maynard Smith[[D89]](#fnD89). Using models of populations of co-evolving genes, from the well-developed area of population genetics, Smith posited genes that can code for strategies, good or bad, used in simple strategic problems (the "games" of game theory). Smith proved that these genes, competing to be propagated into future generations, will evolve strategies that are [Nash equilibria](http://web.archive.org/web/20021028220635/http://www.chass.utoronto.ca/~osborne/2x3/tutorial/SGAME.HTM) to the strategic problems presented by the competition. These games include the prisoner's dilemma, a prototypical problem of cooperation, and [hawk/dove](http://web.archive.org/web/20020828234922/http://www.ucl.ac.uk/~ucbhdjm/courses/b242/Tuts/Tut2-02.html), a prototypical problem of aggression and its mitigation. -Critical to Smith's theory is that these strategic games, while played out between phenotypes proximately, are in fact games between genes at the ultimate level – the level of competition to be propagated. The genes – not necessarily the individuals – influence behavior as if they were boundedly rational (coding for strategies as optimal as possible, within the limits of what phenotypes can express given the biological raw materials and previous evolutionary history) and "selfish" (to use Richard Dawkins' metaphor). Genetic influences on behavior are adaptations to the social problems presented by genes competing through their phenotypes. Smith called these evolved Nash equilibria [evolutionary stable strategies](http://www.ucl.ac.uk/~ucbhdjm/courses/b242/Tuts/Tut2-02.html). +Critical to Smith's theory is that these strategic games, while played out between phenotypes proximately, are in fact games between genes at the ultimate level – the level of competition to be propagated. The genes – not necessarily the individuals – influence behavior as if they were boundedly rational (coding for strategies as optimal as possible, within the limits of what phenotypes can express given the biological raw materials and previous evolutionary history) and "selfish" (to use Richard Dawkins' metaphor). Genetic influences on behavior are adaptations to the social problems presented by genes competing through their phenotypes. Smith called these evolved Nash equilibria evolutionary stable strategies. The "epicycles" built on top of the earlier individual selection theory, such as sexual selection and kin selection, disappear into this more general model which, in a Copernican manner, puts the genes rather than individuals at the center of the theory. Thus Dawkins' metaphorical and often misunderstood phrase, "selfish gene", to describe Smith's theory. @@ -111,7 +111,7 @@ Among small human groups, public reputation can supercede retaliation by a singl The need to remember faces and favors is a major cognitive hurdle, but one that most humans find relatively easy to overcome. Recognizing faces is easy, but remembering that a favor took place when such memory needs to be recalled can be harder. Remembering the specifics about a favor that gave it a certain value to the favored is harder still. Avoiding disputes and misunderstandings can be improbable or prohibitively difficult. -The appraisal or [value measurement](http://szabo.best.vwh.net/measuringvalue.html) problem is very broad. For humans it comes into play in any system of exchange – reciprocation of favors, barter, money, credit, employment, or purchase in a market. It is important in extortion, taxation, tribute, and the setting of judicial penalties. It is even important in reciprocal altruism in animals. Consider monkeys exchanging favors – say pieces of fruit for back scratches. Mutual grooming can remove ticks and fleas that an individual can't see or reach. But just how much grooming versus how many pieces of fruit constitutes a reciprocation that both sides will consider to be "fair", or in other words not a defection? Is twenty minutes of backscratching worth one piece of fruit or two? And how big a piece? +The appraisal or value measurement problem is very broad. For humans it comes into play in any system of exchange – reciprocation of favors, barter, money, credit, employment, or purchase in a market. It is important in extortion, taxation, tribute, and the setting of judicial penalties. It is even important in reciprocal altruism in animals. Consider monkeys exchanging favors – say pieces of fruit for back scratches. Mutual grooming can remove ticks and fleas that an individual can't see or reach. But just how much grooming versus how many pieces of fruit constitutes a reciprocation that both sides will consider to be "fair", or in other words not a defection? Is twenty minutes of backscratching worth one piece of fruit or two? And how big a piece? Even the simple case of trading blood for blood is more complicated than it seems. Just how do the bats estimate the value of blood they have received? Do they estimate the value of a favor by weight, by bulk, by taste, by its ability to satiate hunger, or other variables? Just the same, measurement complications arise even in the simple monkey exchange of "you scratch my back and I'll scratch yours". @@ -212,7 +212,7 @@ Like most hunter-gatherers, the !Kung spend most of the year in small, dispersed ![](https://nakamotoinstitute.org/static/img/docs/shelling-out/HxaroExchangeKinship.gif) -_[Pattern of hxaro exchanges and kinship relations](http://www.mpi-fg-koeln.mpg.de/~lk/netvis/kunggenetic.html) among neighboring tribes of !Khung San hunter-gatherers._ +_Pattern of hxaro exchanges and kinship relations among neighboring tribes of !Khung San hunter-gatherers._ ![](https://nakamotoinstitute.org/static/img/docs/shelling-out/KungSanNecklace.gif) @@ -352,63 +352,61 @@ Primitive money was not modern money as we know it. It took on some of the funct ## References -1. [A90] Adams, Charles, _For Good and Evil: The Impact of Taxes on Civilization_ [↩](#refA90) +1. [A90] Adams, Charles, *For Good and Evil: The Impact of Taxes on Civilization* [↩](#refA90) -2. [A98] Tim Appenzeller, "Art: Evolution or Revolution?", Science 282(Nov 20, 1998), p. 1452\. See also the home page of [Stanley Ambrose](http://www.anthro.uiuc.edu/faculty/ambrose/) [↩](#refA98-1) [↩](#refA98-2) +2. [A98] Tim Appenzeller, "Art: Evolution or Revolution?", Science 282(Nov 20, 1998), p. 1452\. See also the home page of [Stanley Ambrose](https://www.academia.edu/48652357/ART_Evolution_or_Revolution) [↩](#refA98-1) [↩](#refA98-2) -3. [B04] [The Blombos Cave Project](http://www.electrickiva.com/chs_spring_2004/Unit_Anthropology/blomboscave/project_site/!%20artifacts_beads.htm) [↩](#refB04-1) [↩](#refB04-2) +3. [C94] Culiffe, Barry, ed., _The Oxford Illustrated History of Prehistoric Europe_, Oxford University Press 1994. [↩](#refC94-1) [↩](#refC94-2) [↩](#refC94-3) [↩](#refC94-4) [↩](#refC94-5) -4. [C94] Culiffe, Barry, ed., _The Oxford Illustrated History of Prehistoric Europe_, Oxford University Press 1994. [↩](#refC94-1) [↩](#refC94-2) [↩](#refC94-3) [↩](#refC94-4) [↩](#refC94-5) +4. [D89] Dawkins, Richard, _The Selfish Gene_, Oxford University Press 1989. [↩](#refD89-1) [↩](#refD89-2) [↩](#refD89-3) -5. [D89] Dawkins, Richard, _The Selfish Gene_, Oxford University Press 1989. [↩](#refD89-1) [↩](#refD89-2) [↩](#refD89-3) +5. [D94] Davies, Glyn, _A History of Money, From Ancient Times to the Present Day_, University of Wales Press 1994. [↩](#refD94-1) [↩](#refD94-2) [↩](#refD94-3) [↩](#refD94-4) -6. [D94] Davies, Glyn, _A History of Money, From Ancient Times to the Present Day_, University of Wales Press 1994. [↩](#refD94-1) [↩](#refD94-2) [↩](#refD94-3) [↩](#refD94-4) +6. [DW88] Daly, Martin and Wilson, Margo, _Homicide_, New York: Aldine (1998). [↩](#refDW88-1) [↩](#refDW88-2) -7. [DW88] Daly, Martin and Wilson, Margo, _Homicide_, New York: Aldine (1998). [↩](#refDW88-1) [↩](#refDW88-2) +7. [G95] Gilead, I. 1995\. "The Foragers of the Upper Paleolithic Period," in Archaeology and Society in the Holy Land. Ed. by T. E. Levy. New York, Facts on File. [↩](#refG95) -8. [G95] Gilead, I. 1995\. "The Foragers of the Upper Paleolithic Period," in Archaeology and Society in the Holy Land. Ed. by T. E. Levy. New York, Facts on File. [↩](#refG95) +8. [G01] [ref: http://www-geology.ucdavis.edu/~GEL115/115CH1.html] [↩](#refG01) -9. [G01] [ref: http://www-geology.ucdavis.edu/~GEL115/115CH1.html] [↩](#refG01) +9. [Gr01] Graeber, David, _Towards an Anthropological Theory of Value_, Palgrave 2001. -10. [Gr01] Graeber, David, _Towards an Anthropological Theory of Value_, Palgrave 2001. +10. [I98] Ifrah, Georges, _The Universal History of Numbers_, John Wiley & Sons 1998, pg. 73. -11. [I98] Ifrah, Georges, _The Universal History of Numbers_, John Wiley & Sons 1998, pg. 73. +11. [K99] Kohn, M. and Mithen, S. "Handaxes: Products of sexual selection?", Antiquity, 73, 518-526. -12. [K99] Kohn, M. and Mithen, S. "Handaxes: Products of sexual selection?", Antiquity, 73, 518-526. +12. [K99] Kohn, M. and Mithen, S. "Handaxes: Products of sexual selection?", Antiquity, 73, 518-526. -13. [K99] Kohn, M. and Mithen, S. "Handaxes: Products of sexual selection?", Antiquity, 73, 518-526. +13. [L94] Landa, Janet, _Trust, Ethnicity, and Identity: Beyond the New Institutional Economics of Ethnic Trading Networks, Contract Law, and Gift-Exchange_, The University of Michigan Press, second edition, 1998. [↩](#refL94-1) [↩](#refL94-2) [↩](#refL94-3) -14. [L94] Landa, Janet, _Trust, Ethnicity, and Identity: Beyond the New Institutional Economics of Ethnic Trading Networks, Contract Law, and Gift-Exchange_, The University of Michigan Press, second edition, 1998. [↩](#refL94-1) [↩](#refL94-2) [↩](#refL94-3) +14. [M1892] Menger, Carl, "On the Origins of Money" Economic Journal, volume 2,(1892) p. 239-55\. translated by C.A. Foley, at http://www.socsci.mcmaster.ca/~econ/ugcm/3ll3/menger/money.txt [↩](#refM1892) -15. [M1892] Menger, Carl, "On the Origins of Money" Economic Journal, volume 2,(1892) p. 239-55\. translated by C.A. Foley, at http://www.socsci.mcmaster.ca/~econ/ugcm/3ll3/menger/money.txt [↩](#refM1892) +15. [M50] Mauss, Marcel, _The Gift_, 1950, English translation by W.D. Halls, W.W. Norton 1990. [↩](#refM50) -16. [M50] Mauss, Marcel, _The Gift_, 1950, English translation by W.D. Halls, W.W. Norton 1990. [↩](#refM50) +16. [M93] (Morse 1993) via http://www.wac.uct.ac.za/wac4/symposia/papers/s095wht1.pdf [↩](#refM93) -17. [M93] (Morse 1993) via http://www.wac.uct.ac.za/wac4/symposia/papers/s095wht1.pdf [↩](#refM93) +17. [R96] Riddley, Matt, _The Origins of Virtue_, Viking 1996. -18. [R96] Riddley, Matt, _The Origins of Virtue_, Viking 1996. +18. [T01] Taylor, Alan, _American Colonies – The Settling of North America_, Penguin 2001. [↩](#refT01-1) [↩](#refT01-2) -19. [T01] Taylor, Alan, _American Colonies – The Settling of North America_, Penguin 2001. [↩](#refT01-1) [↩](#refT01-2) +19. [P89] Plattner, Stuart, _Economic Anthropology_, Stanford University Press 1989. -20. [P89] Plattner, Stuart, _Economic Anthropology_, Stanford University Press 1989. +20. [W77] Wiessner, P. 1977\. Hxaro: a regional system at reciprocity for reducing risk among the !Kung San. Unpublished PhD thesis: University of Michigan. [↩](#refW77) -21. [W77] Wiessner, P. 1977\. Hxaro: a regional system at reciprocity for reducing risk among the !Kung San. Unpublished PhD thesis: University of Michigan. [↩](#refW77) +21. [W82] Wiessner, P. 1982\. Risk, reciprocity and social influences on !Kung San economies. In: Leacock, H. R. & Lee, R.B. (eds) _Politics and history in band societies_: 61-84\. London: Cambridge University Press. -22. [W82] Wiessner, P. 1982\. Risk, reciprocity and social influences on !Kung San economies. In: Leacock, H. R. & Lee, R.B. (eds) _Politics and history in band societies_: 61-84\. London: Cambridge University Press. +22. [W95] White, Randall, "Ivory Personal Ornaments of Aurignacian Age: Technological, Social and Symbolic Perspectives", Institute For Ice Age Studies, http://www.insticeagestudies.com/library/Ivory/Ivorypersonal.html [↩](#refW95) -23. [W95] White, Randall, "Ivory Personal Ornaments of Aurignacian Age: Technological, Social and Symbolic Perspectives", Institute For Ice Age Studies, http://www.insticeagestudies.com/library/Ivory/Ivorypersonal.html [↩](#refW95) +23. [W97] White, Randall, "From Materials To Meaning", Institute For Ice Age Studies, http://www.insticeagestudies.com/library/materialstomeaning/index.html [↩](#refW97) -24. [W97] White, Randall, "From Materials To Meaning", Institute For Ice Age Studies, http://www.insticeagestudies.com/library/materialstomeaning/index.html [↩](#refW97) +24. [W98] Winterhalder, Bruce, "Intra-Group Resource Transfers: Comparative Evidence, Models, and Implications for Human Evolution", http://www.unc.edu/depts/ecology/winterweb/intra_group.html [↩](#refW98) -25. [W98] Winterhalder, Bruce, "Intra-Group Resource Transfers: Comparative Evidence, Models, and Implications for Human Evolution", http://www.unc.edu/depts/ecology/winterweb/intra_group.html [↩](#refW98) - -26. [W02] Wilford, John, "Debate is Fueled on When Humans Became Human", New York Times, February 26th, 2002  [↩](#refW02) +25. [W02] Wilford, John, "Debate is Fueled on When Humans Became Human", New York Times, February 26th, 2002  [↩](#refW02) ## Acknowledgements My thanks to Jerome Barkow, Andrew Odlyzko, Bruce Smith, K. Eric Drexler, Markus Krummenacker, Mark Wiley, Norm Hardy, and others for their insightful comments. -* * * +--- Please send your comments to nszabo (at) law (dot) gwu (dot) edu diff --git a/_posts/course5-mimblewimble/2021-05-03-mimblewimble-bits.md b/_posts/course5-mimblewimble/2021-05-03-mimblewimble-bits.md index 227a12e0..f8284b72 100644 --- a/_posts/course5-mimblewimble/2021-05-03-mimblewimble-bits.md +++ b/_posts/course5-mimblewimble/2021-05-03-mimblewimble-bits.md @@ -1,42 +1,42 @@ --- layout: module -title: Mimblewimble - what all the bits do -date: 2021-05-01 15:00:00 +0300 +title: Mimblewimble - what all the bits do +date: 2021-05-01 15:00:00 +0300 format: article level: intermediate -image: '/images/banner-08.jpg' +image: '/images/banner-08.jpg' category: mimblewimble time: 25 course: mimblewimble-basics -tags: [protocols, mimblewimble, kernel] +tags: [protocols, mimblewimble, kernel] featured: -description: A more detailed look at the various pieces of data in the Mimblewimble +description: + A more detailed look at the various pieces of data in the Mimblewimble blockchain, what they do and why they are needed. --- -The Mimblewimble white paper provided the foundations of the protocol. During the development of working -implementations of the protocol, the devil that was in the detail necessitated a few deviations and finessing of the -original design. Some of these changes are introduced and discussed in this article. +The Mimblewimble white paper provided the foundations of the protocol. During the development of working +implementations of the protocol, the devil that was in the detail necessitated a few deviations and finessing of the +original design. Some of these changes are introduced and discussed in this article. -This article focuses on vanilla Mimblewimble. Tari has introduced several other additional features to the -Mimblewimble protocol that are not covered here, including TariScript, output burning, and revealed values. +This article focuses on vanilla Mimblewimble. Tari has introduced several other additional features to the +Mimblewimble protocol that are not covered here, including TariScript, output burning, and revealed values. -# Table of Contents +# Table of Contents 1. [Blocks](#blocks) - 1. [Block Header](#block-header) - 2. [Block Body](#block-body) - 3. [Transaction kernels](#transaction-kernels) - 4. [Outputs](#outputs) - 5. [Transaction offsets](#transaction-offsets) + 1. [Block Header](#block-header) + 2. [Block Body](#block-body) + 3. [Transaction kernels](#transaction-kernels) + 4. [Outputs](#outputs) + 5. [Transaction offsets](#transaction-offsets) 2. [Other stuff](#other-stuff) - 1. [Cut-through and output pruning](#cut-through-and-output-pruning) - 2. [Pruning of spent outputs](#pruning-of-spent-outputs) - 3. [Malleability](#malleability) - 4. [Proof of payment](#proof-of-payment) + 1. [Cut-through and output pruning](#cut-through-and-output-pruning) + 2. [Pruning of spent outputs](#pruning-of-spent-outputs) + 3. [Malleability](#malleability) + 4. [Proof of payment](#proof-of-payment) 3. [Tari's changes to Mimblewimble](#taris-changes-to-mimblewimble) - # Blocks The anatomy of a Mimblewimble block is as follows: @@ -44,82 +44,83 @@ The anatomy of a Mimblewimble block is as follows: ![Mimblewimble block](/images/mw-bits/mw-block.png) There are two parts two a block: The header, and the body. The body is further subdivided into the inputs, outputs, -and kernels. +and kernels. ## Block Header The block headers' main function is to provide the proof of work. The do this by -* forming a chain all the way to the genesis block via the `previous_block_hash` field, -* providing a proof of work. +- forming a chain all the way to the genesis block via the `previous_block_hash` field, +- providing a proof of work. The block header also serves some secondary functions: -* Keeping track of the accumulated [offset](#transaction-offsets). -* Committing to the state of the output set, input set, kernel set and range-proof data. -* Recording useful block metadata, such as the block height and timestamp. +- Keeping track of the accumulated [offset](#transaction-offsets). +- Committing to the state of the output set, input set, kernel set and range-proof data. +- Recording useful block metadata, such as the block height and timestamp. -Once you are in possession of all the headers, you know if any competing chain should replace the incumbent chain by -virtue of having done more work. You do _not_ know if all the transactions in the chain are valid. For that, you +Once you are in possession of all the headers, you know if any competing chain should replace the incumbent chain by +virtue of having done more work. You do _not_ know if all the transactions in the chain are valid. For that, you need the UTXO set. ## Block Body -The block body contains the inputs, outputs, and kernels. Interestingly, the structure of a block body and a +The block body contains the inputs, outputs, and kernels. Interestingly, the structure of a block body and a transaction body are identical, and Mimblewimble implementations including Tari, use the same data structure for both. -The set of inputs in a block or transaction are all former _unspent transaction outputs_ (UTXOs). Since they are being -spent in the block, they will shortly become _spent) transaction outputs (STXOs) and by Mimblewimble rules will be +The set of inputs in a block or transaction are all former _unspent transaction outputs_ (UTXOs). Since they are being +spent in the block, they will shortly become \_spent) transaction outputs (STXOs) and by Mimblewimble rules will be eligible for pruning. -The outputs in a block define the new UTXOs that are being created. They are accompanied by a range-proof and will -be added to the existing UTXO set. The sum of UTXOs in the set must always equal the total emission of coins via +The outputs in a block define the new UTXOs that are being created. They are accompanied by a range-proof and will +be added to the existing UTXO set. The sum of UTXOs in the set must always equal the total emission of coins via block rewards. If this is not the case, the block is invalid and will be rejected. The kernels provide important pieces of information that are critical for maintaining the integrity of the blockchain. -* The kernel signatures ensure that all parties involved in the transaction are happy with the state of the transaction. -* The total excess of the transaction (i.e. the sum of all the blinding factors of the commitments involved in the +- The kernel signatures ensure that all parties involved in the transaction are happy with the state of the transaction. +- The total excess of the transaction (i.e. the sum of all the blinding factors of the commitments involved in the transaction) is tracked in the kernel. -* Additional metadata, such as the fee and kernel features are also recorded in the kernel. +- Additional metadata, such as the fee and kernel features are also recorded in the kernel. ## Transaction kernels -You may wonder why the kernel data must be stored separately from the UTXO. Kernels are a necessary evil in what is +You may wonder why the kernel data must be stored separately from the UTXO. Kernels are a necessary evil in what is otherwise a very elegant cryptocurrency protocol. -Nodes must always be able to calculate the accumulated excess in order to validate the overall balance. -Since the kernel excesses are committed to, and stored in the kernels, the can never be pruned. +Nodes must always be able to calculate the accumulated excess in order to validate the overall balance. +Since the kernel excesses are committed to, and stored in the kernels, the can never be pruned. -The kernel signature also allows us to check that owners of UTXOs okayed their spending. -Note that the signatures merely confirm the excess commitment and are not connected to the inputs or outputs. So in -theory, if a kernel signature was _invalid_ you wouldn't be able to know which inputs and outputs the invalid kernel -was referring to. The whole block would have to be rejected. +The kernel signature also allows us to check that owners of UTXOs okayed their spending. +Note that the signatures merely confirm the excess commitment and are not connected to the inputs or outputs. So in +theory, if a kernel signature was _invalid_ you wouldn't be able to know which inputs and outputs the invalid kernel +was referring to. The whole block would have to be rejected. ### Thought experiment - miners stealing funds #### Question + Can miners split UTXOs up, so that the total balance is the same, but the spending keys are different? -E.g. replace +E.g. replace -$$ C = k.G + v.H $$ +$$ C = k.G + v.H $$ -with +with -$$ ( (k-k_s).G + (v-v_s).H ) + ( k_s.G + v_s.H) = C_w + C_s $$ +$$ ( (k-k_s).G + (v-v_s).H ) + ( k_s.G + v_s.H) = C_w + C_s $$ -The idea here being that miners can then steal _v_ coins because they know the blinding factor \\( k_s \\). The other -commitment +The idea here being that miners can then steal _v_ coins because they know the blinding factor \\( k_s \\). The other +commitment -$$ C_w = C - C_s $$ +$$ C_w = C - C_s $$ is "waste", since the blinding factor is unknown, but the villain doesn't care about that. #### Answer -The answer is no, miners cannot, because of the range proofs. Generating a valid range proof requires knowledge of -the blinding factors. Since the miners do not know \\( k-k_s \\), they cannot create a valid range proof for the +The answer is no, miners cannot, because of the range proofs. Generating a valid range proof requires knowledge of +the blinding factors. Since the miners do not know \\( k-k_s \\), they cannot create a valid range proof for the waste commitment. ### Another thought experiment - miners manipulating UTXOs @@ -138,28 +139,27 @@ E.g. `A -> B, B -> M`, miners remove B completely. #### Answer -While miners can perform cut-though on the inputs and outputs, they cannot remove any kernels without breaking the -overall balance. They also cannot tamper with the kernels because they cannot forge the kernel signatures without +While miners can perform cut-though on the inputs and outputs, they cannot remove any kernels without breaking the +overall balance. They also cannot tamper with the kernels because they cannot forge the kernel signatures without knowing the blinding factors of _all_ the parties involved, which includes Bob. In particular, miners would not be able to create a kernel for the `B -> M` transaction without Bob's involvement. Therefore, miners cannot steal funds from Bob by using cut-through. - ### Data malleability -When miners construct blocks, they have the -power to manipulate the block however they choose. It is therefore important to ensure that any tampering of data -that we care about is detectable and disallowed. +When miners construct blocks, they have the +power to manipulate the block however they choose. It is therefore important to ensure that any tampering of data +that we care about is detectable and disallowed. -Let's consider the information in a Mimblewimble block and see which mechanisms are in place to prevent miner +Let's consider the information in a Mimblewimble block and see which mechanisms are in place to prevent miner manipulations. ![Data malleability](/images/mw-bits/malleability.png) | Data | Malleable? | Reason | -|--------------------|------------|--------------------------------------------------------------------------------------------| +| ------------------ | ---------- | ------------------------------------------------------------------------------------------ | | Range proof | No | Constructing a range proof requires knowledge of the blinding factor and commitment value. | | UTXO value | No | The consensus balance will detect a changed UTXO value. | | UTXO spending | No | The kernel signature will be invalid. The consensus balance will fail. | @@ -172,38 +172,40 @@ Tari resolves the UTXO feature set malleability by disabling cut-through and by the output features in a signature stored with the UTXO. -In general though, UTXO features are -malleable in Mimblewimble and thus their application is highly limited. For example, in Grin, output features are -limited to indicating whether an output is a coinbase or not. Since Coinbase outputs cannot be cut-through, this is +In general though, UTXO features are +malleable in Mimblewimble and thus their application is highly limited. For example, in Grin, output features are +limited to indicating whether an output is a coinbase or not. Since Coinbase outputs cannot be cut-through, this is fine. Any other information though, such as spending maturity on regular outputs could easily be ignored by miners. #### Header data malleability -Miners are responsible for constructing the block header, and manipulating the header nonce is the primary means -that miners use to perform the proof-of-work. That said, the data in the header, i.e. the MMR roots, previous block -hash, proof of work data, timestamp, block height, etc., can all be verified _post-facto_ by nodes. If the information + +Miners are responsible for constructing the block header, and manipulating the header nonce is the primary means +that miners use to perform the proof-of-work. That said, the data in the header, i.e. the MMR roots, previous block +hash, proof of work data, timestamp, block height, etc., can all be verified _post-facto_ by nodes. If the information is not correct and consistent, the block will be rejected and will not be used to extend the chain. ## Outputs -Transaction outputs, specifically, _unspent_ transaction outputs (UTXOs), represent the distribution of the supply of +Transaction outputs, specifically, _unspent_ transaction outputs (UTXOs), represent the distribution of the supply of tokens at any given time. Vanilla Mimblewimble outputs carry the following data: -* The homomorphic commitment representing the output amount -* A proof that the commitment value is positive -* The output features + +- The homomorphic commitment representing the output amount +- A proof that the commitment value is positive +- The output features ### The commitment -The commitment is the most important field, since it encodes that value of the output as well as identifying the -output's owner. Knowledge of the blinding factor and value is all that is required to spend the output in vanilla -Mimblewimble. In Tari, this is not always the case, because of the additional flexibility provided by TariScript. We -will not go into details here, but you can read more about TariScript in the +The commitment is the most important field, since it encodes that value of the output as well as identifying the +output's owner. Knowledge of the blinding factor and value is all that is required to spend the output in vanilla +Mimblewimble. In Tari, this is not always the case, because of the additional flexibility provided by TariScript. We +will not go into details here, but you can read more about TariScript in the [TariScript RFC](https://rfc.tari.com/RFC-0201_TariScript.html). ### Range proof -Charlie, who is malicious, has an output containing 1 Tari. He sends -99 Tari to Alice , and gives himself 100 Tari +Charlie, who is malicious, has an output containing 1 Tari. He sends -99 Tari to Alice , and gives himself 100 Tari in change. ``` @@ -214,10 +216,9 @@ Since the values are blinded, in the absence of range proofs, this would pass al Therefore, range proofs are required to ensure that this Enron-like accounting is prevented. - There's another type of attack that, surprisingly, is thwarted by range proofs. Consider the following scenario: -A miner places a transaction into a new block, `A -> C`, spending commitment `A` to commitment `C` with some fee. +A miner places a transaction into a new block, `A -> C`, spending commitment `A` to commitment `C` with some fee. Somehow the miner knows that this transaction is Alice paying Charlie. $$ @@ -225,7 +226,7 @@ A = v_a \cdot G + k_a\cdot H \\ C = v_c \cdot G + k_c\cdot H \\ $$ -The public excess is +The public excess is $$ X = k_c - k_a @@ -233,10 +234,8 @@ $$ and the kernel signature signs the message `H(Ra + Rc || X || fee || m)`. - - -Now the miner adds a new output, `M` to the transaction, for reasons that will soon become clear. -`M` has zero value, i.e. \\( M = 0\cdot V + k' \cdot G \\). +Now the miner adds a new output, `M` to the transaction, for reasons that will soon become clear. +`M` has zero value, i.e. \\( M = 0\cdot V + k' \cdot G \\). The miner then modifies commitment `C` so that things still balance. Now the transaction looks like this: @@ -260,20 +259,20 @@ $$ \end{align} $$ -The excess is still the same value as before! Therefore, the original signature with still validate the excess of +The excess is still the same value as before! Therefore, the original signature with still validate the excess of this transaction. -However, now we're in the situation that Charlie cannot spend his output, since he only knows \\( k_c \\) and not -\\( k_c - k' \\). +However, now we're in the situation that Charlie cannot spend his output, since he only knows \\( k_c \\) and not +\\( k_c - k' \\). The miner can now demand a ransom from Charlie for which he will reveal \\( k' \\) allowing Charlie to spend his output. Oh dear! Is Mimblewimble broken? It turns out that we're saved by an unlikely hero: the range proof! -The only way to generate a valid range proof is by demonstrating knowledge of _both_ the blinding factor and the -value for the commitment. So even though the miner is able to manipulate the transaction as described above, he is -stymied when he realises he is unable to create a _new_ range proof for `C'` since he doesn't know the blinding +The only way to generate a valid range proof is by demonstrating knowledge of _both_ the blinding factor and the +value for the commitment. So even though the miner is able to manipulate the transaction as described above, he is +stymied when he realises he is unable to create a _new_ range proof for `C'` since he doesn't know the blinding factor, \\( k_c - k' \\).

@@ -285,33 +284,33 @@ commitment \( C \). Changing this requires knowledge of \( k_c \). The range proof plays two important roles; one obvious, and one less obvious: -* Forces users to commit to creating coins with positive values, thereby preventing users from creating new coins +- Forces users to commit to creating coins with positive values, thereby preventing users from creating new coins out of thin air. -* Forces creators of UTXOs to demonstrate knowledge of the blinding factor and value, thereby preventing users and +- Forces creators of UTXOs to demonstrate knowledge of the blinding factor and value, thereby preventing users and miners from holding recipients' funds hostage. ## Transaction offsets -Mimblewimble enhances privacy by making all the transactions in a single block look like one giant transaction. But -as it currently stands, a little detective work allows one to rebuild the transaction set in a block by matching the -kernel excesses with +Mimblewimble enhances privacy by making all the transactions in a single block look like one giant transaction. But +as it currently stands, a little detective work allows one to rebuild the transaction set in a block by matching the +kernel excesses with [combinations of inputs and outputs](https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets). To prevent this, Mimblewimble introduces the concept of a _transaction offset_. The simplest way to think about how it works is that it splits the excess into a public and private part. -$$ x = x_p + x_o $$ +$$ x = x_p + x_o $$ -The public part, \\( x_o \\) is completely random, so it gives no information whatsoever as to the nature of the +The public part, \\( x_o \\) is completely random, so it gives no information whatsoever as to the nature of the private part. Now, instead of committing to \\( x \\) in the kernel signature, we commit to \\( x_p \\). -Then, when building a block, all the offsets are simply added together, preserving the overall excess balance +Then, when building a block, all the offsets are simply added together, preserving the overall excess balance equation, but there are no longer any combinations of inputs and outputs that can be used to match the committed excess. # Other stuff ## Cut-through and output pruning -Cut-through, occurs when two transactions +Cut-through, occurs when two transactions ``` A -> B @@ -324,44 +323,44 @@ are combined into one transaction A -> C ``` -In this case, you may never know that Bob was involved in this block at all. The only clue would be that there are -two kernels for the `A->C` transaction rather than one. Of course, kernels are not attached to inputs or outputs by +In this case, you may never know that Bob was involved in this block at all. The only clue would be that there are +two kernels for the `A->C` transaction rather than one. Of course, kernels are not attached to inputs or outputs by design, so in a full block, even this information is highly obfuscated. There are only two ways to prevent this: -1. Prevent cut-through. This is the approach Tari takes in its implementation of TariScript. -2. Commit to non-prunable data outside of outputs, such as the kernel, or block header. However, this is likely to - carry severe downsides, since this strategy would typically require strong coupling between the outputs and the +1. Prevent cut-through. This is the approach Tari takes in its implementation of TariScript. +2. Commit to non-prunable data outside of outputs, such as the kernel, or block header. However, this is likely to + carry severe downsides, since this strategy would typically require strong coupling between the outputs and the data, reducing privacy, while also bloating the blockchain with additional non-prunable data. ## Pruning of spent outputs -In Mimblewimble, the blockchain can be pruned of spent outputs. This is because the blockchain the security model is -slightly different to Bitcoin. A pruned node knows that the total supply of money is correct, by virtue of the -overall commitment balance. +In Mimblewimble, the blockchain can be pruned of spent outputs. This is because the blockchain the security model is +slightly different to Bitcoin. A pruned node knows that the total supply of money is correct, by virtue of the +overall commitment balance. -It also knows that the set of transactions that led to that UTXO set is the correct one. This is because -every kernel is signed by the participants in those transactions and kernels are never pruned. The total accumulated -excess obtained by summing all the excesses committed to in the kernels contains is the sum of all the blinding -factors ever used in the blockchain, even those that have been pruned from the TXO set. If all the signatures are +It also knows that the set of transactions that led to that UTXO set is the correct one. This is because +every kernel is signed by the participants in those transactions and kernels are never pruned. The total accumulated +excess obtained by summing all the excesses committed to in the kernels contains is the sum of all the blinding +factors ever used in the blockchain, even those that have been pruned from the TXO set. If all the signatures are valid, and the total excess balances, then we can be confident that the UTXO set is correct. -However, unlike a Bitcoin node, a pruned Mimblewimble node does not know with certainty that every transaction in the -blockchain's history was valid. For example, a past bug in the consensus rules may have allowed a user to create a -negative coin briefly, that was later reversed to maintain the overall balance and the bug -allowed that block to be published. Future pruned nodes would not be able to detect this. Both the outputs and their -(fallacious) range proofs are long gone; while the kernels only commit to the blinding factor excess and the fact +However, unlike a Bitcoin node, a pruned Mimblewimble node does not know with certainty that every transaction in the +blockchain's history was valid. For example, a past bug in the consensus rules may have allowed a user to create a +negative coin briefly, that was later reversed to maintain the overall balance and the bug +allowed that block to be published. Future pruned nodes would not be able to detect this. Both the outputs and their +(fallacious) range proofs are long gone; while the kernels only commit to the blinding factor excess and the fact that the signing parties accepted the transactions (for whatever reason). ## Malleability Briefly, if -* there’s no permanent record on the blockchain (e.g. some piece of transaction data is discarded during block +- there’s no permanent record on the blockchain (e.g. some piece of transaction data is discarded during block construction), -* there’s no signature proving from the data owner / provider, or -* there isn't a commitment backed up by some other feature preventing manipulation (e.g. range proof, consensus rule) +- there’s no signature proving from the data owner / provider, or +- there isn't a commitment backed up by some other feature preventing manipulation (e.g. range proof, consensus rule) then @@ -369,57 +368,57 @@ miners can change that data however they see fit. There are several strategies once can employ to prevent malleability: -* Signatures. - * Signatures prove that the owner of a secret produced this data. - * But it’s no good if the signature can be thrown out with no consequences. - * So it’s usually backed up by a consensus rule (i.e. if there’s no signature here, AND the signature is signed +- Signatures. + - Signatures prove that the owner of a secret produced this data. + - But it’s no good if the signature can be thrown out with no consequences. + - So it’s usually backed up by a consensus rule (i.e. if there’s no signature here, AND the signature is signed by this secret data, this thing is invalid) -* Commitments - * A commitment is a permanent record of some data, usually using a one-way function such as a hash, or ECC. As with - signatures, commitments are useless if they can be discarded, or modified without detection. -* Consensus rules - * Hardcoded rules that cannot be changed and are enforced within the constraints of Nakamoto consensus. - * Rules are fixed and in place for all of history (not necessarily in effect, but in place). - * Limits certain desirable applications, e.g. digital assets. +- Commitments + - A commitment is a permanent record of some data, usually using a one-way function such as a hash, or ECC. As with + signatures, commitments are useless if they can be discarded, or modified without detection. +- Consensus rules + - Hardcoded rules that cannot be changed and are enforced within the constraints of Nakamoto consensus. + - Rules are fixed and in place for all of history (not necessarily in effect, but in place). + - Limits certain desirable applications, e.g. digital assets.
These bugs are often hard to pick up. Even Bitcoin has had its share of malleability bugs. For years, it was possible to fiddle with transaction data _after_ the transaction was signed to manipulate a bitcoin transaction's ID. This means that anything that relies on the transaction id for its security, including the Lightning Network, had -to wait for this issue to be resolved before it could be deployed. +to wait for this issue to be resolved before it could be deployed. + +This was bug was only fixed in 2017 with the introduction of the Segregated Witness soft fork. Lightning was then +first deployed on the Bitcoin network in December of that year. -This was bug was only fixed in 2017 with the introduction of the Segregated Witness soft fork. Lightning was then -first deployed on the Bitcoin network in December of that year.
## Proof of payment How can Alice prove that she has paid Bob? -This is achieved by Bob signing a message that includes the kernel hash, the received amount and Alice and Bob's -public keys. The Grin RFCs describe one method of +This is achieved by Bob signing a message that includes the kernel hash, the received amount and Alice and Bob's +public keys. The Grin RFCs describe one method of [achieving this](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0006-payment-proofs.md). # Tari's changes to Mimblewimble -This module has focussed on vanilla Mimblewimble -- the original version published by Tom Elvis Jedusor and -implemented in [Grin](https://grin.mw/). +This module has focussed on vanilla Mimblewimble -- the original version published by Tom Elvis Jedusor and +implemented in [Grin](https://grin.mw/). -Tari has made several changes -- some might say, upgrades -- to the Mimblewimble protocol, which are described in +Tari has made several changes -- some might say, upgrades -- to the Mimblewimble protocol, which are described in other modules and the RFCs. Here is a short list of the changes and where to read up more on them: -* [TariScript](https://rfc.tari.com/RFC-0201_TariScript.html) - Adding scripting capabilities to Mimblewimble. -* [Covenants](https://rfc.tari.com/RFC-0250_Covenants.html) - Allows you to place constraints on how outputs may be +- [TariScript](https://rfc.tari.com/RFC-0201_TariScript.html) - Adding scripting capabilities to Mimblewimble. +- [Covenants](https://rfc.tari.com/RFC-0250_Covenants.html) - Allows you to place constraints on how outputs may be spent. -* [Stealth Addresses](https://rfc.tari.com/RFC-0203_StealthAddresses.html) - Not only does Tari allow you to pay to +- [Stealth Addresses](https://rfc.tari.com/RFC-0203_StealthAddresses.html) - Not only does Tari allow you to pay to an "address", but you can pay to unlinkable one-time-use addresses too! -* [Burnt outputs](https://rfc.tari.com/RFC-0122_Burning.html) - Provably burnt outputs. Primarily used to convert +- Burnt outputs - Provably burnt outputs. Primarily used to convert Minotari into Tari. -* Provable minimum values - You can reveal that an output is _at least_ some value, without revealing the actual - value contained in a commitment. This is useful in registration transactions, where validator nodes need to lock +- Provable minimum values - You can reveal that an output is _at least_ some value, without revealing the actual + value contained in a commitment. This is useful in registration transactions, where validator nodes need to lock up a minimum amount of Minotari to participate in the Tari network. -* Revealed values - You can reveal the value of an output, without revealing the blinding factor or providing a +- Revealed values - You can reveal the value of an output, without revealing the blinding factor or providing a range proof. -* Output scanning - Tari provides ways to efficiently scan the blockchain (e.g. in wallet recovery) for outputs +- Output scanning - Tari provides ways to efficiently scan the blockchain (e.g. in wallet recovery) for outputs spendable by a keys derived from your seed phrase. -