MIME-Version: 1.0
References: <CAFQwNuyqJCRYpCEOUFOS54k-Eu5SrkjhcUzk8-4zYK0tYhvX=A@mail.gmail.com>
 <MhqXmoLUj9JwcnZOETQr9lMMsbR_o75DrOG-v1Fz6FN571n31EgGAJUaSGOvMCSmDBSaI4hjAqtl5mLAWTnOjbWHAaJPzrpl06vhmt5xXSI=@protonmail.com>
In-Reply-To: <MhqXmoLUj9JwcnZOETQr9lMMsbR_o75DrOG-v1Fz6FN571n31EgGAJUaSGOvMCSmDBSaI4hjAqtl5mLAWTnOjbWHAaJPzrpl06vhmt5xXSI=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Sat, 5 Mar 2022 08:45:56 -0600
Message-ID: <CAFQwNuxaphkKbVwFdmRRJ7DX2tqMpvfk=8syuBXTTqJ2qBW9rg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000000cda1705d979b112"
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

--0000000000000cda1705d979b112
Content-Type: text/plain; charset="UTF-8"

Hey ZmnSCPxj,

I thought about this for a few days and I think you are right. In the case
of recurring payments this is identical to nLocktime. When doing recurring
payments with this scheme, you probably want to rate limit subsequent UTXOs
_with_ nlocktimes to make sure a malicious Netflix can't withdraw 12 month
so of subscriptions by attesting with their oracle 12 times.

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.

-Chris

On Fri, Mar 4, 2022 at 2:22 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over just handing over `nLockTime`d transactions?
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div>Hey ZmnSCPxj, <br></div><div><br></div><div>I thought=
 about this for a few days and I think you are right. In the case of recurr=
ing payments this is identical to nLocktime. When doing recurring payments =
with this scheme, you probably want to rate limit subsequent UTXOs _with_ n=
locktimes to make sure a malicious Netflix can&#39;t withdraw 12 month so o=
f subscriptions by attesting with their oracle 12 times.</div><div><br></di=
v><div>I think this proposal describes arbitrary lines of pre-approved cred=
it from a bitcoin wallet. The line can be drawn down with oracle attestatio=
ns. You can mix in locktimes on these pre-approved lines of credit if you w=
ould 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.</di=
v><div><br></div><div>-Chris<br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 4, 2022 at 2:22 AM ZmnSCP=
xj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b=
r>
Good morning Chris,<br>
<br>
Quick question.<br>
<br>
How does this improve over just handing over `nLockTime`d transactions?<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--0000000000000cda1705d979b112--