Date: Sun, 06 Mar 2022 20:11:12 +0000
To: Chris Stewart <chris@suredbits.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9yZl_Q0jy6DTD0BLoU-AaGZzHGO53238vIS8t54lGqFa0Rkk6-omZrTvwP3Rq4Yl3mp0krPPANseVFHebvLFw2-wj1FwPJxFSQPYrX6ujv0=@protonmail.com>
In-Reply-To: <CAFQwNuzimRU=Cz7MGRFoY7=cd2=We+9Q8+neOhS8UjgTamns-Q@mail.gmail.com>
References: <CAFQwNuyqJCRYpCEOUFOS54k-Eu5SrkjhcUzk8-4zYK0tYhvX=A@mail.gmail.com>
 <MhqXmoLUj9JwcnZOETQr9lMMsbR_o75DrOG-v1Fz6FN571n31EgGAJUaSGOvMCSmDBSaI4hjAqtl5mLAWTnOjbWHAaJPzrpl06vhmt5xXSI=@protonmail.com>
 <CAFQwNuxaphkKbVwFdmRRJ7DX2tqMpvfk=8syuBXTTqJ2qBW9rg@mail.gmail.com>
 <1ICs_kG6Eloiy6E4yLUkdFUI4EqKtaRPqcIY5kOM8Pq1xdWQHAMsMUxFsQ0xw2RcdMoMfxJSmlhb_ilXaw_nESliKxlE_Xp5tchQxXKD58E=@protonmail.com>
 <CAFQwNuzimRU=Cz7MGRFoY7=cd2=We+9Q8+neOhS8UjgTamns-Q@mail.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>,
 "dlc-dev@mailmanlists.org" <dlc-dev@mailmanlists.org>
Subject: Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs
Precedence: list

Good morning Chris,

> >On the other hand, the above, where the oracle determines *when* the fun=
d can be spent, can also be implemented by a simple 2-of-3, and called an "=
escrow".
>
> I think something that is underappreciated by protocol developers is the =
fact that multisig requires interactiveness at settlement time. The multisi=
g escrow provider needs to know the exact details about the bitcoin transac=
tion and needs to issue a signature (gotta sign the outpoints, the fee, the=
 payout addresses etc).
>
> With PTLCs that isn't the case, and thus gives a UX improvement for Alice=
 & Bob that are using the escrow provider. The oracle (or escrow) just issu=
es attestations. Bob or Alice take those attestations and complete the adap=
tor signature. Instead of a bi-directional communication requirement (the o=
racle working with Bob or Alice to build the bitcoin tx) at settlement time=
 there is only unidirectional communication required. Non-interactive settl=
ement is one of the big selling points of DLC style applications IMO.
>
> One of the unfortunate things about LN is the interactiveness requirement=
s are very high, which makes developing applications hard (especially mobil=
e applications). I don't think this solves lightning's problems, but it is =
a worthy goal to reduce interactiveness requirements with new bitcoin appli=
cations to give better UX.

Good point.

I should note that 2-of-3 contracts are *not* transportable over LN, but PT=
LCs *are* transportable.
So the idea still has merit for LN, as a replacement for 2-fo-3 escrows.

Regards,
ZmnSCPxj