[bisq-network/bisq] TempProposal objects transmit on every startup when already present on starting node (#3629)

[Julian Knutsen]

As part of investigating #3610, I found another bug in how `ProtectedStorageEntry` objects are persisted to disk. The result is that a node starting up does not properly format the `GetData` request from the seed node leading to retransmission of `TempProposal` payloads that it already knows about.

I am already working on this area as part of bisq-network/proposals#140 and it will likely show up as a failing test. Documenting this here in case people see behavior they don't understand.

## Tech Info
`ProtectedPayload` objects implementing the `PersistablePayload` interface are saved to disk by the `Sha256Ripemd160hash` but are loaded from disk expecting the `Sha256Hash`. This results in the keys in the hashmap being 20-bytes for the items loaded from disk and 32-bytes for the items sent from the seed node.

So, we ask the seednode to exclude the 20-byte key and it sends back the 32-byte key which both point to the exact same payload.

This is relevant for #3610 because we need to understand the behavior of non-upgraded nodes and their ability to propagate old `TempProposals` to the network.

More to come with how to address it.



-- 
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/issues/3629
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191118/7f19169d/attachment.html>