To: bitcoin-dev@lists.linuxfoundation.org
References: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
	<CABeL=0gWD8Nvp=j7OWKMVeVYH5NA-TBox1UTbyWxmVBf2nSJfQ@mail.gmail.com>
From: Thomas Kerin <thomas.kerin@gmail.com>
Message-ID: <5661C36A.9090509@gmail.com>
Date: Fri, 4 Dec 2015 16:46:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CABeL=0gWD8Nvp=j7OWKMVeVYH5NA-TBox1UTbyWxmVBf2nSJfQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
Precedence: list

1. Not relaying can cause problems. Gossip networks operate by
propagating new information (like a single new header), and refuse to
relay information if it's obviously invalid.

From the POV of a full node, which will normally hear about the header
first, there's no point to not telling peers about this information.
It's likely in the interest of SPV wallets to hear about EVERY
contending chain, so they can go about their business deciding which is
correct.


2. The only difference between a block and it's header is the list of
transactions. There isn't anywhere else to put the flag but the header's
version. Which is good, because clients usually receive headers first.


3. "Signal would need to include some sort of proof" That's not the
point of this BIP. You can't prove the miner has or hasn't verified the
chain. What purpose would it even serve? If clients accepted this
'proof', they might ignore blocks they should pay attention to.

The BIP doesn't involve proof at all, it's just an indicator you can
chose to use or ignore.


On 04/12/15 12:44, Jannes Faber via bitcoin-dev wrote:
> nodes side by side, one of them doesn't validate in order to reduce latency