summaryrefslogtreecommitdiff
path: root/29/e83e7e76d839c1f7a7297b15d67f1e2f895110
blob: 4b56676c63d40f6b26bc23a9686c0165935a4174 (plain)
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
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
Return-Path: <miron@hyper.to>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D02D8C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:07:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B0251824C1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:07:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 URI_HEX=0.1] autolearn=no autolearn_force=no
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 DPPVhctix-Qz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:07:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com
 [209.85.208.41])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 0906A82423
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:07:27 +0000 (UTC)
Received: by mail-ed1-f41.google.com with SMTP id b13so13276003edn.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 13:07:27 -0800 (PST)
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;
 bh=0byMeES7Q4CEBb23RiAfPeClv4b/GYEPJZAnM7uh+og=;
 b=LTDgKADvnaa2lcKmMXcLnVRO+zPD2O53/JmXmpH6iWVjd1LjLXIwUSLxzzcJfq8fJC
 VNigaW6o2wEYiXag7CKEeiOOoTt/gdoIf6jGYimE4SyqQ+kY63UlB6dPknpplWzLCcog
 nKPGOBOX5nwlPeMqO1PjuehdUyxAomOrvwrsXvSXJu0DLPyc3/wjU/jhEpBgPBVnTGBq
 sdmpyNRumFcIZxErhyRJhgEfYlnsDWody0zFnaalhS06co6EkfGIDsAhDAPQjkMhENT3
 YmQhZ2ZUIKvAXky165q8cGe6lJE8OkWyCgFkwHDQ0hTP5NImgJmU6ac7w9Vweod9cHu2
 2qJA==
X-Gm-Message-State: AOAM532EQ+6scEBwd2uZ3ITJlBrrrNQwRUhhgO8Ygi3KbQOvF2LC/I36
 3Eq8/wPcfczbMe+9HptDUrQrcttfHRrjgt/zqVQwSEQ16P+/HyPn
X-Google-Smtp-Source: ABdhPJwAhAaW7GrVtnYyZFN9bDttrGy4nCYCvmji82PQWG1MaecHBKhxX60dBzk6uu52fgq055qU8cc1GHpOdNH4+tw=
X-Received: by 2002:a05:6402:520b:: with SMTP id
 s11mr10405839edd.365.1644527246022; 
 Thu, 10 Feb 2022 13:07:26 -0800 (PST)
MIME-Version: 1.0
References: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>
In-Reply-To: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Thu, 10 Feb 2022 13:07:14 -0800
Message-ID: <CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com>
To: enclade <enclade@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000052c85b05d7b0561b"
X-Mailman-Approved-At: Thu, 10 Feb 2022 21:10:47 +0000
Subject: Re: [bitcoin-dev] Advancing the security of Neutrino using
 minimally trusted oracles
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: Thu, 10 Feb 2022 21:07:29 -0000

--00000000000052c85b05d7b0561b
Content-Type: text/plain; charset="UTF-8"

This would be very useful for the Validating Lightning Signer project,
since we need to prove to a non-network connected signer that a UTXO has
not been spent.  It allows the signer to make sure the channel is still
active.

( the related design doc is at
https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md )

I think it would be useful if the oracles were non-interactive, so that
they can communicate with the world over a one-way connection.  This would
reduce their attack surface.  Instead of signing over a client-provided
timestamp, we could pre-quantize the timestamp and emit attestations for
each quantum time step.

On Thu, Feb 10, 2022 at 11:10 AM enclade via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The design document which inspired Neutrino outlined the use of oracles to
> provide a moderate level of confidence to lightweight clients in the
> filters they have received from an untrusted source. Current
> implementations of lightweight wallets using Neutrino either trust in a
> single source, or a sampling of untrusted peers for this information. The
> determinism of the filter headers allows for them to be simply and
> compactly attested by a potentially large number of authoritative sources
> with minimal loss in privacy. These sources could be exchanges, hardware
> wallet manufacturers, block explorers, or other well known parties.
>
> The most obvious transport for these oracles is DNS, several[0][1]
> implementations of tools exist which provide either headers or raw filter
> data to clients by encoding it in record responses. With careful
> construction oracles can operate using DNS with extremely low resource
> requirements and attack surface, while providing a privacy maximizing
> service to their clients. For situations where DNS is not appropriate,
> other tools can aggregate the signatures into other formats as required.
>
> Clients could consider their view of the current network state to be
> strong when several of their oracle sources present agreeing signatures, or
> display an error to their user if no suitable number of attestations could
> be found. Fault or fraud proofs can be generated by any party by simply
> collecting differing signatures, for example if an oracle was presenting
> disjoint filter headers from its peers the error would be readily apparent
> and provable.
>
> -
>
> Host names and their associated keys would be baked into the binaries of
> client software supporting the system, but their location and credentials
> could be attested in a text file of their primary domain. For example, a
> popular fictional exchange could advertise their ability to provide this
> service using RFC5785.
>
>  # curl https://pizzabase.com/.well-known/neutrino.txt
>
> 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutrino.pizzabase.com
>
> The client would request its known sources for attestations, using the
> current unix timestamp as a nonce. Use of a lower precision (for example
> rounded to 60 seconds) allows the oracle to cache the result with a long
> TTL, while allowing a client to poll with relatively high frequency if
> required.
>
>  # dig 6204dd70.neutrino.pizzabase.com
>  # dig 6204dd70.neutrino.blockspaghettini.com
>  # dig 6204dd70.neutrino.mtgnocchi.com
>
> Oracles would return the current block hash, hash of the tip of the
> neutrino header chain, and a ECDSA signature over the data including the
> requesting quantized timestamp. In totality giving the client sufficient
> and portable evidence that their view of the state of the network has not
> been tampered with, while maintaining as much privacy as possible.
>
> -
>
> RFC.
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.html
> [1]: https://github.com/mempoolco/chaindnsd
> [2]: https://bitcoinheaders.net/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000052c85b05d7b0561b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"ltr"><div>This would be very useful for the V=
alidating Lightning Signer project, since we need to prove to a non-network=
 connected signer that a UTXO has not been spent.=C2=A0 It allows the signe=
