From: Gregory Maxwell <gmaxwell@gmail•com>
To: Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
Date: Thu, 6 Aug 2015 18:42:38 +0000 [thread overview]
Message-ID: <CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@mail.gmail.com> (raw)
In-Reply-To: <55C3A4BF.1010509@thinlink.com>
On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> - Will the relay network at least validate block version numbers in the
> future?
It already validates block version numbers.
It only relays valid transactions.
Although, the block relaying itself is explicitly "unvalidated" and
the software client can only usefully be used with a mempool
maintaining full node (otherwise it doesn't provide much value,
because the node must wait to validate the things). ... but that
doesn't actually mean no validation at all is performed, many
stateless checks are performed.
On Thu, Aug 6, 2015 at 5:16 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart from
> the source code)
I don't know if Matt has an extensive writeup. But the basic
optimization it performs is trivial. I wouldn't call it compression,
though it does have some analog to RTP "header compression".
All it does is relay transactions verified by a local node and keeps a
FIFO of the relayed transactions in both directions, which is
synchronous on each side.
When a block is recieved on either side, it replaces transactions with
their indexes in the FIFO and relays it along. Transactions not in the
fifo are escaped and sent whole. On the other side the block is
reconstructed using the stored data and handed to the node (where the
preforwarded transactions would have also been pre-validated).
There is some more than basic elaboration for resource management
(e.g. multiple queues for different transaction sizes)-- and more
recently using block templates to learn transaction priority be a bit
more immune to spam attacks, but its fairly simple.
Much better could be done about intelligently managing the queues or
efficiently transmitting the membership sets, etc. It's just
basically the simplest thing that isn't completely stupid.
next prev parent reply other threads:[~2015-08-06 18:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 19:07 Arnoud Kouwenhoven - Pukaki Corp
2015-08-05 19:27 ` Matt Corallo
2015-08-05 19:53 ` Arnoud Kouwenhoven - Pukaki Corp
2015-08-05 20:16 ` Gregory Maxwell
2015-08-05 21:19 ` Arnoud Kouwenhoven - Pukaki Corp
2015-08-05 22:14 ` Gregory Maxwell
2015-08-06 17:16 ` Sergio Demian Lerner
2015-08-06 17:33 ` Olaoluwa Osuntokun
2015-08-06 18:17 ` Tom Harding
2015-08-06 18:42 ` Gregory Maxwell [this message]
2015-08-06 20:50 ` Matt Corallo
2015-08-06 20:55 ` Matt Corallo
2015-08-06 20:38 ` Matt Corallo
2015-08-07 7:14 ` jl2012
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='CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(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