From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id ED196C000B for ; Thu, 10 Feb 2022 10:02:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id DAD024016A for ; Thu, 10 Feb 2022 10:02:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gue6ZP8KtzNu for ; Thu, 10 Feb 2022 10:02:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8E35340127 for ; Thu, 10 Feb 2022 10:02:13 +0000 (UTC) Date: Thu, 10 Feb 2022 10:02:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1644487330; bh=BIhckM+IiQOCLDeIaeeQtfpiGUk/J8Wt767qy9mu8f4=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject: Reply-To:Feedback-ID:Message-ID; b=V0gZX3lAoLWXIXSxfFb6yyAGWAcK0Sm39VCXTh8NR+WzLmX4Xn0eFn4zax2ZaknSJ 7rJdlXhBce5N/WbFZTgJ7F8Bony4XgmzN3Qaji99K2lS7IP1LPWEXXIBjb7uwREf2p rF5OYBpt37UBzSB5WRCH0IPvcK15kvxHdJJYo8m/khp4iG4wRszNDId0T3IfnPzmaw N6qQNFNNw4Ey5DZUITH8uXe5hjzdsTCRt3dxH29eYm+mKmHmts/nfcRK1x+m3OPhjJ m3+GPe/F2/2Jw/ZSV0ppmeHmkNuqEQ0Hb2yOkXZgQgQkFROS9004IC9mLodPRSrLGi gQlyWwLYCSWpQ== To: "bitcoin-dev@lists.linuxfoundation.org" From: enclade Reply-To: enclade Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 10 Feb 2022 10:10:15 +0000 Subject: [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 10:02:15 -0000 The design document which inspired Neutrino outlined the use of oracles to = provide a moderate level of confidence to lightweight clients in the filter= s they have received from an untrusted source. Current implementations of l= ightweight wallets using Neutrino either trust in a single source, or a sam= pling of untrusted peers for this information. The determinism of the filte= r headers allows for them to be simply and compactly attested by a potentia= lly large number of authoritative sources with minimal loss in privacy. The= se sources could be exchanges, hardware wallet manufacturers, block explore= rs, 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. # curl https://pizzabase.com/.well-known/neutrino.txt 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutrin= o.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. # 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 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]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0= 13417.html [1]: https://github.com/mempoolco/chaindnsd [2]: https://bitcoinheaders.net/