cerc-io/solidity
10
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #13580 from R-Y-M-R/fix-docs-phrasing

Browse Source 
Fix: improve docs typos & phrasing
This commit is contained in:
Kamil Śliwak 2022-09-29 00:10:58 +02:00 committed by GitHub
commit 1c77d30cea
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/examples/blind-auction.rst
View File

@ -177,7 +177,7 @@ During the **bidding period**, a bidder does not actually send their bid, but
only a hashed version of it. Since it is currently considered practically only a hashed version of it. Since it is currently considered practically
impossible to find two (sufficiently long) values whose hash values are equal, impossible to find two (sufficiently long) values whose hash values are equal,
the bidder commits to the bid by that. After the end of the bidding period, the bidder commits to the bid by that. After the end of the bidding period,
the bidders have to reveal their bids: They send their values unencrypted and the bidders have to reveal their bids: They send their values unencrypted, and
the contract checks that the hash value is the same as the one provided during the contract checks that the hash value is the same as the one provided during
the bidding period. the bidding period.
@ -189,7 +189,7 @@ transfers cannot be blinded in Ethereum, anyone can see the value.
The following contract solves this problem by accepting any value that is The following contract solves this problem by accepting any value that is
larger than the highest bid. Since this can of course only be checked during larger than the highest bid. Since this can of course only be checked during
the reveal phase, some bids might be **invalid**, and this is on purpose (it the reveal phase, some bids might be **invalid**, and this is on purpose (it
even provides an explicit flag to place invalid bids with high value even provides an explicit flag to place invalid bids with high-value
transfers): Bidders can confuse competition by placing several high or low transfers): Bidders can confuse competition by placing several high or low
invalid bids. invalid bids.

8
docs/examples/micropayment.rst
View File

@ -2,7 +2,7 @@
Micropayment Channel Micropayment Channel
******************** ********************
In this section we will learn how to build an example implementation In this section, we will learn how to build an example implementation
of a payment channel. It uses cryptographic signatures to make of a payment channel. It uses cryptographic signatures to make
repeated transfers of Ether between the same parties secure, instantaneous, and repeated transfers of Ether between the same parties secure, instantaneous, and
without transaction fees. For the example, we need to understand how to without transaction fees. For the example, we need to understand how to
@ -17,14 +17,14 @@ Alice is the sender and Bob is the recipient.
Alice only needs to send cryptographically signed messages off-chain Alice only needs to send cryptographically signed messages off-chain
(e.g. via email) to Bob and it is similar to writing checks. (e.g. via email) to Bob and it is similar to writing checks.
Alice and Bob use signatures to authorise transactions, which is possible with smart contracts on Ethereum. Alice and Bob use signatures to authorize transactions, which is possible with smart contracts on Ethereum.
Alice will build a simple smart contract that lets her transmit Ether, but instead of calling a function herself Alice will build a simple smart contract that lets her transmit Ether, but instead of calling a function herself
to initiate a payment, she will let Bob do that, and therefore pay the transaction fee. to initiate a payment, she will let Bob do that, and therefore pay the transaction fee.
The contract will work as follows: The contract will work as follows:
1. Alice deploys the ``ReceiverPays`` contract, attaching enough Ether to cover the payments that will be made. 1. Alice deploys the ``ReceiverPays`` contract, attaching enough Ether to cover the payments that will be made.
2. Alice authorises a payment by signing a message with her private key. 2. Alice authorizes a payment by signing a message with her private key.
3. Alice sends the cryptographically signed message to Bob. The message does not need to be kept secret 3. Alice sends the cryptographically signed message to Bob. The message does not need to be kept secret
(explained later), and the mechanism for sending it does not matter. (explained later), and the mechanism for sending it does not matter.
4. Bob claims his payment by presenting the signed message to the smart contract, it verifies the 4. Bob claims his payment by presenting the signed message to the smart contract, it verifies the
@ -259,7 +259,7 @@ Messages are cryptographically signed by the sender and then transmitted directl
Each message includes the following information: Each message includes the following information:
* The smart contract's address, used to prevent cross-contract replay attacks. * The smart contract's address, used to prevent cross-contract replay attacks.
* The total amount of Ether that is owed the recipient so far. * The total amount of Ether that is owed to the recipient so far.
A payment channel is closed just once, at the end of a series of transfers. A payment channel is closed just once, at the end of a series of transfers.
Because of this, only one of the messages sent is redeemed. This is why Because of this, only one of the messages sent is redeemed. This is why