From eb57ec48a07a40c3433ae6c5a0097e445cc7104c Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 31 Jan 2021 18:22:49 +0100 Subject: [PATCH] ch12: transaction -> transactions --- ch12.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index 54a9730a..a37affce 100644 --- a/ch12.asciidoc +++ b/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.