From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 07FFAC0051 for ; Wed, 2 Sep 2020 18:27:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id E07ED2291D for ; Wed, 2 Sep 2020 18:27:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVfYSdBN2OKT for ; Wed, 2 Sep 2020 18:27:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by silver.osuosl.org (Postfix) with ESMTPS id E41EA20349 for ; Wed, 2 Sep 2020 18:27:14 +0000 (UTC) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 082IRCIZ028591 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 2 Sep 2020 14:27:13 -0400 Received: by mail-ed1-f54.google.com with SMTP id ay8so5886219edb.8 for ; Wed, 02 Sep 2020 11:27:13 -0700 (PDT) X-Gm-Message-State: AOAM533ITHPuMyVFGYfu4A06AtBeRcdrZjZ4XLMrla1W0wkDctIry7xM meExJWEFQ2onNn7WQ3/lThgdgB7E527YV23F3Mw= X-Google-Smtp-Source: ABdhPJyoBP2ZrZIIYBCy5JQx9mAnxXWAjRdKpZpCmf7kY6W8aWpVrevo7+wl4Qx+/fMBhL18r4i9u99RxAYlH9XZQmA= X-Received: by 2002:aa7:db02:: with SMTP id t2mr1351690eds.95.1599071232098; Wed, 02 Sep 2020 11:27:12 -0700 (PDT) MIME-Version: 1.0 References: <20200822164619.vh3rdmdqf6vlmcji@ganymede> In-Reply-To: <20200822164619.vh3rdmdqf6vlmcji@ganymede> From: Jeremy Date: Wed, 2 Sep 2020 11:27:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c2863b05ae58c84f" Subject: Re: [bitcoin-dev] reviving op_difficulty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 18:27:17 -0000 --000000000000c2863b05ae58c84f Content-Type: text/plain; charset="UTF-8" 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 CLTV B DROP CHECKSIG ELSE 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 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 > --000000000000c2863b05ae58c84f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep this is a good exampl= e construction. I'd also point out that modulo a privacy improvement, y= ou can also script it as something like:

IF=C2=A0=C2=A0 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 clo= sing / early closing positions, but you make the redeem script non-interact= ive to setup which enable someone to pay into one of these contracts withou= t 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 inte= ractivity goes away if you want non-binary outcomes (e.g., Alice gets 1.5 C= oin 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-f= requency update and model a hashrate perpetual swap, assuming your counterp= arty is online.


=
The general issu= e 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 bloc= ks of time to claim the funds before either party can win. So there's s= ome minimum times and hashrate moves to play with, and the less "clear= ly 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.




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.
>
> http= s://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitco= in-developer

RIP, Tamas.

> Tamas proposed an additional opcode for enabling bitcoin difficulty > futures, on this list at
>
> https://www.mai= l-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.=C2=A0 In short, it takes advantage of the fact that changes in<= br> difficulty also cause a difference in maturation time between timelocks
and height-locks.=C2=A0 As an simple example:

1. Alice and Bob create an unsigned transaction that deposits their
=C2=A0 =C2=A0money into a 2-of-2 multisig.

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

=C2=A0 =C2=A0 a. Pays Alice with an nLockTime(height) of CURRENT_HEIGHT + 2= 016 blocks

=C2=A0 =C2=A0 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
=C2=A0 =C2=A0broadcast the deposit transaction from #1.

4. If hashrate increases during the subsequent period, the spend that
=C2=A0 =C2=A0pays Alice will mature first, so she broadcasts it and receive= s that
=C2=A0 =C2=A0money.=C2=A0 If hashrate decreases, the spend to Bob matures f= irst, so he
=C2=A0 =C2=A0receives 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] h= ttps://powswap.com/
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000c2863b05ae58c84f--