morcos · December 22, 2016 13:44
diff --git a/Block Request Logic b/Block Request Logic
 Suggested change to allow second outstanding block request
 Request/Process first announcement as we do now, then additionally once we have the block in flight, we are still willing to request a cmpctblock from the first sendcmpct peer which headers us until we have received a new cmpctblock (either in response to our request or from an HB peer, but not counting from the first announcemnt). Then we request blocktxn from that peer as well so we have two blocks in flight, at least the second of which is a cmpctblock.
 I think that outstanding requests for cmpct blocks at either the first or second annoucement should only influence whether we request more cmpct blocks.  Until we have at least 2 known block or blocktxn requests outstanding, we will continue to respond with getblocktxn to any cmpct blocks we receive.  But once we have one outstanding request for anything (cmpctblock, block, blocktxn), we will never request another full block.
	Suggested change to allow second outstanding block request
	Request/Process first announcement as we do now, then additionally once we have the block in flight, we are still willing to request a cmpctblock from the first sendcmpct peer which headers us until we have received a new cmpctblock (either in response to our request or from an HB peer, but not counting from the first announcemnt). Then we request blocktxn from that peer as well so we have two blocks in flight, at least the second of which is a cmpctblock.
	I think that outstanding requests for cmpct blocks at either the first or second annoucement should only influence whether we request more cmpct blocks. Until we have at least 2 known block or blocktxn requests outstanding, we will continue to respond with getblocktxn to any cmpct blocks we receive. But once we have one outstanding request for anything (cmpctblock, block, blocktxn), we will never request another full block.