execute should not be payable

Question

execute should not be payable

gbalabasquer opened this issue 5 years ago · comments

Gonzalo Balabasquer commented 5 years ago

I don't think the payable modifier should be in a function that can be called by anyone.
It's like leaving that door open to the public to add a custom value to the proposal elected. I know in most of cases will be just a waste of ETH value, but there might be actions tight to what is received in msg.value.
I think there shouldn't be a value at all or the value should be defined and saved at the moment the execution is scheduled by the owner. So basically the msg.value is part of the execution scheduled.

dxo · Answer 1 · Mon Jan 21 2019 22:26:05 GMT+0800 (China Standard Time)

ohhhhh, good point 🙏 ✨

I'm kinda undecided on what's best:

Never send ETH (remove payable from execute)
Make schedule payable and store the amount of ETH to be forwarded when execute is called.

AFAICT tradeoffs are complexity vs generality, and since this is a dappsys component I'm leaning towards making schedule payable, but interested to hear other opinions (cc @apmilen @rainbreak).

Tom Smith · Answer 2 · Thu Jan 31 2019 22:20:52 GMT+0800 (China Standard Time)

@xwvvvvwx - pls can you move this issue to the PM repo :)

dxo · Answer 3 · Thu Feb 28 2019 03:42:10 GMT+0800 (China Standard Time)

For now removed the payable modifier in 4e4077427b3aa9fea7c00f33aca2fe5253f35acc.

May decide to add it again to schedule in the future.

Nikolai Mushegian · Answer 4 · Sat Mar 09 2019 13:22:37 GMT+0800 (China Standard Time)

IMO it should draw from both the execute function, and the scheduled call, and possibly should have arguments acting as checks on one or both

I would guess removing this right now kills a full 50% of use cases!!

Nikolai Mushegian · Answer 5 · Sat Mar 09 2019 13:22:59 GMT+0800 (China Standard Time)

open for 'thinking'

dxo · Answer 6 · Tue Mar 12 2019 21:09:53 GMT+0800 (China Standard Time)

IMO it should draw from both the execute function, and the scheduled call, and possibly should have arguments acting as checks on one or both

Why both? What use case does this serve that only taking a value from schedule doesn't cover?

I would guess removing this right now kills a full 50% of use cases!!

Which use cases?

Nikolai Mushegian · Answer 7 · Sun Mar 17 2019 21:32:54 GMT+0800 (China Standard Time)

Wouldn't it always be preferable to pay w/ execute instead of schedule? The only reason the scheduler might prefer to pay is to ensure the funds are there, but it remains 100% under their control since they're the ones that can drop the call. Why wouldn't the caller want to retain the option to pay last moment?

An example application might be WETH. I don't have a contrived example of why someone might want to delay a pause to WETH, but it's a huge smell that you can't.

Gonzalo Balabasquer · Answer 8 · Mon Mar 18 2019 21:14:43 GMT+0800 (China Standard Time)

I guess it depends on how you see the msg.value regarding the proposal. Can it do different stuff depending on the value you pass or will it be just a unique value accepted?
I find a bit hard to get a real example of governance for the MCD system that requires sending ETH.

livnev · Answer 9 · Mon Mar 18 2019 21:43:33 GMT+0800 (China Standard Time)

I don't think the payable modifier should be in a function that can be called by anyone.
It's like leaving that door open to the public to add a custom value to the proposal elected. I know in most of cases will be just a waste of ETH value, but there might be actions tight to what is received in msg.value.
I think there shouldn't be a value at all or the value should be defined and saved at the moment the execution is scheduled by the owner. So basically the msg.value is part of the execution scheduled.

I agree with this perspective: the value of the message call is just another parameter: to not have it locked down at plan-time and leave it as a free variable for the public to choose feels weird. Following the same reasoning, I'd even entertain the notion that plan should take as another parameter gas and we should require(msg.gas == gas); (n.b. the caller of exec would have to precalculate the remaining gas when the check is reached, which is only slightly annoying).

Nikolai Mushegian · Answer 10 · Mon Mar 18 2019 22:01:14 GMT+0800 (China Standard Time)

This makes sense actually. If anything, a execute-time payment should be attempting to pull ETH from the scheduler's address, which you can't do with native ETH.

dxo · Answer 11 · Tue Mar 19 2019 23:24:44 GMT+0800 (China Standard Time)

I find a bit hard to get a real example of governance for the MCD system that requires sending ETH.

@gbalabasquer I agree with this, but the pause is a general purpose dappsys component, so we I think should be striving to support use cases beyond Maker governance only.

An example application might be WETH. I don't have a contrived example of why someone might want to delay a pause to WETH, but it's a huge smell that you can't.

@nmushegian Yeah this is a totally valid point. I'll submit a PR that lets users specify the value as part of plan in the next day or two.

dxo · Answer 12 · Tue Mar 19 2019 23:25:30 GMT+0800 (China Standard Time)

I'd even entertain the notion that plan should take as another parameter gas and we should require(msg.gas == gas);

@livnev what do we gain from this? If an attacker tries to exec with insufficient gas, won't the transaction just revert, leaving it available for someone else to come along and exec?

I suppose it's feasible that the target of the delegatecall could have some conditional logic depending on the value of msg.gas?

livnev · Answer 13 · Wed Mar 20 2019 01:00:26 GMT+0800 (China Standard Time)

I'd even entertain the notion that plan should take as another parameter gas and we should require(msg.gas == gas);

@livnev what do we gain from this? If an attacker tries to exec with insufficient gas, won't the transaction just revert, leaving it available for someone else to come along and exec?

I suppose it's feasible that the target of the delegatecall could have some conditional logic depending on the value of msg.gas?

Exactly what you said: gas can take on more than the two values "enough" and "not enough". To be more specific, I was imagining a scenarios like:

(a) a silly user plans some code that has gas-dependent behaviour without realising it, and then some member of the general public comes in and triggers unexpected behaviour on exec. Unless the user formally verified the code or at least tested its execution with every possible value of gas, they would have no way of knowing that the thing they plan doesn't have gas-dependent behaviour. They would only know what to expect if exec is called with the amount of gas that they tested. But knowing this would have been good enough if they hadn't used ds-pause.

(b) a popular language/compiler has a bug that results in unexpected gas-dependent behaviour, some evil member of the public exploits this on exec, resulting in (a). The user would not have been affected by this bug had they not used ds-pause which allowed their code to be called by arbitrary people.

dxo · Answer 14 · Thu Mar 28 2019 03:53:26 GMT+0800 (China Standard Time)

PR for adding value to interface here: #17

Nikolai Mushegian · Answer 15 · Sat Mar 30 2019 00:46:30 GMT+0800 (China Standard Time)

Maybe we should sync before this gets too all over the place #15 (comment)

livnev · Answer 16 · Sun Apr 28 2019 17:55:06 GMT+0800 (China Standard Time)

Re the specifying exact gas issue: looks like Gnosis safe recently noticed this issue as well.

dxo · Answer 17 · Tue May 28 2019 23:42:13 GMT+0800 (China Standard Time)

I spent a while playing around with specifying the exact gas, but everything I tried was too messy to be worth it. Implementation here for future ref: 080fc4f

A clean implementation probably requires new opcodes (see EIP-1930).

exec is not payable and the caller has control over the gas passed to the plan. Closing.