Privacy in Cryptocurrencies: An Overview

Transactions in Bitcoin are recorded in its blockchain. This makes it possible to see whether coins sent through the network are still valid unspent coins. At the same time, however, the transparency of the data stored in the blockchain can be used to infer private information of users. There are already many cryptocurrencies and “money laundry” options which promise to ensure, or at least increase, privacy for their users. In the two tables below, we list key features and specifications of several cryptocurrencies (table 1) and categorize mixing services (table 2) which claim to protect privacy.

In our comparison of anonymous cryptocurrencies we use the following definition of the term “Privacy”: To protect privacy, an e-cash scheme should satisfy the following conditions:

  • Untraceability: It is infeasible to learn anything about the history of a coin.
  • Sender-Anonymity: It is infeasible to link two payments to the same sender.
  • Receiver-Anonymity: It is infeasible to link two payments to the same recipient.
  • Hidden Amount: It is possible to hide the value of a transaction.

Note that an attacker who wants to obtain the private information of a user could come in different disguises: e.g. as the sender of a transaction or just as a passive observer. “Infeasible” should mean that no one has the means to extract private information from the data exchanged during a transaction and the traces left in the ledger.

Important: In the table below, “ü” does not necessarily mean 100% privacy protection. It only indicates that methods are taken to improve privacy (depending for example on the size of the anonymity set; see also e.g. [1], [2] below). Furthermore, we do not discuss other aspects of security, like unforgeability of coins, double-spending, setup issues, or vulnerabilities in the P2P network. Please see the official websites and blogs of the corresponding services for further information.

Please contact us if you find inaccuracies or if you would like to suggest additions. Thanks!


Anonymous decentralized e-cash schemes:

 UntraceabilitySender-AnonymityReceiver-AnonymityHidden Amount
(a draft)
Private, Delegated, and Public Shuffle of
Private, Delegated, and Public Shuffle of Coins
One-Time Address
(Universal Re-Encryption)
(Zero-Knowledge Proof for Balance in Splitting Transaction)
Off-chain Mix with Secure Communication Channel via Onion-Routing
Off-chain Mix
(Enigma Transaction)
Off-chain Mix
(Enigma Transaction)

(Fixed Denomination)
Dashcoin, ... )
Ring Signature and One-Time Address
Ring Signature
One-Time Address
(Stealth Address)

Coin-Mixing by Masternodes
Coin-Mixing by Masternodes
Coin-Mixing by Masternodes

