Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 046E0C0012 for ; 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 ; 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 ; 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 ; 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 To: Jeremy Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ). > 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
Hi Jeremy,

>= 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 powswap).

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

https://github.com/p2pderivatives/p2pderivatives-client
=

https://github.com/p2pderivat= ives/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 mak= es some stuff nicer though, and opens up new possibilities for opening thes= e 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 wis= h we could discuss this topic in a trading community with some Bitcoiners t= hat 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.


--
Praya= nk

A3B1 E430 2298 178F
= ------=_Part_128950_1490909029.1640364162570--