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
|
Return-Path: <darosior@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1CD14C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Mar 2022 12:07:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 043484058D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Mar 2022 12:07:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kY5ForR_wSXo
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Mar 2022 12:06:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp2.osuosl.org (Postfix) with ESMTPS id 3065E40447
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Mar 2022 12:06:58 +0000 (UTC)
Date: Mon, 21 Mar 2022 12:06:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1647864415;
bh=pU51Y3R2iqrVs/yyWZSTOepdUnlyAURFNYCEJx6gnQg=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=V8ewehXnE/DtI8oMVDhc3b6/K3q/U2rFjguoedcD8PwmpBUAXIYtsRU01rsBBZGuq
lZL+W8Rn/Evvbica9fhsxLazII7s6Rr9uhO2TEScA/dil12h5gt16tqXybTsQUJ8Ki
KPJiTQ04g4QQbgNpwjeMyggwMnWC3ehFhlxw25RGPLFfG0+i0LOjxjkKuy7qAiIIGc
1KPYegt2bNSEzZoizNQAa8naxSWIebu0esccxEvLBn4vV0ZuJJaB+Tw7FSxZ6diQvr
0WK5J69NFZV4xd1bjjiumBUVpuq35gI0E2qcvnLVCc5PX5EP5FIVyqpNJzrvguSLws
46JsUAnf6y6ZQ==
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <pTzeaeIYoCFWgzqTjyTxuy7Uc9v-H9jTRFhVrxiSUb2OJtBYgRgHXy--RGQhn563NpmcuFnoz4izEgeinQaUgU8kgGJqws_d6KEAyUlyn-0=@protonmail.com>
In-Reply-To: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com>
References: <Udzkz8ZPM4na6yNcGnINLCskodTve66hhpoXevwYuVVgfWfbJnLH70Btmp_dmvk8X8sNXqywBVviG3OzFzeoXQanPb8KkWNGjKG2mxxDsAo=@protonmail.com>
<CAD5xwhgoxMnGpwn=4Ww_ZWP+ViZabvcxUV_n5=sXFdCwSe6-Mw@mail.gmail.com>
<QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
<8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 21 Mar 2022 12:36:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenants and feebumping
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: Mon, 21 Mar 2022 12:07:02 -0000
Hi ZmnSCPxj,
Thanks for the feedback. The DLC idea is interesting but you are centralizi=
ng the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no ne=
ed to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no revocati=
on transaction can be pushed.
> Okay, let me see if I understand your concern correctly.
> When using a signature challenge, the concern is that you need to presign=
multiple versions of a transaction with varying feerates.
I was thinking of having a hot key (in this case probably shared amongst th=
e monitors) where they would sign
the right fee level at broadcast time. Pre-signing makes it quickly too man=
y signatures (and kills the purpose
of having covenants in the first place).
> And you have a set of network monitors / watchtowers that are supposed to=
watch the chain on your behalf in case your ISP suddenly hates you for no =
reason.
> The more monitors there are, the more likely that one of them will be cor=
rupted by a miner and jump to the highest-feerate version, overpaying fees =
and making miners very happy.
> Such is third-party trust.
> Is my understanding correct?
Your understanding of the tradeoff is correct.
------- Original Message -------
Le jeudi 17 mars 2022 =C3=A0 12:29 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> a=
=C3=A9crit :
> Good morning Antoine,
>
> > For "hot contracts" a signature challenge is used to achieve the same. =
I know the latter is imperfect, since
> >
> > the lower the uptime risk (increase the number of network monitors) the=
higher the DOS risk (as you duplicate
> >
> > the key).. That's why i asked if anybody had some thoughts about this a=
nd if there was a cleverer way of doing
> >
> > it.
>
> Okay, let me see if I understand your concern correctly.
>
> When using a signature challenge, the concern is that you need to presign=
multiple versions of a transaction with varying feerates.
>
> And you have a set of network monitors / watchtowers that are supposed to=
watch the chain on your behalf in case your ISP suddenly hates you for no =
reason.
>
> The more monitors there are, the more likely that one of them will be cor=
rupted by a miner and jump to the highest-feerate version, overpaying fees =
and making miners very happy.
>
> Such is third-party trust.
>
> Is my understanding correct?
>
> A cleverer way, which requires consolidating (but is unable to eliminate)=
third-party trust, would be to use a DLC oracle.
>
> The DLC oracle provides a set of points corresponding to a set of feerate=
ranges, and commits to publishing the scalar of one of those points at som=
e particular future block height.
>
> Ostensibly, the scalar it publishes is the one of the point that correspo=
nds to the feerate range found at that future block height.
>
> You then create adaptor signatures for each feerate version, correspondin=
g to the feerate ranges the DLC oracle could eventually publish.
>
> The adaptor signatures can only be completed if the DLC oracle publishes =
the corresponding scalar for that feerate range.
>
> You can then send the adaptor signatures to multiple watchtowers, who can=
only publish one of the feerate versions, unless the DLC oracle is hacked =
and publishes multiple scalars (at which point the DLC oracle protocol reve=
als a privkey of the DLC oracle, which should be usable for slashing some b=
ond of the DLC oracle).
>
> This prevents any of them from publishing the highest-feerate version, as=
the adaptor signature cannot be completed unless that is what the oracle p=
ublished.
>
> There are still drawbacks:
>
> * Third-party trust risk: the oracle can still lie.
>
> * DLC oracles are prevented from publishing multiple scalars; they cannot=
be prevented from publishing a single wrong scalar.
>
> * DLCs must be time bound.
>
> * DLC oracles commit to publishing a particular point at a particular fix=
ed time.
>
> * For "hot" dynamic protocols, you need the ability to invoke the oracle =
at any time, not a particular fixed time.
>
> The latter probably makes this unusable for hot protocols anyway, so mayb=
e not so clever.
>
> Regards,
>
> ZmnSCPxj
|