(based on
Ring Signature and One-Time Address
Ring Signature
One-Time Address
(Stealth Address)
Confidential Transaction
Minting Shadow Tokens from Shadowcash
Ring Signature for Shadow Tokens
One-Time Address
(Stealth Address)
Fully Encrypted Coin
Zero-Knowledge Proof of Ownership
One-Time Address
(zk-SNARK for Balance in Pour Transaction)
(needs a
Encrypted Coin Serial Number
Zero-Knowledge Proof of Ownership

(Fixed Denomination)


Mixing Services:

A mixing service is an external tool which attempts to increase anonymity of a cryptocurrency. We organize several mixing services into centralized mixes, n-Party mixes, or mixes which use other methods.

The user of a centralized mixing service must trust the operator to return his money, and to keep the information about the mix private. Some services offer accountability, i.e., the ability to prove theft if the operator does not return the client’s money.

The user of an n-party mix (or decentralized mix) forms a group with other users and mixes his coins with theirs. This is usually done in a single mix transaction and prevents theft. Anonymity depends on the size of the anonymity set and whether it is possible to find partners anonymously. Frequent problems related to decentralized mixes include: Denial of Service and Sybil attacks, poor performance, and incompatibility with Bitcoin.

Centralized Mixn-Party MixOther Type
Barber´s Fair Exchange
Bitcoin Fog
(based on Mixcoin; Blind Signature/Public Log)
(Threshold Transaction)
(based on CoinJoin;
+ Stealth Payment
by W. Ladd
(Blind Signature)
(with accountability)
(Off-Blockchain Payments)
(based on Barber;
2-Party; Sybil and DoS resilient)


Recent article(s) about this topic:

[1] An empirical analysis of linkability in Monero blockchain 2017 (A. Miller, M. Moeser, K. Lee, A. Narayanan)



Live Updated Cryptocurrency Investment Tracking Spreadsheet (Update 2)

We present an update of my previous article for cryptocurrency investment tracking. I received valuable feedback from some users, and I decided to update the spreadsheet based on those suggestions.

The idea with this new spreadsheet, is to add only the transactions in the History tab:

Cryptocurrency Investment Tracking History
Live update Cryptocurrencies Positions History

And reflect current asset position in the ‘Position’ tab:

Cryptocurrency Investment Tracking Positions
Live update Cryptocurrencies Positions

Also, ‘Prices’ tab contains the cryptocurrencies prices:

Cryptocurrency Investment Tracking Prices
Live update Cryptocurrencies Positions Prices

This new structure keeps tack of all your transactions, and also allows to calculate the profits of those movements.

You can see, copy and comment the Cryptocurrencies Positions Spreadsheet. To create your own version go to ‘File’ -> ‘Make a copy’.

Thanks to blockchain development team.

Review of AppeCoin: An Alternative Anonymous Cryptocurrency

AppeCoin, Sergio D. Lerner‘s proposal for an e-cash scheme, is designed for a peer-to-peer network which does not rely on a Trusted Third Party. Like the cryptocurrencies Monero or Zcash, AppeCoin is a protocol which aims to guarantee to its users full privacy. Lerner’s e-cash scheme leverages coin shuffling. Unlike ZeroCoin, where the monetary units are of a fixed value and so the transaction amount can be deduced from the number of units sent, AppeCoin enables users to truly hide transaction amounts by offering the option to divide and combine coins.

You can find the latest version of the AppeCoin draft here.


Peers have private accounts and can send monetary units, called bills, to other peers. The amount of a bill is encrypted and is only known to the bill`s owner. Bills can be divided into smaller bills or combined into larger bills. The process of bill splitting and bill combining can be done without revealing the value of the bill or its parts. Zero-knowledge proofs are used to demonstrate correctness: the value of the bill is equal to the sum of its parts. There is a minimum bill value in order to avoid inflation.

Transactions to other peers can be sent without revealing their public addresses by using universal re-encryption. Once a payment is sent, it has to be accepted by the receiver. Payer and payee exchange the secret keys of the encrypted bill. The communication between payer and payee uses hybrid encryption and entity authentication.

The community verifies the validity of transactions and that coins have been divided or combined correctly. In a proof-of-work based framework, these changes are recorded in a ledger maintained by the miners. In order to increase anonymity, AppeCoin provides private, delegated, and public bill shuffling. The correctness of the shuffles is verified by the miners.

AppeCoin seeks to ensure (see p. 6 in draft):

  • Efficiency: low transaction wait-time.
  • Security: no double-spending, no over-spending, unforgeability (of bills and payment transcripts), authenticity, non-repudiation, portability.
  • Privacy: anonymity (payer cannot be identified from data exchanged during payment), untraceable (infeasible to follow the history of a bill), unlinkable payments, private account balance, hidden transaction amounts.

The difficulty of the decisional Diffie-Hellman problem and of the representation problem should guarantee security and privacy as long as the encryption scheme used resists Ciphertext-only attacks and Chosen-Plaintext attacks.

More Details:

Below, we describe some key cryptographic building blocks and algorithms used in the AppeCoin protocol.

A.1: Universal Re-Encryption of Schnorr Public Keys: A bill contains the public key of the present bill owner. Universal re-encryption is used to re-encrypt the public key of the bill owner without making him change his private key.

A.2: Bill Shuffle: The BillShuffle algorithm shuffles the bills and provides a zero-knowledge proof of correctness of the shuffle. The input of the BillShuffle algorithm is a list A = (a1, … , an) of bills ai with i=1, … , n and its output is a list B = (b1, … , bn) where bi is the encryption of  aπ(i) for a permutation π with encryption key k.

Two proof systems are considered in AppeCoin proposal. Both apply the Fiat-Shamir heuristic to an interactive public-coin proof system. The second proof system proposed uses a (pseudo-)random subset test which makes it more efficient. Zero-knowledge is achieved by blinding the encryption key and only showing the verifier the image or preimage of a randomly chosen subset under the given permutation π, but not the subset itself. The prover commits to the encryption of the product of the elements of the subset. The assumed hardness of the representation problem makes it difficult to just guess the product.

A.3: CoinSplitting: The input of the CoinSplitting algorithm is a bill a and produces an output of two bills b and c whose values add up to the value of bill a. The algorithm provides a zero-knowledge proof for correctness.

The amount v of a bill is hidden in the exponent, i.e. as xv. (Note that in the proposal exponentiation refers to homomorphic encryption). The core idea of the CoinSplitting algorithm for proving balance, i.e. va= vb + vc, is to check the correctness of the equation xva = xvb × xvc.  A blinding factor is used to disguise proportion: xkva  zk= xkvb  zkb × xkvc zkc  with k=kb + kc for random kb and kc. The prover changes exponents or multiplies factors and provides the verifier with proofs of knowledge.

A.4: InRangeProof: The input for the InRangeProof algorithm is a bill and a range for its value. When the bill is in the given range, the algorithm´s output is 1.

A.5: SendBill: This action includes two algorithms which produce a public and a private message.

Public message: This message is spread through the network and contains the hash of the public key of the current bill owner, and the destination address and signature of the sender.

Private message: This message is sent privately from the sender to the receiver of the transaction, and is essentially the encryption of the secret keys of the bill, so that the receiver can verify the amount and modify the bill.

A.6: ReceiveBill: The receiver checks the sender´s identity, and verifies that the bill and the amount which was sent to him, is correct.

A.7: Public Check of Transaction: Miners search for the serial number of the bill in the ledger, and verify that the bill is unspent and that the sender´s Schnorr signature is correct. The sender´s public address is temporarily visible, until it is disguised by re-encryption.


We think the AppeCoin proposal is exciting and would like to comment on some of its strong points and point to places which we think should be filled out more.

Ad A.1: Universal Re-Encryption:

a) The decisional Diffie-Hellman (DDH) should be assumed instead of computational Diffie-Hellman (CDH) (AppeCoin draft, p. 8).

b) The AppeCoin draft claims that universal re-encryption is secure for any encryption scheme satisfying indistinguishability, but provides no reference. Young/Yung´s article Semantically Secure Anonymity: Foundations of Re-Encryption demonstrates the security for one such encryption scheme, the ElGamal encryption.

Ad A.2: BillShuffle:

a) Security aspects: Formal proof is needed for the claim that BillShuffle provides a non-interactive zero-knowledge proof.

The Fiat-Shamir heuristic is a common way to transform a constant round interactive proof into a non-interactive proof. The heuristic is proven to be secure, i.e. computationally sound, in the random oracle model. Some examples of insecure transformations exist in the plain model, but the Fiat-Shamir heuristic applied to interactive proofs, not just arguments, was recently  proven secure under some conditions for the hash functions involved. See Tauman-Kalai/Rothblum/Rothblum.

Some evidence is provided for the security of the BillShuffle algorithm, but there is no formal proof of security in the draft. Completeness is straight-forward. The article of Tauman-Kalai/Rothblum/Rothblum may imply that the BillShuffle algorithm satisfies computational soundness even in the plain model: the Fiat-Shamir transform is applied to proofs. Although it seems plausible that zero-knowledge can be deduced from the strength of the encryption scheme, the required zero-knowledge simulator is missing.

b) Performance: The proof system with the random subset test requires an average of rounds*3/2 exponentiations to prove and verify a shuffle of n bills which results in a very fast run time. [Compare the shuffle protocol by Abe (22*n log⁡(n) exponentiations), Sako-Kilian (642*n exponentiations), Furukawa or Groth or Lipmaa-Fausti/Zajac (using pairings: roughly 3n), Lindell-Pinkas (cut-and-choose on circuits; roughly  15qn + 39n + 10q + 6 exponentiations, where q is a statistical security parameter)].

The private keys of shuffle participants may be vulnerable to side-channel attacks since a participant of a shuffle must decrypt all shuffled bills until he finds his own which causes an average of n/2  calls of his private key.

c) Technical Remarks:

  1. In figure 4, the definition of bw as bw:=awk is missing.
  2.  In figure 7, p. 13, Blob D should start with s (number of rounds) in order to have the same hash H(C) as in the proof;
  3. In figure 7, p. 13, bj in 8.2.3 should be swapped with aQ(s,i)  in 9.2.3;
  4. In figure 8, p. 14, in, ts × k should be replaced by rs × k. Index s should be j. Similarly, this applies to ts × k-1  in

Ad A.3: CoinSplitting:

a) Security aspects: Formal proof is needed for the claim that CoinSplitting provides a zero-knowledge proof for correctness.

Heuristically, the Discrete Logarithm Problem makes it hard for the prover to cheat the verifier by changing exponents. The prover could try to push some part of vb into the exponent of the neighboring factor z, but he would have to know the logarithm of the blinding factor  (which should be verifiably chosen at random) with respect to the basepoint or with respect to x. However, the draft lacks a formal proof for soundness. Although we could find no evidence that the proof in CoinSplitting leaks information, the draft does not provide a formal proof for zero-knowledge.

b) Performance: Proof and verification for two bills requires 12 exponentiations and many zk-proofs of knowledge of encryption keys (e.g. using Schnorr ID protocol in case of a Pohlig-Hellman encryption scheme). The proposal´s author, Sergio Lerner, hopes to improve this in the future.

c) Technical Remarks:

  1. In DecompProof1, p. 23, we suggest defining bu as bu=au, i.e., bu= auk qb ; otherwise bt= budoes not hold;
  2. In DecompProof1, p. 23, Step 6 should be analogous to step 3.

Additional Resources

If you liked this article, you might also like:

Live Updated Cryptocurrency Investment Tracking Spreadsheet

Read the latest version of this article here.

This Google Spreadsheet can help you track your cryptocurrency investments. It gets the prices from an external API and keeps them updated. It supports the 15 most popular cryptocurrencies. It uses Poloniex and Cryptocompare APIs to retrieve latest currency’s rates:

Cryptocurrencies Value Calculator

It uses a script based on FastFedora Project which can be optionally downloaded from GitHub.


  • Go to the Google spreadsheet here.
  • Go to File -> Make a Copy.
  • Put you own cryptocurrencies and values.
  • Enjoy!

Fast Smart Contracts Execution in an Ethereum Private Blockchain Development Environment

We describe a geth source code change which enables faster block mining. We hope this option will be included in Ethereum command lines.

Private Ethereum blockchains may be deployed by private entities to use in production or in the software development process. There are different ways of speeding the development environment. Some developers choose an Ethereum branch which does not depend on mining via slow proof-of-x methods. Others prefer a modification of the most up to date Ethereum node. The unchanged Ethereum node takes about 15 seconds per new block, while the mining difficulty function below dramatically reduces this lag time.

For developers, this means faster transaction and smart contract execution since every smart contract function, every event fired, and every state change depends on block mining time.

Source Code Change

In the current version you should replace CalcDifficulty here with the following:


Increasing the mining rate will reduce your filesystem capacity much faster than usual due to the underlying Ethash DAG. You can safely remove your ~/.ethash directory to free space. Be sure to stop geth first.


Private blockchains which use different consensus algorithms can still take advantage of the Ethereum virtual machine and the programming languages supported there (e.g. Solidity). See the following technologies:

Real World Project in Private Blockchain Development

In the blockchain development industry lot of new technologies had arisen in the latest months. Unfortunately, most of the new platforms are not ready to use in production or directly they were built only to develop Demos.

Our developers in Coinfabrik have been struggling to use them in the real world. Our customer asked to use Hyperledger but our initial tests were not successful. It was difficult to make the blockchain work and the smart contract platform is not ready yet. Therefore, the only available option was an Ethereum based blockchain since the EVM is the only one able to run smart contracts out of the box. We first tried Monax Eris but they provide docker images which we were not able to make it work on AWS and also they did not provide a permissionable smart contract store. Then, we started testing JP Morgan Quorum platform for this blockchain software development project. To start, we solved the AWS issue, also present in Monax Eris. In addition to this, we found that Cakeshop, Quorum’s smart contract deployment tool, was not working fine. It was able to publish only small smart contracts but we needed to develop some bigger ones and it did not work at all. In addition to this, Quorum does not have a Web3 like interface so the interaction with the smart contracts was very hard. Monax Eris provides a different API which is richer than Quorum interface.

Finally, we started testing our own Private Ethereum Blockchain. We had to solve some gas price issues to avoid ‘out of gas’ issues, PoW difficulty adjustments and some issues with Solidity versions but it mostly worked. The problem we found when relaying on a smart contract for all the website functionality is that everything was slower than we were expecting, user interaction was not fluent. That is why we had to adjust the complexity to generate blocks every second or faster, which ended up in a very fast blockchain storage grow. We fixed it modifying core code to trigger block creation in a different way. This problem is not present in Monax Eris since they use Tendermint which generates new blocks when it is necessary.


Private Blockchain development technologies are very immature and are not ready for the real world. Each small task requires a lot of time and adjusting the platforms is not straightforward and there is almost no documentation. I hope Enterprise Ethereum Alliance can fix the platform to use it for enterprise use.

zk-SNARKs Technically Explained: Basic Principles

The full technical article is available here.


Payment confidentiality is a property for cryptocurrencies which allows the user to hide the sender and receiver, as well as the amount of a transaction in the blockchain. Monero Research Lab invented Ring Confidential Transactions, while Zcash uses a different approach based on recent scientific progress in the field of ‘Non-Interactive Proof systems’: zk-SNARK protocol for circuits.

Circuits are basically ‘programs’ which take values as inputs and result in an output value. The corresponding decisional problem is to determine whether a given assignment for the inputs and output of a specific circuit is valid. Such a problem can be reduced to an algebraic problem about polynomials which allows a ‘shorter’ verification and, at the same time, can hide the correct assignment from the verifier. This might sound unlikely, but we will see how it is possible.   

Our aim is to illustrate the reduction of the decisional problem for circuits to an algebraic property of polynomials, which C. Reitwießner’s excellent survey zkSNARKs in a Nutshell leaves out,  and to show how this reduction can be used for zk-SNARK. Please see M. Green’s blog post Zero-Knowledge-Proofs: An illustrated Primer  for a good survey  of Zero-Knowledge-Proof.

We will discuss the security assumptions behind zk-SNARKs in a future article.

If you liked this article, you might also like:

Quantum Resistant Public Key Exchange: The Supersingular Isogenous Diffie-Hellman Protocol

Synopsis of our full article:

Though the research on quantum computers is still facing big challenges, there is also some progress in this field. The National Institute of Security and Technology (NIST) recently published a report on Post-Quantum Cryptography which informs about new developments. They believe that it is time to think of quantum-safe primitives, and  announced open calls to encourage researchers to work on proposals. This continues prior work in the field by D. J. Bernstein and others.

Quantum computers would endanger all cryptographic protocols which are based on prime factorization and discrete logarithms. Private keys used for transactions in Ethereum and Bitcoin would no longer be safe. Shor`s algorithm could be used to discover them in quantum polynomial time. We will give a glimpse of the idea of how this algorithm works, starting with  Deutsch´s quantum algorithm which is easier to understand but shows already some basic principles.

Some cryptographic protocols, including code-based, lattice-based or hash-based cryptography,  would already survive quantum computers. De Feo and Jao´s proposal — the Supersingular Isogenous Diffie-Hellman Protocol — which we discuss in the article, has the advantage of being exponentially complex while having much smaller key-size compared to these other protocols. The very recent work by Castello-Longa-Naehrig presents a high-speed and constant-time implementation of SIDH which pushes this proposal further for practical use. We will briefly discuss their interesting proposals.

Comparison of Cryptocurrency Developments

Working for our customers in our blockchain development company we built this spreadsheet which is a work in progress, comments are welcome here, which describes the features of multiple blockchain and sidechain technologies. Views about blockchain technologies range from hype to skepticism. A blockchain is a distributed database and consensus network that can be used to validate cryptocurrency transactions. Blockchains do not replace conventional databases, instead they create consensus protocols between untrusted parties on what information needs to be appended to a shared database. This obviates or reduces the need for trusted third parties in financial agreements.

Below we describe the different types of blockchain players and their features:

Type of player

  • Cryptocurrencies (e.g. Bitcoin, the first cryptocurrency in history)
  • Blockchain platforms (e.g. Ethereum, a platform that has its own cryptocurrency)
  • Sidechains (e.g. Rootstock, a sidechain which provides smart contracts for Bitcoin)
  • Distributed ledgers/private blockchains (e.g. R3 develops blockchains for the financial industry)

Market capitalization

Market capitalization is a meaningful indicator of the importance and power of a blockchain player. Bitcoin is the biggest player with a market capitalization of approximately 10 billion dollars, followed by Ethereum with around 1 billion dollars (as of July 2016). This can change quickly, because it’s a young and therefore unpredictable market.


A meaningful indicator for the usability and value of a cryptocurrency is liquidity. Liquidity defines how easily and quickly cryptocurrencies can be purchased or sold without significant loss.


Most players have licensed their software as open source. For example Bitcoin is licensed under the MIT free software license.

Asset names, currency symbols and three letter currency codes

Cryptocurrencies and sidechains use unique asset names, currency symbols and three letter currency codes to identify themselves. For example Bitcoin, which is also the asset name, uses ฿ as its currency symbol and BTC as its official three letter currency code.

Public and private

Public blockchains are available to the general public, while private blockchains are restricted to clients and internals of banks or other institutions.


Identity protection and privacy may be important to users and traders to safeguard their business strategies, while identifying users may be important to criminal and tax institutions. There are different levels of protection:

  • anonymous (traders or users cannot be identified by anyone)
  • pseudo-anonymous (traders or users can be identified only by blockchain intelligence and network traffic analysis)
  • private (traders or users identities are only known to the organization running the blockchain or platform)
  • transparent (traders and users identities are known to everyone)

Consensus methods

Consensus methods like Proof of Work or Proof of Stake determine how transactions are validated.

  • In validation by Proof of Work (PoW) the result of an expensive cryptographic calculation is required as proof of the right to vote on consensus.
  • In validation by Proof of Stake (PoS) the amount of voting power for consensus is directly proportional to the shares held. For example, holding 10% shares bestows 10% voting power.

Scripting language, Turing completeness and smart contracts

Many cryptocurrencies have their own scripting languages which can be embedded into transactions. Some languages are Turing complete (e.g. Solidity in Ethereum) and can run any algorithm. This is necessary to run smart contracts which are programs to conduct consensus-enforced contracts between users. Insurance companies could use smart contracts to compensate automatically for crop loss due to hail, for instance. A supply service could use a smart contract to charge on delivery. A more complex example of the use of smart contracts is a DAO (Decentralized Autonomous Organization), a company run by smart contracts rather than by managers. Smart contracts can be used for financial products, property registration, prediction markets, crowdfunding, and other purposes.

Governance, Stakeholders and Conflict of Interests

Governance refers to who decides what happens with a blockchain in terms of software updates: Miners, nodes, users, the core development team, and other stakeholders. Ideological, technical, financial and privacy interests can influence the direction of a cryptocurrency. This can lead to conflicts of interests among the governance and may even cause a cryptocurrency to split and form an Altcoin.

Transaction speed, fees and micropayments

Cryptocurrency transactions should be fast and cheap and even micropayments should be allowed. The proof of stake consensus method allows faster and cheaper transactions, although these are less secure than those which use proof of work. New off-chain methods offer secure, instant micropayments. This is useful when charging for small amounts, like in pay-per-minute video streaming, or pay-per-megabyte data transmission.

Processing power

Processing power costs (CPUs, GPUs, ASICs) are proportional to energy costs. Proof of work tends to require a lot of energy and substantial computer equipment. proof of stake is less expensive.


A variety of attack vectors challenge the security and reliability of a blockchain. Here are some examples: A 51% Attack is when a stakeholder of a Proof of Stake cryptocurrency owns 51% of all shares and abuses his or her majority power to bias consensus to agree on double spending. A Sybil attack is when one node fakes various node identities and gains a voting advantage to bias consensus.

Note: Bitcoin’s security threshold is not 51%, but about 33% due to selfish mining. Ethereum’s security is theoretically 12.5% due to uncle mining. The only PoW blockchain that has 51% security is RSK.

Some Comments on the Security of ECIES with secp256k1

The challenge of modern cryptography is to find efficient but secure encryption schemes. The Elliptic Curve Integrated Encryption Scheme (ECIES) is a widely used encryption scheme which is specified in many standards. It is used for example in Ethereum’s Whisper. While Bitcoin Core does not implement ECIES, it can be employed to send secure messages using Bitcoin keys. Together with the Decentral Jaxx project we contributed with the OpenPGP.js project that follows this approach.

Most encryption schemes rely on the intractability of some variants of the Diffie-Hellman problem. ECIES security assumes, amongst other things, that the hashed decisional Diffie-Hellman problem over the specified elliptic curve is of exponential complexity. Although this problem is easy for a specific class of elliptic curves, the rest can currently only be solved via discrete logarithms. This is in general a harder task which is believed to be of exponential complexity for carefully chosen elliptic curves.

In our paper here we summarize the ECIES scheme and its security when paired with the secp256k1 curve of the SEC Group which is currently used in Ethereum.  (For more information about the complexity of the discrete logarithm problem on elliptic curves please see our previous article: ECDSA Security in Bitcoin and Ethereum: a Research Survey)