From: Thomas Hartman <thomashartman1@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 19 Aug 2020 19:32:25 -0400
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
 <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com>
 <C4A9F1FC-8BD9-4A03-806B-5091375090B5@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <C4A9F1FC-8BD9-4A03-806B-5091375090B5@gmail.com>
Message-Id: <1EE02345-9A45-427F-AE13-6E96FD25B55E@gmail.com>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Precedence: list

>=20
> So perhaps the way op_diff should work is take 2 packed targets, 1 =
known and 1 unknown at time of contract, and return the ratio.=20

On second thought, I don=E2=80=99t think this is a good idea. The 32-bit =
packed difficulty target is equivalent to difficulty, and this is =
probably what should get pushed onto the stack. No division is needed, =
just the arithmetic less than operator, which is already live in script, =
using the tick strategy described by Tier. So it seems to me these =
contracts could truly be done with the addition of the single op_diff =
opcode. It=E2=80=99s probably less human readable to be using difficulty =
target instead of difficulty, but no one reads script anyway.=20

It was also bothering me that difficulty was a floating point number (I =
have floating point phobia), so it is great not to have to think about =
floats anymore!