Merge pull request #764 from rating89us/patch-21

ch12: transaction -> transactions

ch12.asciidoc

@@ -146,7 +146,7 @@ image::images/mbc2_1203.png["Emma's payment channel with Fabian, showing the com
 
 Both of these problems can be solved with timelocks—let's look at how we could use transaction-level timelocks (+nLocktime+).
 
-Emma cannot risk funding a 2-of-2 multisig unless she has a guaranteed refund. To solve this problem, Emma constructs the funding and refund transaction at the same time. She signs the funding transaction but doesn't transmit it to anyone. Emma transmits only the refund transaction to Fabian and obtains his signature.
+Emma cannot risk funding a 2-of-2 multisig unless she has a guaranteed refund. To solve this problem, Emma constructs the funding and refund transactions at the same time. She signs the funding transaction but doesn't transmit it to anyone. Emma transmits only the refund transaction to Fabian and obtains his signature.
 
 The refund transaction acts as the first commitment transaction and its timelock establishes the upper bound for the channel's life. In this case, Emma could set the +nLocktime+ to 30 days or 4320 blocks into the future. All subsequent commitment transactions must have a shorter timelock, so that they can be redeemed before the refund transaction.