You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
95 lines
4.7 KiB
95 lines
4.7 KiB
[[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")))
|