
_The project uses Ergo’s Sigma protocols to enable efficient, trustless mixing of funds, enabling a high degree of privacy while ensuring security is not compromised._

_ErgoMixer command-line demo tool along with detailed technical description can be found at https://github.com/anon92048/ergo-mixer-demo ._

Ergo’s Sigma protocols can be used to create many interesting and exciting DeFi use cases, with greater simplicity, efficiency and security than other smart contract platforms offer. Created by one of Ergo’s community members @anon92408, Σ3 (‘Sigma Three’) is a powerful mixer that works by pooling funds and enabling participants to spend them without anyone knowing who made the transactions.

## How does it work?

While understanding the full operation of the mixer will require some in-depth knowledge of cryptography, the root concept is fairly simple. (For those who want to learn the details, you can find out more in the white paper.)

Participants send coins to a pool, and these can be spent by different members. However, the use of Sigma protocols – specifically ring signatures – means that it’s impossible to know which member spent them.

Take the simplest case of a pool in which a ‘box’ of coins can be spent by either Alice or Bob. Either Alice or Bob can sign a transaction and move the coins, but no external observer will be able to tell which of the two signed it. This is different to multi-signature transactions, in which (say) 2 of 3 participants have to sign a tx; with multi-sig, it is known which two do the signing.

Thus anyone observing from the outside would have a 50:50 chance of guessing whether Alice or Bob moved those coins. But that process is iterated, over and over again, with different users. After many rounds, with many users, it’s effectively impossible to know who owns the coins. Still, the coins never leave the control of their original owner – there is no risk of lost funds.

## ErgoScript

This process can be implemented natively on the blockchain, as is the case with ZCash. This has a similar process hardwired into the blockchain – which works, but imposes limits on the blockchain.

It would be possible to implement something similar with Ethereum, since Ethereum has Turing-complete smart contracts and any computational task can be executed. But it would be clunky and inefficient, and the result would be expensive and possibly risky.

Ergo allows this kind of use case to be implemented easily, using Sigma protocols. ErgoScript includes native support for all the cryptographic and blockchain functionality required to create Σ3 on the Ergo chain, securely and efficiently.


Introducing Σ3 – ErgoMixer

