[bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]

DLCs are typically thought to be used for betting. Alice & Bob want to
speculate on an event, and have bitcoin payouts rewarded to them if they
bet correctly. The oracle determines what event occurred and produces
attestations representing that outcome.

Recently I had a conversation with a friend about implementing recurring
subscriptions with Discreet Log Contracts. At a high level, you should
think about this working like ACH. If you are purchasing a subscription
from Netflix, they will deduct $20 from your bank account every month. To
do this, you give them your credit card information.

You can do this with Discreet Log Contracts. It requires a slightly
modified DLC setup. Netflix would create an oracle representing a monthly
subscription. They require that users setup DLCs to them that will be
executed at the end of the month. Alice, a subscriber to Netflix, creates a
unilaterally funded DLC to Netflix. She creates adaptor signatures for her
payment and sends them to Netflix.

No bitcoin transaction is required to create this subscription since the
DLC is unilaterally funded. Alice can “cancel” the subscription at any time
by spending from the utxo she is using to fund the DLC.

At the end of the month, Netflix attests that it is time to charge Alice
for her subscription. Netflix takes its own attestation and decrypts
Alice’s adaptor signature to get her signature to send funds to Netflix.
Netflix publishes the settlement transaction for the DLC which pays Netflix
it’s subscription fee for the next month. Netflix also publishes a new
announcement for next month so that Alice can create a new DLC subscription.

Netflix needs to give Alice a bitcoin address to pay to.

The information Alice is required to send Netflix is


   1.

   Her utxo used to fund the DLC
   2.

   Her adaptor signature representing her monthly subscription to netflix.


Netflix must verify the adaptor signatures are correct and the utxo exists.

Why is this useful?

It's very convenient for a user to give access to withdraw a certain amount
of money from a bank account at a given time in the future. This is how
recurring payments work in tradfi. This brings the same principle to
bitcoin payments.

DLCs also give you the power to specify how much the service can withdraw.
For instance, with Netflix, they shouldn’t have the ability to withdraw
thousands of dollars worth of bitcoin. The monthly service fee is $20. With
DLCs, you can cryptographically enforce that they will only receive $20.
They cannot withdraw more or less money than they are authorized to.

There may be concerns about Netflix being both the oracle and the entity
receiving a monthly payment. I would argue this is mitigated by the fact
that the service provider could steal at most one months worth of service
fees for users of the subscription. After users get scammed once, they will
cancel their future subscription and distrust the service. The key feature
is the amount of money in the subscription is predetermined, thus the
oracle cannot withdraw excess funds if they are evil.

### QA

Does the DLC use a 2 of 2 multisig between Netflix and Alice?

No, the DLC is unilaterally funded by Alice. This allows her to create the
subscription without an onchain transaction, and also allows her to cancel
the subscription at any time. She cancels the subscription by double
spending the utxo.

Can Netflix steal all the money in the funding output?

No, Alice’s adaptor signatures allow Netflix to withdraw a specific amount
of bitcoin. The change is sent back to an address Alice controls. Both of
these outputs are protected by the adaptor signature.

Is there a perverse incentive for Netflix to be the oracle and receive the
subscription?

The most Netflix can steal in this setup is one months worth of
subscription fees across the entire customer base. In this setup, Alice is
accepting that risk for the convenience of auto withdrawals from her
bitcoin wallet. Remember, Alice can cancel the subscription at any time she
wants by spending from the funding utxo.

[-- Attachment #2: Type: text/html, Size: 12281 bytes --]

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[ZmnSCPxj]

Good morning Chris,

Quick question.

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


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 1386 bytes --]

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[ZmnSCPxj]

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

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Jeremy Rubin]

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

This may be of interest:

https://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py

Basically, a (old, python) sapio contract whereby you can make cancellable
subscriptions that are essentially a time based autopay scheme whereby
cancellation gives time for the receiver to claim the correct amount of
money.

--
@JeremyRubin <https://twitter.com/JeremyRubin>

On Sat, Mar 5, 2022 at 10:58 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3792 bytes --]

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

>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
>

[-- Attachment #2: Type: text/html, Size: 3551 bytes --]

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[ZmnSCPxj]

Good morning Chris,

> >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.

Good point.

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

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

FWIW, the initial use case that I hinted at in the OP is for lightning.

The problem this company has is they offer an inbound liquidity service,
but it is common after a user purchases liquidity, the channel goes unused.

This is bad for the company as their liquidity is tied up in unproductive
channels. The idea was to implement a monthly service fee that requires the
user to pay a fixed amount if the channel isn’t being used. This
compensates the company for the case where their liquidity is NOT being
used. With standard lightning fees, you only get paid when liquidity is
used. You don’t get paid when it is NOT being used. If you are offering
liquidity as a service this is bad.

The user purchasing liquidity can make the choice to pay the liquidity fee,
or not to pay it. In the case where a user does not pay the fee, the
company can take this as a signal that they are no longer interested in the
service. That way they can put their liquidity to use somewhere else that
is more productive for the rest of the network.

So it’s sort of a recurring payment for liquidity as a service, at least
that is how I’m thinking about it currently.

On Sun, Mar 6, 2022 at 2:11 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Chris,
>
> > >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.
>
> Good point.
>
> I should note that 2-of-3 contracts are *not* transportable over LN, but
> PTLCs *are* transportable.
> So the idea still has merit for LN, as a replacement for 2-fo-3 escrows.
>
> Regards,
> ZmnSCPxj
>

[-- Attachment #2: Type: text/html, Size: 3457 bytes --]