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
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
On December 3, 2015 7:02:20 AM GMT+08:00, Peter Tschipper
wrote:
>On 02/12/2015 2:23 PM, Matt Corallo wrote:
>> My issue is more that its additional complexity and attack surface,
>> and for a very minor gain
>What is a minor gain? 15 to 27% compression sounds good to me and the
>larger the d
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
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
