Possible to generate a block that is too large

[abitmore]

This one: steemit/steem#2632.

IMHO, BitShares doesn't have the same issue, since BitShares block header is fixed size so far. There are 2 fields in Steem block header which made its size non-fixed, witness (string) and extensions (array-like), see changes in the PR steemit/steem#2637.

I'm creating this ticket so other developers will get notified, and hope they'll review the code as well. If we have the issue, we need to fix it. If we're going to add data to extensions in block header in the future, need to take care of related code to avoid similar issues.

[abitmore]

If we're going to add data to extensions in block header in the future, need to take care of related code to avoid similar issues.

To remember this, I think we can add a note to the code

bitshares-core/libraries/chain/include/graphene/chain/protocol/block.hpp

Lines 29 to 40 in 5111084

	struct block_header
	{
	digest_type digest()const;
	block_id_type previous;
	uint32_t block_num()const { return num_from_id(previous) + 1; }
	fc::time_point_sec timestamp;
	witness_id_type witness;
	checksum_type transaction_merkle_root;
	extensions_type extensions;
	static uint32_t num_from_id(const block_id_type& id);
	};

Why not port code from Steem now? Because current code has slightly better performance in current situation due to static:

bitshares-core/libraries/chain/db_block.cpp

Line 312 in 5111084

static const size_t max_block_header_size = fc::raw::pack_size( signed_block_header() ) + 4;

[abitmore]

Closed via #1142.

[abitmore]

Just noticed that witness_id_type in block header is not fixed-length after serialized. Reopening this issue for further discussion and action.

[jmjatlanta]

My notes (preliminary, verify before trusting):

block_header has a few variable-width fields. witness_id_type and extensions_type. I believe extensions_type is not being used. If it is, I believe a block can easily be created that exceeds max_block_header_size.

Issue #1088 will increase the size of signed_block_header, so max_block_header_size should also return a larger (although not always accurate) size.

[abitmore]

According to this in-code comment, it can cause unexpected large blocks as well:

bitshares-core/libraries/chain/db_block.cpp

Lines 365 to 383 in 4b915ef

	size_t new_total_size = total_block_size + fc::raw::pack_size( tx );
	// postpone transaction if it would make block too big
	if( new_total_size >= maximum_block_size )
	{
	postponed_tx_count++;
	continue;
	}
	try
	{
	auto temp_session = _undo_db.start_undo_session();
	processed_transaction ptx = _apply_transaction( tx );
	temp_session.merge();
	// We have to recompute pack_size(ptx) because it may be different
	// than pack_size(tx) (i.e. if one or more results increased
	// their size)
	total_block_size += fc::raw::pack_size( ptx );

E.G. force settlement can return different size depends on whether the asset is globally settled.

I think we should check size before merging the undo session.

[abitmore]

Fixed by #1252.