cerc-io/solidity
16
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
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 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 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
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
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
invalid bids.

8
docs/examples/micropayment.rst
View File

@ -2,7 +2,7 @@
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
repeated transfers of Ether between the same parties secure, instantaneous, and
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
(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
to initiate a payment, she will let Bob do that, and therefore pay the transaction fee.
The contract will work as follows:
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
(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
@ -259,7 +259,7 @@ Messages are cryptographically signed by the sender and then transmitted directl
Each message includes the following information:
* 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.
Because of this, only one of the messages sent is redeemed. This is why