mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-26 18:08:31 +00:00
ch12: transaction -> transactions
This commit is contained in:
parent
e3695afbf6
commit
eb57ec48a0
@ -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.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user