Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

2015-12-05 Thread James Hilliard via bitcoin-dev
I think something that anyone who isn't validating should be aware of is that cgminer(which powers the vast majority of the current mining network) doesn't allow for a pool to revert to mining on the previous block due to the way chain tracking is implemented.

Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

2015-12-05 Thread Gregory Maxwell via bitcoin-dev
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

[bitcoin-dev] Blockchain verification flag (BIP draft)

2015-12-04 Thread Gregory Maxwell via bitcoin-dev
For discussion, A significant fraction of hashrate currently mines blocks without verifying them for a span of time after a new block shows up on the network for economically rational reasons. This otherwise harmful behavior can be made a beneficial to the whole network; but only if it is

Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

2015-12-04 Thread Thomas Kerin via bitcoin-dev
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