Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D02D8C000B for ; Thu, 10 Feb 2022 21:07:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B0251824C1 for ; Thu, 10 Feb 2022 21:07:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPPVhctix-Qz for ; Thu, 10 Feb 2022 21:07:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0906A82423 for ; Thu, 10 Feb 2022 21:07:27 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id b13so13276003edn.0 for ; Thu, 10 Feb 2022 13:07:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0byMeES7Q4CEBb23RiAfPeClv4b/GYEPJZAnM7uh+og=; b=LTDgKADvnaa2lcKmMXcLnVRO+zPD2O53/JmXmpH6iWVjd1LjLXIwUSLxzzcJfq8fJC VNigaW6o2wEYiXag7CKEeiOOoTt/gdoIf6jGYimE4SyqQ+kY63UlB6dPknpplWzLCcog nKPGOBOX5nwlPeMqO1PjuehdUyxAomOrvwrsXvSXJu0DLPyc3/wjU/jhEpBgPBVnTGBq sdmpyNRumFcIZxErhyRJhgEfYlnsDWody0zFnaalhS06co6EkfGIDsAhDAPQjkMhENT3 YmQhZ2ZUIKvAXky165q8cGe6lJE8OkWyCgFkwHDQ0hTP5NImgJmU6ac7w9Vweod9cHu2 2qJA== X-Gm-Message-State: AOAM532EQ+6scEBwd2uZ3ITJlBrrrNQwRUhhgO8Ygi3KbQOvF2LC/I36 3Eq8/wPcfczbMe+9HptDUrQrcttfHRrjgt/zqVQwSEQ16P+/HyPn X-Google-Smtp-Source: ABdhPJwAhAaW7GrVtnYyZFN9bDttrGy4nCYCvmji82PQWG1MaecHBKhxX60dBzk6uu52fgq055qU8cc1GHpOdNH4+tw= X-Received: by 2002:a05:6402:520b:: with SMTP id s11mr10405839edd.365.1644527246022; Thu, 10 Feb 2022 13:07:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Devrandom Date: Thu, 10 Feb 2022 13:07:14 -0800 Message-ID: To: enclade , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000052c85b05d7b0561b" X-Mailman-Approved-At: Thu, 10 Feb 2022 21:10:47 +0000 Subject: Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 21:07:29 -0000 --00000000000052c85b05d7b0561b Content-Type: text/plain; charset="UTF-8" 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 > --00000000000052c85b05d7b0561b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This would be very useful for the V= alidating Lightning Signer project, since we need to prove to a non-network= connected signer that a UTXO has not been spent.=C2=A0 It allows the signe= r to make sure the channel is still active.


<= /div>
I think it would be useful if the oracles were non-interactive, s= o that they can communicate with the world over a one-way connection.=C2=A0= This would reduce their attack surface.=C2=A0 Instead of signing over a cl= ient-provided timestamp, we could pre-quantize the timestamp and emit attes= tations for each quantum time step.

On Thu, Feb 10, 2022 at 11:10 AM enc= lade via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
The design document which inspired Neutrino outlined the use of oracl= es to provide a moderate level of confidence to lightweight clients in the = filters they have received from an untrusted source. Current implementation= s 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 po= tentially large number of authoritative sources with minimal loss in privac= y. These sources could be exchanges, hardware wallet manufacturers, block e= xplorers, or other well known parties.

The most obvious transport for these oracles is DNS, several[0][1] implemen= tations of tools exist which provide either headers or raw filter data to c= lients by encoding it in record responses. With careful construction oracle= s can operate using DNS with extremely low resource requirements and attack= surface, while providing a privacy maximizing service to their clients. Fo= r situations where DNS is not appropriate, other tools can aggregate the si= gnatures 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 displ= ay an error to their user if no suitable number of attestations could be fo= und. Fault or fraud proofs can be generated by any party by simply collecti= ng differing signatures, for example if an oracle was presenting disjoint f= ilter headers from its peers the error would be readily apparent and provab= le.

-

Host names and their associated keys would be baked into the binaries of cl= ient software supporting the system, but their location and credentials cou= ld be attested in a text file of their primary domain. For example, a popul= ar fictional exchange could advertise their ability to provide this service= using RFC5785.

=C2=A0# curl https://pizzabase.com/.well-kn= own/neutrino.txt
=C2=A003a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutri= no.pizzabase.com

The client would request its known sources for attestations, using the curr= ent unix timestamp as a nonce. Use of a lower precision (for example rounde= d to 60 seconds) allows the oracle to cache the result with a long TTL, whi= le allowing a client to poll with relatively high frequency if required.
=C2=A0# dig 6204dd70.neutrino.pizzabase.com
=C2=A0# dig 6204dd70.neutrino.blockspaghet= tini.com
=C2=A0# dig 6204dd70.neutrino.mtgnocchi.com

Oracles would return the current block hash, hash of the tip of the neutrin= o header chain, and a ECDSA signature over the data including the requestin= g quantized timestamp. In totality giving the client sufficient and portabl= e evidence that their view of the state of the network has not been tampere= d with, while maintaining as much privacy as possible.

-

RFC.

[0]: http= s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.htm= l
[1]: https://github.com/mempoolco/chaindnsd
[2]: https://bitcoinheaders.net/
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000052c85b05d7b0561b--