Send transactions after a CMerkleBlock when asked for it in an inv.
This actually simplifies some SPV code, as they can keep track of a filtered block and its txn before accepting both in one step. The previous argument was that SPV nodes should handle the txn the same as any other free txn and then mark them as connected to a block when they get the filtered block itself. However, it now appears that SPV nodes will need to put in more effort to verify loose txn than they would to verify txn in blocks, thus making it more approriate to send the txn after the filtered block.
This commit is contained in:
parent
2c7847349d
commit
28b80e6065
@ -3267,6 +3267,7 @@ bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)
|
||||
if (pfrom->pfilter)
|
||||
{
|
||||
CMerkleBlock merkleBlock(block, *pfrom->pfilter);
|
||||
pfrom->PushMessage("merkleblock", merkleBlock);
|
||||
// CMerkleBlock just contains hashes, so also push any transactions in the block the client did not see
|
||||
// This avoids hurting performance by pointlessly requiring a round-trip
|
||||
// Note that there is currently no way for a node to request any single transactions we didnt send here -
|
||||
@ -3277,7 +3278,6 @@ bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)
|
||||
BOOST_FOREACH(PairType& pair, merkleBlock.vMatchedTxn)
|
||||
if (!pfrom->setInventoryKnown.count(CInv(MSG_TX, pair.second)))
|
||||
pfrom->PushMessage("tx", block.vtx[pair.first]);
|
||||
pfrom->PushMessage("merkleblock", merkleBlock);
|
||||
}
|
||||
// else
|
||||
// no response
|
||||
|
Loading…
Reference in New Issue
Block a user