Title: EIP_1077_Executable_Signed_Message
Category: Web

Author: alexvandesande
Date: 2018-05-18T18:21:12.524Z

As part of the Executable Signed Message, I’ll be calling people that shown interest in this topic for these threads and want to debate specifics of the scheme…
I’ve updated the spec of ERC1077 based on feedback and conversations with the gnosis team. Right now, the best two references for executable signed messages are:


Status Identity Gas Relay which has the ability to pay back in tokens

Gnosis Safe Contract which has the ability to do delegateCall and create opcode, so a contract can be used to deploy a new contract.

I’ve added Gnosis Operation Type to the standard, so that it comprises both. A normal call is 0, so a contract that doesn’t want to support this option can simply leave it at 0.
I’ve also made a few modifications to make it EIP191 compatible, by request of Dan and Gnosis team and removed the nonce as timestamp thing, that was adding unnecessary complexity (feedback by @arachnid). I have replaced it by adding support for nonce 0 as a nonceless transaction which is more flexible for some cases but uses more memory.
Topics to discuss:

How do the multiple deployer parties communicate among each other, specially if you need multiple signatures before posting the message?
If there is a competition among the deployers and multiple send at the same time, one or more will have their gas burned and incur in a cost which will increase the price of the service for everyone. Is there a way to create a cooperation among them to prevent this?
How to create the initial contracts? There are some tricks that can be done to save gas cost, and there are some schemes where the user can already have an account address to send funds before deploying the contract, so you don’t need to deploy to inactive users
What are the gas costs overhead of this scheme and how can we reduce them?

Author: cooganb
Date: 2018-05-18T21:35:13.316Z

Hey all! I approached Alex about this project because we have a bunch of developers learning blockchain and we’re setting this up as a group project.
We’re going to start making a truffle box / npm package that can be used by smaller developers, first as a testnet POC to road-test and find the bumps along the way. Here’s what I’m imagining our first steps will be, open to any and all feedback:


Context-specific ether-less account, public-private keys created client-side — Built in React using Consensys LightWallet

Signs EIP-191 compliant transaction with newly-generated private key

Centralized server wraps up transaction in a relay transaction — (Probably absorbing the cost just for demo sake right now)
Centralized server uses factory pattern to deploy an erc-725 identity contract with relayed transaction from user to testnet

Author: alexvandesande
Date: 2018-05-21T17:30:42.393Z

EIP191 requires that messages be hash of these parameters:
keccak256(byte(0x19), byte(0), from, whatever);
The initial implementation (based on Status imp) asked the user to sign a string based on this:
keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken);
But upon looking at Gnosis I also added OperationType:
keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken, operationType);
In order to make it future proof, I suggest adding in the end of the hashes an extra parameter (maybe instead of operationType):
keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken, extra);
The purpose of which would be basically making it more future proof.
On solidity, multiple parameters on Keccak are the equivalent of doing concatenation and then hashing… so keccak256(requiredParam1, requiredParam2, extraParam1, extraParam2); is the same hash as keccak256(requiredParam1, requiredParam2, (extraParam1+extraParam2));
This allows anyone to add any amount of parameters at the end of the message, and still make it compatible with previous implementations.

Author: alexvandesande
Date: 2018-05-28T14:44:43.035Z

In light of the last message, I’ve updated the standard to allow more flexibility in multiple implementations:


github.com/ethereum/EIPs








increases backwards and forwards compatibility


master ← alexvandesande:patch-6



          opened 02:41PM - 28 May 18 UTC




            alexvandesande
          



+20
-6






When opening a pull request to submit a new EIP, please use the suggested templa…te: https://github.com/ethereum/EIPs/blob/master/eip-X.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your Github username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.






Now some fields are optional if your contract doesn’t care for them, but if you ignore some fields, you must add an extra hash at the end to make yours compatible with other future implementations. While this thread isn’t getting a lot of attention, I’ve been having conversations via email, skype etc (and keep referring people back to this to keep this alive)

Author: pet3rpan
Date: 2018-05-29T04:40:46.934Z

@alexvandesande Replying to your ERC1077, you talk about user pain points and developer pain points.
I would like to add that, we should always be focusing on achieving the best user experience at all costs. (I assume we are talking about consumer facing applications) User pain points will need to be solved first (or items that drive business goals). Only once that those are satisfied, the developer pain points in creating the best experience should then be addressed. (not saying we shouldn’t think about them but just highlighting the priorities). We should be optimising for the development of great user experiences not just optimising for code to be pushed.
Product trade offs between ux and dev resources are a matter of economics and should be considered aside all together.
Take care when considering the user pain points and the developer pain points.

Author: juniset
Date: 2018-05-29T10:27:24.138Z

Hey All! Julien from Argent here.
We’ve been working on a Wallet with ETH less accounts for the past 6 months and are very excited to see some of these ideas being standardised.
One possible area of improvement that is not addressed by the current version is the possibility for the ‘key’ to be a smart contract itself. The use case is that of e.g. a recovery where User A with WalletA would like to authorise User B with WalletB do to a recovery on its Wallet. In that scenario the signed message would be signed with a key (say keyB) authorised to sign on behalf of WalletB, and WalletA needs to reconcile the signature by keyB with WalletB.
One possible solution is to use the ‘extra’ field to pass the address on behalf of which the message was signed, or add an additional parameter to the call.

