Re: [bitcoin-dev] reviving op_difficulty

[Jeremy <jlrubin@mit.edu>]

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

Yep this is a good example construction. I'd also point out that modulo a
privacy improvement, you can also script it as something like:

IF   IF <T> CLTV B DROP CHECKSIG ELSE <T2> CLTV DROP A CHECKSIG ENDIF ELSE
2 A B 2 CHECKMULTI ENDIF

This way you equivalently have cooperative closing / early closing
positions, but you make the redeem script non-interactive to setup which
enable someone to pay into one of these contracts without doing
pre-signeds. This is unfortunate for privacy as the script is then visible,
but in a taproot world it's fine.

Of course the non interactivity goes away if you want non-binary outcomes
(e.g., Alice gets 1.5 Coin and Bob gets .5 Coin in case A, Bob gets 1.5
Coin Alice gets .5 coin in Case B).

And it's also possible to mix relative and absolute time locks for some
added fun behavior (e.g., you win if > Time and > Blocks)


A while back I put together some python code which handles these embedded
in basic channels between two parties (no routing). This enables you to
high-frequency update and model a hashrate perpetual swap, assuming your
counterparty is online.


The general issue with this construction family is that the contracts are
metastable. E.g., if you're targeting a 100 block deficit , that means you
have 100 blocks of time to claim the funds before either party can win. So
there's some minimum times and hashrate moves to play with, and the less
"clearly correct" you were, the less clearly correct the execution will be.
This makes the channel version of the contract compelling as you can update
and revoke frequently on further out contracts.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Sat, Aug 22, 2020 at 9:47 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6550 bytes --]