bitcoinbook/ch07.asciidoc

[[ch07]]
[[adv_transactions]]
== Advanced Transactions and Scripting

==== Median-Time-Past

((("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 BIP-113, 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[BIP-113].

[[fee_sniping]]
==== Timelock Defense Against Fee Sniping

((("scripting", "timelocks", "defense against
fee-sniping")))((("timelocks", "defense against
fee-sniping")))((("fees", "fee sniping")))((("security", "defense
against fee-sniping")))((("sniping")))Fee-sniping is a theoretical
attack scenario, where miners attempting to rewrite past blocks "snipe"
higher-fee transactions from future blocks to maximize their
profitability.

For example, let's say the highest block in existence is block
#100,000. If instead of attempting to mine block #100,001 to extend the
chain, some miners attempt to remine  #100,000. These miners can choose
to include any valid transaction (that hasn't been mined yet) in their
candidate block  #100,000. They don't have to remine the block with the
same transactions. In fact, they have the incentive to select the most
profitable (highest fee per kB) transactions to include in their block.
They can include any transactions that were in the "old" block
#100,000, as well as any transactions from the current mempool.
Essentially they have the option to pull transactions from the "present"
into the rewritten "past" when they re-create block  #100,000.

Today, this attack is not very lucrative, because block reward is much
higher than total fees per block. But at some point in the future,
transaction fees will be the majority of the reward (or even the
entirety of the reward). At that time, this scenario becomes inevitable.

To prevent "fee sniping," when Bitcoin Core creates transactions, it
uses +nLocktime+ to limit them to the "next block," by default. In our
scenario, Bitcoin Core would set +nLocktime+ to 100,001 on any
transaction it created. Under normal circumstances, this +nLocktime+ has
no effect—the transactions could only be included in block
#100,001 anyway; it's the next block.

But under a blockchain fork attack, the miners would not be able to pull
high-fee transactions from the mempool, because all those transactions
would be timelocked to block #100,001. They can only remine  #100,000
with whatever transactions were valid at that time, essentially gaining
no new fees.

To achieve this, Bitcoin Core sets the +nLocktime+ on all new
transactions to <current block # + 1> and sets the +nSequence+ on all
the inputs to 0xFFFFFFFE to enable +nLocktime+.((("",
startref="Stimelock07")))