Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles

2022-02-11 Thread enclade via bitcoin-dev
That sounds completely reasonable.

Originally I had discussed privately making the protocol design completely 
interactive (client sends a nonce over DNS, oracle responds signing the nonce), 
but it was pointed out that making them use quantized timestamps mitigated a 
lot of the issues regarding denial of service, and allows for fault proofs to 
be significantly stronger.

Delivering the oracle messages over a write only channel like Kryptoradio or 
Blockstream Satellite would scale extremely well too. When the oracles produce 
agreeing messages (hopefully, the majority of the time except on block 
boundaries) the additional data is only 64 bytes per additional signer, so it 
makes sense to broadcast any a client may want to trust.


--- Original Message ---

On Thursday, February 10th, 2022 at 4:07 PM, Devrandom 
 wrote:

> 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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles

2022-02-10 Thread Devrandom via bitcoin-dev
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
>
> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles

2022-02-10 Thread enclade via bitcoin-dev
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