Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 452CAC000B for ; 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 ; 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 ; 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 ; 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 From: enclade Reply-To: enclade Message-ID: In-Reply-To: References: 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 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: 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 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.