feefilter messages being sent too often

rebroad commented at 3:35 pm on April 8, 2021: contributor

I have noticed (after adding a debug line) that feefilter messages are being sent more than once to a peer even if the MinRelayFee has not changed:-

2021-04-08T15:24:47.454 send feefilter 5959 (actual: 6006) peer=33 2021-04-08T15:25:03.770 send feefilter 6554 (actual: 6006) peer=34 2021-04-08T15:26:30.933 UpdateTip: new best=0000000000000000000b2b33e937dfaf38000d52ecd2d5d3620838cb37288c6d height=678337 version=0x3fffe000 log2_work=92.795673 tx=632211134 date=‘2021-04-08T15:26:09Z’ progress=1.000000 cache=18.9MiB(140609txo) 2021-04-08T15:27:37.803 send feefilter 6554 (actual: 6006) peer=33

I would have thought a feefilter message should only be sent if there has been a change since the last message was sent.

rebroad added the label Bug on Apr 8, 2021

amitiuttarwar commented at 5:25 pm on April 8, 2021: contributor

@rebroad, a question for you, in these logs we send

5959 to peer 33
6554 to peer 34
6554 to peer 33

What part seems unexpected- the two messages to peer 33? or the two 6554 messages to different peers?

MarcoFalke added the label Questions and Help on Apr 9, 2021

MarcoFalke removed the label Bug on Apr 9, 2021

MarcoFalke removed the label Questions and Help on Apr 9, 2021

MarcoFalke added the label Brainstorming on Apr 9, 2021

MarcoFalke added the label TX fees and policy on Apr 9, 2021

fanquake added the label Waiting for author on Apr 11, 2021

rebroad commented at 12:50 pm on April 15, 2021: contributor

@rebroad, a question for you, in these logs we send

5959 to peer 33

6554 to peer 34

6554 to peer 33

What part seems unexpected- the two messages to peer 33? or the two 6554 messages to different peers?

the two messages to peer 33 - given that the actual value did not change.

ajtowns commented at 8:12 am on April 20, 2021: member

the two messages to peer 33 - given that the actual value did not change.

There’s a few different variables here – DEFAULT_MIN_RELAY_TX_FEE, m_mempool.GetMinFee(), minRelayTxFee, and lastSentFeeFilter; not sure which of these is actual in your log – I’m assuming you’re the 6554/5959 values are filterToSend.

rebroad commented at 11:17 am on April 29, 2021: contributor

the two messages to peer 33 - given that the actual value did not change.

There’s a few different variables here – DEFAULT_MIN_RELAY_TX_FEE, m_mempool.GetMinFee(), minRelayTxFee, and lastSentFeeFilter; not sure which of these is actual in your log – I’m assuming you’re the 6554/5959 values are filterToSend.

the “actual” is the currentFilter variable, before the round() is applied to it (for privacy reasons).

rebroad renamed this:
~~feefilter messages being too repetitively~~
feefilter messages being sent too often
on Apr 29, 2021

rebroad commented at 3:59 pm on April 29, 2021: contributor

@MarcoFalke I’d argue that this is a bug as there’s no need to send multiple feefilter messages (going up and down each time around the actual feefilter) - in fact, this wobbling of the number reveals the actual number more than it would otherwise reveal without the wobbling.

MarcoFalke commented at 5:46 am on April 30, 2021: member

Not sure this is an issue. #21805 (comment)

rebroad commented at 10:54 am on April 30, 2021: contributor

@MarcoFalke replied at #21805 (comment)

ajtowns commented at 1:32 pm on April 30, 2021: member

I think the advantage of doing it this way is that it means your peer will see the same behaviour when your feefilter is constant and when it’s only changing by small amounts (and staying in the same fee bucket). That seems like a small privacy advantage (you’d otherwise be revealing that your mempool isn’t changing enough for your feefilter to adjust?), and not a significant cost to me.

Note that it is sending a different fee filter to the peer, so the message isn’t a no-op – it will change what txs your peer sends to you.

MarcoFalke commented at 9:09 am on May 1, 2021: member

Closing for now because this is a change too controversial without any significant benefits and potential risks due to complexity increase and privacy-loss. Feel free to continue discussion, though.

