fix typos

channel-operation.asciidoc

@@ -9,7 +9,7 @@ We are finally at the point to explain the communications protocol via Lightning
 The same protocol will be executed along a path of channels if the network of channels is being utilized to make a payment between two participants without requiring them to have a dedicated payment channel connecting them directly.
 
 Let us start with the payment channel with a capacity of 100 mBTC between Alice and Bob.
-at its current state Alice and Bob have agreed that 20 mBTC belong to Bob and 80 mBTC belong to Alice.
+At its current state Alice and Bob have agreed that 20 mBTC belong to Bob and 80 mBTC belong to Alice.
 As Alice bought a coffee flatrate for the week she has to pay 15 mBTC to Bob and wants to use this channel.
 Just creating a new pair of commitment transactions and signing them is not so easy as the old ones have to be invalidated by sharing the revocation secret.
 This process should be executed in a way that it is atomic meaning the nodes will either be able to negotiate a new state without giving the other side the chance to play tricks or it should fail.
@@ -37,7 +37,7 @@ As the name suggests the amount is depicted in millisatoshi even those cannot be
 Still Lightning nodes keep track of subsatoshi amounts to avoid rounding issues.
 As in the offline example Alice includes the `payment_hash` in the next data field.
 This was told to Alice by Bob in case she wants to just send money to him.
-If Alice was to send Money to Gloria the Payment hash would have been given to Alice by Gloria.
+If Alice was to send Money to Gloria the payment hash would have been given to Alice by Gloria.
 We discussed the potential of time lock or deadline of the contract.
 This is encoded in the `cltv_expiry`.
 cltv stands for OP_CHECKTIMELOCKVERIFY and is the OP_CODE that will be used in the HTLC output and serve as the deadline in which the contract is valid.