mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Changed references to money
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user