Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transferring ethers with privacy protection based on precompiled cont… #701

Closed
wants to merge 1 commit into from

Conversation

jl8610
Copy link

@jl8610 jl8610 commented Aug 31, 2017

Transferring ethers with privacy protection based on precompiled contracts for ring signature verification.

@@ -0,0 +1,72 @@
## Preamble

EIP:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use 701 and move this file to EIPS/eip-701.md

Copy link

@HarryR HarryR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am interested in collaborating on this proposal and can provide implementations of the algorithm for the alt_bn128 curve or additional feedback and assistance if needed.


**Ring signature verification**

Signature σ consists of a set of public keys, two arrays of random numbers selected by signer and a point I called key image.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Franklin, Zhang signature algorithm and its relation to coin tumbling is described in the following IACR paper: https://eprint.iacr.org/2017/881.pdf

Implementations in Solidity and Go for the Ethereum alt_bn128 curve are located at https://github.com/clearmatics/mobius and https://github.com/clearmatics/orbital

This EIP suggests implementing a special precompiled contract for ring signature verification and adding one-time account mechanism on Ethereum. This can in turn be combined with *#eip-draft\_Precompiled contracts for ring signature verification on the elliptic curve alt\_bn128.* to provide privacy protection for ether transactions without affecting the in-protocol mechanisms. In each transaction, a one-time account is created for the receiver, of which no one can figure out the very owner without the corresponding scan key. Ring signature is verified by precompiled contracts and helps the receiver transfer ethers to his/her main account from one-time account, which is hidden in a set of one-time accounts to keep untraceable.

## Motivation
Currently, ether transactions on Ethereum are fully transparent, which makes them unsuitable for several use-cases where users’ privacy is of concern and the link between sender and receiver should not be retrieved by anyone else. #196 and #197 suggest adding precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve to verify zkSNARKs in Ethereum smart contract, thus increasing the privacy for users. But it has high computation complexity. Monero solves this problem by using Cryptonote under UTXO model. However, this technology cannot be directly used in Ethereum under account model. Considering all of the above, this EIP forgoes zero knowledge proof and proposes to implement a special precompiled contract for ring signature verification and add one-time account mechanism on Ethereum to provide privacy protection for ether transactions. Note that, with this smart contract, users can choose regular transactions or transactions with privacy protection depending on their needs for privacy and anonymity.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Account abstraction discussed in #678 hopes to provide a mechanism to address these problems, I hope that this precompiled contract will be a useful building block to solve problems like this.

@Arachnid
Copy link
Contributor

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

  • Frontmatter is now contained between lines with only a triple dash ('---')
  • Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

@@ -0,0 +1,78 @@
## Preamble

EIP:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file needs to go into a separate PR to have a number allocated.

@axic axic added EIP labels Jun 28, 2019
@axic
Copy link
Member

axic commented Jun 28, 2019

@JackXLu are you still pursuing these EIPs?

@github-actions
Copy link

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Sep 22, 2020
@github-actions
Copy link

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

@github-actions github-actions bot closed this Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants