[bisq-network/bisq] Fix DAO sync issue requiring a manual kill-and-restart (#3266)

[Florian Reimair]

This PR prevents the Bisq application to never get its DAO status updated without a force-kill and restart of the application over and over again.

This fix is not final, however, this core issue is not easily resolved. The DAO sync logic tries one seed node after another until the DAO status is received. The very first attempt targets the seed node that already delivered the initial data. However, when the first attempt fails for whatever reason, other seed nodes are tried. The issue is that even if a connection can be summoned to such a seed node, the local Bisq client does not know its capabilities (these only get updated once a node responds with a suitable message), the DAO sync message, however, requires a capability. Bottom line is, the local Bisq app does not send the DAO sync message to seed nodes other than the initial one.

This PR fixes the issue by having the DAO sync message not requiring any capabilities. As this change only affects clients and not other nodes, this does not change the attack surface of the Bisq network.

fixes #3094
You can view, comment on, or merge this pull request online at:

  https://github.com/bisq-network/bisq/pull/3266

-- Commit Summary --

  * GetBlocksReq is no CapRequiringPayload anymore

-- File Changes --

    M core/src/main/java/bisq/core/dao/node/messages/GetBlocksRequest.java (16)

-- Patch Links --

https://github.com/bisq-network/bisq/pull/3266.patch
https://github.com/bisq-network/bisq/pull/3266.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/3266
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190916/8239a5b0/attachment.html>