path: root/83/3108b28f29ff491444e1a85fd6c15ec27f249d

Return-Path: <chris@suredbits.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 25645C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 14:05:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0D27260A70
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 14:05:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=suredbits-com.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id mnD6s4s5Jaoa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 14:05:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com
 [IPv6:2607:f8b0:4864:20::f2e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id ACFFD60669
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 14:05:37 +0000 (UTC)
Received: by mail-qv1-xf2e.google.com with SMTP id eq14so4293368qvb.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Mar 2022 06:05:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=suredbits-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=DM/V+Z+OYOFHnG2cp5zO7vkYnvt3v4pC64eIo6BoVsk=;
 b=OSF6PbWtT22WgqoZFf7S6/b5ex9zcle3qQB79G20fFCPzxTufBCokdaINwya+NXygH
 Sb7DWtmjY61DcK3FTWrPIszunwZwrmeHLsD7+2G/9dp03D59kIq7xfm6L8JkAWwTxdL2
 K+tfxbyuuW9qK3Vj7kG+gY062D/lnyIUAlFHXY9e/bm4DV3ep3XKSRfRo0CxpmSJkLDZ
 p9DRR6GkFlwUOIHFe4EC9b7EKiTMlvMwLl8A5cbKYnR1hnDy2t/NUUDZsVlTElMm9yf0
 INZJeXHvT3omyjR6zyc8/q0CU5nnWDhvb1Qx9/R6ZvzBfsi+Mn+kKodVtx0s0Z42mHCf
 XRXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=DM/V+Z+OYOFHnG2cp5zO7vkYnvt3v4pC64eIo6BoVsk=;
 b=JYOR9m5WFSKTR6gN6iLAok+xwFF0QrKZFmTPX6v5nHBFWFloWL4TV1+xcpCTtVKlLJ
 /wK+EGfplxZ+SOUBa0zPyacS0sNjvilHVpta/AkhrbHfWDmtbXBndRsSZRp1+B2m2OJY
 OaNEQ9vGDwdEqfZPjObc19DSsghJ/nGBNC6/2Uqys0LmyltwQMlvYoueZDeMBSRlu9SN
 VgW56EIT6cKXs6IP3fJ+1X/bEVgFqsgRK6+Kq/o/vLTshD506cCfoRi6DK4IgRMooq9M
 IJ0TA1QBv4fAAxanXowAFMxT3W2ogZJeXMEjPbvNFIKlD9UxW9rCMOL/qOFXsqG7wci3
 o65Q==
X-Gm-Message-State: AOAM532EBvbir2B1NFiHd5JCcBl8bd3OmDaE9ZaF4ONwjO2UCBlVuWQ3
 YYzwdwwHOuYDpWxsKJx0C+O2+7Of+lKVrtoc/RPSIav9Id8=
X-Google-Smtp-Source: ABdhPJz5USaOZNYlfMpkCnnfv1OCtNegtxelHVOrPsnT8O8S8B0COg8MVOJoaxjj1dF8liJ8atxl8nDTIQ8j504u5RI=
X-Received: by 2002:a05:6214:ca1:b0:432:eee0:1c1 with SMTP id
 s1-20020a0562140ca100b00432eee001c1mr5504867qvs.46.1646575536340; Sun, 06 Mar
 2022 06:05:36 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <1ICs_kG6Eloiy6E4yLUkdFUI4EqKtaRPqcIY5kOM8Pq1xdWQHAMsMUxFsQ0xw2RcdMoMfxJSmlhb_ilXaw_nESliKxlE_Xp5tchQxXKD58E=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Sun, 6 Mar 2022 08:05:25 -0600
Message-ID: <CAFQwNuzimRU=Cz7MGRFoY7=cd2=We+9Q8+neOhS8UjgTamns-Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f0984805d98d3d4d"
X-Mailman-Approved-At: Sun, 06 Mar 2022 14:15:11 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Mar 2022 14:05:39 -0000

--000000000000f0984805d98d3d4d
Content-Type: text/plain; charset="UTF-8"

>On the other hand, the above, where the oracle determines *when* the fund
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
multisig escrow provider needs to know the exact details about the bitcoin
transaction 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 issues
attestations. Bob or Alice take those attestations and complete the adaptor
signature. Instead of a bi-directional communication requirement (the
oracle working with Bob or Alice to build the bitcoin tx) at settlement
time there is only unidirectional communication required. Non-interactive
settlement is one of the big selling points of DLC style applications IMO.

One of the unfortunate things about LN is the interactiveness requirements
are very high, which makes developing applications hard (especially mobile
applications). I don't think this solves lightning's problems, but it is a
worthy goal to reduce interactiveness requirements with new bitcoin
applications to give better UX.

-Chris

On Sat, Mar 5, 2022 at 4:57 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-approved credit
> from a bitcoin wallet. The line can be drawn down with oracle attestations.
> You can mix in locktimes on these pre-approved lines of credit if you would
> like to rate limit, or ignore rate limiting and allow the full utxo to be
> spent by the borrower. It really is contextual to the use case IMO.
>
> Ah, that seems more useful.
>
> Here is an example application that might benefit from this scheme:
>
> I am commissioning some work from some unbranded workperson.
> I do not know how long the work will take, and I do not trust the
> workperson to accurately tell me how complete the work is.
> However, both I and the workperson trust a branded third party (the
> oracle) who can judge the work for itself and determine if it is complete
> or not.
> So I create a transaction whose signature can be completed only if the
> oracle releases a proper scalar and hand it over to the workperson.
> Then the workperson performs the work, then asks the oracle to judge if
> the work has been completed, and if so, the work can be compensated.
>
> On the other hand, the above, where the oracle determines *when* the fund
> can be spent, can also be implemented by a simple 2-of-3, and called an
> "escrow".
> After all, the oracle attestation can be a partial signature as well, not
> just a scalar.
> Is there a better application for this scheme?
>
> I suppose if the oracle attestation is intended to be shared among
> multiple such transactions?
> There may be multiple PTLCs, that are triggered by a single oracle?
>
> Regards,
> ZmnSCPxj
>

--000000000000f0984805d98d3d4d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;On the other hand, the above, where the oracle de=
termines *when* the=20
fund can be spent, can also be implemented by a simple 2-of-3, and=20
called an &quot;escrow&quot;.</div><div><br></div><div>I think something th=
at is underappreciated by protocol developers is the fact that multisig req=
uires interactiveness at settlement time. The multisig escrow provider need=
s to know the exact details about the bitcoin transaction and needs to issu=
e a signature (gotta sign the outpoints, the fee, the payout addresses etc)=
. <br></div><div><br></div><div>With PTLCs that isn&#39;t the case, and thu=
s gives a UX improvement for Alice &amp; Bob that are using the escrow prov=
ider. The oracle (or escrow) just issues attestations. Bob or Alice take th=
ose attestations and complete the adaptor signature. Instead of a bi-direct=
ional communication requirement (the oracle working with Bob or Alice to bu=
ild the bitcoin tx) at settlement time there is only unidirectional communi=
cation required. Non-interactive settlement is one of the big selling point=
s of DLC style applications IMO.</div><div><br></div><div>One of the unfort=
unate things about LN is the interactiveness requirements are very high, wh=
ich makes developing applications hard (especially mobile applications). I =
don&#39;t think this solves lightning&#39;s problems, but it is a worthy go=
al to reduce interactiveness requirements with new bitcoin applications to =
give better UX.<br></div><div><br></div><div>-Chris<br></div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 5,=
 2022 at 4:57 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">Zm=
nSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Good morning Chris,<br>
<br>
&gt; I think this proposal describes arbitrary lines of pre-approved credit=
 from a bitcoin wallet. The line can be drawn down with oracle attestations=
. You can mix in locktimes on these pre-approved lines of credit if you wou=
ld like to rate limit, or ignore rate limiting and allow the full utxo to b=
e spent by the borrower. It really is contextual to the use case IMO.<br>
<br>
Ah, that seems more useful.<br>
<br>
Here is an example application that might benefit from this scheme:<br>
<br>
I am commissioning some work from some unbranded workperson.<br>
I do not know how long the work will take, and I do not trust the workperso=
n to accurately tell me how complete the work is.<br>
However, both I and the workperson trust a branded third party (the oracle)=
 who can judge the work for itself and determine if it is complete or not.<=
br>
So I create a transaction whose signature can be completed only if the orac=
le releases a proper scalar and hand it over to the workperson.<br>
Then the workperson performs the work, then asks the oracle to judge if the=
 work has been completed, and if so, the work can be compensated.<br>
<br>
On the other hand, the above, where the oracle determines *when* the fund c=
an be spent, can also be implemented by a simple 2-of-3, and called an &quo=
t;escrow&quot;.<br>
After all, the oracle attestation can be a partial signature as well, not j=
ust a scalar.<br>
Is there a better application for this scheme?<br>
<br>
I suppose if the oracle attestation is intended to be shared among multiple=
 such transactions?<br>
There may be multiple PTLCs, that are triggered by a single oracle?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000f0984805d98d3d4d--