From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <8870AC4C-B5E4-491C-8973-8962DEBD39CE@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 23 May 2019 22:26:49 +0200
In-Reply-To: <CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
	<CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
Precedence: list


--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 23, 2019, at 21:45, Pieter Wuille <pieter.wuille@gmail.com> =
wrote:
>=20
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Difficulty change has profound impact on miner=E2=80=99s production =
thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on =
traditional trading venues. Some might soon list difficulty futures.
>>=20
>> I think we could do much better than them natively within Bitcoin.
>>=20
>> A better solution could be a transaction that uses nLocktime =
denominated in block height, such that it is valid after the difficulty =
adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of =
difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike =
which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who =
entered the bet.
>> The winner would broadcast.
>=20
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
>=20
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
>=20
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.

Thanks for these suggestions I will follow up while preparing the BIP.

>=20
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
>=20

This is the best reception I could have hoped for :)

> Cheers,
>=20
> --
> Pieter


--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80
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-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlznAgoACgkQ9nKRxRdx
ORy8zAf/YVsBFCLraoMx8gid3xqdsdv0upBdj6tv9bIYonwEdjlUNorHJDvQD6Pm
0L7xrm8cNcY1kc350y+fAdnIhfA1CS/zKuCCwNeFch4Uf189Q5WrfXVrP/zLYW24
a6eKfkhWW0Rf0pkyyFazU5qY5Fk3Vw490ExuKhSMRmtYYH3Rvei21tEw3HK6NuNK
mbqevrD7nOmny62ApbTOaUYzf+jHrX4henai8xLzkEMoPaVF/keXfeB1Q8pFkrPp
tqJpl2rmdZsGHT6IGkAwO3xekebID2QHqWmuewD/w9ep0/cH1ODSCpIVA57fNAfC
EytZyEbF4SUE2I06dSTJktk5EoPArQ==
=qZJx
-----END PGP SIGNATURE-----

--Apple-Mail=_7F17239D-5AE2-459C-AE09-9943EFE71A80--