MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <871tb16diz.fsf@rustcorp.com.au>
References: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
	<CABsx9T1vBRMYm6rLuqzvOxD0eABE4saF44JzZjMF3iUU==Nz0Q@mail.gmail.com>
	<871tb16diz.fsf@rustcorp.com.au>
Date: Sun, 6 Dec 2015 05:13:15 +0000
Message-ID: <CAAS2fgRMi3KKKUW_7eunG9cprOLtz8yrEtA+8ChiCgninjMMZw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
Precedence: list

On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell <rusty@rustcorp.com.au> 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.)