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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id C7BDCC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 23:29:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B695860F6F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 23:29:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, 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: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id yO7L9taw-dVo
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 23:29:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp3.osuosl.org (Postfix) with ESMTPS id F2C8260F6A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 23:29:48 +0000 (UTC)
Date: Wed, 16 Mar 2022 23:29:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1647473385;
bh=lN25IhNyVMoNYn1jKKqNpVdL6RRXrEzv1U9JwDcfP4M=;
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=BPays0XI3WOjKEECGszCZOJiNT4Y9a58T+syeu/Harv4g2bmO6o0LBbq6ZY4Pd9CZ
zMTOs4G6mQI9M3D5nYj9T4Prr24/WQaDsdpJDQhKm0DYowh6qbIQ89iY4cb4xiX6JV
Q23vZmmPk4CHM/g5fkKxcl3CBCy/HoxNAla7mALT/d1wLNBgiANTdjfeUOzTYFFWq5
s6YEmpf58z6/yZTJooTPGLsEnhCdBbhzcejJiD75tDSCIx7faTcUS/jcPVrdCaKxDE
QyhCtB6KbWl8XFNBHTMoDsHsqzsl6oMxfAl3VlCymqyErHyZbhcHS9GLvKWvB4/J8G
FfHhmk+QOptZQ==
To: darosior <darosior@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com>
In-Reply-To: <QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
References: <Udzkz8ZPM4na6yNcGnINLCskodTve66hhpoXevwYuVVgfWfbJnLH70Btmp_dmvk8X8sNXqywBVviG3OzFzeoXQanPb8KkWNGjKG2mxxDsAo=@protonmail.com>
<CAD5xwhgoxMnGpwn=4Ww_ZWP+ViZabvcxUV_n5=sXFdCwSe6-Mw@mail.gmail.com>
<QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Wed, 16 Mar 2022 23:29:49 -0000
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 h=
igher the DOS risk (as you duplicate
> the key).. That's why i asked if anybody had some thoughts about this and=
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 m=
ultiple versions of a transaction with varying feerates.
And you have a set of network monitors / watchtowers that are supposed to w=
atch the chain on your behalf in case your ISP suddenly hates you for no re=
ason.
The more monitors there are, the more likely that one of them will be corru=
pted by a miner and jump to the highest-feerate version, overpaying fees an=
d making miners very happy.
Such is third-party trust.
Is my understanding correct?
A cleverer way, which requires consolidating (but is unable to eliminate) t=
hird-party trust, would be to use a DLC oracle.
The DLC oracle provides a set of points corresponding to a set of feerate r=
anges, and commits to publishing the scalar of one of those points at some =
particular future block height.
Ostensibly, the scalar it publishes is the one of the point that correspond=
s to the feerate range found at that future block height.
You then create adaptor signatures for each feerate version, corresponding =
to the feerate ranges the DLC oracle could eventually publish.
The adaptor signatures can only be completed if the DLC oracle publishes th=
e corresponding scalar for that feerate range.
You can then send the adaptor signatures to multiple watchtowers, who can o=
nly publish one of the feerate versions, unless the DLC oracle is hacked an=
d publishes multiple scalars (at which point the DLC oracle protocol reveal=
s a privkey of the DLC oracle, which should be usable for slashing some bon=
d of the DLC oracle).
This prevents any of them from publishing the highest-feerate version, as t=
he adaptor signature cannot be completed unless that is what the oracle pub=
lished.
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 maybe =
not so clever.
Regards,
ZmnSCPxj
|
