From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24E9EC0051 for ; Mon, 17 Aug 2020 23:14:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 20938864C1 for ; Mon, 17 Aug 2020 23:14:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsDGVJTI8ywF for ; Mon, 17 Aug 2020 23:14:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by whitealder.osuosl.org (Postfix) with ESMTPS id 0F7108637D for ; Mon, 17 Aug 2020 23:14:12 +0000 (UTC) Date: Mon, 17 Aug 2020 23:14:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1597706050; bh=lwakzhwzO5svncDCBUPl7srtLjCE59xPxYfVaMnl42k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=UDrIGyczWCop9Qu0gw0NywSsA964I9jMeooHsTjbOtD7RVg11CS7o5sgjigTsTByA i2bOlITuvzgP2BOh19MoUEj3PgGGKJSPeLx4/OQ4fKpVLhKnOL4eV8FpIGBEpLNA93 DDhH37I7HYsRSDHDintTtC7/tv2h8Arqf6MRKy1E= To: Thomas Hartman From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] reviving op_difficulty 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: Mon, 17 Aug 2020 23:14:15 -0000 Good morning Thomas, > Tier, AJ, ZmnSCPxj, thanks!=C2=A0 > > > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev wrote: > > > > Taproot MAST to the rescue. > > OK. So, using the tick scheme described by Tier a difficulty futures inst= rument is possible with current script + op_diff; and with taproot + op_dif= f (ZmnSCPxj) it may even be economical. (I will set aside covenants for now= .) > > To do it all on-chain, we need a mechanism for selling such an instrument= in a trustless way. > > That is to say (using ZmnSCPxj's construction), we have now a future wher= e Bob pays Alice a pico-difficulty at next adjustment.=C2=A0 > > But how does Alice pay Bob his 17.4 sat? > > I am trying to figure out a way to do this naively using the base layer. = (I really want this with lightning, and eventually hft, but first things fi= rst.) > > My thinking so far is, Alice and Bob collaborate to create partial versio= ns of > > ** the difficulty future funded by Bob, spendable by Alice in 1000 blocks > ** and a 17.4 sat payment from Alice to Bob, spendable by Bob immediately > > When Bob completes and broadcasts the payment from Alice, it should enabl= e Alice to complete and broadcast the difficulty future funded by Bob.= =C2=A0 > > I am thinking a hash lock on the payment, with a preimage secret generate= d by Bob, could be used to accomplish this. When Bob unlocks and broadcasts= the payment, this reveals the preimage, and with the preimage Alice can un= lock and broadcast the difficulty future funded by Bob.=C2=A0 > > Am I correct in thinking something like this could work? Bitcoin transactions on the blockchain layer are atomic, so it would be far= simpler to make the purchase output and the options output in the same tra= nsaction, in a sort of PayJoin-like cooperatively-signed transaction. That said, the construction you are imagining is indeed going to work. The only requirement is that the hash-branch needs two signatures in order = to ensure that it pays out to a transaction with a very specific contract. Xref. how Lightning *really* creates its HTLCs. Regards, ZmnSCPxj