Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
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
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
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
