From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 523D4C000B for ; Sat, 5 Mar 2022 14:46:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3C115408F7 for ; Sat, 5 Mar 2022 14:46:10 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=suredbits-com.20210112.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT1dtkPzxmJC for ; Sat, 5 Mar 2022 14:46:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7B698408F4 for ; Sat, 5 Mar 2022 14:46:09 +0000 (UTC) Received: by mail-qt1-x82c.google.com with SMTP id s15so9780531qtk.10 for ; Sat, 05 Mar 2022 06:46:09 -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=vLOLT/nFCPu/1SoUdDdTD92dsvYbfkAgmHFufM8Uq2s=; b=mCLrnUTtT/NJosRKDj8mzvsoS58U3JUOxEWx0u37EOjzDidcrszSjRCFZW4LXtlNkv Y7j3RldeAvIOGbjdlkK1CWCf1nxphj6TODAYcn4+/n5kcBzgU6XbprbIukq9C74eJWBu EK3anXgRVaPG4TFgd1QhqWPEiA/biyu5qR4W+yL8fh97NhzLcitiDCShHaSDLxklOoCz CoiqW3+sybmIKvwRuF5Ec0FoRDB9/NVOpJxSO6lkmvau4NL7YJ6qdasHsM5NVyDTtcPG HKYXO1DGmEgyEQaMoeZGh3jgkDFtzpVmQlY/WaoWis5lQHFmW8OFJlDY6Odvy3/x4VnB 16uA== 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=vLOLT/nFCPu/1SoUdDdTD92dsvYbfkAgmHFufM8Uq2s=; b=ABifHl7MrYfv1aJR9TxoEyFDDADlYw6XT0fpLWTbiNwmL9nBpfY6MBr7skHw1JNApM uLE85Vdk0F2UBbtfeNwyB++WtPz9rUag/MZYiXcIYcD1DmWK/pQ/ZNw6lQL+H1/3TGL1 5cZmvPXoaCBV1IuFiyGew39iEAaRM2v1+gFewbI8fDytSvvYjgYrhRUBoT05R1WaTrrZ cU78HbOontVAXwcG078S4CLMB7f2nwGsTkF8CkC8LExMsD9TyQaQYF8oRnFI6F8s5smb L6XbKhJ3v+nxPA0Va3fFooeAmbH9jWq5B97THSGplG0xy7CO0IHmw3p3+onsicH8o6YK As9g== X-Gm-Message-State: AOAM530JAre/ayoMAZ6pxfre6hhrr+If1WRssE6nB16vG2r6pwghjfBD /Z3NNRhKPDvuNSI8Hpr5HzSy6ehDKW4TrxC6YjwsNw== X-Google-Smtp-Source: ABdhPJwJHvkBr1Ea0E0XIJnvuTVJaqbI6Kg5/ZqHlVGbyM8JPz+EhEUzqXs7tduRIKxE+wZBNNfWnKTm5tBUpODygNw= X-Received: by 2002:ac8:4e46:0:b0:2cf:942e:518c with SMTP id e6-20020ac84e46000000b002cf942e518cmr3061514qtw.68.1646491568228; Sat, 05 Mar 2022 06:46:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Stewart Date: Sat, 5 Mar 2022 08:45:56 -0600 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000000cda1705d979b112" X-Mailman-Approved-At: Sat, 05 Mar 2022 15:52:48 +0000 Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2022 14:46:10 -0000 --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 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
Hey ZmnSCPxj,

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't withdraw 12 month so o= f subscriptions by attesting with their oracle 12 times.

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.

-Chris

=
On Fri, Mar 4, 2022 at 2:22 AM ZmnSCP= xj <ZmnSCPxj@protonmail.com> wrote:
Good morning Chris,

Quick question.

How does this improve over just handing over `nLockTime`d transactions?


Regards,
ZmnSCPxj
--0000000000000cda1705d979b112--