From: Thomas Hartman <thomashartman1@gmail.com>
Message-Id: <C7C0864D-5635-43B8-88B6-E53A14C3066C@gmail.com>
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: <Y9rFseQ13QJ0TspORM_a542mUib8lJV2IiDe8GXS5SrxkvXbVI13MfbgGqVoSVftumcYNBBKut6Fz840ehS5VfvF2AsO_qNTyzvs6tTCpBk=@protonmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
 <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com>
 <Y9rFseQ13QJ0TspORM_a542mUib8lJV2IiDe8GXS5SrxkvXbVI13MfbgGqVoSVftumcYNBBKut6Fz840ehS5VfvF2AsO_qNTyzvs6tTCpBk=@protonmail.com>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Precedence: list


--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 =
<bitcoin-dev@lists.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Tier,=
 AJ, ZmnSCPxj, thanks!&nbsp;<br class=3D""><div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div class=3D"">On Aug 17, 2020, at 1:04 AM, =
ZmnSCPxj via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">Taproot MAST to the =
rescue.</span></div></blockquote></div><br class=3D""><div class=3D""><div=
 class=3D"">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.)</div><div class=3D""><br class=3D""></div><div =
class=3D"">To do it all on-chain, we need a mechanism for selling such =
an instrument in a trustless way.</div><div class=3D""><br =
class=3D""></div><div class=3D"">That is to say (using ZmnSCPxj's =
construction), we have now a future where Bob pays Alice a =
pico-difficulty at next adjustment.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">But how does Alice pay Bob his 17.4 =
sat?</div><div class=3D""><br class=3D""></div><div class=3D"">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.)</div><div class=3D""><br class=3D""></div><div class=3D"">My =
thinking so far is, Alice and Bob collaborate to create partial versions =
of</div><div class=3D""><br class=3D""></div><div class=3D"">** the =
difficulty future funded by Bob, spendable by Alice in 1000 =
blocks</div><div class=3D"">** and a 17.4 sat payment from Alice to Bob, =
spendable by Bob immediately</div><div class=3D""><br =
class=3D""></div><div class=3D"">When Bob completes and broadcasts the =
payment from Alice, it should enable Alice to complete and broadcast the =
difficulty future funded by Bob.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.&nbsp;</div><div =
class=3D""><br class=3D""></div><div class=3D"">Am I correct in thinking =
something like this could work? &nbsp;</div></div></body></html>=

--Apple-Mail=_51DB0917-DA60-4717-919A-BD881916EF17--