Re: [bitcoin-dev] reviving op_difficulty

["David A. Harding" <dave@dtrt.org>]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote:
> First, I would like to pay respects to tamas blummer, RIP.
> 
> 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
> 
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.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 multisig:

    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 seconds

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/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]