From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 864DFC0051 for ; Mon, 17 Aug 2020 19:48:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6DDD586FE7 for ; Mon, 17 Aug 2020 19:48:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAaDpRiNky9h for ; Mon, 17 Aug 2020 19:48:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by hemlock.osuosl.org (Postfix) with ESMTPS id A7B2586F85 for ; Mon, 17 Aug 2020 19:48:32 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id dd12so8410733qvb.0 for ; Mon, 17 Aug 2020 12:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CwTeo0YYaIBXwo3rshdpFHw6+6dI95iY1larYO/+/WA=; b=s/RsSln6lHR+iplMBcAkOW+lMtgkEkmK23Jw08MgGttox7zn+E7CKxp4QBdBv09eiF Ygt/AK/xT5AxVtZQ2Ol2peg1Xkj30kcOsohw6M1jFURZQvxyyUfKY7FkTwW/rHgaTQpz QE08BFzARXJfdIJjzkvz7922b1fVcdxlT8l3uiPe+dyOB98cpG/UbGPKxdYr8x7Qqn+p wehnBrDyHm6FpLNcVTuLNfOJ2CCuZXC8fBlZbweVB0I2RPX2mYuWIJYmXNPlnoyuulf0 gQ98mwVRdPvbdnCLNN11wlKaMMJ3PsPDLVX8AyIP/sqBOzql/KuE2OgykPE0WrvTVEh7 5TCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CwTeo0YYaIBXwo3rshdpFHw6+6dI95iY1larYO/+/WA=; b=onmbvXjbbEVYwQza4iwL5bp72GI9zDpfOC4KMK2IEGqybm+/9NbOJ2mQSu9viIoKtH S3tLpY0JHTQE5tiEFUuUepIQ1k3PfWFqAnSGbmzNmq8rACRH9Pd7Bcf6KOxwLkvxfMPN ytkhiPhxgOVhUhcL8uB//NLmF+dszWSNfGOsODsqFYIbhhZ2u34Hg8xi4ahWlopODGcF e7EY10bdcyD3DH74DmahJrz3COqkse43cu+Wg8wNn2JXlSR6E3lAPs4H+ChUtUNP8Osq 9poTMkxsEPjRFnpWzPHwa2PxzdX1Aqx1pnxLQF3ovfVSr/x5d8rAxoK/uthkD0EfTIRR +EIw== X-Gm-Message-State: AOAM531KTgvczjISu223c6Ah03NYIUpN8xs7VrZDGcTd3UVPIrGuvYc2 yfsP85DqbdjhvN5sUGhDBmQSzglkq/ZOrwcZ X-Google-Smtp-Source: ABdhPJwpYz4JEzG18l0XFEYjdtDamjZ8pb6kD1wYv5/MIfRnP4VYe292icI0VDH/A6FyC9aNv45QVw== X-Received: by 2002:a0c:ea8e:: with SMTP id d14mr15483609qvp.37.1597693711183; Mon, 17 Aug 2020 12:48:31 -0700 (PDT) Received: from [192.168.43.187] ([172.58.4.53]) by smtp.gmail.com with ESMTPSA id l29sm20904603qtu.88.2020.08.17.12.48.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 12:48:30 -0700 (PDT) From: Thomas Hartman Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_51DB0917-DA60-4717-919A-BD881916EF17" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 17 Aug 2020 15:48:27 -0400 In-Reply-To: To: Bitcoin Protocol Discussion References: X-Mailer: Apple Mail (2.3445.9.1) X-Mailman-Approved-At: Mon, 17 Aug 2020 19:53:14 +0000 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 19:48:33 -0000 --Apple-Mail=_51DB0917-DA60-4717-919A-BD881916EF17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tier, AJ, ZmnSCPxj, thanks!=20 > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev = wrote: >=20 > Taproot MAST to the rescue. OK. So, using the tick scheme described by Tier a difficulty futures = instrument is possible with current script + op_diff; and with taproot + = op_diff (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 = where Bob pays Alice a pico-difficulty at next adjustment.=20 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 = first.) My thinking so far is, Alice and Bob collaborate to create partial = versions 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 = enable Alice to complete and broadcast the difficulty future funded by = Bob.=20 I am thinking a hash lock on the payment, with a preimage secret = generated 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 unlock and broadcast the difficulty future funded by Bob.=20 Am I correct in thinking something like this could work? =20= --Apple-Mail=_51DB0917-DA60-4717-919A-BD881916EF17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tier,= AJ, ZmnSCPxj, thanks! 

On Aug 17, 2020, at 1:04 AM, = ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Taproot MAST to the = rescue.

OK. So, using the tick scheme described by Tier a difficulty = futures instrument is possible with current script + op_diff; and with = taproot + op_diff (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 where Bob pays Alice a = pico-difficulty at next adjustment. 

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

My = thinking so far is, Alice and Bob collaborate to create partial versions = 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 enable Alice to complete and broadcast the = difficulty future funded by Bob. 

I am thinking a hash lock on the = payment, with a preimage secret generated 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 unlock and = broadcast the difficulty future funded by Bob. 

Am I correct in thinking = something like this could work?  
= --Apple-Mail=_51DB0917-DA60-4717-919A-BD881916EF17--