Date: Sat, 22 Aug 2020 12:46:20 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Thomas Hartman <thomashartman1@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200822164619.vh3rdmdqf6vlmcji@ganymede>
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="l5bv5a6itujcvsvb"
Content-Disposition: inline
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] reviving op_difficulty
Precedence: list


--l5bv5a6itujcvsvb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wr=
ote:
> First, I would like to pay respects to tamas blummer, RIP.
>=20
> https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering=
-bitcoin-developer

RIP, Tamas.

> Tamas proposed an additional opcode for enabling bitcoin difficulty
> futures, on this list at
>=20
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg079=
91.html

Subsequent to Blummer's post, I heard from Jeremy Rubin about a
scheme[1] that allows difficulty futures without requiring any changes
to Bitcoin.  In short, it takes advantage of the fact that changes in
difficulty also cause a difference in maturation time between timelocks
and height-locks.  As an simple example:

1. Alice and Bob create an unsigned transaction that deposits their
   money into a 2-of-2 multisig.

2. They cooperate to create and sign two conflicting spends from the multis=
ig:

    a. Pays Alice with an nLockTime(height) of CURRENT_HEIGHT + 2016 blocks

    b. Pays Bob with an nLockTime(time) of CURRENT_TIME + 2016 * 10 * 60 se=
conds

3. After both conflicting spends are signed, Alice and Bob sign and
   broadcast the deposit transaction from #1.

4. If hashrate increases during the subsequent period, the spend that
   pays Alice will mature first, so she broadcasts it and receives that
   money.  If hashrate decreases, the spend to Bob matures first, so he
   receives the money.

Of course, this basic formula can be tweaked to create other contracts,
e.g. a contract that only pays if hashrate goes down more than 25%.

As far as I can tell, this method should be compatible with offchain
commitments (e.g. payments within channels) and could be embedded in a
taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.

-Dave

[1] https://powswap.com/

--l5bv5a6itujcvsvb
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9BS9sACgkQ2dtBqWwi
adP+hxAAg7uPYPtIXTpa7H0+3sSrqcgNiXwbe52Pj0YTxgeb0f6TK4F/cvJ68zDE
oDHlep5kVopfvhVD1bq6+XB3RFrKHPGIq1gt1EtRrabAD5oD8VyqE/7vj4icwGUQ
k8yVPQyX6h/sdZJvB2GMMUXVL0Zq2Lkex63DSVHvaI42Damd7SCLqgRNwb0frr9E
PUea8BnBNb55dKWHI2RW3XVfnryp1FfudB+K3iKHpJ2h3C7osUCyx5d9sg+YPxKZ
9ShmJK2Qn5xhDnnJfYuSwT8mehJ8mO6YlrL/YQNcKGYhSOxFWXiVTGFWXgs6Jvip
DoEPN+c17bVLOjH1CfTacptMUoairrV6U4oawpgrJeMnGPq36zaCT94zV1yJGxaH
GODvAJIha+PSFRGzbT71geeHMxjc2qfjGhp8PqIBQz5NiBjdCC2DPwcKK0Uck2pz
34pf604XMTbLYYmBshQ19kfTQW3kzUi0lcLdShxkif9Ewov5MMqxmxKAtLGdbps2
V5TxBUnTc0d6n88encuKbiit3wAaWBA2rZl27YDwqWH0p5t3Cj8F3HaDP3FyWTp2
1d78yXk+61jkg4jCicSx7upReqX03gQcQ8PnOu18ULSluFc2fYeIC5X33moVWf2J
E4D6p3yVD7+SsXNqbjcUOVKoMd9rHEmYwzvtRkxyP0IVAWsXgkQ=
=Xt3l
-----END PGP SIGNATURE-----

--l5bv5a6itujcvsvb--