diff --git a/docs/common-patterns.rst b/docs/common-patterns.rst index a76f61c18..cbc219b53 100644 --- a/docs/common-patterns.rst +++ b/docs/common-patterns.rst @@ -18,7 +18,7 @@ introduces a potential security risk. You may read more about this on the :ref:`security_considerations` page. The following is an example of the withdrawal pattern in practice in -a contract where the goal is to send the most money to the +a contract where the goal is to send the most of some compensation, e.g. Ether, to the contract in order to become the "richest", inspired by `King of the Ether `_. diff --git a/docs/control-structures.rst b/docs/control-structures.rst index 88fb53a56..f7a33db7e 100644 --- a/docs/control-structures.rst +++ b/docs/control-structures.rst @@ -685,7 +685,7 @@ and ``assert`` for internal error checking. addr.transfer(msg.value / 2); // Since transfer throws an exception on failure and // cannot call back here, there should be no way for us to - // still have half of the money. + // still have half of the Ether. assert(address(this).balance == balanceBeforeTransfer - msg.value / 2); return address(this).balance; } diff --git a/docs/examples/blind-auction.rst b/docs/examples/blind-auction.rst index 3c7b3dcc6..47e19033f 100644 --- a/docs/examples/blind-auction.rst +++ b/docs/examples/blind-auction.rst @@ -16,11 +16,11 @@ Simple Open Auction =================== The general idea of the following simple auction contract is that everyone can -send their bids during a bidding period. The bids already include sending money -/ Ether in order to bind the bidders to their bid. If the highest bid is -raised, the previous highest bidder gets their money back. After the end of +send their bids during a bidding period. The bids already include sending some compensation, +e.g. Ether, in order to bind the bidders to their bid. If the highest bid is +raised, the previous highest bidder gets their Ether back. After the end of the bidding period, the contract has to be called manually for the beneficiary -to receive their money - contracts cannot activate themselves. +to receive their Ether - contracts cannot activate themselves. .. code-block:: solidity @@ -92,19 +92,19 @@ to receive their money - contracts cannot activate themselves. revert AuctionAlreadyEnded(); // If the bid is not higher, send the - // money back (the revert statement + // Ether back (the revert statement // will revert all changes in this // function execution including - // it having received the money). + // it having received the Ether). if (msg.value <= highestBid) revert BidNotHighEnough(highestBid); if (highestBid != 0) { - // Sending back the money by simply using + // Sending back the Ether by simply using // highestBidder.send(highestBid) is a security risk // because it could execute an untrusted contract. // It is always safer to let the recipients - // withdraw their money themselves. + // withdraw their Ether themselves. pendingReturns[highestBidder] += highestBid; } highestBidder = msg.sender; @@ -182,7 +182,7 @@ the contract checks that the hash value is the same as the one provided during the bidding period. Another challenge is how to make the auction **binding and blind** at the same -time: The only way to prevent the bidder from just not sending the money after +time: The only way to prevent the bidder from just not sending the Ether after they won the auction is to make them send it together with the bid. Since value transfers cannot be blinded in Ethereum, anyone can see the value. diff --git a/docs/examples/safe-remote.rst b/docs/examples/safe-remote.rst index e42b017fb..a2651af23 100644 --- a/docs/examples/safe-remote.rst +++ b/docs/examples/safe-remote.rst @@ -6,18 +6,18 @@ Safe Remote Purchase Purchasing goods remotely currently requires multiple parties that need to trust each other. The simplest configuration involves a seller and a buyer. The buyer would like to receive -an item from the seller and the seller would like to get money (or an equivalent) +an item from the seller and the seller would like to get some compensation, e.g. Ether, in return. The problematic part is the shipment here: There is no way to determine for sure that the item arrived at the buyer. There are multiple ways to solve this problem, but all fall short in one or the other way. In the following example, both parties have to put twice the value of the item into the -contract as escrow. As soon as this happened, the money will stay locked inside +contract as escrow. As soon as this happened, the Ether will stay locked inside the contract until the buyer confirms that they received the item. After that, the buyer is returned the value (half of their deposit) and the seller gets three times the value (their deposit plus the value). The idea behind this is that both parties have an incentive to resolve the situation or otherwise -their money is locked forever. +their Ether is locked forever. This contract of course does not solve the problem, but gives an overview of how you can use state machine-like constructs inside a contract. diff --git a/docs/introduction-to-smart-contracts.rst b/docs/introduction-to-smart-contracts.rst index 2edf22d47..5595a2fed 100644 --- a/docs/introduction-to-smart-contracts.rst +++ b/docs/introduction-to-smart-contracts.rst @@ -282,7 +282,7 @@ the source account is also not modified. Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that -only the person holding the keys to the account can transfer money from it. +only the person holding the keys to the account can transfer some compensation, e.g. Ether, from it. .. index:: ! block diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst index 95c0edb99..92d601043 100644 --- a/docs/security-considerations.rst +++ b/docs/security-considerations.rst @@ -447,7 +447,7 @@ so help through off-chain computations might be needed there. If the self-check fails, the contract automatically switches into some kind of "failsafe" mode, which, for example, disables most of the features, hands over control to a fixed and trusted third party -or just converts the contract into a simple "give me back my money" contract. +or just converts the contract into a simple "give me back my Ether" contract. Ask for Peer Review =================== diff --git a/docs/types/value-types.rst b/docs/types/value-types.rst index 60a11d6c3..872f54b0e 100644 --- a/docs/types/value-types.rst +++ b/docs/types/value-types.rst @@ -263,7 +263,7 @@ reverts on failure. There are some dangers in using ``send``: The transfer fails if the call stack depth is at 1024 (this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order to make safe Ether transfers, always check the return value of ``send``, use ``transfer`` or even better: - use a pattern where the recipient withdraws the money. + use a pattern where the recipient withdraws the Ether. * ``call``, ``delegatecall`` and ``staticcall`` diff --git a/docs/units-and-global-variables.rst b/docs/units-and-global-variables.rst index e890f9042..a9b29d6ba 100644 --- a/docs/units-and-global-variables.rst +++ b/docs/units-and-global-variables.rst @@ -107,7 +107,7 @@ Block and Transaction Properties Both the timestamp and the block hash can be influenced by miners to some degree. Bad actors in the mining community can for example run a casino payout function on a chosen hash - and just retry a different hash if they did not receive any money. + and just retry a different hash if they did not receive any compensation, e.g. Ether. The current block timestamp must be strictly larger than the timestamp of the last block, but the only guarantee is that it will be somewhere between the timestamps of two @@ -282,7 +282,7 @@ For more information, see the section on :ref:`address`. There are some dangers in using ``send``: The transfer fails if the call stack depth is at 1024 (this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order to make safe Ether transfers, always check the return value of ``send``, use ``transfer`` or even better: - Use a pattern where the recipient withdraws the money. + Use a pattern where the recipient withdraws the Ether. .. warning:: Due to the fact that the EVM considers a call to a non-existing contract to always succeed,