path: root/29/e83e7e76d839c1f7a7297b15d67f1e2f895110

Return-Path: <miron@hyper.to>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D02D8C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:07:27 +0000 (UTC)
Received: by mail-ed1-f41.google.com with SMTP id b13so13276003edn.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>
In-Reply-To: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Thu, 10 Feb 2022 13:07:14 -0800
Message-ID: <CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com>
To: enclade <enclade@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"auto"><div dir=3D"ltr"><div>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><div><br></div><div>( the =
related design doc is at <a href=3D"https://gitlab.com/lightning-signer/doc=
s/-/blob/master/oracle.md" target=3D"_blank" rel=3D"noreferrer">https://git=
lab.com/lightning-signer/docs/-/blob/master/oracle.md</a> )</div><div><br><=
/div><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.<br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 10, 2022 at 11:10 AM enc=
lade via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-<br>
<br>
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.<br>
<br>
=C2=A0# curl <a href=3D"https://pizzabase.com/.well-known/neutrino.txt" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://pizzabase.com/.well-kn=
own/neutrino.txt</a><br>
=C2=A0<a href=3D"mailto:03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b=
8b56ac1c540c5bd@neutrino.pizzabase.com" target=3D"_blank" rel=3D"noreferrer=
">03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd@neutri=
no.pizzabase.com</a><br>
<br>
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.<br=
>
<br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.pizzabase.com" rel=3D"noref=
errer noreferrer" target=3D"_blank">6204dd70.neutrino.pizzabase.com</a><br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.blockspaghettini.com" rel=
=3D"noreferrer noreferrer" target=3D"_blank">6204dd70.neutrino.blockspaghet=
tini.com</a><br>
=C2=A0# dig <a href=3D"http://6204dd70.neutrino.mtgnocchi.com" rel=3D"noref=
errer noreferrer" target=3D"_blank">6204dd70.neutrino.mtgnocchi.com</a><br>
<br>
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.<br>
<br>
-<br>
<br>
RFC.<br>
<br>
[0]: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
7-January/013417.html" rel=3D"noreferrer noreferrer" target=3D"_blank">http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.htm=
l</a><br>
[1]: <a href=3D"https://github.com/mempoolco/chaindnsd" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">https://github.com/mempoolco/chaindnsd</a><br>
[2]: <a href=3D"https://bitcoinheaders.net/" rel=3D"noreferrer noreferrer" =
target=3D"_blank">https://bitcoinheaders.net/</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--00000000000052c85b05d7b0561b--