MarcoFalke closed this on May 1, 2021

mzumsande commented at 9:37 am on May 1, 2021: member

I think the reason for the randomness in sending the upper/lower bound of the current fee bucket (the “wobbling”) is to obfuscate not only the exact value of the mempool minFee within its current bucket, but also the bucket it’s currently in, leading to a range of possible values for minFee that is twice as large than without this mechanism, and thus to more privacy. Your peer doesn’t know that your minFee hasn’t changed.

If we’d always send the lower bound of the current bucket, it would be transparent that our minFee is somewhere within one bucket (and is still there if we send no updates). The way it is implemented, our minFee could be anywhere within the two buckets bordering the last sent feefilter value.

So, the current mechanism does seem intentional to me.

rebroad commented at 6:57 am on May 3, 2021: contributor

The pull request linked to this issue REDUCES privacy loss. @MarcoFalke have you turned on logging for when feefilters are sent and seen for yourself the issue I am talking about?

It is possible I am seeing it more often due to using a different algorithm for calculating the minrelayfee - the new algorithm makes it stay at one number for longer than the current algorithm - the intention also to be to help reduce the number of feefilter messages - but due to the wobble, it currently doesn’t.

Is the wobble intentional?

FYI - an example of my minrelayfee (as I’m running #21618) , showing that it does stay constant more often than the current algorithm:-

rebroad commented at 7:01 am on May 3, 2021: contributor

I think the reason for the randomness in sending the upper/lower bound of the current fee bucket (the “wobbling”) is to obfuscate not only the exact value of the mempool minFee within its current bucket, but also the bucket it’s currently in, leading to a range of possible values for minFee that is twice as large than without this mechanism, and thus to more privacy. Your peer doesn’t know that your minFee hasn’t changed.

If we’d always send the lower bound of the current bucket, it would be transparent that our minFee is somewhere within one bucket (and is still there if we send no updates). The way it is implemented, our minFee could be anywhere within the two buckets bordering the last sent feefilter value.

So, the current mechanism does seem intentional to me.

Combined with the knowledge of the algorithm being used to calculate the minrelayfee, then it can be deduced that the minrelayfee stayed the same. I think deducations can always be made when enough info is known about the algorithms being used. Given this, the only difference that the wobbling provides is to waste bandwidth.

Also… why is it so important to not reveal our minrelayfee?

MarcoFalke commented at 7:07 am on May 3, 2021: member

Also… why is it so important to not reveal our minrelayfee?

It may serve as a unique fingerprint if your node has multiple connections that are not meant to be tied to the same network node.

Though, there are also ways to ask a node for the “exact” mempool min fee by paying a few satoshis in tx fees.

mzumsande commented at 11:18 am on May 3, 2021: member

Combined with the knowledge of the algorithm being used to calculate the minrelayfee, then it can be deduced that the minrelayfee stayed the same. I think deducations can always be made when enough info is known about the algorithms being used.

No, because the algorithm uses a RNG, and our peer can’t know how it is seeded (see here).

If we send a feerate of 5959 at t1 and 6554 at t2 that could be because 1.) The minFee stayed constant 2.) The minFee moved anywhere within its original bucket 3.) The minFee moved up one bucket 4.) The minFee moved up two buckets (at t1, we reported the upper bound of bucket 0, at t2 we reported the lower bound of bucket 2 Our peer can’t know which one is the case.,

rebroad commented at 11:23 am on May 5, 2021: contributor

@MarcoFalke please can you re-open this issue given that it is still an issue? @mzumsande but if a node is alternating between two numbers over a prolonged period of time, then it does become quite clear that the actual minrelayfee is between those two numbers - therefore my first pull request did help to provide extra privacy by stopping it doing that. My second pull request doesn’t stop the wobble, but it does reduce some cases where it would be revealed. The first pull request is the one I would suggest to stop the wobble altogether though. @MarcoFalke what are your objections to the first pull request please? Why is it controversial? What is the privacy loss that you claim it provides? And how is providing more privacy (which I believe it does provide) not a significant benefit? Plus, reduced traffic also.

DrahtBot locked this on Nov 28, 2022

feefilter messages being sent too often #21635