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