From 9a5a4dfc6c1c3e16d63c2de79ccbb6ab78ef32af Mon Sep 17 00:00:00 2001 From: Harikrishnan Mulackal Date: Mon, 8 Feb 2021 14:19:13 +0100 Subject: [PATCH] Added a note about 63/64 rule Co-authored-by: Alex Beregszaszi --- docs/security-considerations.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst index 9cb1e6ea9..63a30a3a1 100644 --- a/docs/security-considerations.rst +++ b/docs/security-considerations.rst @@ -181,14 +181,13 @@ Sending and Receiving Ether contract. Again, the best practice here is to use a :ref:`"withdraw" pattern instead of a "send" pattern `. -Call stack Depth +Call Stack Depth ================ External function calls can fail any time because they exceed the maximum call stack of 1024. In such situations, Solidity throws an exception. Malicious actors might be able to force the call stack to a high value -before they interact with your contract, by controlling the number of calls -and local function variables on the stack. +before they interact with your contract. Note that, since [Tangerine Whistle](https://eips.ethereum.org/EIPS/eip-608) hardfork, the [63/64 rule](https://eips.ethereum.org/EIPS/eip-150) makes call stack depth attack impractical. Also note that the call stack and the expression stack are unrelated, even though both have a size limit of 1024 stack slots. Note that ``.send()`` does **not** throw an exception if the call stack is depleted but rather returns ``false`` in that case. The low-level functions