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
03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c...@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