Date: Thu, 10 Feb 2022 10:02:08 +0000
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
Subject: [bitcoin-dev] Advancing the security of Neutrino using minimally
	trusted oracles
Precedence: list

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/