public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Devrandom <c1.bitcoin@niftybox.net>
To: enclade <enclade@protonmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
Date: Thu, 10 Feb 2022 13:07:14 -0800	[thread overview]
Message-ID: <CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com> (raw)
In-Reply-To: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 4043 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5697 bytes --]

  reply	other threads:[~2022-02-10 21:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 10:02 [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles enclade
2022-02-10 21:07 ` Devrandom [this message]
2022-02-11  2:39   ` enclade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com' \
    --to=c1.bitcoin@niftybox.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=enclade@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox