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 communic
1) (I would assume this is already current default behaviour, but just in
case.) Would it not make sense to *never* send a blockheader to an SPV
client unless the node itself fully validated that block? Regardless of who
mined the block and whether this verification flag has been set or not.
2) Be
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 abo
Overall, good idea.
Is there a write-up somewhere describing in detail the 'accidental selfish
mining' problem that this mitigates? I think a link in the BIP to a fuller
description of the problem and how validation-skipping makes it go away
would be helpful.
RE: which bit to use: the draft vers
Gavin Andresen via bitcoin-dev
writes:
> Overall, good idea.
>
> Is there a write-up somewhere describing in detail the 'accidental selfish
> mining' problem that this mitigates? I think a link in the BIP to a fuller
> description of the problem and how validation-skipping makes it go away
> would
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'
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.
https://github.com/ckolivas/cgminer/b
On Sun, Dec 6, 2015 at 2:47 AM, James Hilliard via bitcoin-dev
wrote:
> 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
