Bisq does not verify maker node is online when displaying offers aka ghost offers #4026
Comments
even if you restart your Bisq during that time? |
Yes.
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. |
Entire VM and node were deleted several days ago. It's just a ghost offer. |
|
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. |
|
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: " |
|
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). |
|
Observed 2 more ghost orders on 20-Mar-2020. They both 'bounce'.
|
|
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. |
|
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? |
|
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 ;-). |
and do not broadcast. It is unclear why we receive expired data (some are very old), but a manipulated node might produce that and as it only removed at each batch process running each minute to clean out expired data it still could propagate. Is an attack vector also to flood the network with outdated offers where the maker is likely not online. Should fix #4026
Description
After killing a Bisq node, its offers are still visible on the network for several days
Version
v1.2.7
Steps to reproduce
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
The text was updated successfully, but these errors were encountered: