In an earlier post [1] I suggested an approach to create native Bitcoin contracts that reduce mining's income volatility and received very helpful comments on implementation from Pieter Wuille [2] and Natanael [3]
After processing those comments I instead suggest the following restricted
interpretation of nSequence and a new opcode WORKVERIFY that in combination is
easier to implement and reason about as it follows the implementation pattern
of CHECKSEQUENCEVERIFY[5]
Accumulated work on the blockchain is strictly increasing, therefore
transaction eligibility rule with a >= condition on it would need no
re-evaluation for descendant blocks, in mempool or at re-org, since additional
blocks or re-org can only increase the accumulated work. Accumulated work is
just like time, it is actually an alternate measure of time through
computation[6], therefore analogous to MTP based restriction implemented with
BIP68 [4].
=== (the implementation proposal) ===
(needs soft fork for two reasons, activation logic tbd.)
I. Stricter interpretation of nSequence to optionally refer accumulated work:
Only if bit 31 AND bit 30 is set in nSequence can the transaction be included
into any block. This is a restricting a rule of BIP68 [4] that only required
bit 31 to be set for unrestricted inclusion into blocks. Otherwise nSequence
refers to accumulated work (see encoding later) and it is only viable to
include the transaction into a block if the block has >= work accumulated. This
would define the meaning of one additional bit in nSequence, but leave all
other freedom of later improvement left by BIP68.
II. New WORKVERIFY opcode redefining a NOPx in transaction script as:
Terminate script with false for any reason described in BIP112 or if bit 31 is
set but bit 30 is not set and 256 bit unsigned integer on stack is higher than
(nSequence &0xffff)>> 6 * 2^((nSequence & 0x3f) + 84)
=== (end proposal) ===
Notes on the work encoding:
Total accumulated work as of now is > 2^90 and if we assume that mining
capacity keeps increasing with Moore’s law (double every year) for the next 50
years, then it could sum up to 2^140. We have much less bits available in
nSequence therefore we have to encode accumulated work in a floating point
number with sufficient precision.
The work accumulated during the current difficulty adjustment cycle is > 2016 *
2^74 which is > 2^84. It is rather unlikely that accumulated work in a
difficulty adjustment period drops below 2^80 ever again in future which means
we need not be more precise than 2^80/2^90 or 2^-10 to allow for contracts
that reference increment until the next adjustment. Therefore a mantissa of 10
bits should be sufficient. Using 6 bits of exponent and an offset of 2^84 we
can express the range of [2^84, 2^148) that should be sufficient now and for
foreseeable future. Please let me know if the approach is not optimal or future
proof in your opinion.
Why, should we build this into Bitcoin ?
The most influential risk factor in miners' investment decision is the
anticipated change of difficulty over the time horizon of the mining
equipment's expected lifetime. Their investments secure the network. The
ability to create contracts that reduce income volatility would lead to
additional investment into mining.
A native Bitcoin contract is far superior to alternatives that could be offered
on traditional markets as:
a native Bitcoin contract would be:
- uncensorable: It requires only the agreement to terms between those
financially involved
- fully collaterized: no counterparty risk which means Miner could buy hedging
contracts from any unkown and un-trusted actor that is able to commit collateral
- no oracle is needed
- no disagreement on the settlement
- publicly observable: allow to observe market opinion on future difficulty
- the length of the contract could match miner's investment horizon extending
over several difficulty adjustments.
Why not on a side-chain ?
Work is fundamental and intrinsic to the base layer. A contract that reduces
earnings volatility helps to attract more capital for mining and therefore
increase security on the base layer.
How would this be used?
Miner and Speculator sign a transaction that has an nLockTime of S in the
future. This gives both parties the option to alternatively spend committed
output in case the other would not follow through and publish committing the
collateral until S.
Speculators contribution to collateral is higher than that of the Miner.
Miner’s collateral is the premium for the insurance provided by Speculator.
The single output of the transaction has following script:
IF
<maturity> CHECKLOCKTIMEVERIFY DROP
<speculator’s key> CHECKSIGVERIFY
ELSE
<sufficient work> WORKVERIFY DROP
<miner’s key> CHECKSIGVERIFY
ENDIF
This allows the speculator to take back its collateral plus the option premium
after the maturity time point, which would however only be possible if it was
not taken earlier by Miner as sufficient work was reached.
The contract in finance terms is an american digital call option with maturity
and sufficient work as strike. The Miner profits of the contract if work
accumulated is more than contracted in which case he would also have lower
mining income, hence the contract would reduce earnings shortcome. The
Speculator would earn the option premium if the contracted work was not
required until maturity. In this case higher mining income through higher
market share compensates Miner for the loss of option premium. In both cases
Miner’s income volatility is reduced. The Speculator may find it attractive to
enter the contract if the probability weighted option premium represents an
attractive interest on the capital committed.
Contracted work would reflect the consenus of expected difficulty increase over
future time horizons. Observing above contracts on the blockchain would allow
calculation of market implied forward curve of mining difficulty and its
implied volatility which again would help evaluating investment proposals into
mining.
An alternate more flexible setup would be a Lightning Network like
re-allocation of total collateral. Which would allo parties to mark the option
to market (observed work and volatility) as time passes and allow for
cooperative unwind.
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016952.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016969.html
[4] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[5] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
[6]
https://medium.com/@tamas.blummer/measuring-time-with-chain-of-blocks-893a38cc06bb
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
