'noreentrancy' flag

[mezrin]

There are really many attacks that use reentrancy. It would be amazing to have a modifier for functions noreentrancy. Just like constant

If function marked with this flag and called twice in one transaction - exception was thrown

It is even better to break backwards compatibility and make this flag default for all public functions. I.e.:

• by default public functions are not allow reentrancy
• a public function can be marked with 'reentrant'

[federicobond]

Keep in mind that reentrancy is different from calling a function twice. There is usually nothing wrong with the latter.

Also, should the reentrancy guard lock the whole contract or just that particular function? It may be safer (and cheaper) to do the first, to better protect contract invariants.

[roadriverrail]

I think this is a clever idea, almost to the point if wondering if the default should be locking reentrancy.

…

On Fri, Jul 21, 2017, 11:25 Federico Bond ***@***.***> wrote: Keep in mind that reentrancy is different from calling a function twice. There is usually nothing wrong with the latter. Also, should the reentrancy guard lock the whole contract or just that particular function? It may be safer (and cheaper) to do the first, to better protect contract invariants. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2619 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlhYIhDkvQcxOU5E0EuZ1KaZUpGA4zBks5sQMMEgaJpZM4OfiPx> .

[mezrin]

Keep in mind that reentrancy is different from calling a function twice. There is usually nothing wrong with the latter.

I think people should start to write better contracts. And implement business-logic in internal functions. In this case, we can do smth like this:
The public function of a contract called -> contract does smth, make a call to external contract / transfer ETH -> calls to public functions of this contract become prohibited, even if they performed from inside the contract as an internal call.

It should be easier to implement and it is quite straightforward security model.

Also, should the reentrancy guard lock the whole contract or just that particular function? It may be safer (and cheaper) to do the first, to better protect contract invariants.

I think some use-cases require reentrancy and we need to have function-level modifiers that allow this. In this case, this is up to the developer to implement needed security measures

[axic]

This has been discussed twice in #656 and #662, things may have changed since, but it is perhaps worth reading those two threads.

[EricR]

I want to point out that this issue is also being addressed in EIP 214, which adds a new opcode aptly named STATICCALL.

[chriseth]

I don't think it is beneficial to the discussion to keep this issue open. Please discuss on the other two issues and be advised that "noreentrancy" does not have to be a language feature.