Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.176 as permitted sender)
	client-ip=209.85.217.176;
	envelope-from=bernd.jendrissek@gmail.com;
	helo=mail-lb0-f176.google.com; 
MIME-Version: 1.0
Sender: bernd.jendrissek@gmail.com
In-Reply-To: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
References: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
Date: Sun, 25 May 2014 00:59:36 +0200
Message-ID: <CAF7PVPoGAyhQhU-p-SiT1H86A+Zs3Fb-s9wgFZQtxdb6674k3w@mail.gmail.com>
From: Bernd Jendrissek <bitcoin@bpj-code.co.za>
To: Ashley Holman <dscvlt@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
Precedence: list

On Sat, May 24, 2014 at 5:57 AM, Ashley Holman <dscvlt@gmail.com> wrote:
> * As far as I can tell, this shouldn't change any game theory or incentives
> because nodes still receive blocks exactly as they do now, just sooner.  The
> difference is, invalid blocks that meet the PoW will be broadcast to
> everyone, but this is nothing new since someone can peer with you and send
> you an invalid block already.  Network DoS should not be a possibility since
> it is very expensive to make invalid blocks that meet network PoW.

The difference is that with cut-through forwarding of blocks, a
sufficiently motivated attacker (being willing to blow 25BTC's worth
of electricity on the effort) can subjugate the entire Bitcoin network
to its DoS attack, rather than having to connect to every node
individually and then still have those individual nodes reject that
invalid block without relaying any knowledge of its existence.

An attack could also take the form of a block body that never arrives
- a sort of teergrube attack, where the goal is to get the network
mining empty block upon empty block on top of that valid-PoW header
whose body never arrives. It doesn't have to be with an explicitly
invalid block.

Could one mitigate such attacks by allowing nodes to send a message to
the effect of, "Oops, I know that header i just sent is valid PoW, but
I'd like you to forget about it - I think its body is invalid"?