Author: Tier Nolan 2015-09-24 08:52:34
Published on: 2015-09-24T08:52:34+00:00
On September 24, 2015, Jonathan Toomim from Toomim Bros posted on the Bitcoin-dev mailing list about the current block propagation algorithm. The algorithm consists of a node mining a block, notifying its peers that it has a new block with an "inv," and the peers responding that they have not seen it, and request the block with "getdata" [hash]. The node then sends out the block in parallel to all eight peers simultaneously, and once a peer completes the download, it verifies the block, then enters step two. Mining pools currently connect to the "fast relay network" which is optimised for fast block distribution. 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. Each relay node keeps a mapping of txid to key for each of its peers, and there is some garbage collection and entries are removed once the transaction is included in a block. When a block is found, the local node sends it to the relay node, which 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, but 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 one 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 transaction with an optimization that compresses this to 1 byte per tx.
Updated on: 2023-06-10T23:00:38.349369+00:00