r to make sure the channel is still active.</div><div><br></div><div>( the =
related design doc is at <a href=3D"https://gitlab.com/lightning-signer/doc=
s/-/blob/master/oracle.md" target=3D"_blank" rel=3D"noreferrer">https://git=
lab.com/lightning-signer/docs/-/blob/master/oracle.md</a> )</div><div><br><=
/div><div>I think it would be useful if the oracles were non-interactive, s=
o that they can communicate with the world over a one-way connection.=C2=A0=
 This would reduce their attack surface.=C2=A0 Instead of signing over a cl=
ient-provided timestamp, we could pre-quantize the timestamp and emit attes=
tations for each quantum time step.<br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 10, 2022 at 11:10 AM enc=
lade via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">The design document which inspired Neutrino outlined the use of oracl=
es to provide a moderate level of confidence to lightweight clients in the =
filters they have received from an untrusted source. Current implementation=
s of lightweight wallets using Neutrino either trust in a single source, or=
 a sampling of untrusted peers for this information. The determinism of the=
 filter headers allows for them to be simply and compactly attested by a po=
tentially large number of authoritative sources with minimal loss in privac=
y. These sources could be exchanges, hardware wallet manufacturers, block e=
xplorers, or other well known parties.<br>
<br>
The most obvious transport for these oracles is DNS, several[0][1] implemen=
tations of tools exist which provide either headers or raw filter data to c=
lients by encoding it in record responses. With careful construction oracle=
s can operate using DNS with extremely low resource requirements and attack=
 surface, while providing a privacy maximizing service to their clients. Fo=
r situations where DNS is not appropriate, other tools can aggregate the si=
gnatures into other formats as required.<br>
<br>
Clients could consider their view of the current network state to be strong=
 when several of their oracle sources present agreeing signatures, or displ=
ay an error to their user if no suitable number of attestations could be fo=
und. Fault or fraud proofs can be generated by any party by simply collecti=
ng differing signatures, for example if an oracle was presenting disjoint f=
ilter headers from its peers the error would be readily apparent and provab=
le.<br>
<br>
-<br>
<br>
Host names and their associated keys would be baked into the binaries of cl=
ient software supporting the system, but their location and credentials cou=
ld be attested in a text file of their primary domain. For example, a popul=
ar fictional exchange could advertise their ability to provide this service=
 using RFC5785.<br>
<br>
=C2=A0# curl <a href=3D"https://pizzabase.com/.well-known/neutrino.txt" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://pizzabase.com/.well-kn=
own/neutrino.txt</a><br>
=C2=A0<a href=3D"mailto:03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b=
8b56ac1c540c5bd@neutrino.pizzabase.com" target=3D"_blank" rel=3D"noreferrer=
">03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutri=
no.pizzabase.com</a><br>
<br>
The client would request its known sources for attestations, using the curr=
ent unix timestamp as a nonce. Use of a lower precision (for example rounde=
d to 60 seconds) allows the oracle to cache the result with a long TTL, whi=
le allowing a client to poll with relatively high frequency if required.<br=
>
<br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.pizzabase.com" rel=3D"noref=
errer noreferrer" target=3D"_blank">6204dd70.neutrino.pizzabase.com</a><br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.blockspaghettini.com" rel=
=3D"noreferrer noreferrer" target=3D"_blank">6204dd70.neutrino.blockspaghet=
tini.com</a><br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.mtgnocchi.com" rel=3D"noref=
errer noreferrer" target=3D"_blank">6204dd70.neutrino.mtgnocchi.com</a><br>
<br>
Oracles would return the current block hash, hash of the tip of the neutrin=
o header chain, and a ECDSA signature over the data including the requestin=
g quantized timestamp. In totality giving the client sufficient and portabl=
e evidence that their view of the state of the network has not been tampere=
d with, while maintaining as much privacy as possible.<br>
<br>
-<br>
<br>
RFC.<br>
<br>
[0]: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
7-January/013417.html" rel=3D"noreferrer noreferrer" target=3D"_blank">http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.htm=
l</a><br>
[1]: <a href=3D"https://github.com/mempoolco/chaindnsd" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">https://github.com/mempoolco/chaindnsd</a><br>
[2]: <a href=3D"https://bitcoinheaders.net/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://bitcoinheaders.net/</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--00000000000052c85b05d7b0561b--