mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-01-09 15:20:55 +00:00
CH12: Median Time Past: move and update
This commit is contained in:
parent
e145b6fd29
commit
d9a730a512
100
ch10.asciidoc
100
ch10.asciidoc
@ -1,52 +1,6 @@
|
|||||||
[[mining]]
|
[[mining]]
|
||||||
== Mining and Consensus
|
== Mining and Consensus
|
||||||
|
|
||||||
[[mtp]]
|
|
||||||
=== Median Time Past (MTP)
|
|
||||||
|
|
||||||
((("scripting", "timelocks",
|
|
||||||
"Median-Tme-Past")))((("Median-Tme-Past")))((("timelocks",
|
|
||||||
"Median-Tme-Past")))As part of the activation of relative timelocks,
|
|
||||||
there was also a change in the way "time" is calculated for timelocks
|
|
||||||
(both absolute and relative). In bitcoin there is a subtle, but very
|
|
||||||
significant, difference between wall time and consensus time. Bitcoin is
|
|
||||||
a decentralized network, which means that each participant has his or
|
|
||||||
her own perspective of time. Events on the network do not occur
|
|
||||||
instantaneously everywhere. Network latency must be factored into the
|
|
||||||
perspective of each node. Eventually everything is synchronized to
|
|
||||||
create a common ledger. Bitcoin reaches consensus every 10 minutes about
|
|
||||||
the state of the ledger as it existed in the _past_.
|
|
||||||
|
|
||||||
The timestamps set in block headers are set by the miners. There is a
|
|
||||||
certain degree of latitude allowed by the consensus rules to account for
|
|
||||||
differences in clock accuracy between decentralized nodes. However, this
|
|
||||||
creates an unfortunate incentive for miners to lie about the time in a
|
|
||||||
block so as to earn extra fees by including timelocked transactions that
|
|
||||||
are not yet mature. See the following section for more information.
|
|
||||||
|
|
||||||
To remove the incentive to lie and strengthen the security of timelocks,
|
|
||||||
a BIP was proposed and activated at the same time as the BIPs for
|
|
||||||
relative timelocks. This is BIP113, which defines a new consensus
|
|
||||||
measurement of time called _Median-Time-Past_.
|
|
||||||
|
|
||||||
Median-Time-Past is calculated by taking the timestamps of the last 11
|
|
||||||
blocks and finding the median. That median time then becomes consensus
|
|
||||||
time and is used for all timelock calculations. By taking the midpoint
|
|
||||||
from approximately two hours in the past, the influence of any one
|
|
||||||
block's timestamp is reduced. By incorporating 11 blocks, no single
|
|
||||||
miner can influence the timestamps in order to gain fees from
|
|
||||||
transactions with a timelock that hasn't yet matured.
|
|
||||||
|
|
||||||
Median-Time-Past changes the implementation of time calculations for
|
|
||||||
+nLocktime+, +CLTV+, +nSequence+, and +CSV+. The consensus time
|
|
||||||
calculated by Median-Time-Past is always approximately one hour behind
|
|
||||||
wall clock time. If you create timelock transactions, you should account
|
|
||||||
for it when estimating the desired value to encode in +nLocktime+,
|
|
||||||
+nSequence+, +CLTV+, and +CSV+.
|
|
||||||
|
|
||||||
Median-Time-Past is specified in
|
|
||||||
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki[BIP113].
|
|
||||||
|
|
||||||
[[duplicate_transactions]]
|
[[duplicate_transactions]]
|
||||||
=== Preventing Duplicate Transactions
|
=== Preventing Duplicate Transactions
|
||||||
|
|
||||||
@ -1179,6 +1133,60 @@ of electricity in bitcoin, because that determines the profitability of
|
|||||||
mining and therefore the incentives to enter or exit the mining
|
mining and therefore the incentives to enter or exit the mining
|
||||||
market.((("", startref="targets10")))
|
market.((("", startref="targets10")))
|
||||||
|
|
||||||
|
[[mtp]]
|
||||||
|
=== Median Time Past (MTP)
|
||||||
|
|
||||||
|
In bitcoin there is a subtle, but very
|
||||||
|
significant, difference between wall time and consensus time. Bitcoin is
|
||||||
|
a decentralized network, which means that each participant has his or
|
||||||
|
her own perspective of time. Events on the network do not occur
|
||||||
|
instantaneously everywhere. Network latency must be factored into the
|
||||||
|
perspective of each node. Eventually everything is synchronized to
|
||||||
|
create a common ledger. Bitcoin reaches consensus every 10 minutes about
|
||||||
|
the state of the ledger as it existed in the _past_.
|
||||||
|
|
||||||
|
The timestamps set in block headers are set by the miners. There is a
|
||||||
|
certain degree of latitude allowed by the consensus rules to account for
|
||||||
|
differences in clock accuracy between decentralized nodes. However, this
|
||||||
|
creates an unfortunate incentive for miners to lie about the time in a
|
||||||
|
block. For example, if a miner sets their time in the future, they can
|
||||||
|
lower difficulty, allowing them to mine more blocks and claim some of
|
||||||
|
the block subsidy reserved for future miners. If they can set their
|
||||||
|
times in the past for some blocks, they can use the current time for
|
||||||
|
some other blocks, and so again make it look like there's a long time
|
||||||
|
between blocks for the purpose of manipulating difficulty.
|
||||||
|
|
||||||
|
To prevent manipulation, Bitcoin has two consensus rules. The first is
|
||||||
|
that no node will accept any block with a time further in the future
|
||||||
|
than two hours. The second is that no node will accept a block with a
|
||||||
|
time less than or equal to the median time of the last 11 blocks, called
|
||||||
|
_median time past_ (MTP).
|
||||||
|
|
||||||
|
As part of the activation of BIP68 relative timelocks,
|
||||||
|
there was also a change in the way "time" is calculated for timelocks
|
||||||
|
(both absolute and relative) in transactions. Previously, a miner
|
||||||
|
could include any transaction in a block with a time lock equal to or
|
||||||
|
below the time of the block. That incentivized miners to use the latest
|
||||||
|
possible time they thought was possible (close to two hours in the future)
|
||||||
|
so that more transactions would be eligible for their block.
|
||||||
|
|
||||||
|
To remove the incentive to lie and strengthen the security of timelocks,
|
||||||
|
BIP113 was proposed and activated at the same time as the BIPs for
|
||||||
|
relative timelocks.
|
||||||
|
The median time past became the consensus
|
||||||
|
time and is used for all timelock calculations. By taking the midpoint
|
||||||
|
from approximately two hours in the past, the influence of any one
|
||||||
|
block's timestamp is reduced. By incorporating 11 blocks, no single
|
||||||
|
miner can influence the timestamps in order to gain fees from
|
||||||
|
transactions with a timelock that hasn't yet matured.
|
||||||
|
|
||||||
|
Median time past changes the implementation of time calculations for
|
||||||
|
+nLocktime+, +CLTV+, +nSequence+, and +CSV+. The consensus time
|
||||||
|
calculated by median time past is usually about one hour behind
|
||||||
|
wall clock time. If you create timelock transactions, you should account
|
||||||
|
for it when estimating the desired value to encode in +nLocktime+,
|
||||||
|
+nSequence+, +CLTV+, and +CSV+.
|
||||||
|
|
||||||
=== Successfully Mining the Block
|
=== Successfully Mining the Block
|
||||||
|
|
||||||
((("mining and consensus", "mining the block", "successful
|
((("mining and consensus", "mining the block", "successful
|
||||||
|
Loading…
Reference in New Issue
Block a user