compact block fingerprinting #28272

1. 
   Crypt-iQ commented at 1:27 pm on August 15, 2023: contributor

   I haven’t written a test for this, but it seems that a peer can fingerprint a chunk of our mempool by announcing a new compact block with a valid header, but inserting many shorttxids that don’t belong to the block but are suspected to be in our mempool. Assuming no short id collisions, we’ll then request each tx that we didn’t find in either vExtraTxnForCompact or the mempool.

   I’m not sure how to fix this since compact block relay relies on this behavior. One possible way of fixing this was brought up here #27086 (comment).

2. MarcoFalke added the label P2P on Aug 15, 2023
3. MarcoFalke added the label Privacy on Aug 15, 2023
4. 
   MarcoFalke commented at 1:42 pm on August 15, 2023: member

   I guess this relates to the TODO as well: https://github.com/bitcoin/bitcoin/blob/80d70cb6b04b5a3c13e661c0718a4b5108d55869/src/blockencodings.cpp#L24
5. 
   Crypt-iQ commented at 1:53 pm on August 15, 2023: contributor

   I think implementing the TODO might add round-trips and maybe leak what we had in our own mempool prior to block acceptance?
6. 
   Crypt-iQ commented at 3:18 pm on August 25, 2023: contributor

   There are two cases to think about here that currently leak some info:

   1. we have the tx, so we won’t request it
   2. we don’t have the tx, so we will request it

   To solve both cases, we could choose some transactions to request even if we have them. For example, if we need X transactions to reconstruct the block, we could request Y transactions in GETBLOCKTXN where we have the other Y-X transactions. Adding these decoy transactions increases the BLOCKTXN response and could cause more round trips. We would also have to ignore the known transactions in BLOCKTXN.

   If there are too many txn’s that we’re missing, we could fall back to block relay instead of trying to add many decoy transactions. According to this data point, compact block reconstruction works pretty well. Most of the time no reconstruction happens and sometimes only a few txn’s are needed. So falling back to block relay should be unlikely.

   Since quick compact block relay is pretty important to avoid stale blocks, I’m not really sure how to weigh the privacy-bandwidth tradeoff.

7. 
   mzumsande commented at 3:49 pm on August 25, 2023: contributor

   After #27675 (but also before, with a few more restrictions), we relay any tx from our mempool (except for those that arrived after the last INV sent to the peer), so someone wanting to fingerprint our mempool could just ask for those transactions directly instead I think and then check whether we send it to them or answer with NOTFOUND.

   So I wonder why would someone trouble themselves with doing compact blocks for this, which would involve either creating a new valid block header (expensive) or trying to be the first to announce a compact block found by someone else to the victim (which has timing issues), if they could just ask for this info directly? (this doesn’t apply to block-relay-only peers though).

Contributors
Crypt-iQ MarcoFalke mzumsande

Labels
P2P Privacy