path: root/ef/f4176b8214bfb3300ae60dc904278088e8dad5

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B5D78C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Dec 2021 17:17:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id ADC1383DFD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Dec 2021 17:17:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8Mt1Amopp036
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Dec 2021 17:17:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 8D47183DFB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Dec 2021 17:17:32 +0000 (UTC)
Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com
 [209.85.167.41]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BOHHTGc018278
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 24 Dec 2021 12:17:30 -0500
Received: by mail-lf1-f41.google.com with SMTP id i31so20205963lfv.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Dec 2021 09:17:30 -0800 (PST)
X-Gm-Message-State: AOAM531JEVx1HTsRWubAO/VmRG5arWkEk2dYUAcGYTaBBXfP0cZA0Q9H
 Ylcv8rBNdPNfqSlJNBR0gK/TjvRuNNHfcd+jZ9I=
X-Google-Smtp-Source: ABdhPJzqIAdtiXsiHFjpNoWvqnVARkSC+h2z1ka38YmS7YXhBiRXJbiRe5YoAyRZ53EpTjhouPV2tApuw/CjzS9DEa0=
X-Received: by 2002:a05:6512:33c9:: with SMTP id
 d9mr589475lfg.516.1640366249129; 
 Fri, 24 Dec 2021 09:17:29 -0800 (PST)
MIME-Version: 1.0
References: <MrhJf_p--3-2@tutanota.de>
In-Reply-To: <MrhJf_p--3-2@tutanota.de>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 Dec 2021 09:17:16 -0800
X-Gmail-Original-Message-ID: <CAD5xwhja5+vAjsMpDoJRGpoJXwTVde+QmYtTofUgWO_+=Y1PPw@mail.gmail.com>
Message-ID: <CAD5xwhja5+vAjsMpDoJRGpoJXwTVde+QmYtTofUgWO_+=Y1PPw@mail.gmail.com>
To: Prayank <prayank@tutanota.de>
Content-Type: multipart/alternative; boundary="00000000000094bc5e05d3e787b5"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Dec 2021 17:17:33 -0000

--00000000000094bc5e05d3e787b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 24, 2021, 8:42 AM Prayank <prayank@tutanota.de> wrote:

