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
>