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