Author: pet3rpan
Date: 2018-05-29T11:25:10.390Z

@juniset So the private key would kinda be like beach ball where it is passed back and forth amongst the user dapps to sign transactions?

Author: pet3rpan
Date: 2018-05-29T12:19:17.011Z

Also @everyone here, what do you think about relying on emails for login / registration? Current systems depend on it for confirmation emails and account recovery. How can we transition people into using new mental models of dealing with signing things etc.

Author: alexvandesande
Date: 2018-05-29T13:05:38.244Z

pet3rpan:

We should be optimising for the development of great user experiences not just optimising for code to be pushed.


Could you be more specific? I generally agree with this sentiment, but most UX challenges are actually deeper than just skin deep and the purpose of this standard is to allow these challenges to be surmounted.



 juniset:

One possible area of improvement that is not addressed by the current version is the possibility for the ‘key’ to be a smart contract itself. The use case is that of e.g. a recovery where User A with WalletA would like to authorise User B with WalletB do to a recovery on its Wallet. In that scenario the signed message would be signed with a key (say keyB) authorised to sign on behalf of WalletB, and WalletA needs to reconcile the signature by keyB with WalletB.


Juni, you don’t need the key to be a smart contract for that. Both Gnosis and Status are doing social recovery keys, where you authorize X users to reset your wallet. The way to do that is that Wallet A, when doing a recovery process, can check if key B that signed the message, is authorized to do so by wallet B. No need to complicate things.



 pet3rpan:

So the private key would kinda be like beach ball where it is passed back and forth amongst the user dapps to sign transactions?


Yes, that’s the idea.



 pet3rpan:

what do you think about relying on emails for login / registration?


Emails are centralized services. I think one way in which one can use email is actually to add a “central recovery key” option, in which users from company A say they trust keys from company A to reset their keys. That interaction and recovery request can be done via email, and the company can confirm their identity by email.
Of course, as soon as users have enough devices on the system so that they are effectively multisig, they should switch recovery options.

Author: pet3rpan
Date: 2018-05-30T03:40:19.594Z

Another thought I had: How we design these systems and user experiences will change along with cheaper gas execution costs. While it may cost $5 in gas fees to claim an ens or execute a smart contract, it might cost fractions of a cent in the future. Along with this shift, people’s attitudes towards signing transactions might change.
Ether and gas might fade into the background just like internet data. Earlier on, internet data was way more expensive and you paid a monthly subscription for say 15gigabites of data. With expensive data and a low total bandwith, streaming a movie or playing a 2hr youtube video had be a careful consideration. This is the opposite today where we hardly care as much, we use data more liberally and don’t monitor data usages.
Just some food for thought

Author: alexvandesande
Date: 2018-05-30T13:49:18.555Z

How we design these systems and user experiences will change along with cheaper gas execution costs

Good point. We design a lot of things today trying to optmize for cheaper gas. The big drawback of this signed approach is that it might end up in more costly transactions (need to benchmark how much) but it might not matter in the long term

Author: cooganb
Date: 2018-05-30T15:49:53.360Z

Hey all! Students at Hatch worked on a very basic way to generate Ethereum addresses and keys without passwords, seed phrases, etc., store them locally and use them to sign messages. We’re hoping to build-out the Solidity side to take notes from Gnosis Identity Relay contract.
It’s a very simple implementation, but we’re hoping to continue working on it (after some great input from @alexvandesande yesterday!) and wrap it up as an npm package or truffle box. Please check out the repo link! Comment, PR, etc. etc.


github.com




GitHub - HatchCrypto/unilogin: Signup / Login Design Pattern with Minimal...
Signup / Login Design Pattern with Minimal Ethereum Front-End Schema






Please note: These are front-end developers who have learned blockchain concepts & practices over the past five weeks. This was done in a mini-sprint that lasted about a day and half culminating in Alex’s visit!

Author: cooganb
Date: 2018-08-07T11:54:51.278Z

I know this thread has been quiet, but I wanted to post another project here:
https://github.com/austintgriffith/bouncer-proxy
Austin has built a nice working demonstration of transaction forwarding (a concept I’ve found tricky to explain to students) with a nice UI (which we all love!). I’m going to try and work with him on getting it to EIP-1077 standards, notably getting ERC-191 signed message parameters into the workflow.

Author: jpitts
Date: 2018-09-02T22:55:41.852Z

FYI, I created a link page of projects relating to meta transactions: https://github.com/jpitts/eth-community-discussions/blob/master/meta-transactions.md

Author: cooganb
Date: 2018-09-05T12:15:49.168Z

This is amazing! Thank you.

Author: cooganb
Date: 2018-10-23T13:32:31.456Z

Gave a talk yesterday for 8btc and hyped meta-transactions & universal login. It was written up here (in Mandarin), linked to repos at the bottom!
https://m.8btc.com/article/296078