diff options
| author | enclade <enclade@protonmail.com> | 2022-02-11 02:39:15 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-11 02:39:20 +0000 |
| commit | a79c9447b38bc035d27b949e1af39f2ffd5225ad (patch) | |
| tree | 63e8dba7e0e026bca9d53923af2bea4438a12570 | |
| parent | ca15585e7e60de921365b6c32437b6530c73576b (diff) | |
| download | pi-bitcoindev-a79c9447b38bc035d27b949e1af39f2ffd5225ad.tar.gz pi-bitcoindev-a79c9447b38bc035d27b949e1af39f2ffd5225ad.zip | |
Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
| -rw-r--r-- | 0a/87146159ca711a4bc89693eeafc7b91a516fd0 | 105 |
1 files changed, 105 insertions, 0 deletions
diff --git a/0a/87146159ca711a4bc89693eeafc7b91a516fd0 b/0a/87146159ca711a4bc89693eeafc7b91a516fd0 new file mode 100644 index 000000000..29c6acc0d --- /dev/null +++ b/0a/87146159ca711a4bc89693eeafc7b91a516fd0 @@ -0,0 +1,105 @@ +Return-Path: <enclade@protonmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 452CAC000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 02:39:20 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 1B47C4091D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 02:39:20 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.102 +X-Spam-Level: +X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=protonmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id c8liAfqL9u45 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 02:39:19 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch + [185.70.40.132]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 2D74F408FD + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 02:39:19 +0000 (UTC) +Date: Fri, 11 Feb 2022 02:39:15 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1644547156; + bh=z/NcNtsl/1o+x02PxrsmUdkG0MHT/TAgTaDKsincLh8=; + h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: + References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID; + b=mfEF0hu6Ssu3OncjXeIBlM9Le3iIRCopwJ6pNTblo5HoUrm0YOfqh2VIIkw2nFAyb + nGrvYEzVodvxFDhS1aNusUpYCx5NYjcT2+09AdKO4odi3TsVncFleWzOXMmjzc58ws + RBRMobtYulMVJi/OWjr7pMTijlZNCLPtBLUjTooVV20Ehd68GTs/CU+Q26pAj85NDM + t7P8N8kZrtGz4arhEswtm2iIh57yYX+HMWWGRmo8hrvlqRu80aHCGYS1oN9KJxpLDs + M63VPeW3sHbTd56bQ+GWKBfTCFJ4eeM4+nbDPv762GUN3lLdfmmlm7tehLmpFMCAH2 + mt71eZ3TPsvOg== +To: Devrandom <c1.bitcoin@niftybox.net> +From: enclade <enclade@protonmail.com> +Reply-To: enclade <enclade@protonmail.com> +Message-ID: <eWWmEi8ofiungvQuh41R2FSA5vNK5HMUV4SeBkvSdocpP2Khh4p6BWq7WZuB3vYayj7V1ifgQvvrCIvCetm-RFjtlCQxtDRE1ZeafDPXoe8=@protonmail.com> +In-Reply-To: <CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com> +References: <tX3sVcTrVucOJoofiJ2ttaBdeUELAMvJ7nlSe1K9-CMk7Eu4IRD70rEhjpaxH8y7G5Dha2FXTnXaoSUCSkL2Z6V5wdeEAzmCMifppK3rbhg=@protonmail.com> + <CAB0O3SWYXOr6mhytgkTFmO3i_p2=WAXg9RsRxYXU7w2eowWtnw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-Mailman-Approved-At: Fri, 11 Feb 2022 09:12:53 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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: Fri, 11 Feb 2022 02:39:20 -0000 + +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 non= +ce), but it was pointed out that making them use quantized timestamps mitig= +ated 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 o= +r Blockstream Satellite would scale extremely well too. When the oracles pr= +oduce agreeing messages (hopefully, the majority of the time except on bloc= +k boundaries) the additional data is only 64 bytes per additional signer, s= +o it makes sense to broadcast any a client may want to trust. + + +------- Original Message ------- + +On Thursday, February 10th, 2022 at 4:07 PM, Devrandom <c1.bitcoin@niftybox= +.net> wrote: + +> This would be very useful for the Validating Lightning Signer project, si= +nce 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 t= +hey can communicate with the world over a one-way connection. This would re= +duce their attack surface. Instead of signing over a client-provided timest= +amp, we could pre-quantize the timestamp and emit attestations for each qua= +ntum time step. + + |