cerc-io/solidity
15
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

Update spelling and phrasing.

Browse Source
This commit is contained in:
Riley 2022-09-28 06:38:05 -04:00 committed by GitHub
parent 71308ce5ee
commit 269a0463e4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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