On Thu, Sep 24, 2015 at 12:12 AM, Jonathan Toomim (Toomim Bros) via bitcoin-dev 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.