Fluffyblocks sending already known txs(?)

[nahuhh]

my eli5 understanding of fluffyblocks, is that the block relayed should only include missing txs / txs that the node does not already have. Making for bandwidth savings.

When testing tx_relay v2, my setup was 3 nodes.

• node A = wallet spams txs. Node A is connected exclusively to node B.
• node B = intermediate node. Connected to node A and node C.
• node C = mining. Connected exclusively to node B.

This means that node A always has every tx - they all originate on node A.

monitoring the amount of data sent / received, would look similar to
Node A = 50kb down, 5mb up
Node B = 5mb down, 5mb up
Node C = 5mb down, 50kb up

Here's where i think there is an issue:
Node C mines a block. Node B and A already have all of the txs in the block, so i'd expect the block sent to them to be small (not including the txs). But after receiving the block, the data looks like

Node A = 5mb down, 5mb up
Node B = 10mb down, 10mb up
Node C = 5mb down, 5mb up

if i understand fluffyblock correctly, the relayed block shouldnt have included the txs if the node already had them.

note: this isnt related to tx_relay v2, but is just where i first noticed it (due to my large block sizes). It is also present on stressnet. I don't think its related to fcmp.

[Boog900]

I have a couple questions:

1. Was D++ accounted for? To properly test this you would want all txs to be fluffed from the start.
2. Is that up/down usage just from the block or a total of all communication?

[nahuhh]

I have a couple questions:

1. Was D++ accounted for? To properly test this you would want all txs to be fluffed from the start.
2. Is that up/down usage just from the block or a total of all communication?

the main thing im looking at is the data jump at the time the block is mined.
ie, when node c sends block to node b, why does it go from 5mb down/50kb up -> 5mb down/5mb up? Essentially returning the full data amount that it had received. Node c only has 1 peer - node b. All txs known to node c, were send there by Node b.

for a weak reproduction, you can look at the data jump when receiving a block on the stressnet

[j-berman]

@jeffro256 pointed out the node that found the block is relaying the full block to its peers here:

monero/src/cryptonote_core/cryptonote_core.cpp

Lines 1309 to 1331 in d32b5bf

	if(bvc.m_added_to_main_chain)
	{
	cryptonote_connection_context exclude_context = {};
	NOTIFY_NEW_FLUFFY_BLOCK::request arg{};
	arg.current_blockchain_height = m_blockchain_storage.get_current_blockchain_height();
	std::vector<crypto::hash> missed_txs;
	std::vector<cryptonote::blobdata> txs;
	m_blockchain_storage.get_transactions_blobs(b.tx_hashes, txs, missed_txs);
	if(missed_txs.size() && m_blockchain_storage.get_block_id_by_height(get_block_height(b)) != get_block_hash(b))
	{
	LOG_PRINT_L1("Block found but, seems that reorganize just happened after that, do not relay this block");
	return true;
	}
	CHECK_AND_ASSERT_MES(txs.size() == b.tx_hashes.size() && !missed_txs.size(), false, "can't find some transactions in found block:" << get_block_hash(b) << " txs.size()=" << txs.size()
	<< ", b.tx_hashes.size()=" << b.tx_hashes.size() << ", missed_txs.size()" << missed_txs.size());
	block_to_blob(b, arg.b.block);
	//pack transactions
	for(auto& tx: txs)
	arg.b.txs.push_back({tx, crypto::null_hash});
	m_pprotocol->relay_block(arg, exclude_context);
	}

It should be a relatively straightforward fix to have the node relay an empty fluffy block in that spot.