aboutsummaryrefslogtreecommitdiffstats
path: root/docs/common-patterns.rst
diff options
context:
space:
mode:
authorchriseth <chris@ethereum.org>2017-05-02 20:12:25 +0800
committerchriseth <chris@ethereum.org>2017-05-03 18:03:02 +0800
commit7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4 (patch)
treebb7a425dcbf890588eb6caea6fca5df610555e3c /docs/common-patterns.rst
parent2b4b86aa7f72d8f7c2c4e250953d8f9018f4fd53 (diff)
downloaddexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar.gz
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar.bz2
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar.lz
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar.xz
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.tar.zst
dexon-solidity-7e838fd4a875e6a1f7e7ec60d7b4c5502e22dde4.zip
Cleanup to make the docs more consistent.
Diffstat (limited to 'docs/common-patterns.rst')
-rw-r--r--docs/common-patterns.rst29
1 files changed, 13 insertions, 16 deletions
diff --git a/docs/common-patterns.rst b/docs/common-patterns.rst
index 37973c62..acef13b7 100644
--- a/docs/common-patterns.rst
+++ b/docs/common-patterns.rst
@@ -52,17 +52,12 @@ become the new richest.
}
}
- function withdraw() returns (bool) {
+ function withdraw() {
uint amount = pendingWithdrawals[msg.sender];
// Remember to zero the pending refund before
// sending to prevent re-entrancy attacks
pendingWithdrawals[msg.sender] = 0;
- if (msg.sender.send(amount)) {
- return true;
- } else {
- pendingWithdrawals[msg.sender] = amount;
- return false;
- }
+ msg.sender.transfer(amount);
}
}
@@ -83,9 +78,7 @@ This is as opposed to the more intuitive sending pattern:
function becomeRichest() payable returns (bool) {
if (msg.value > mostSent) {
- // Check if call succeeds to prevent an attacker
- // from trapping the previous person's funds in
- // this contract through a callstack attack
+ // This line can cause problems (explained below).
richest.transfer(msg.value);
richest = msg.sender;
mostSent = msg.value;
@@ -98,12 +91,16 @@ This is as opposed to the more intuitive sending pattern:
Notice that, in this example, an attacker could trap the
contract into an unusable state by causing ``richest`` to be
-the address of a contract that has a fallback function
-which consumes more than the 2300 gas stipend. That way,
-whenever ``send`` is called to deliver funds to the
-"poisoned" contract, it will cause execution to always fail
-because there will not be enough gas to finish the execution
-of the fallback function.
+the address of a contract that has a fallback function
+which fails (e.g. by using ``revert()`` or by just
+conssuming more than the 2300 gas stipend). That way,
+whenever ``transfer`` is called to deliver funds to the
+"poisoned" contract, it will fail and thus also ``becomeRichest``
+will fail, with the contract being stuck forever.
+
+In contrast, if you use the "withdraw" pattern from the first example,
+the attacker can only cause his or her own withdraw to fail and not the
+rest of the contract's workings.
.. index:: access;restricting