user52573: When an SPV client starts up with no state, connects to a full node and sets a bloom filter what messages will it receive?
Will it only get new transactions that match its filter or is there some way to also get the full node to supply all previous blocks that match the filter?

user15378: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki

Upon receiving a filterload command, the remote peer will immediately
  restrict the broadcast transactions it announces (in inv packets) to
  transactions matching the filter, where the matching algorithm is
  specified below. The flags control the update behaviour of the
  matching algorithm.

The filter applies as soon as you set the filter using filterload. You can set fRelay false in the version command, to indicate that you want to disable broadcasting transactions until a filter is added. 

SPV clients that wish to use Bloom filtering would normally set fRelay
  to false in the version message, then set a filter based on their
  wallet (or a subset of it, if they are overlapping different peers).
  Being able to opt-out of inv messages until the filter is set prevents
  a client being flooded with traffic in the brief window of time
  between finishing version handshaking and setting the filter.


user52573: This question has the answer.
For the first question when an SPV client starts up and sets a bloom filter it will not receive any special messages from connected bitcoin nodes. The bloom filter will result in transaction broadcasts to the SPV being filtered.
In answer to the second question an SPV client must still request ALL block headers and send a getdata request for every block in order to determine whether it contains any relevant transactions. The purpose of the bloom filter is to restrict the number of transactions returned by the merkleblock response to the getdata request.
An SPV client that's relying on bitcoin peer nodes for transaction information will have a slow initial start up as it needs to request all the block headers.

52573: <p>When an SPV client starts up with no state, connects to a full node and sets a bloom filter what messages will it receive?</p>

<p>Will it only get new transactions that match its filter or is there some way to also get the full node to supply all previous blocks that match the filter?</p>
 15378: <p><a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki</a></p>

<blockquote>
  <p>Upon receiving a filterload command, the remote peer will immediately
  restrict the broadcast transactions it announces (in inv packets) to
  transactions matching the filter, where the matching algorithm is
  specified below. The flags control the update behaviour of the
  matching algorithm.</p>
</blockquote>

<p>The filter applies as soon as you set the filter using <code>filterload</code>. You can set <code>fRelay</code> <code>false</code> in the <code>version</code> command, to indicate that you want to disable broadcasting transactions until a filter is added. </p>

<blockquote>
  <p>SPV clients that wish to use Bloom filtering would normally set fRelay
  to false in the version message, then set a filter based on their
  wallet (or a subset of it, if they are overlapping different peers).
  Being able to opt-out of inv messages until the filter is set prevents
  a client being flooded with traffic in the brief window of time
  between finishing version handshaking and setting the filter.</p>
</blockquote>
 52573: <p>This <a href="https://bitcoin.stackexchange.com/questions/36818/how-do-spv-get-their-transactions-after-being-offline?rq=1">question</a> has the answer.</p>

<p>For the first question when an SPV client starts up and sets a bloom filter it will not receive any special messages from connected bitcoin nodes. The bloom filter will result in transaction broadcasts to the SPV being filtered.</p>

<p>In answer to the second question an SPV client must still request ALL block headers and send a <strong>getdata</strong> request for every block in order to determine whether it contains any relevant transactions. The purpose of the bloom filter is to restrict the number of transactions returned by the <strong>merkleblock</strong> response to the <strong>getdata</strong> request.</p>

<p>An SPV client that's relying on bitcoin peer nodes for transaction information will have a slow initial start up as it needs to request all the block headers.</p>
