From: Chris Stewart <chris@suredbits•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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
Date: Sun, 6 Mar 2022 14:53:55 -0600 [thread overview]
Message-ID: <CAFQwNuyj_mozs9e=B6qoCywMkeYtL_yEL7=BF8drSYATR3kE7g@mail.gmail.com> (raw)
In-Reply-To: <9yZl_Q0jy6DTD0BLoU-AaGZzHGO53238vIS8t54lGqFa0Rkk6-omZrTvwP3Rq4Yl3mp0krPPANseVFHebvLFw2-wj1FwPJxFSQPYrX6ujv0=@protonmail.com>
[-- 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 --]
prev parent reply other threads:[~2022-03-06 20:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 12:58 Chris Stewart
2022-03-04 8:22 ` ZmnSCPxj
2022-03-05 14:45 ` Chris Stewart
2022-03-05 22:57 ` ZmnSCPxj
2022-03-06 0:14 ` Jeremy Rubin
2022-03-06 14:05 ` Chris Stewart
2022-03-06 20:11 ` ZmnSCPxj
2022-03-06 20:53 ` Chris Stewart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFQwNuyj_mozs9e=B6qoCywMkeYtL_yEL7=BF8drSYATR3kE7g@mail.gmail.com' \
--to=chris@suredbits$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dlc-dev@mailmanlists$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox