news165: add pr review club summary

Author: glozow

_posts/en/newsletters/2021-09-08-newsletter.md

@@ -43,14 +43,76 @@ infrastructure projects.
 meeting, highlighting some of the important questions and answers.  Click on a
 question below to see a summary of the answer from the meeting.*
 
-FIXME:intro
+[Use legacy relaying to download blocks in blocks-only mode][review club #22340]
+is a PR by Niklas Gögge to make blocksonly nodes always use legacy block relay
+for downloading blocks. The review club compared legacy block download with
+BIP152 compact block download, and why blocksonly nodes don't benefit from
+the latter.
 
 {% include functions/details-list.md
 
-  q0="FIXME"
-  a0="FIXME"
-  a0link="https://bitcoincore.reviews/12345#l-123FIXME"
-
+  q0="What sequence of messages is used in legacy block relaying?"
+  a0="Nodes (except those running versions earlier than v0.10) [sync
+headers-first][headers first pr]. A node first learns about a block and its
+block hash through a block header or `inv` message. It can then request the full
+block by sending a `getdata(MSG_BLOCK, blockhash)` message to a peer that
+announced it, and they respond with a `block` message containing the full
+block."
+  a0link="https://bitcoincore.reviews/22340#l-49"
+
+  q1="What sequence of messages is used in BIP152 low bandwidth compact block relaying?"
+  a1="Peers indicate that they want to use compact block relay by sending
+`sendcmpct` at the start of the connection. Low bandwidth compact block relay is
+very similar to legacy block relay: the node syncs headers first, requests a
+compact block from its peer using `getdata(MSG_CMPCT_BLOCK, blockhash)`, and
+receives a `cmpctblock` in response. The node can use the compact block shortids
+to look for the block transactions in its mempool and cache of extra
+transactions. If any transactions are still unknown, it can request them from
+a peer using `getblocktxn` and receive `blocktxn` messages in response."
+  a1link="https://bitcoincore.reviews/22340#l-56"
+
+  q2="What sequence of messages is used in BIP152 high bandwidth compact block relaying?"
+  a2="A node can request high bandwidth compact blocks from a peer when first
+establishing the connection by sending `sendcmpct(1)` at the start of the
+connection. This means the peer can send a `cmpctblock` immediately, without
+sending headers first or waiting for a `getdata` request for the block. If
+needed, the node can download any unknown block transactions using `getblocktxn`
+and `blocktxn`, identically to low bandwidth compact block relay."
+  a2link="https://bitcoincore.reviews/22340#l-59"
+
+  q3="Why does compact block relay waste bandwidth for blocksonly nodes during
+block download? How much bandwidth is wasted?"
+  a3="Compact block relay reduces bandwidth usage for nodes that have a mempool
+because they don't need to re-download the majority of block transactions.
+However, nodes in blocksonly mode don't participate in transaction relay and
+typically have empty mempools, which means they need to download all of the
+transactions anyway. The shortids, `getblocktxn` and `blocktxn` overhead [add up
+to approximately 38kB per block][aj calculations] of wasted bandwidth, and the
+extra round trip for `getblocktxn` and `blocktxn` messages also increases the
+time it takes to download the block."
+  a3link="https://bitcoincore.reviews/22340#l-82"
+
+  q4="Does a node in blocksonly mode keep a mempool?"
+  a4="While blocksonly nodes don't participate in transaction relay, they still
+have a mempool and it may contain transactions for a few different reasons. For
+example, if the node was in normal mode, then restarted in blocksonly mode, the
+mempool is persisted across the restart. Also, any transactions submitted
+through the wallet and client interfaces are validated and relayed using the
+mempool."
+  a4link="https://bitcoincore.reviews/22340#l-97"
+
+  q5="What is the difference between blocksonly and block-relay-only? Should
+these changes be applied for block-relay-only connections as well?"
+  a5="Blocksonly mode is a node setting, while block-relay-only is an attribute
+of a peer connection. When a node is started in blocksonly mode, the node sends
+`fRelay=false` in the version handshake with all peers and disconnects peers that
+send any transaction-related messages. Whether or not in blocksonly mode, a node
+may have block-relay-only connections on which they ignore incoming transaction
+and addr messages. As such, the existence of block-relay-only connections has no
+relation to a node's mempool contents and ability to reconstruct blocks from
+compact block messages, so these changes shouldn't be applied to
+block-relay-only connections."
+  a5link="https://bitcoincore.reviews/22340#l-111"
 %}
 
 ## Preparing for taproot #12: Vaults with taproot
@@ -123,7 +185,7 @@ BOLTs][bolts repo].*
 ## Footnotes
 
 {% include references.md %}
-{% include linkers/issues.md issues="22009,1907,1910,1143,847,880,824,1867,5669,4616" %}
+{% include linkers/issues.md issues="22009,1907,1910,1143,847,880,824,1867,5669,4616,22340" %}
 [bitcoin core 22.0]: https://bitcoincore.org/bin/bitcoin-core-22.0/
 [bitcoin core 0.21.2]: https://bitcoincore.org/bin/bitcoin-core-0.21.2/
 [news115 anchor fees]: /en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs
@@ -136,3 +198,5 @@ BOLTs][bolts repo].*
 [gray bip]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019390.html
 [braidpool paper]: https://github.com/pool2win/braidpool/raw/main/proposal/proposal.pdf
 [pool2win post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019371.html
+[aj calculations]: https://github.com/bitcoin/bitcoin/pull/22340#issuecomment-872723147
+[headers first pr]: https://github.com/bitcoin/bitcoin/pull/4468