From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8480F284E for ; Sat, 20 Apr 2019 04:45:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32FB479 for ; Sat, 20 Apr 2019 04:45:26 +0000 (UTC) Date: Sat, 20 Apr 2019 04:45:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555735524; bh=/5BFRv73x1s3Mety7SM+/tVNH3L5RnLONcg7BX4w1I0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=tTOKgSb7yHmpdPMjnXv+Ym5IJrK2mtk3Au0S+DLKEeJb9g+R5sSly7mA1kzyky856 aFQZMefM7tfmhODq7kbKCFPVf5Hf8IHQKARvRNBWysdHSxC6qW3XJP3lRq2sV44khH iYoE4rAyh9uYEvZIFQjlB4lZsIcy7EuZonhQVnZw= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 20 Apr 2019 14:21:03 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 04:45:28 -0000 Good morning Ruben, > Hi ZmnSCPxj, > > > There is no safe way to use UTXO sets without identifying who is tellin= g you those sets are valid, or making it expensive to lie > > The first option requires trust and is weaker than SPV, the second requ= ires committing to a proof-of-work > > Olaoluwa Osuntokun's BIP157 manages to function without a commitment: > "If the client receives conflicting filter headers from different > peers for any block and filter type, it SHOULD interrogate them to > determine which is faulty." > > I am wondering if the same logic can be applied to UTXO sets or the > fraud proofs I just described. UTXO sets can only be validated by actually running the entire blockchain, = i.e. fullnoding. What BIP157 does is summarize data that is within a block, thus validating = them can be done simply by downloading the block in question. UTXO sets summarize data in the entire blockchain, hence proper validation = requires downloading the entire blockchain. Thus it cannot be a comparison point. > > This makes no sense > > or you trust that every peer you have is not omitting the proof. > > It's the latter, you trust every peer you have is not omitting the > proof. It requires one honest peer. The reason this is acceptable is > because you're already making that assumption. If none of your peers > are honest, you have no guarantee of hearing about the chain with the > most PoW. But peers can be set up to allow you to hear of all chains while denying yo= u proof of the invalidity of some UTXO. This is precisely the "data unavailability claim" that shot down the previo= us fraud proofs (i.e. absence of proof is not proof of absence, and proof o= f UTXO validity was defined by proof of absence of any intervening spend of= the UTXO). Perhaps in combination with BIP157/158 it may be possible, if the filters c= ontain UTXO spends and a BIP158 filter was committed to on-chain. Then a proof of absence could be done by revealing all the BIP158 filters f= rom the UTXO creation to the block being validated, as well as the blocks w= hose BIP158 filters matched the UTXO and revealing that no, they actually d= o not spend the UTXO. -- Tangentially, we cannot just magically commit to anything on the blockchain= . Header blocks commit to block data and commit to some other header block. All those header blocks and the block data need to be stored and transmitte= d over the network somehow, even though they are "only" being committed to. Thus, if you are adding new information to be committed, that may increase = the resource usage of fullnodes. So if UTXO set commitments, or utreexo commitments, or BIP158 filter digest= s, etc. are committed to in the coinbase, they have to be stored somehow in= fullnodes the entire UUTXO set, or the actual utreexo structure, or the ac= tual BIP158 filter, etc. at each block. Otherwise it would be pointless to store those commitments since it would n= ot be possible to somehow acquire the data being committed to after-the-fac= t. This is probably still better than BIP37 but we should still be aware the a= dditional load on fullnodes. Regards, ZmnSCPxj