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
|
Return-Path: <enclade@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id ED196C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Feb 2022 10:02:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id DAD024016A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Feb 2022 10:02:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.102
X-Spam-Level:
X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=0.1]
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 Gue6ZP8KtzNu
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Feb 2022 10:02:13 +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 8E35340127
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Feb 2022 10:02:13 +0000 (UTC)
Date: Thu, 10 Feb 2022 10:02:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1644487330;
bh=BIhckM+IiQOCLDeIaeeQtfpiGUk/J8Wt767qy9mu8f4=;
h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject:
Reply-To:Feedback-ID:Message-ID;
b=V0gZX3lAoLWXIXSxfFb6yyAGWAcK0Sm39VCXTh8NR+WzLmX4Xn0eFn4zax2ZaknSJ
7rJdlXhBce5N/WbFZTgJ7F8Bony4XgmzN3Qaji99K2lS7IP1LPWEXXIBjb7uwREf2p
rF5OYBpt37UBzSB5WRCH0IPvcK15kvxHdJJYo8m/khp4iG4wRszNDId0T3IfnPzmaw
N6qQNFNNw4Ey5DZUITH8uXe5hjzdsTCRt3dxH29eYm+mKmHmts/nfcRK1x+m3OPhjJ
m3+GPe/F2/2Jw/ZSV0ppmeHmkNuqEQ0Hb2yOkXZgQgQkFROS9004IC9mLodPRSrLGi
gQlyWwLYCSWpQ==
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
From: enclade <enclade@protonmail.com>
Reply-To: enclade <enclade@protonmail.com>
Message-ID: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 10 Feb 2022 10:10:15 +0000
Subject: [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 10:02:15 -0000
The design document which inspired Neutrino outlined the use of oracles to =
provide a moderate level of confidence to lightweight clients in the filter=
s they have received from an untrusted source. Current implementations of l=
ightweight wallets using Neutrino either trust in a single source, or a sam=
pling of untrusted peers for this information. The determinism of the filte=
r headers allows for them to be simply and compactly attested by a potentia=
lly large number of authoritative sources with minimal loss in privacy. The=
se sources could be exchanges, hardware wallet manufacturers, block explore=
rs, or other well known parties.
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.
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.
-
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.
# curl https://pizzabase.com/.well-known/neutrino.txt
03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutrin=
o.pizzabase.com
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.
# 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 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.
-
RFC.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0=
13417.html
[1]: https://github.com/mempoolco/chaindnsd
[2]: https://bitcoinheaders.net/
|
