From: Tamas Blummer <tamas.blummer@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail•com>
Subject: [bitcoin-dev] WORKVERIFY: uncensorable contracts hedging biggest risk of mining without 3rd party or oracle
Date: Sat, 8 Jun 2019 20:59:09 +0200 [thread overview]
Message-ID: <CD8B22E6-6A8C-414B-86F2-D993475FE386@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6871 bytes --]
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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
reply other threads:[~2019-06-08 18:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD8B22E6-6A8C-414B-86F2-D993475FE386@gmail.com \
--to=tamas.blummer@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox