On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell <ru...@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.) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