> Hi Jeremy,
>
> > Wheres the info come from? Well, multiple places. We could get it from =
a
> third party (maybe using an attestation chain of some sort?), or there ar=
e
> certain ways it could be self-referential (like for powswap
> <https://powswap.com>).
>
> > Now let=E2=80=99s define a threshold oracle =E2=80=93 we wouldn=E2=80=
=99t want to trust just one
> lousy oracle, so let=E2=80=99s trust M out of N of them!
>
> Similar approach is used in discreet log contracts for multi oracles.
> There is even a project for P2P derivatives but it was not used for any
> real trades on mainnet or further developed. What difference would OP_CTV
> make in this project if its implemented in Bitcoin?
>
> https://github.com/p2pderivatives/p2pderivatives-client
>
> https://github.com/p2pderivatives/p2pderivatives-server
>
> https://github.com/p2pderivatives/p2pderivatives-oracle
>

Discussed a bit here
https://twitter.com/JeremyRubin/status/1473175356366458883?t=3D7U4vI4CYIM82=
vNc8T8n6_g&s=3D19


A core benefit is unilateral opens. I.e. you can pay someone into a
derivative without them being online.


For example, you want to receive your payment in a Bitcoin backed Magnesium
risk reversal in exchange for some phys magnesium. I can create the
contract with your signing keys offline.

>
>
> > Does this NEED CTV?
> No, not in particular. Most of this stuff could be done with online signe=
r
> server federation between you and counterparty. CTV makes some stuff nice=
r
> though, and opens up new possibilities for opening these contracts
> unilaterally.
>
> Nicer? How would unilateral derivatives work because my understanding was
> that you always need a peer to take the other side of the trade. I wish w=
e
> could discuss this topic in a trading community with some Bitcoiners that
> even had some programming knowledge.
>
> Derivatives are interesting and less explored or used in Bitcoin projects=
.
> They could be useful in solving lot of problems.
>
>
I have a decent understanding of a bit of the trading world and can answer
most questions you have, or point you to someone else who would.


The way a unilateral option would work is that I can create a payment to
you paying you into an Option expiring next week that gives you the right
to purchase from me a magnesium risk reversal contract that settles next
month.



An example where this type of pattern must be used is in conjunction with
DCFMP and PowSwap where miners could commit to, instead of just keys,
'trade specs' and an Automatic market maker inside the DCFMP could attempt
to match that miner to a counterparty who wants the opposite hashrate
hedge. The need to exchange signatures would make this unviable otherwise.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, Dec 24, 2021, 8:42 AM Prayank &lt;<a href=3D"m=
ailto:prayank@tutanota.de">prayank@tutanota.de</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
 =20
   =20
 =20
  <div>
<div>Hi Jeremy,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt;=
 Wheres the info come from? Well, multiple places. We could get it from a t=
hird party (maybe using an
attestation chain of some sort?), or there are certain ways it could be
self-referential (like for <a href=3D"https://powswap.com" rel=3D"noopener =
noreferrer noreferrer" target=3D"_blank">powswap</a>).<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">&gt; Now let=E2=80=99s define a threshol=
d oracle =E2=80=93 we wouldn=E2=80=99t want to trust just one
lousy oracle, so let=E2=80=99s trust M out of N of them!<br><br>Similar app=
roach is used in discreet log contracts for multi oracles. There is even a =
project for P2P derivatives but it was not used for any real trades on main=
net or further developed. What difference would OP_CTV make in this project=
 if its implemented in Bitcoin?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><a href=3D"https://github.com/p2pderivatives/p2pderivatives-clien=
t" target=3D"_blank" rel=3D"noreferrer">https://github.com/p2pderivatives/p=
2pderivatives-client</a><br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><a href=3D"https://github.com/p2pderivatives/p2pderivatives-server" ta=
rget=3D"_blank" rel=3D"noreferrer">https://github.com/p2pderivatives/p2pder=
ivatives-server</a><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<a href=3D"https://github.com/p2pderivatives/p2pderivatives-oracle" target=
=3D"_blank" rel=3D"noreferrer">https://github.com/p2pderivatives/p2pderivat=
ives-oracle</a><br></div><div dir=3D"auto"></div></div></blockquote></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">Discussed a bit here=C2=
=A0</div><div dir=3D"auto"><a href=3D"https://twitter.com/JeremyRubin/statu=
s/1473175356366458883?t=3D7U4vI4CYIM82vNc8T8n6_g&amp;s=3D19">https://twitte=
r.com/JeremyRubin/status/1473175356366458883?t=3D7U4vI4CYIM82vNc8T8n6_g&amp=
;s=3D19</a></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">A core benefit is unilateral opens. I.e. you can pay someon=
e into a derivative without them being online.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">For example, you want to=
 receive your payment in a Bitcoin backed Magnesium risk reversal in exchan=
ge for some phys magnesium. I can create the contract with your signing key=
s offline.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">&gt; Does this NEED CTV?<br></div><div dir=3D"au=
to">No, not in particular. Most of this stuff could be done with online sig=
ner server federation between you and counterparty. CTV makes some stuff ni=
cer though, and opens up new possibilities for opening these contracts unil=
aterally.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Nicer? How=
 would unilateral derivatives work because my understanding was that you al=
ways need a peer to take the other side of the trade. I wish we could discu=
ss this topic in a trading community with some Bitcoiners that even had som=
e programming knowledge.<br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Derivatives are interesting and less explored or used in Bitcoin proje=
cts. They could be useful in solving lot of problems.<br></div><div dir=3D"=
auto"><br></div><div></div></div></blockquote></div></div><div dir=3D"auto"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div>=
</div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">I have a decent understanding of a bit of the trading world and can answe=
r most questions you have, or point you to someone else who would.=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">The way a unilateral option would work is that I can create a payment to =
you paying you into an Option expiring next week that gives you the right t=
o purchase from me a magnesium risk reversal contract that settles next mon=
th.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">An example where this type of pat=
tern must be used is in conjunction with DCFMP and PowSwap where miners cou=
ld commit to, instead of just keys, &#39;trade specs&#39; and an Automatic =
market maker inside the DCFMP could attempt to match that miner to a counte=
rparty who wants the opposite hashrate hedge. The need to exchange signatur=
es would make this unviable otherwise.</div></div>

--00000000000094bc5e05d3e787b5--