Change Details

This diff introduces a new getavaproofs message, which has similarities with the getblocks message. It requests the peer for an inventory message with all the proof ids it knows. This will be sent after we got a new proof, expecting to get more from the same peer. The inventories still follow the same rules and will not be sent several times to the same peer. We also limit the quantity of invs to store in the `setInventoryProofToSend` to avoid our memory to grow unbound. Note that this limit is left untested because it is very time consuming (it requires to build over 1000 proofs) and is trivial enough. Other solutions have been evaluated, especially using a short id computation on proofs so reduce the bandwidth. However this will require either costly lookups or large cache memory for requesting the missing transactions, so this solution has not been selected.

This diff introduces a new `getavaproofs` message, which which requests for an `avaproofs` message containing all the proofs short ids from the peer. Notes: - The name does not contain the "compact" mention like one might expect, due to the limitation in the command name to 12 chars. - There is a theoretical limit of 21 millions proofs which could cause the node to generate a oversized message (limited to 2MiB). This will be taken care in a follow-up. Depends on D11454.

This diff introduces a new getavaproofs message, which has similarities with the getblocks message. It requests the peer for an inventory message with all the proof ids it knows. This will be sent after we got a new proof, expecting to get more from the same peer. The inventories still follow the same rules and will not be sent several times to the same peer. We also limit the quantity of invs to store in the `setInventoryProofToSend` to avoid our memory to grow unbound.`getavaproofs` message, Note that this limit is left untested because it is very time consuming (it requires to build over 1000 proofs) and is trivial enoughwhich which requests for an `avaproofs` message containing all the proofs short ids from the peer. Other solutions have been evaluated,Notes: especially using a short id - The name does not contain the "computation on proofs so reduce the bandwidth.act" mention like one might expect, However this will require either costly lookups or large cache memory for requesting the missing transactions,due to the limitation in the command name to 12 chars. - There is a theoretical limit of 21 millions proofs which could cause the node to generate a oversized message (limited to 2MiB). so tThis solution has not been selectedwill be taken care in a follow-up. Depends on D11454.