From: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <CD8B22E6-6A8C-414B-86F2-D993475FE386@gmail.com>
Date: Sat, 8 Jun 2019 20:59:09 +0200
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
Precedence: list


--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 >=3D 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].

=3D=3D=3D (the implementation proposal) =3D=3D=3D

(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 >=3D 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)

=3D=3D=3D (end proposal) =3D=3D=3D

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=E2=80=99s 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=E2=80=99s collateral is the premium for the insurance provided by =
Speculator.

The single output of the transaction has following script:

IF
	<maturity> CHECKLOCKTIMEVERIFY DROP
        <speculator=E2=80=99s key> CHECKSIGVERIFY
ELSE
        <sufficient work> WORKVERIFY DROP
        <miner=E2=80=99s 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=E2=80=99s 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.ht=
ml
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.ht=
ml
[3] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016969.ht=
ml
[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-893a=
38cc06bb

--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlz8BX0ACgkQ9nKRxRdx
ORxSkgf+JzDoNo6hEpRZzDyGVkyCDwcanm+qS2NeDrXGLkrnHiXS9GykfYnS1wkv
oSwCgdPYgXwICwByJ3mEfaSBxHUTqhW2ZTebmU4j/NwUgStUQwFfiIiFWCGsLVOV
qfZTh/FtI9dXFRt+TEPPcsPlUVbFRAHv6DmFFTnbcezWUOYQ/qOZB8AR1KgADzsg
CWmPnKq/npuSKcxtpaRW8HyDX6L9Td/Llb9kVh4krn1n2fPVcfVI4ABY7n6LpLlh
ZGXnOY/+erf+3lxO6RDxaQ7nB5+j5Bl5izFJnUErEl0ipXoMetef4CFxw3q2jjJv
9EhfQN+7oq0joLV8VU8OmwjlQ7DjsQ==
=rsYw
-----END PGP SIGNATURE-----

--Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F--