public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Gregory Maxwell <gmaxwell@gmail.com>,
	Gregory Maxwell via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>,
	Tom Harding <tomh@thinlink.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
Date: Thu, 06 Aug 2015 20:50:32 +0000	[thread overview]
Message-ID: <5C79A979-5D68-4A1C-B33A-177212506D24@mattcorallo.com> (raw)
In-Reply-To: <CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@mail.gmail.com>



On August 6, 2015 8:42:38 PM GMT+02:00, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>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

No, just one queue, but it has a count-of-oversize-txn-limit, in addition to a size.

>recently using block templates to learn transaction priority be a bit
>more immune to spam attacks, but its fairly simple.

Except it doesn't really work :( (see https://github.com/TheBlueMatt/RelayNode/issues/12#issuecomment-128234446)

>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.

Patches welcome :) (read the issues list first... Rewriting the protocol from scratch is by far not the biggest win here).

Matt


  reply	other threads:[~2015-08-06 20:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 19:07 [bitcoin-dev] Idea: Efficient bitcoin block propagation 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
2015-08-06 20:50                 ` Matt Corallo [this message]
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=5C79A979-5D68-4A1C-B33A-177212506D24@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@gmail.com \
    --cc=tomh@thinlink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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