Bisq does not verify maker node is online when displaying offers aka ghost offers

[wiz]

Description

After killing a Bisq node, its offers are still visible on the network for several days

Version

v1.2.7

Steps to reproduce

1. Create an offer
2. kill -9 bisq

Expected behaviour

Offer should disappear from the offer book after a few minutes

Actual behaviour

Offer is still visible on the market after several days

[freimair]

Actual behaviour

Offer is still visible on the market after several days

even if you restart your Bisq during that time?

[ghost]

@freimair

even if you restart your Bisq during that time?

Yes.
There is currently one such order at the top of the BTC/USD buy offer list; it has been there over 3 days. When you click to take the offer it does a check and says you cannot take that offer.

The ghost offer stays there many days, regardless of how many times you reboot your own client.

[edit] This same ghost order is still at the top of the USD book, 7 days old now. Interestingly enough it was not there yesterday. Another interesting thing is the user's onion address is about 3x longer than all the other users in the system.
Ping @freimair @wiz

[wiz]

even if you restart your Bisq during that time?

Entire VM and node were deleted several days ago. It's just a ghost offer.

[freimair]

that is quite interesting. Offers have a timeout of 9 minutes. If your client does not "RefreshOffer" it will disappear. At least that is how it works/worked.

The RefeshOffer stuff has been made to reduce network load. If every client asks if the offer is still available we would have to deal with a substantially more messages. So I am not particularly fond of doing that.

Is this a one-off or is there a pattern to it? Because I am not able to reproduce the issue by following the steps provided by @wiz.

[ghost]

Looking for a 'maker offline' ghost offer, found something similar. There's an offer that constantly bounces on and off the list of available offers. On for a variable amount of time, off for 2 to 16 seconds. Clicking to take the offer pops up the error: "Take offer attempt rejected because of: OFFER TAKEN". Even after a reboot it shows up. Seems strange to keep appearing and disappearing when it is already taken.
[edit] The same user has two other active offers that do not bounce and are not taken.

[freimair]

one scenario I can think of that is creating a ghost offer is when someone had to delete her tor files. Therefore, the offer is still refreshed but the original host is no longer available (this is fixed in #4021).

but that of course does not explain having the ghost offer after shutting down the whole machine (@wiz) or a reappearing offer (@jmacxx).

[ghost]

Observed 2 more ghost orders on 20-Mar-2020. They both 'bounce'.

[chimp1984]

I can confirm there is an issue. We receive many outdated offers from the seed nodes. I will add an isExpired check at the point when we receive the data so they will not end up in the storage anymore. But we should find out why seed nodes are sending out expired data. They should run the expired check every minute and remove such items.

[chimp1984]

I can confirm there is an issue. We receive many outdated offers from the seed nodes. I will add an isExpired check at the point when we receive the data so they will not end up in the storage anymore. But we should find out why seed nodes are sending out expired data. They should run the expired check every minute and remove such items.

This issue was reported nearly 2 months ago. Nobody had time to look into it?

[chimp1984]

We receive from seed nodes lots of expired data as well as from our peers over broadcast messages. We check 60 sec for expired data and remove it but if an attacker (or dev who manipulated code without knowing what he does) broadcast all the time to the network outdated data we get still polluted as it takes each node 60 seconds to clean up.

#4215 adds a expire check when we receive the data and return if it is expired, thus avoiding that those data is stored and further broadcast.

If we still see many such expired messages we should check the address of that peer and at him to the ban list, once the release is well propagated. But at current situations all nodes would broadcast such data so we must not ban those ;-).