We would like to announce that Ergo has successfully passed security audit of certain (most critical) parts of the code. This time the audit was done by Jean-Philipee Aumasson (aka veorq, <https://aumasson.jp/> ).

The detailed report is below. Nothing critical is found. Comments on issues found:

1. On wallet password, we'll provide a recommendation in next versions of the protocol client. Not sure hard enforcement on password will take place, but we'll do more consultations on this.
2. Changing "n" and "k" parameters makes sense when launching new network only. Changing this parameters in mining node will make blocks produced invalid for other nodes. Changing this parameters in protocol client means going on another fork (blocks coming from the honest protocol participants will be rejected). So no need for extra checks maybe, as people launching new networks will set "n" and "k" properly.
3. Currently the Ergo node (as well as other blockchain protocol clients and wallets we're aware of, as well as cryptographic libraries we're using) do not provide protection from side-channel attacks running locally (e.g. timing attacks or memory inspection by malware or viruses). So please protect machines you're running wallets on!  

\==========================================================================================================

% Ergo security assessment % Jean-Philippe Aumasson % 07/Dec/19

## Summary

We were solicited by Ergo to perform a security assessment of several components of their Ergo Platform:

* Sigma protocol proofs creation and verification
* Wallet's secure storage of secrets
* Proof-of-Work validation

​This brief report summarizes our assessment and describes our findings and mitigation recommendations.

## Sigma protocol proofs

​The Ergo protocol relies on ErgoScript, a scripting language supporting sigma-statements, which can be proven and verified through non-interactive proofs of knowledge.

These proofs are statements described as a tree of AND, OR, and threshold conditions, whose leaves are proofs of knowledge of a discrete-logarithm problem.

The proof of the sigma-statement is then made non-interactive thanks to the Fiat-Shamir transform.

This logic is specified in the [ErgoScript paper](https://ergoplatform.org/docs/ErgoScript.pdf), and the specific
proving and verification routines described in its Appendix A.

​Implementation challenges are then to:

* Define encoding of the proofs that are safe and efficient, and implement serialization and deserialization that always succeeds in processing valid input, and that always gracefully fails to process invalid input.
* Implement the proving and verification functionalities correctly, in compliance with the specification, and most importantly such that no invalid statement can successfully pass verification.

We reviewed these two aspects, based on the code in the repository [sigmastate-interpreter](https://github.com/ScorexFoundation/sigmastate-interpreter), and on the [ErgoScript paper](https://ergoplatform.org/docs/ErgoScript.pdf), carefully comparing the intended behavior (in Appendix A) with the actual behavior as implemented.

​We notably reviewed code from the [SigSerializer](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/sigmastate/src/main/scala/sigmastate/SigSerializer.scala), [Interpreter](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/sigmastate/src/main/scala/sigmastate/interpreter/Interpreter.scala), and [ProverInterpreter](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/sigmastate/src/main/scala/sigmastate/interpreter/ProverInterpreter.scala) traits and objects.

​We mainly sought bugs from the following classes:

* ​Unsafe processing of malformed input
* Unsafe processing of unusually long or short input
* Behavior when large tree depth or recursion level
* Unsafe use Scala types and structures
* Inappropriate variable types
* Integer overflows
* Race conditions
* Logic bugs 

​Despite extensive review, we did not identify any security issue.

The protocol's logic and internals are nonetheless relatively complex, and we believe the highest risk is in the parsing and verification of proofs. To exploit such issues, however, an attacker would have to create a semantically correct script that somehow benefits them, yet that passes verification when it does not ought to.

Regarding software security, Scala eliminates certain classes of bugs, but Scala code may still suffer from bugs due to Scala's specific behavior or to unhandled errors.

## Wallet

Ergo's wallet functionality enables its users to store a secret on disk and recover it, initializing the wallet with a new seed when it's first used.

​This logic is mainly defined in [ErgoWalletActor](https://github.com/ergoplatform/ergo/blob/master/src/main/scala/org/ergoplatform/nodeView/wallet/ErgoWalletActor.scala), and a key component regarding secrets' storage is [JsonSecretStorage](https://github.com/ergoplatform/ergo/blob/master/ergo-wallet/src/main/scala/org/ergoplatform/wallet/secrets/JsonSecretStorage.scala).

​The first time a wallet is create, the `InitWallet` command does the following:

* Generate `settings.walletSettings.seedStrengthBits` random bits, as initial entropy. [By default](https://github.com/ergoplatform/ergo/blob/master/src/main/resources/reference.conf), 160 bits are generated.
* Generate a BIP39 from the random bits generated, which can be seen as an encoding of the entropy bits. The standard BIP39 logic is used, with optional password.
* Derive a seed from the mnemonic using BIP39's PBKDF2-based derivation logic.
* Encrypt this seed to disk with AES-GCM, using a random nonce, and a key derive from the password using PBKDF2-HMAC-SHA256 with [128000](https://github.com/ergoplatform/ergo/blob/master/src/test/resources/application.conf#L107) iterations, using a random salt.

To unlock a wallet already created, a user provides the password and the wallet attempts to decrypt the stored data.

​To restore an existing account from a BIP39 passphrase, a similar process as initialization is performed, except that the wallet will derive the seed from the mnemonic instead of picking random mnemonic.

​The two risks we identified here are:

* The absence of checks on the password's length: since the password is sufficient to access the seed given the wallet's on-disk stored secret, the password should in theory have at least as much entropy as the mnemonic, and in practice should be practically hard to crack. We thus recommend to enforce a minimal password length, for example of 16 characters.
* Copies of secret values (password, seed, and derive private keys) are likely to remain in memory after wallet software execution, which is an intrinsic limitation garbage-collected languages such as Scala.

Another process or user sharing the same memory address space could potentially recover the secrets, and they could also appear in crash dumps. To the best of our knowledge, there is no effective mitigation in pure Scala.

​

## PoW validation

​After previously reviewing the security of the Autolykos PoW, we performed another round of review focusing on its latest verification logic, and notably the changes in the commit [eb0f85a](https://github.com/ergoplatform/ergo/commit/eb0f85ac48b0ee8194c12369faf4cc5f16954af9).

​The main relevant file is [AutolykosPowScheme](https://github.com/ergoplatform/ergo/blob/master/src/main/scala/org/ergoplatform/mining/AutolykosPowScheme.scala),and other important operations are for example implemented in
[HeadersProcessor](https://github.com/ergoplatform/ergo/blob/master/src/main/scala/org/ergoplatform/nodeView/history/storage/modifierprocessors/HeadersProcessor.scala) and [ModifierValidator](https://github.com/ScorexFoundation/Scorex/blob/master/src/main/scala/scorex/core/validation/ModifierValidator.scala).

​We checked that the implemented verification logic is consistent with that specified in the Autolykos specifications, and that it is properly integrated in the block header validation logic.

​We believe the following points should be addressed:

* Stricter validation of `k` and `n`: although the class enforces `k<=32` (number of elements in the solution) and `n<31` (log2 of the total number of elements), weak could still be created from the authorized parameters. The `validate()` function may therefore have additional validation that `n` and `k` are equal to the intended
  values.
* Assert that `k` and `n` are positive values, since currently negative ones (as `Int`s) would pass the `assert` statements.

Security Audit (by Jean Philippe Aumasson)


A lot of blockchain-related news these days are saying us that a bank _X_ or a corporation _Y_
is going to use a "blockchain" to "reduce costs". Basically it means that just another buzzword is 
considered by big banksters as just another tool to extract value from everywhere in a more efficient way,
and also to save on cutting job positions.  

While I am avoiding to say anything about "Satoshi's vision" (nothing but speculations could be dug there after 
his exodus), a broad view I witnessed in the early years around online forums users is that a cryptocurrency 
should provide tools to enrich the ordinary people behind their small businesses providing no much above making ends meet, not depersonalized big financial capital. The tools of 
a cryptocurrency in the eyes of the original broad community vision should allow people to do economic activity dependless on business size, geographic location, interest rates set by big players, and so on. 
The tools should allow people to do contracts (no paper contracts, but digital, self-enforcing, and reasonably smart contracts) dependless on differences in jurisdictions, traditions, followed business practices etc.

I hope Ergo would be useful here. Thousands of small cooperatives and individual entrepreneurs are more important to healthy and sustainable wealth growth around the globe than a couple of corporations hiding profits in offshore heavens. 

As an example, let's consider a cooperative federation (such as [Radical Routes](http://www.radicalroutes.org.uk/)) willing to provide financial help to an entrepreneur thousands kilometers away (say, in Rojava). 

We need to assume some details now. In the first place, assume that there are four cooperatives in the network. They collectively lock _10,000_ Ergs (in equal parts, so _2,500_ Ergs each) in a contract, which says the following:

1. The cooperatives are associated with public keys _pubkeyA_, _pubkeyB_, _pubkeyC_, _pubkeyD_. The entrepreneur is associated with a public key _businessKey_.
2. The cooperatives are locking money in a coin protected by a funding contract, then doing due diligence and vote on whether to fund the entrepreneur or not. All the contract fund (_10,000_ Ergs) is going to the entrepreneur if _3_ votes out of _4_ are for that. Technically, the voting is done via 3-out-of-4 threshold signature. If voting is not successful (_3_ out of _4_ signatures are not collected) before the block number _1,000_, any cooperative (actually, anyone) can submit withdraw transaction, which is returning _2,500_ Ergs (at least) to every cooperative. Further, the funding contract will also be called the voting contract.
3. The investments could be spent on three goals, with some strict bounds. Namely, the entrepreneur must spend at least _5,000_ Ergs on equipment, at least _2,000_ Ergs on construction of a building needed, other funds the entrepreneur may spend arbitrarily.
4. To be sure that equipment money will be spent on equipment, the cooperative federation is using public keys of known equipment sellers in the area of the entrepreneur. For example, consider that there are equipment sellers with public keys _pubkeyTool1_, _pubkeyTool2_, _pubkeyTool3_, _pubkeyTool4_ in the area. Technically, the transfer is organized as a collective signature of one equipment sellers (thus ring signature from equipment sellers ring AND entrepreneur's signature)
5. Similarly, assume that there are _3_ builders in the are cooperative federation is recognizing, associated with public keys _pubkeyConstr1_, _pubkeyConstr2_, and _pubkeyConstr3_.
6. Similarly to the voting contract, if equipment and construction contracts are not co-signed before block number _5000_, the federation cooperatives could withdraw funds. 

There are different ways to define contracts in Ergo. A script in the low-level language, **ErgoTree**, is describing a (single) logical condition on whether a coin could be spent according it, and also a spending proof provided by a spending transaction. Internally, the condition is represented as a typed syntax tree thus the name. The structure is allowing us to do ahead-of-time cost analysis etc. Higher-level language called **ErgoScript** allows to have more traditional and readable description, use variables and break logic into subroutines. 

Let's start with the main contract defined in (1-3) above:

```scala
{
 val votingSuccess  = atLeast(3, Array(pubkeyA, pubkeyB, pubkeyC, pubkeyD))
 val properSpending = OUTPUTS(0).value >= 5000L &&
                      blake2b256(OUTPUTS(0).propositionBytes) == spendingContract1Hash &&
                      OUTPUTS(1).value >= 2000L &&
                      blake2b256(OUTPUTS(1).propositionBytes) == spendingContract2Hash

 val withdrawCondition = HEIGHT >= 1000L &&
                         OUTPUTS(0).value >= 2500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 2500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 2500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 2500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 (votingSuccess && properSpending) || withdrawCondition
}
```

This script in the **ErgoScript** is to be compiled into a syntax tree (which is to be written into the blockchain in a serialized form) by binding it with concrete values for variables (_pubkeyA_, _pubkeyB_, _pubkeyC_, _pubkeyD_, _spendingContract1Hash_, _spendingContract2Hash_). _spendingContract1Hash_ is a hash of (serialized) equipment spending script which will be provided below, _spendingContract2Hash_ is a hash of construction spending script. 


The equipment spending script is below: 

```scala
{
 val spendingSuccess = (pubkeyTool1 || pubkeyTool2 || pubkeyTool3 || pubkeyTool4) && businessKey

 val withdrawCondition = HEIGHT > 5000L &&
                         OUTPUTS(0).value >= 1250L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 1250L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 1250L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 1250L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 spendingSuccess || withdrawCondition
}
```

And the construction script is: 

```scala
{
 val spendingSuccess = (pubkeyConstr1 || pubkeyConstr2 || pubkeyConstr3) && businessKey

 val withdrawCondition = HEIGHT > 5000L &&
                         OUTPUTS(0).value >= 500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 spendingSuccess || withdrawCondition
}
```

Now assume that the cooperative federation has created a coin protected by the voting contract. Below is how the entrepreneur can do his business:

1. Create a transaction which consumes the coin and create at least three coins, one with equipment spending contract, another with construction spending contract, third is creating a coin protected by entrepreneur's public key.  
2. Send the transaction to the cooperatives, wait for the transaction with the threshold-signed input being published on the blockchain.  
3. Consider a contract with an equipment seller, co-sign a spending transaction.
4. Consider a contract with a builder, co-sign a spending transaction.


The entrepreneur can easily run away without doing any business, but with no more than _3,000_ Ergs. This can be fixed, e.g. this money could be made spendable only after block number _5,000_, and before that money could be withdrawn by the cooperatives. For equipment and construction spendings, the entrepreneur is working along with some, presumably already reputable, business. Thus the investor is reducing its risks.

You can find [code and example transactions online](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/src/test/scala/sigmastate/utxo/examples/CoopExampleSpecification.scala). Please note that we have more examples of complex signature schemes, multi-step contracts (with on-the-go execution paths revealing, like MAST in Bitcoin, but with cycles allowed), oracles, crowdfunding and so on. Please check our [examples repository](https://github.com/ScorexFoundation/sigmastate-interpreter/tree/master/src/test/scala/sigmastate/utxo/examples). 
