Return-Path: <prayank@tutanota.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 046E0C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Dec 2021 16:42:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id E7B26416A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Dec 2021 16:42:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vSQYbKn26fZc
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Dec 2021 16:42:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
by smtp4.osuosl.org (Postfix) with ESMTPS id A2B2D402BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Dec 2021 16:42:45 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id 93642FA04A8;
Fri, 24 Dec 2021 16:42:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1640364162;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
bh=XODzwVuwFOTPLyncDjJrvgQiFVZBnOHKojQCmk+zaH0=;
b=33Zd3yfEZOyDnK802ba/x7qwbWuCbSKk/GxeSY2zEiydPRQZ7VQS13C56I2cQeyr
IO8KLcQnnUbxnQZyzMO4fPD10t+MevEym6ZMjQhCmqcbWPU5GSfumGxLU0cBIjW7Gn7
PeQQHAplKavDpHmXuNQnw6RMocmgZi/PaBtsnsX5nTuDm7GHlGqZaPNBzT6PSL4FnSE
K6sAEMIerPCYhLyM6P/iilT/RN3q2q6G6V/Hup/oX47DgVPyn3tPH0ZIIVy/wBMb9Rb
e6xyOwA/wXR9eTDoxslgKl0zfPInPmDqsevjWGoEHPHjK8NjwzQCabvYmfn/WhEaMm3
wBh0ZsLdDg==
Date: Fri, 24 Dec 2021 17:42:42 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Jeremy <jlrubin@mit.edu>
Message-ID: <MrhJf_p--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_128950_1490909029.1640364162570"
X-Mailman-Approved-At: Fri, 24 Dec 2021 17:26:31 +0000
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 16:42:47 -0000
------=_Part_128950_1490909029.1640364162570
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Jeremy,
> Wheres the info come from? Well, multiple places. We could get it from a =
third party (maybe using anattestation chain of some sort?), or there are c=
ertain ways it could beself-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 onelousy oracle, so let=E2=80=99s trust M out of N of t=
hem!
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 tra=
des on mainnet or further developed. What difference would OP_CTV make in t=
his project if its implemented in Bitcoin?
https://github.com/p2pderivatives/p2pderivatives-client
https://github.com/p2pderivatives/p2pderivatives-server
https://github.com/p2pderivatives/p2pderivatives-oracle
> Does this NEED CTV?
No, not in particular. Most of this stuff could be done with online signer =
server federation between you and counterparty. CTV makes some stuff nicer =
though, and opens up new possibilities for opening these contracts unilater=
ally.
Nicer? How would unilateral derivatives work because my understanding was t=
hat you always need a peer to take the other side of the trade. I wish we c=
ould discuss this topic in a trading community with some Bitcoiners that ev=
en had some programming knowledge.
Derivatives are interesting and less explored or used in Bitcoin projects. =
They could be useful in solving lot of problems.
--=20
Prayank
A3B1 E430 2298 178F
------=_Part_128950_1490909029.1640364162570
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body>
<div>Hi Jeremy,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">>=
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" target=3D"_blank">powswap</a>).<br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">> 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!<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">https://github.com/p2pderivatives/p2pderivatives-client<br></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">https://github.com/p2pderivat=
ives/p2pderivatives-server<br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">https://github.com/p2pderivatives/p2pderivatives-oracle<br></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">> Does this NEED CTV?<br></di=
v><div dir=3D"auto">No, not in particular. Most of this stuff could be done=
with online signer server federation between you and counterparty. CTV mak=
es some stuff nicer though, and opens up new possibilities for opening thes=
e contracts unilaterally.<br></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">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 wis=
h we could discuss this topic in a trading community with some Bitcoiners t=
hat even had some programming knowledge.<br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Derivatives are interesting and less explored or used =
in Bitcoin projects. They could be useful in solving lot of problems.<br></=
div><div dir=3D"auto"><br></div><div><br></div><div>-- <br></div><div>Praya=
nk<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div> =
</body>
</html>
------=_Part_128950_1490909029.1640364162570--