✅ All reviewers have approved.

Quick reminder that here eth/68 was updated: ethereum/devp2p@6b259a7

On this issue it was discussed:

ethereum/devp2p#245

See: ethereum/devp2p#245 (comment)

So maybe we want to include this as well in eth/69 or whatever version gets choosen here? (have no strong opinion to include this though)

I've renamed the proposal to eth/69 now after discussing with @smartprogrammer93 as this will likely go in before the proposal that drops history. Thanks again!

@jochem-brouwer Do you think we should change the protocol to use the previously proposed mechanism? I would prefer leaving it as is and enshrining the "bug"

The commit 127877f (as a parent of b59d95c) contains errors.
Please inspect the Run Summary for details.

@jochem-brouwer Do you think we should change the protocol to use the previously proposed mechanism? I would prefer leaving it as is and enshrining the "bug"

I have no strong opinion here, I think just leaving it in as bug is fine :)

I did some more benchmarks and determined the floor for bandwidth improvements to be at ~95GiB.
I converted the receipts of a node from non-bloom to with bloom (and compressed them with snappy) and the disk usage for receipts goes up from 179.07GiB to 273.28 GiB, so up by 94.21 GiB. The theoretical increase should be 530GB, so the snappy compression is quite good. We can not expect the same level of compression on the wire though, but this gives us a good floor for this improvement in terms of bandwidth