Metamask-extension: RFC: Make Tx confirmation view editable

[danfinlay]

I think there may be a case to be made for making the TX confirmation view editable by the user before approving it. Opening several possible items here for comment.

• [ ] User should be able to change value transmitted before sending.
• [ ] User should be able to change sender before sending.
• [ ] User should be able to even change recipient before sending?
• [ ] User should be able to view & edit data field before sending
• [ ] User should be able to customize gas limit.
• [ ] User should be able to adjust gas price.
• [ ] Allow the user to specify amount to send in their preferred currency (automatically converted).

If this becomes too similar to the send view, maybe this is evidence that they are the same views?

Maybe there should be a revise button on the tx confirmation that moves to the send view, to allow editing.

[egalano]

I think adjusting the gas price and gas limit makes sense for adjusting priority of the transaction. I dont think editing the recipient or eth value is a good idea because it is a way of introducing user error into the flow. A site which has integrated with metamask is populating those fields so the user doesnt have to worry about it.

[ramos-j]

The dapp being used knows what the data field of a TX should contain, but usually not the users themselves. So if a user wants to manually configure gas price and gas limit of a TX, forcing her to use the Send view is not a good solution. It makes sense to allow for this flexibility on the TX Confirmation view.

[danfinlay]

That all sounds reasonable. Adding gas controls at least could make a lot of sense here.

• Dan

On Nov 18, 2016, at 6:24 PM, Jaime Ramos [email protected] wrote:

The dapp being used knows what the data field of a TX should contain, but usually not the users themselves. So if a user wants to manually configure gas price and gas limit of a TX, forcing her to use the Send view is not a good solution. It makes sense to allow for this flexibility on the TX Confirmation view.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[danfinlay]

We need some design for adding gas controls to this view.

• Adjusting gas price (priority/speed to reaching the blockchain).
• Adjusting gas limit (maximum tx fee).

Any designers want to take a pass at this? @VladTod?

[VladTod]

I thought about it a bit, and have a solution for it, i think it would be nice if we could have a slider. Right side with Slowe and left with Faster. Than the slider will have a bar under that is the gas price. Will design it the following days and post it.

[danfinlay]

Sounds good, but I usually think of slower as left and faster as right. That's also how Mist does their gas slider:

[VladTod]

Yeah, thats what i thought too :), just not what i wrote :))
One more thing, do we need the gas limit? i'm thinking since we have a select price, than having a gas limit in irrelevant. Since the price should be the gas max limit

[danfinlay]

In Ethereum, gas limit and gas price are two different things:

Gas price is how much you're willing to pay per operation relative to other transactions, and this fee is paid to miners, and so the higher it is, the faster they work to include your tx in a block.

Gas limit is the transaction's absolute max cost. If a transaction finds itself in an infinite loop, this is cost in ether when the transaction will end with an Out of Gas error, undoing anything the transaction did.

One of the reasons for this feature request is because there have been gas mis-estimations happening, and so users want to be able to raise their gas limits manually.

Meanwhile, it is also nice to be able to customize gas price for urgent transactions.

[VladTod]

ohh, ok. Thats something i didn't know :) Thanks for the lesson!
i always thought that the network doesn't use all the gas price you select. But instead it keeps some in case the transaction has to loop back, and only after that the limit is reached and you get out of gas error.

[danfinlay]

That's correct, for most successful transactions, you don't use all your gas, but you still pay the gas price per gas for each operation. Each operation has its own gas price.

You only pay the gas limit if you use up every last gas, or run out of gas.

[kumavis]

I think that gas-cost-per-op chart does not reflect the recent hard fork that adjusted these prices - but you get the idea

[VladTod]

Hello :)
Here is the design for changing gass price and transaction fee. I used my old designs, so there are a few things different., but the important parts are there :)
Let me know what you think.

[danfinlay]

Looks great, Vlad, thanks!

• Dan

On Nov 24, 2016, at 1:48 AM, VladTod [e-mail] wrote:

Hello :)
Here is the design for changing gass price and transaction fee. I used my old designs, so there are a few things different., but the important parts are there :)
Let me know what you think.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[kumavis]

This mostly looks good but more accurate would be:

• Amount (editable, input, unit: eth)
• Gas Limit (editable, input, unit: gas)
• Gas Price (editable, slider, unit: eth)
• Data Included (non-editable, unit: bytes)
• Max Tx Fee (non-editable, unit: eth)
• Max Total (non-editable, unit: eth + preferred_currency)

[VladTod]

Hello @kumavis, what i've read above lead me to believe that we are only letting people edit gas limit and gas price. So not allow people to edit the amount, has this changed?

[VladTod]

also isn't max tx fee the sam thing as gas limit? as Dan also stated above.

[kumavis]

@VladTod

So not allow people to edit the amount, has this changed?

yes, amount should be an editable field

also isn't max tx fee the sam thing as gas limit?

maxTxFee = gasPrice * gasLimit

maxTotal = amount + maxTxFee

[danfinlay]

Isn't maxTxFee the same as what he's listed as Max Total in the design?

[kumavis]

@flyswatter yes that was a mistake, i corrected it

[mikeshultz]

Just to throw in my 2 wei, I came across a use case where a dapp I'm building would want the user to adjust the value as they see fit. For instance, making a general deposit into a contract.

I have not yet checked how other browsers deal with this.

Perhaps some logic can be built in?

• If the dapp specifies a value, the MM dialog value is locked in place.
• If value is not provided, allow an editable field