1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-26 18:08:31 +00:00

ch12: transaction -> transactions

This commit is contained in:
rating89us 2021-01-31 18:22:49 +01:00 committed by GitHub
parent e3695afbf6
commit eb57ec48a0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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+). 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. 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.