Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FEF8267 for ; Sun, 6 Dec 2015 05:13:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA97D121 for ; Sun, 6 Dec 2015 05:13:15 +0000 (UTC) Received: by iofh3 with SMTP id h3so153367086iof.3 for ; Sat, 05 Dec 2015 21:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bM3aEzn80R2T+6m+GOyDvInb4J2FY2gNJW9jMdOHBJA=; b=ZEBhvOTi5Yp/z4hzgs3036sQu6wf+YXJohSyEUlm6y5cMXyxtvXnVXbUyazz0mY8e8 2ySuVYR+AUYxmnNWsO/lNpYIn3K+fh/gWaUeer62r87wEOtASytmE8Be3L2F+bMmSHI7 TVBLeAOdiYTi4GTIXDYCTO11TvW0UhhvDjL22+Bl2403vmpXlKEj7NxRfUij70w5Fbgo TZZeSsB9Rv3Gfn3TbQ2GN8+QxoN+3gP48ZlVzbDAxofVfZS/RcVCEnXht6zsbEyERrDX d0E6ZuIyTcM0IcpPuNm9csarwJBVQTibjMh13A249UwcgBKXaKM9XVcCdpuWbiP13ar4 QY/g== MIME-Version: 1.0 X-Received: by 10.107.34.199 with SMTP id i190mr21379261ioi.150.1449378795343; Sat, 05 Dec 2015 21:13:15 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.192.70 with HTTP; Sat, 5 Dec 2015 21:13:15 -0800 (PST) In-Reply-To: <871tb16diz.fsf@rustcorp.com.au> References: <871tb16diz.fsf@rustcorp.com.au> Date: Sun, 6 Dec 2015 05:13:15 +0000 X-Google-Sender-Auth: vcSLhSmHbeZxUOQhHDNk0S9v02c Message-ID: From: Gregory Maxwell To: Rusty Russell Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 05:13:17 -0000 On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell wrote: >> I agree with Jannes Faber, behavior with respect to SPV clients should be >> to only tell them about fully validated headers. > > A delicate balance. If we penalize these blocks too much, it's > disincentive to set the bit. Fortunately it's easy for SPV clients to > decide for themselves, I think? I think this is orthogonal: You should only tell SPV clients* about blocks you've fully validated yourself. The bit in the header doesn't matter with respect to that. (Effectively, the wallet risk model gets as input the fact that they got given the block in the first place as well as the flag where the miner said they were validating things or not.) Whatever the ideal behavior is for network nodes towards lite clients; it's insanely cheap to just spin up a lot of 'nodes' that have arbitrary behavior; so it shouldn't be relied on too much; but absolutely they should be filtering to things they've verified themselves... unlike the mining case, there is no reason not to. [Specific attacks to consider: You get a broken miner to include both your payment, and some invalid transaction. Other miners extend it without verifying. To avoid the fact that nodes sensibly filter invalid blocks from their lite clients, you simply just run a lot of 'nodes' so that virtually every lite client has a connection to you] (More specifically, peers should be able to specify that they want to know about pre-validated blocks and you should be able to fetch blocks from them which haven't been validated... but no one should get fed unverified blocks by surprise.)