1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
Return-Path: <chris@suredbits.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 03C0AC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:54:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id D30EB81428
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:54:07 +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: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=suredbits-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id sikh-NJ-qoQ8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:54:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com
[IPv6:2607:f8b0:4864:20::f2f])
by smtp1.osuosl.org (Postfix) with ESMTPS id D623F81425
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:54:06 +0000 (UTC)
Received: by mail-qv1-xf2f.google.com with SMTP id j5so10662238qvs.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 06 Mar 2022 12:54:06 -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=B50l6rtbOXLS53rIwVtndROySrEgrIZpVE52sKt2ntI=;
b=32BdhXGPSJGvNweYAVtc22Dk3n/Eo3Ffsr5MwRd8qpZus1AycBvzzY+4Fdh/Nosgro
4cUAt+W+kJOyDSFPsyBQAhwwRU5jt6JcmY5K84qmU/akuIiZYPOUS+mBuf+WIucJZRFu
9jYZ9dLjO478FNjyT0TpnHoOjI2vQby4A66qJjy1OslJx2dFELpJU0f32jchhFklvEP/
N025yyeTpuyRNpIYt75wfVocWzRaFNTe3Yr+Cko+jufPcN6frTJskjeaMVImWqElUE1F
Ie7cN6abdvBY5HIZuSgVaEArZJdfLpx3I/nlDdLECjImnvUxGcEOG3KT5txSs+ErFtIx
2eJA==
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=B50l6rtbOXLS53rIwVtndROySrEgrIZpVE52sKt2ntI=;
b=LvbtclWCy20f7+K98WbpEIzCCVmoJkKvYrkQRMrLfvzJwS5b7EcrMCTIS3m3sTI72o
Pa9+Kc/rtGnxf+lz1AqNnShpVoMkIv1SpDFLNgJ+tZAjdPtNvI2LJpw9c9NY5aFH9cHt
qlZuR4a8xzLNawcneiXjkdvGh4Yb5rRTc+8w+d/8GWhzZffMrxcqiXhuaTvIxvxiiSbn
V0fifQgErpP9EJrvljowPQg/Ekm1d+cOFOrDJOYUqNJACN6NKRX1XaqJm2HExyaWxM42
dlNKcbGicUEF9juKgwCbYbRou4MB5ngci5ECe7xF+p33gdI4KfzXhgZaH2XG8yF9sDl6
3rXw==
X-Gm-Message-State: AOAM533H6VMGqaj4O00IETEsZNtvJxo1U9tvIpU5PeUs4zW+dlrwcNhT
YUMKu6g/Zv3JytXgU1gaZj4ZGL2hEV/zmZ3UO/5hvA==
X-Google-Smtp-Source: ABdhPJz/s0VNsdONfYRvAl6KJTbJa4MlBc6bMauURhktw+7HOtwNK119roojeqetKJ4ErJjOxXBGSY6jmkscCsghsNA=
X-Received: by 2002:a05:6214:242c:b0:432:b613:bb24 with SMTP id
gy12-20020a056214242c00b00432b613bb24mr6263438qvb.29.1646600045727; Sun, 06
Mar 2022 12:54:05 -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>
<CAFQwNuzimRU=Cz7MGRFoY7=cd2=We+9Q8+neOhS8UjgTamns-Q@mail.gmail.com>
<9yZl_Q0jy6DTD0BLoU-AaGZzHGO53238vIS8t54lGqFa0Rkk6-omZrTvwP3Rq4Yl3mp0krPPANseVFHebvLFw2-wj1FwPJxFSQPYrX6ujv0=@protonmail.com>
In-Reply-To: <9yZl_Q0jy6DTD0BLoU-AaGZzHGO53238vIS8t54lGqFa0Rkk6-omZrTvwP3Rq4Yl3mp0krPPANseVFHebvLFw2-wj1FwPJxFSQPYrX6ujv0=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Sun, 6 Mar 2022 14:53:55 -0600
Message-ID: <CAFQwNuyj_mozs9e=B6qoCywMkeYtL_yEL7=BF8drSYATR3kE7g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000d0242405d992f215"
X-Mailman-Approved-At: Sun, 06 Mar 2022 20:54:44 +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 20:54:08 -0000
--000000000000d0242405d992f215
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=E2=80=99t 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=E2=80=99t get paid when it is NOT being used. If you are offe=
ring
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=E2=80=99s sort of a recurring payment for liquidity as a service, at =
least
that is how I=E2=80=99m 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 th=
e
> fact that multisig requires interactiveness at settlement time. The
> multisig escrow provider needs to know the exact details about the bitcoi=
n
> 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) ju=
st
> issues attestations. Bob or Alice take those attestations and complete th=
e
> 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
>
--000000000000d0242405d992f215
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">FWIW, the initial use case that I hinted at in the OP is =
for lightning.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The probl=
em this company has is they offer an inbound liquidity service, but it is c=
ommon after a user purchases liquidity, the channel goes unused.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">This is bad for the company as the=
ir 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=E2=80=99t 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=E2=80=99t get paid when it i=
s NOT being used. If you are offering liquidity as a service this is bad.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">The user purchasing liqui=
dity 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 sig=
nal that they are no longer interested in the service. That way they can pu=
t their liquidity to use somewhere else that is more productive for the res=
t of the network.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So it=
=E2=80=99s sort of a recurring payment for liquidity as a service, at least=
that is how I=E2=80=99m thinking about it currently.=C2=A0</div><div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar=
6, 2022 at 2:11 PM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com"=
>ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Good morn=
ing Chris,<br>
<br>
> >On the other hand, the above, where the oracle determines *when* t=
he fund can be spent, can also be implemented by a simple 2-of-3, and calle=
d an "escrow".<br>
><br>
> I think something that is underappreciated by protocol developers is t=
he fact that multisig requires interactiveness at settlement time. The mult=
isig escrow provider needs to know the exact details about the bitcoin tran=
saction and needs to issue a signature (gotta sign the outpoints, the fee, =
the payout addresses etc).<br>
><br>
> With PTLCs that isn't the case, and thus gives a UX improvement fo=
r Alice & Bob that are using the escrow provider. The oracle (or escrow=
) just issues attestations. Bob or Alice take those attestations and comple=
te the adaptor signature. Instead of a bi-directional communication require=
ment (the oracle working with Bob or Alice to build the bitcoin tx) at sett=
lement time there is only unidirectional communication required. Non-intera=
ctive settlement is one of the big selling points of DLC style applications=
IMO.<br>
><br>
> One of the unfortunate things about LN is the interactiveness requirem=
ents are very high, which makes developing applications hard (especially mo=
bile applications). I don't think this solves lightning's problems,=
but it is a worthy goal to reduce interactiveness requirements with new bi=
tcoin applications to give better UX.<br>
<br>
Good point.<br>
<br>
I should note that 2-of-3 contracts are *not* transportable over LN, but PT=
LCs *are* transportable.<br>
So the idea still has merit for LN, as a replacement for 2-fo-3 escrows.<br=
>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>
--000000000000d0242405d992f215--
|