flywithu/Learning-Bitcoin-from-the-Command-Line
1
1
Fork 0
mirror of https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git synced 2025-06-08 08:26:17 +00:00
Code Issues Releases Wiki Activity

Update 6_3_Sending_a_Transaction_with_a_Locktime.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-12 12:30:20 -07:00 committed by GitHub
parent ef1f2651f6
commit 161e83b2df
1 changed files with 4 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
6_3_Sending_a_Transaction_with_a_Locktime.md
View File

@ -12,10 +12,9 @@ _What is block height?_ It's the total count of blocks in the chain, going back
When a locktime transaction is waiting to go into a block, it can be cancelled. This means that it is far, far from finalized. In fact, the ability to cancel is the whole purpose of a locktime transaction.
_What is nLockTime?_ It's the same thing as locktime. More specifically, it's what locktime is called internal to the Bitcoin Core source code.
_What is Timelock?_ Locktime is just one way to lock Bitcoin transactions; collectively they're called timelocks. Locktime is covered here because it's the most basic timelock method. It locks an entire transaction, and it's available through `bitcoin-cli`. A second timelock method is called CheckLockTimeVerify, which is based on [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). It locks up outputs rather than whole transactions. A third timelock method is called a relative timelock, which allows for timelocks based on when funds were acquired. The CheckSequenceVerify opcode, which is based on [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki), and [BIP 113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki), locks transactions based on relative times.
_What is Timelock?_ Locktime is just one way to lock Bitcoin transactions until some point in the future; collectively these methods are called timelocks. Locktime is covered here because it's the most basic timelock method. It locks an entire transaction, and it's available through `bitcoin-cli`. A second timelock method is called CheckLockTimeVerify, which is based on [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). It locks up outputs rather than whole transactions. A third timelock method is called a relative timelock, which allows for timelocks based on when funds were acquired. The CheckSequenceVerify opcode, which is based on [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki), and [BIP 113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki), locks transactions based on relative times. Only Locktime is covered here, because it's the only one curently available through `bitcoin-cli`.
## Create a Locktime Transaction
@ -29,7 +28,7 @@ _Why Would I Use a UNIX Timestamp?_ Using a UNIX timestamp makes it easy to defi
> **WARNING:** Locktime with UNIX timestamps has a bit of wriggle room: the release of blocks isn't regular and block times can be two hours ahead of real time, so a locktime actually means "within a few hours of this time, plus or minus".
### Figure Out Your Locktime By UNIX Timestamp
### Figure Out Your Locktime By Block Height
Alternatively, you can set the locktime to a smaller number representing a block height. To calculate your future block height, you need to first know what the current block height is. `bitcoin-cli getblockcount` will tell you what your local machine thinks the block height is. You can verify that it's up to date with the `btcblock` alias, which compares the blockheight from your `bitcoind` with a block height taken from the network.
@ -37,7 +36,7 @@ Once you've figured out the current height, you can decide how far in the future
_Why Would I Use a Blockheight?_ Unlike with timestamps, there's no fuzziness for blockheights. If you set a blockheight of 120,000 for your locktime, then there's absolutely no way for it to go into block 119,999. This can make it easier to algorithmically control your locktimed transaction. The downside is that you can't be as sure of when precisely the locktime will be.
> **WARNING:** If you want to set a block height locktime, you must set the locktime to less than 500 million. If you set it to 500 million or over, your number will instead be interpreted as a timestamp. Since the UNIX timestamp of 500 million was November 5, 1985, that probably means that your transaction will be put into a block at the miners' first opportunity.
> **WARNING:** If you want to set a block-height locktime, you must set the locktime to less than 500 million. If you set it to 500 million or over, your number will instead be interpreted as a timestamp. Since the UNIX timestamp of 500 million was November 5, 1985, that probably means that your transaction will be put into a block at the miners' first opportunity.
## Write Your Transaction
@ -126,4 +125,4 @@ Cancelling a locktime transaction is _very_ simple: you send a new transactions
Locktime offers a way to create a transaction that _should_ not be relayable to the network and that _will_ not be accepted into a block until the appropriate time has arrived. In the meantime, it can be cancelled simply by reusing a UTXO.
_What is the Power of Locktime?_ The power of locktime may not be immediately obvious because of the ability to cancel it so easily. Nonetheless, it has a lot of utility in a variety of custodial or contractual applications. For example, consider a situation where a third party is holding your bitcoins. In order to guarantee the return of your bitcoins if the custodian ever disappeared, they could produce a timelock transition to return the coins to you, then update that every once in a while with a new one, further in the future. If they ever failed to update, then the coins would return to you when the current timelock expired. Locktime could similarly be applied to a payment network, where the network holds coins while they're being exchanged by network participants. Finally, a will offers an example of a more complex contract, where payments are sent out to a number of people. These payments would be build on locktime transactions, and would be continually updated as long as the owner continues to show signs of life. (The unifying factor of all of these applications is, of course, _trust_. Simple locktime transactions only work if the holder of the coins can be trusted to send them out under the appropriate conditions.)
_What is the Power of Locktime?_ The power of locktime may not be immediately obvious because of the ability to cancel it so easily. However, it's another of the bases of Smart Contracts: it has a lot of utility in a variety of custodial or contractual applications. For example, consider a situation where a third party is holding your bitcoins. In order to guarantee the return of your bitcoins if the custodian ever disappeared, they could produce a timelock transition to return the coins to you, then update that every once in a while with a new one, further in the future. If they ever failed to update, then the coins would return to you when the current timelock expired. Locktime could similarly be applied to a payment network, where the network holds coins while they're being exchanged by network participants. Finally, a will offers an example of a more complex contract, where payments are sent out to a number of people. These payments would be build on locktime transactions, and would be continually updated as long as the owner continues to show signs of life. (The unifying factor of all of these applications is, of course, _trust_. Simple locktime transactions only work if the holder of the coins can be trusted to send them out under the appropriate conditions.)