Hey! This is something that we have started investigating for our smart-contract based wallet Argent. We are working on the mixer but have not yet started tackling the “deanonymize yourself by paying for gas” issue. We were planning on looking at some form or meta-transactions for that which is essentially what you @vbuterin are suggesting. Will let you know if we find something even partly satisfactory.
@jpitts I agree that “account contracts” pose a challenge for privacy but I also think they are nicely positioned to bring solutions to users.
Yeah, I would definitely support reusing BIP32 for this.
We were planning on looking at some form or meta-transactions for that which is essentially what you @vbuterin are suggesting
I personally hope there could be a coordinated effort to get meta-transactions or whatever other scheme figured out and made in a way that anyone can use. It’s just too useful. Maybe it requires finally getting something like whisper working well; would be good to have more discussion…
We got a step further with the EIP proposal and it is now a draft
They way it is currently written would already allow this use case by defining a “dApp” key type (the document defining all key types is still WIP) and then each dApp gets an identifier.
If it is desired to keep a register of dApps, then simply using the key_index already defined would make the job.
Otherwise, for each dApp a 128-bit GUID can be generated and split in 4 32-bit integers which would be used as sublevels of key_type (hierarchy having no specific meaning, but just being used to get longer IDs). 4 bits of this identifier would probably need to be set to a fixed value since they are interpreted as hardened/unhardened derivation, but we would still have enough bits to avoid collisions.
I have updated the draft to allow the key_index field to encode larger identifiers, spanning across several derivation levels. It is quite generic to allow any kind of identifier to be used. Additional EIPs can define specific use cases, remaining compatible to the EIP-1581 specs.
Thanks for drawing my attention here, @jpitts! Hadn’t seen this one yet.
A couple of my answers to the questions by @vbuterin that are not addressed in the linked EIP:
How would that work for multi-contract dapps?
Our current EIP assigns a unique domain string to whatever app it connects to, this should be the most secure string we can attribute to the loading site, so public key, site hash, or ideally ENS address is presented as our preferred initial solution.
This allows many keys to be assigned in many ways, and all that is needed to allow multiple domains to then seamlessly integrate is a delegation system for these app keys, which can/will be part of a later proposal.
Ideally from a UX point of view, it would still feel like the user makes one operation; the UX of dapps that requires users to sign three transactions in a row to do something honestly really sucks.
I totally agree. We are definitely building towards making the initial sign-in increasingly look like a coherent contract that sets terms that allow the app to accomplish the user’s goal with minimal subsequent approvals, while enforcing hard restrictions under the hood based on those terms.
I suggest back-burning all but the simplest privacy initiatives until we’ve solved our problems. Ethereum is already such disruptive technology. And private disruptive tech is even more dangerous. We want someone else to take the brunt of the privacy. I suggest we work on other issues (scaling, UX, DevX, economic efficiency, etc.) while letting Zcash et al. lead the privacy charge. We can look at what they did right/wrong and then play fast follower and not make as many social mistakes as we would if we moved first.
I suggest back-burning all but the simplest privacy initiatives until we’ve solved our problems. Ethereum is already such disruptive technology. And private disruptive tech is even more dangerous.
I can see where you’re coming from, though OTOH non-private disruptive tech is also dangerous (see: recent Facebook scandals etc etc). What we’re suggesting here isn’t full-scale ZEXE, it’s just the minimal simplest level of unlinking needed to ensure that all of a user’s activities, particularly non-financial ones, can’t be trivially publicly linked to each other.
We can travel these roads, but we should tread lightly. In the privacy game, let Zcash and Monero run out ahead. After seeing what false steps they make (and I’m confident there will be at least one), we will then be able to step much more artfully in those pro-privacy directions.
However, my advice is not to frame Ethereum as “privacy technology”, but as “transparency technology”. And then only afterwards start nudging toward privacy technology.
I don’t think we should lose focus on privacy. At least go for the low hanging fruit as @vbuterin said. Has anyone considered building a separate WASM with cryptographic technologies from the ground up? These could be delegated special nodes forming a layer 2 MPC style protocol. Thoughts?
Actually I think there’s more aspects that are very important to privacy than the on-chain considerations. One additional area that I find interesting and we’re working on with HOPR is network-level metadata privacy. A specific example is that you’re in my co-working space and connected to my wifi. Now you make an on-chain txs with mixers, change of address separate account for each dapp and everything that has been discussed in the thread above.
There are now at least two angles from which I can identify you:
As your wifi operator, I know that you are using Ethereum, I know that you just connected to some node (like Metamask / Infura) or that you’re using some wallet (like MyCrypto). With minimal additional meta data info (e.g. I know you’re into crypto kitties from your Twitter profile or I have some additional timing information or I know what gas price you commonly use) I should be able to guess fairly reliably which txs has been broadcasted by you.
Even without making you connect through my wifi, a global passive adversary (someone who smartly connects to Ethereum nodes in order to get a global overview of the topology) could probably find out which tx is known to which node at what time. That should allow for a triangulation of where the tx originated (which node knew it first) and from there it should be possible to identify or attack the sender (get their IP address etc).
Bottom line: Ethereum relies on broadcasting which (in contrast to mix nets) is not designed to be privacy-preserving and does not have as strong privacy guarantees. We need some bottom-layer privacy-preserving networking and that’s what we’re working on. Ideally to be implemented as a libp2p transport module at some point to reduce switching costs.
Yep! Those are definitely the two parts I am advocating. Though for the privacy reasons mentioned above you probably want to build a relayer market that could then work for all mixer designs.
One third part that seems really valuable is some standardized anon network over which to send transactions. This could be Tor, some kind of customized onion-routing network, or something else.
I’m working on a web browser which solve transport issue. Currently I’ve finished enhancing the SSL to use Ethereum blockchain as a Certificate Authority and ENS as primary DNS.
It allows to connect to nodes and even classic sites to work with it. It’s required to start decent transformation and make it seamless for users and business.
Browser has pluggable structure for network interfaces so it could be upgraded to use some onion-like solution. But I haven’t worked with onion yet. And it would be nice to hear what is the best implementation to educate on. And to decide is it reasonable to create own implementation.
The question I have now:
What encryption has it use?
How encryption keys are distributing over network?
Would it work with HTTP/3?
Another group of questions is a transport layer security protocol working over the onion. It could be SSL or Noise. Also I have an idea on timing alignment to reduce traffic analysis: different software generates different packets pattern and it could be traced as well. For example messengers generate a bunch of tiny packets with high but irregular frequency, while video streaming creates more solid pattern. It could be used to understand kind of victim activity.
Browser is required to cover all users’ needs in daily task. Users should have a tool to discover the decentralized web without creating unwanted artifacts in centralized.