Extra data passed with blocks should be ignored

[alexdovzhanyn]

Currently, a block with literally any arbitrary data is accepted as valid. We expect blocks to look something like:

%{
  difficulty: 18775743.58334009,
  hash: "0000000D0E89D9A13DE616FEC8B12A62B646B2B5D0E1419C1A460442474E2AF0",
  index: 2324,
  merkle_root: "9084BB7F7D5A722FC2075644E71C2A518545E33C27402376D19863721EF0063B",
  nonce: 32535345,
  previous_hash: "0000003987CE7A874B760D50B183232A8C910C29CC7342E858503656D687BEE2",
  timestamp: 1542634035,
  version: 1,
  transactions: []
}

This block is considered a valid block, and when a miner or node (or wallet) receives this block, they'll take the received data verbatim and store it. This approach is naive. A miner can include any data they want onto this block, and it will still be deemed valid, and still be stored verbatim, wasting resources on a machine storing data that may be irrelevant. An example of this is the following:

%{
  difficulty: 18775743.58334009,
  hash: "0000000D0E89D9A13DE616FEC8B12A62B646B2B5D0E1419C1A460442474E2AF0",
  index: 2324,
  merkle_root: "9084BB7F7D5A722FC2075644E71C2A518545E33C27402376D19863721EF0063B",
  nonce: 32535345,
  previous_hash: "0000003987CE7A874B760D50B183232A8C910C29CC7342E858503656D687BEE2",
  timestamp: 1542634035,
  version: 1,
  transactions: [],
  my_favorite_food: "Pizza",
  my_favorite_binary: <<0, 12, 122, 255, 1, 4, 0, 23, 231>>
}

In this case, miners would store the extra fields my_favorite_food and my_favorite_binary on their disk, even though this benefits the chain in no way.

I propose we prune fields that we expect from received blocks and only store those. In this case, the above block would still be deemed valid, as it is, but we wouldn't store the extra data.

[alexdovzhanyn]

Fixed in #77