From: Ashley Holman <dscvlt@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
Date: Sun, 25 May 2014 09:11:39 +0930 [thread overview]
Message-ID: <CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgSJh83YEZjRfL81sKjC=nSKHtWT1qzS0evLJ9Gy6qdA1w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3335 bytes --]
On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek <bitcoin@bpj-code•co.za>
wrote:
>
> 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.
>
That is true, but they could also apply the same hash power to mine valid
blocks and would achieve the same outcome (their blocks would go to
everyone), except they would get paid for it. I wonder if it should even
be called DoS, due to the extreme and costly rate-limiting thats implied.
> 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.
>
Thank you for raising this, as I share this concern. There is another
similar attack: if I send you a new block very slowly, I occupy all your
upstream peer slots indefinitely until the block is complete, because there
is no out-of-band messaging capability or ability to cancel a message.
There is also sub-optimal logic in choosing to download a block only from
the first person to offer it. It means you are fetching it from the lowest
latency path, but what really matters is who can give it to you fastest.
If there are multiple people who can send you a block at once, and you
have some idea of your spare upstream bandwidth capacity, why not let two
or more peers compete to send you the block fastest?
So to implement this type of thing, the p2p protocol should allow for
multiplexing of messages. Something like HTTP chunked encoding. It could
be in the form of:
<msgid><chunksize><rawbytes>, <msgid><chunksize><rawbytes>, etc etc
You only send a chunk once you've got the whole chunk in your buffer, so
it's not possible to get hung up on a single slow message. One block can
overtake another along the same hop path if it is being streamed faster.
On Sun, May 25, 2014 at 8:46 AM, Gregory Maxwell <gmaxwell@gmail•com>
wrote:
>
> If you want to go full out crazy in optimizing in this space, there
> are fancier things that can be done to further reduce latency and
> increase efficiency:
> https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but
> some of this stuff really should be done as a seperate protocol. There
> is no need to have Bitcoin transport all using a single protocol, and
> we can get better robustness and feature velocity if there are a
> couple protocols in use (you could just run a block-transport-protocol
> daemon that connects to your local node via the classic protocol).
What about a separate project which is a mesh router specifically designed
for low-latency transmission of blocks? It could support things like a
more sophisticated/configurable routing table, and have some kind of
discovery where it tries to optimise its topology. There could even be
some way for nodes to prove their hash power, so pools can find each other
and directly peer / prioritise sends.
[-- Attachment #2: Type: text/html, Size: 4490 bytes --]
next prev parent reply other threads:[~2014-05-24 23:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 3:57 Ashley Holman
2014-05-24 5:11 ` Ashley Holman
2014-05-24 22:59 ` Bernd Jendrissek
2014-05-24 23:16 ` Gregory Maxwell
2014-05-24 23:41 ` Ashley Holman [this message]
2014-05-25 0:04 ` Alan Reiner
2014-05-25 0:14 ` Gregory Maxwell
2014-05-25 0:38 ` Alan Reiner
2014-05-25 9:36 ` Mike Hearn
2014-05-25 9:51 ` Gregory Maxwell
2014-05-26 15:08 ` Mike Hearn
[not found] <mailman.177181.1400974908.2207.bitcoin-development@lists.sourceforge.net>
2014-05-24 23:57 ` Jonathan Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com' \
--to=dscvlt@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox