📅 Original date posted:2022-02-10
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/dcc0fea8/attachment-0001.html>;
Devrandom [ARCHIVE] /
npub1j0…w9k8n
2023-06-07 23:04:05
in reply to nevent1q…ujzu
Author Public Key
npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8nPublished at
2023-06-07 23:04:05Event JSON
{
"id": "90b985668ecf5f40b076e84d45c65a467e55d03f84be6c8b0227be199e70551d",
"pubkey": "93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85",
"created_at": 1686179045,
"kind": 1,
"tags": [
[
"e",
"7c4b9ac24ac0ed83c68bf3763e04f96ec59ac5d90e0fe8c248c6c27c1b43a503",
"",
"root"
],
[
"e",
"d0e839f13b7ad4cf28a7f28daa0f04cfc4e86b48d572ee1f849a50ad5239c17a",
"",
"reply"
],
[
"p",
"60b5474b187a4d36b06be97b81bd653a216e6cb82b9495d4c7afac3f5bd2447d"
]
],
"content": "📅 Original date posted:2022-02-10\n📝 Original message:This would be very useful for the Validating Lightning Signer project,\nsince we need to prove to a non-network connected signer that a UTXO has\nnot been spent. It allows the signer to make sure the channel is still\nactive.\n\n( the related design doc is at\nhttps://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md )\n\nI think it would be useful if the oracles were non-interactive, so that\nthey can communicate with the world over a one-way connection. This would\nreduce their attack surface. Instead of signing over a client-provided\ntimestamp, we could pre-quantize the timestamp and emit attestations for\neach quantum time step.\n\nOn Thu, Feb 10, 2022 at 11:10 AM enclade via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The design document which inspired Neutrino outlined the use of oracles to\n\u003e provide a moderate level of confidence to lightweight clients in the\n\u003e filters they have received from an untrusted source. Current\n\u003e implementations of lightweight wallets using Neutrino either trust in a\n\u003e single source, or a sampling of untrusted peers for this information. The\n\u003e determinism of the filter headers allows for them to be simply and\n\u003e compactly attested by a potentially large number of authoritative sources\n\u003e with minimal loss in privacy. These sources could be exchanges, hardware\n\u003e wallet manufacturers, block explorers, or other well known parties.\n\u003e\n\u003e The most obvious transport for these oracles is DNS, several[0][1]\n\u003e implementations of tools exist which provide either headers or raw filter\n\u003e data to clients by encoding it in record responses. With careful\n\u003e construction oracles can operate using DNS with extremely low resource\n\u003e requirements and attack surface, while providing a privacy maximizing\n\u003e service to their clients. For situations where DNS is not appropriate,\n\u003e other tools can aggregate the signatures into other formats as required.\n\u003e\n\u003e Clients could consider their view of the current network state to be\n\u003e strong when several of their oracle sources present agreeing signatures, or\n\u003e display an error to their user if no suitable number of attestations could\n\u003e be found. Fault or fraud proofs can be generated by any party by simply\n\u003e collecting differing signatures, for example if an oracle was presenting\n\u003e disjoint filter headers from its peers the error would be readily apparent\n\u003e and provable.\n\u003e\n\u003e -\n\u003e\n\u003e Host names and their associated keys would be baked into the binaries of\n\u003e client software supporting the system, but their location and credentials\n\u003e could be attested in a text file of their primary domain. For example, a\n\u003e popular fictional exchange could advertise their ability to provide this\n\u003e service using RFC5785.\n\u003e\n\u003e # curl https://pizzabase.com/.well-known/neutrino.txt\n\u003e\n\u003e 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd at neutrino.pizzabase.com\n\u003e\n\u003e The client would request its known sources for attestations, using the\n\u003e current unix timestamp as a nonce. Use of a lower precision (for example\n\u003e rounded to 60 seconds) allows the oracle to cache the result with a long\n\u003e TTL, while allowing a client to poll with relatively high frequency if\n\u003e required.\n\u003e\n\u003e # dig 6204dd70.neutrino.pizzabase.com\n\u003e # dig 6204dd70.neutrino.blockspaghettini.com\n\u003e # dig 6204dd70.neutrino.mtgnocchi.com\n\u003e\n\u003e Oracles would return the current block hash, hash of the tip of the\n\u003e neutrino header chain, and a ECDSA signature over the data including the\n\u003e requesting quantized timestamp. In totality giving the client sufficient\n\u003e and portable evidence that their view of the state of the network has not\n\u003e been tampered with, while maintaining as much privacy as possible.\n\u003e\n\u003e -\n\u003e\n\u003e RFC.\n\u003e\n\u003e [0]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.html\n\u003e [1]: https://github.com/mempoolco/chaindnsd\n\u003e [2]: https://bitcoinheaders.net/\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/dcc0fea8/attachment-0001.html\u003e",
"sig": "701868236566e629b81aba557c4c318897df44156f643c540e58717083dceb057ce5e866ee24ab30bbf4a5c5fa9b8b61bab67ea71467f4c44c78fa62e5fb9bf5"
}