MIME-Version: 1.0
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
 <20200822164619.vh3rdmdqf6vlmcji@ganymede>
In-Reply-To: <20200822164619.vh3rdmdqf6vlmcji@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 2 Sep 2020 11:27:00 -0700
Message-ID: <CAD5xwhidng5tCcu0fzodEwni+bSdhpT-7qLYH7xtB-HxJJttxA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c2863b05ae58c84f"
Subject: Re: [bitcoin-dev] reviving op_difficulty
Precedence: list

--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 <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
>

--000000000000c2863b05ae58c84f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Yep this is a good exampl=
e construction. I&#39;d also point out that modulo a privacy improvement, y=
ou can also script it as something like:</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">IF=C2=A0=C2=A0 IF &lt;T&gt; =
CLTV B DROP CHECKSIG ELSE &lt;T2&gt; CLTV DROP A CHECKSIG ENDIF ELSE 2 A B =
2 CHECKMULTI ENDIF<br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">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&#39;s fine.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">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).<br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">And it&#39;s also possible to mix relative and absolute=
 time locks for some added fun behavior (e.g., you win if &gt; Time and &gt=
; Blocks)<br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signa=
ture" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><br></div><div di=
r=3D"ltr"><br></div><div dir=3D"ltr"><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">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.</div></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br>=
</div><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">The general issu=
e with this construction family is that the contracts are metastable. E.g.,=
 if you&#39;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&#39;s s=
ome minimum times and hashrate moves to play with, and the less &quot;clear=
ly correct&quot; 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.</div><br></div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jerem=
yRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Je=
remyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 22, 2020=
 at 9:47 AM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun,=
 Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote:<br=
>
&gt; First, I would like to pay respects to tamas blummer, RIP.<br>
&gt; <br>
&gt; <a href=3D"https://bitcoinmagazine.com/articles/remembering-tamas-blum=
mer-pioneering-bitcoin-developer" rel=3D"noreferrer" target=3D"_blank">http=
s://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitco=
in-developer</a><br>
<br>
RIP, Tamas.<br>
<br>
&gt; Tamas proposed an additional opcode for enabling bitcoin difficulty<br=
>
&gt; futures, on this list at<br>
&gt; <br>
&gt; <a href=3D"https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundat=
ion.org/msg07991.html" rel=3D"noreferrer" target=3D"_blank">https://www.mai=
l-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html</a><br>
<br>
Subsequent to Blummer&#39;s post, I heard from Jeremy Rubin about a<br>
scheme[1] that allows difficulty futures without requiring any changes<br>
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<br>
and height-locks.=C2=A0 As an simple example:<br>
<br>
1. Alice and Bob create an unsigned transaction that deposits their<br>
=C2=A0 =C2=A0money into a 2-of-2 multisig.<br>
<br>
2. They cooperate to create and sign two conflicting spends from the multis=
ig:<br>
<br>
=C2=A0 =C2=A0 a. Pays Alice with an nLockTime(height) of CURRENT_HEIGHT + 2=
016 blocks<br>
<br>
=C2=A0 =C2=A0 b. Pays Bob with an nLockTime(time) of CURRENT_TIME + 2016 * =
10 * 60 seconds<br>
<br>
3. After both conflicting spends are signed, Alice and Bob sign and<br>
=C2=A0 =C2=A0broadcast the deposit transaction from #1.<br>
<br>
4. If hashrate increases during the subsequent period, the spend that<br>
=C2=A0 =C2=A0pays Alice will mature first, so she broadcasts it and receive=
s that<br>
=C2=A0 =C2=A0money.=C2=A0 If hashrate decreases, the spend to Bob matures f=
irst, so he<br>
=C2=A0 =C2=A0receives the money.<br>
<br>
Of course, this basic formula can be tweaked to create other contracts,<br>
e.g. a contract that only pays if hashrate goes down more than 25%.<br>
<br>
As far as I can tell, this method should be compatible with offchain<br>
commitments (e.g. payments within channels) and could be embedded in a<br>
taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.<br>
<br>
-Dave<br>
<br>
[1] <a href=3D"https://powswap.com/" rel=3D"noreferrer" target=3D"_blank">h=
ttps://powswap.com/</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c2863b05ae58c84f--