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 #10928 from RostyslavDzhohola/develop

Browse Source 
Changing grammar for clarification
This commit is contained in:
chriseth 2021-02-09 19:41:03 +01:00 committed by GitHub
commit f8d74bc3e1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/examples/micropayment.rst
View File

@ -24,10 +24,10 @@ to initiate a payment, she will let Bob do that, and therefore pay the transacti
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 their private key. 2. Alice authorises 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 their 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
authenticity of the message and then releases the funds. authenticity of the message and then releases the funds.
Creating the signature Creating the signature
@ -222,7 +222,7 @@ unidirectional payment channel between two parties (Alice and Bob). It involves
1. Alice funds a smart contract with Ether. This "opens" the payment channel. 1. Alice funds a smart contract with Ether. This "opens" the payment channel.
2. Alice signs messages that specify how much of that Ether is owed to the recipient. This step is repeated for each payment. 2. Alice signs messages that specify how much of that Ether is owed to the recipient. This step is repeated for each payment.
3. Bob "closes" the payment channel, withdrawing their portion of the Ether and sending the remainder back to the sender. 3. Bob "closes" the payment channel, withdrawing his portion of the Ether and sending the remainder back to the sender.
.. note:: .. note::
Only steps 1 and 3 require Ethereum transactions, step 2 means that the sender Only steps 1 and 3 require Ethereum transactions, step 2 means that the sender
@ -230,9 +230,9 @@ unidirectional payment channel between two parties (Alice and Bob). It involves
methods (e.g. email). This means only two transactions are required to support methods (e.g. email). This means only two transactions are required to support
any number of transfers. any number of transfers.
Bob is guaranteed to receive their funds because the smart contract escrows the Bob is guaranteed to receive his funds because the smart contract escrows the
Ether and honours a valid signed message. The smart contract also enforces a Ether and honours a valid signed message. The smart contract also enforces a
timeout, so Alice is guaranteed to eventually recover their funds even if the timeout, so Alice is guaranteed to eventually recover her funds even if the
recipient refuses to close the channel. It is up to the participants in a payment recipient refuses to close the channel. It is up to the participants in a payment
channel to decide how long to keep it open. For a short-lived transaction, channel to decide how long to keep it open. For a short-lived transaction,
such as paying an internet café for each minute of network access, the payment such as paying an internet café for each minute of network access, the payment
@ -300,7 +300,7 @@ Here is the modified JavaScript code to cryptographically sign a message from th
Closing the Payment Channel Closing the Payment Channel
--------------------------- ---------------------------
When Bob is ready to receive their funds, it is time to When Bob is ready to receive his funds, it is time to
close the payment channel by calling a ``close`` function on the smart contract. close the payment channel by calling a ``close`` function on the smart contract.
Closing the channel pays the recipient the Ether they are owed and Closing the channel pays the recipient the Ether they are owed and
destroys the contract, sending any remaining Ether back to Alice. To destroys the contract, sending any remaining Ether back to Alice. To
@ -325,9 +325,9 @@ Channel Expiration
------------------- -------------------
Bob can close the payment channel at any time, but if they fail to do so, Bob can close the payment channel at any time, but if they fail to do so,
Alice needs a way to recover their escrowed funds. An *expiration* time was set Alice needs a way to recover her escrowed funds. An *expiration* time was set
at the time of contract deployment. Once that time is reached, Alice can call at the time of contract deployment. Once that time is reached, Alice can call
``claimTimeout`` to recover their funds. You can see the ``claimTimeout`` function in the full contract. ``claimTimeout`` to recover her funds. You can see the ``claimTimeout`` function in the full contract.
After this function is called, Bob can no longer receive any Ether, After this function is called, Bob can no longer receive any Ether,
so it is important that Bob closes the channel before the expiration is reached. so it is important that Bob closes the channel before the expiration is reached.