Re: [bitcoin-dev] Torrent-style new-block propagation on Merkle trees

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

On Thu, Sep 24, 2015 at 12:12 AM, Jonathan Toomim (Toomim Bros) via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> As I understand it, the current block propagation algorithm is this:
>
> 1. A node mines a block.
> 2. It notifies its peers that it has a new block with an *inv*. Typical
> nodes have 8 peers.
> 3. The peers respond that they have not seen it, and request the block
> with *getdata* [hash].
> 4. The node sends out the block in parallel to all 8 peers simultaneously.
> If the node's upstream bandwidth is limiting, then all peers will receive
> most of the block before any peer receives all of the block. The block is
> sent out as the small header followed by a list of transactions.
> 5. Once a peer completes the download, it verifies the block, then enters
> step 2.
>

Mining pools currently connect to the "fast relay network".  This is
optimised for fast block distribution.  It does no validation and is only
for low latency propagation.  The normal network is used as a fallback.

My understanding is that it works as follows:

Each miner runs a normal full node and a relay node on the same computer.

The full node tells the relay node whenever it receives a new transaction
via the inv message and the node requests the full transaction.

The relay node tells its relay peers that it knows about the transaction
(hash only) and its 4 byte key. This is not forwarded onwards, since the
relay peer only gets the hash of the transaction and doesn't do validation
anyway.  The key is just a 4 byte counter.

Each relay node keeps a mapping of txid to key for each of its peer.  There
is some garbage collection and entries are removed once the transaction is
included in a block (there might be a confirm threshold).

When a block is found, the local node sends it to the relay node.  The
relay node then forwards it to all of its peers in a compact form.

The block is sent as a list of keys for that peer and full transactions are
only sent for unknown transactions.

When a relay node receives a block, it just verifies the POW, checks that
it is new and recent.  It does not do tx validation.  It forwards the block
to its local full node, which does the validation.  Since the relay node is
on localhost, it never gets kicked due to sending invalid blocks.  This
prevents a DOS attack where you could send invalid blocks to the relay node
and cause the local full node to kick it.

If all the transactions are already known, then it can forward a block for
only 4 bytes per transactions.  I think it has an optimisation, so that is
compressed to 1 byte per tx.

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]