Date: Mon, 17 Aug 2020 23:14:00 +0000
To: Thomas Hartman <thomashartman1@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bc0SG26C9FUzZO4l9cGDtbBGb0lrhsxrcvDoJXpJGUbyKEUq3eE3vLwTu_WufWOsN6DK3lPcKttNdEa9h7_tqixk12sBVErMi0YYF_HNBGo=@protonmail.com>
In-Reply-To: <C7C0864D-5635-43B8-88B6-E53A14C3066C@gmail.com>
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
 <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com>
 <Y9rFseQ13QJ0TspORM_a542mUib8lJV2IiDe8GXS5SrxkvXbVI13MfbgGqVoSVftumcYNBBKut6Fz840ehS5VfvF2AsO_qNTyzvs6tTCpBk=@protonmail.com>
 <C7C0864D-5635-43B8-88B6-E53A14C3066C@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Precedence: list

Good morning Thomas,

> Tier, AJ, ZmnSCPxj, thanks!=C2=A0
>
> > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> 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