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
|
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3413BC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Feb 2022 17:56:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 1CDE5813EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Feb 2022 17:56:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.077
X-Spam-Level:
X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1,
FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 TGk0YzcTRF59
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Feb 2022 17:56:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
[IPv6:2a00:1450:4864:20::231])
by smtp1.osuosl.org (Postfix) with ESMTPS id 6748A8137F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Feb 2022 17:56:25 +0000 (UTC)
Received: by mail-lj1-x231.google.com with SMTP id t14so16525309ljh.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 06 Feb 2022 09:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:cc;
bh=YgJul6DS5/hoDP8Qk9WJvUr2aedF83cau4AwKEBYylI=;
b=fRDeUUxujfk7UVTiDecfN/NMAAgwHUr3VlfrCsCsDJrSc0bPgD8Pm89TEUNC/LH6Wa
j8utxSjZi+cN0xkUvZO0xGphkBB0DnhurOTbKyTG6+QxqZTRKSPLkzWUSngvZz+bOb+f
SjoyS2c9AWav508VihNXa9W9cRX8OuihS7chEGJk5B3dg0xoqsaD1PgWdl0DH5n3sfXP
8CR6NVffUTronZnN450TNnFp4rfOa4U+s2h2BqbnaoEYe8SO0kqK+ZMQM5XTL3CuVgMJ
YNSCVHqWsTi1onwPH5aRhjcVVKQDWRi9EKPJGCTTiZH9sb4aTQ3mld3OaGiSiNpMoYly
1MuA==
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:cc;
bh=YgJul6DS5/hoDP8Qk9WJvUr2aedF83cau4AwKEBYylI=;
b=1ijU2lEpQ7aj/32Mb9zPynXCciPKpCl1LRRRhy1uZZaRL3P4dnzQC67FRHLoSREItG
gysjIw/dcw/1OS4AhNwyvN5C5v93YvMBtz2frQEbcKBqImroSo+sRNJbq4hPwE1dRqWs
/5CfFGXuFp4B9HxePmGgNNRO25l81Rmxmews1rZl6R4aPX20KVt4buM0M0DD3PQJoI0z
sN3I6MDkUEppcGYG4uB/ScPBqPrdGRmxZgWtU6UM1+haJm5M4USHBMNYO29kO2mPqZLl
FOlE+8BkcmwOk0faTn4RB106NfJEif0MwmHMbgSdgzGe7p1qCQjwb+otItfPEJQU8J5o
gZ9g==
X-Gm-Message-State: AOAM531mWKKGzu+rplFSeK2YIpjiyI3DBlrvdxGeLAQnzB8zklxODJmM
8FMqm1QB1N8DpQD4CSPfCkE8DdRCY3Qdfxi2wnb6f9yNEmw=
X-Received: by 2002:a2e:9e82:: with SMTP id f2mt1855957ljk.57.1644170182885;
Sun, 06 Feb 2022 09:56:22 -0800 (PST)
MIME-Version: 1.0
References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
<CAD5xwhiJiopwH87Bn+yq_0-XXSJYOtNzUg4JCaYwuj=oo9CacA@mail.gmail.com>
<CAH5Bsr1d0_xaVW59i+pzKtU2yb1FFMG7CJZgTueJwEO7XmkdYw@mail.gmail.com>
In-Reply-To: <CAH5Bsr1d0_xaVW59i+pzKtU2yb1FFMG7CJZgTueJwEO7XmkdYw@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Sun, 6 Feb 2022 09:56:12 -0800
Message-ID: <CAD5xwhhL_+wdUboJZ6i-WvJou7LQHq043ELr1ogOq5OH12iuNQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b4f78d05d75d3321"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
dlc-dev@mailmanlists.org
Subject: Re: [bitcoin-dev] CTV dramatically improves 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 Feb 2022 17:56:26 -0000
--000000000000b4f78d05d75d3321
Content-Type: text/plain; charset="UTF-8"
I'm not sure what is meant concretely by (5) but I think overall
performance is ok here. You will always have 10mins or so to confirm the
DLC so you can't be too fussy about performance!
I mean that if you think of the CIT points as being the X axis (or
independent axes if multivariate) of a contract, the Y axis is the
dependent variable represented by the CTV hashes.
For a DLC living inside a lightning channel, which might be updated between
parties e.g. every second, this means you only have to recompute the
cheaper part of the DLC only if you update the payoff curves (y axis) only,
and you only have to update the points whose y value changes.
For on chain DLCs this point is less relevant since the latency of block
space is larger.
--000000000000b4f78d05d75d3321
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div style=3D"color:rgb(80,0,80);font-size:12.8px" dir=3D=
"auto"><div dir=3D"auto" class=3D"elided-text"><blockquote style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"elided-text"><div>I'm not sure what is m=
eant concretely by (5) but I think overall performance is ok here. You will=
always have 10mins or so to confirm the DLC so you can't be too fussy =
about performance!<br></div></div></div></blockquote></div><div dir=3D"auto=
"><br></div></div><div dir=3D"auto" style=3D"font-size:12.8px">I mean that =
if you think of the CIT points as being the X axis (or independent axes if =
multivariate) of a contract, the Y axis is the dependent variable represent=
ed by the CTV hashes.=C2=A0</div><div dir=3D"auto" style=3D"font-size:12.8p=
x"><br></div><div dir=3D"auto" style=3D"font-size:12.8px"><br></div><div di=
r=3D"auto" style=3D"font-size:12.8px">For a DLC living inside a lightning c=
hannel, which might be updated between parties e.g. every second, this mean=
s you only have to recompute the cheaper part of the DLC only if you update=
the payoff curves (y axis) only, and you only have to update the points wh=
ose y value changes.</div><div dir=3D"auto" style=3D"font-size:12.8px"><br>=
</div><div dir=3D"auto" style=3D"font-size:12.8px">For on chain DLCs this p=
oint is less relevant since the latency of block space is larger.=C2=A0</di=
v></div>
--000000000000b4f78d05d75d3321--
|
