Research Spike: Can we get data / battery savings from compression?

[gmale]

GZip reduces text by over 70% but it also reduces battery drain by similar margins. GRPC offers an experimental compression feature and although binary (protobuf) data is not nearly as compressible as text, it still might offer significant savings on data size, which in turn saves battery usage.

This might even be enough to offset the data requirements when fetching all memos. Either way, with light clients being so data heavy, this is probably worth researching.

Time Box: 2 days

Desired outcome:

• determine whether it is possible to enable support for full stream compression in lightwalletd
• If so, setup a network metering test to determine approximately how much data is saved streaming 10,000 blocks. The percentage of data saved will equate roughly to the amount of battery saved, as well.

[defuse]

There's an interesting security problem that arises when you turn on compression.

(Aside to explain the attack.)
Suppose a client is receiving some compressed data that contains a secret, and you have control over part of the input data (but you have no control over the secret and other parts of the data). If you set the part of the data you can control to your guess for what the secret is, then if you guessed right it will compress better than if you guessed it wrong (because there's duplication when you guess right). This means there's a side-channel attack where the length of the compressed data tells you if you guessed right or not, and you can leak the secret this way.

We shouldn't avoid compression because of this, but we should make sure to check that whatever we do is not susceptible to it. It's not a problem at all if all of the data is already public, e.g. mempool and block contents. It only becomes a problem when some of the data is secret or depends on the identity of the client (i.e. leaking something about the data affects anonymity).