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 6158E2548 for ; Sat, 20 Apr 2019 01:59:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7608E14D for ; Sat, 20 Apr 2019 01:59:33 +0000 (UTC) Date: Sat, 20 Apr 2019 01:59:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555725571; bh=R4+loMkQFnr5Glj9zYywBVUMTQaQwho4j6fr1RG8lgk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=hbM6vhgWtXDGu9+vgjAr7WR0kaFiYMRgUhyif61Iv+Mq2JId2kJB/FTJ1R2AeWqho hWBauEryJ34gQNRS2E4If2mpO0QmG1bQZF41dsxUbkIK3af4Hic3VzdtcrXdCSr35L AoapDXL9AkQxaZGn0IQLOaEsvveSGKpb1bV5RmSo= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com> 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 , "tdryja@media.mit.edu" 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 01:59:34 -0000 Good morning, > > As I understand it, this requires that UTXO commitments be mandatory. > > Perhaps UTXO sets can be made useful without committing them. I have > some very loose thoughts on the subject, I consider it an open > question. There is no safe way to use UTXO sets without identifying who is telling yo= u those sets are valid, or making it expensive to lie. The first option requires trust and is weaker than SPV, the second requires= committing to a proof-of-work (and probably best to fold it into the Bitco= in blockchain if so). You would get the UTXO commitment from the previous block (if the UTXO comm= itment is in the coinbase, then all you need is the Merkle proof of the coi= nbase). > > > More difficult is: how can an SPV node acquire the UTXO set at a partic= ular block? > > I think you are asking fair questions about how the UTXO set > commitments would work in practice, and how viable that makes it. I'm > not sure. The most comprehensive work I have seen on this topic has > been the utreexo proposal by Tadge Dryja: > https://www.youtube.com/watch?v=3DedRun-6ubCc > > Actually, now that I think about it... As an alternative to UTXO set > commitments, the old fraud proofs idea for segwit can be applied here. > > We get miners to commit to the location of the UTXOs that are being > spent (e.g. transaction 5 in block 12). This allows full nodes to > succinctly prove invalidity to SPV clients in the following ways: > > - a committed location does not contain the stated UTXO > - the UTXO has already been spent in a prior block > > If no fraud proofs are given, then the inputs can be assumed to be va= lid. > > As you may recall, these kinds of fraud proofs were abandoned mainly > because the data unavailability claim could only be verified by > downloading the data, resulting in a DoS vector where all blocks had > to be downloaded. This problem does not seem to apply here, because w= e > are only interested in blocks which have forks, so it's more doable t= o > download them. This makes no sense. In order to validate block N, you need to know that every UTXO spent by a t= ransaction in block N is valid. The UTXO you want to validate is located in some other block, not on the si= ngle block you are verifying. Thus the non-existent fraud proof can only be validated by loading the bloc= k of the UTXO purported to be spent, and every block between that and the c= urrent block you are verifying, i.e. fullnode. Either that or you trust that every peer you have is not omitting the proof= . Regards, ZmnSCPxj