Make sure witness data is stripped from the seller's prepared deposit
tx, in addition to ScriptSig data, to prevent the buyer from being able
to publish it prematurely (before having signed the delayed payout tx).
These are failing on the tip of release/1.5.0 currently due to extra
validation added to PersistenceManager, causing the build to fail upon
merging upstream. Add missing PersistenceManager.shutDown calls to the
tearDown methods of the affected tests to fix.
We need to set addDecryptedDirectMessageListener without
delay as otherwise we could miss direct messages (detected
with localhost testing, with tor its likely slower and
would not have been triggered).
This is not really needed as we call it at each state change of the
trade but gives more redundancy in case we missed one or once
changes are applied and a dev forgets to call it.
Multiple repeated calls do have close to zero costs.
The deposit confirmed state is set after we applied the mailbox messages,
which led to a task failure due wrong phase and the message was not applied.
Further it can be that the wallet is still syncing and the deposit
confirmed state is set in any time in the future.
To fix the first problem we add a bit of delay so that the trade has
been updated when we apply the mailbox messages. A better fix would be to change
the order of the methods but that is a bit tricky to get right and I dont want to
risk that for that release.
The second problem would require a large change to trigger the mailbox
processing based on wallet state. We prefer to be more tolerant with
the expected phase instead so allow the mailbox message to be processed
also in the DEPOSIT_PUBLISHED state.
This has no risks as the payout tx would be invalid anyway if the
buyer has cheated and sent the msg in not confirmed deposit tx state (only
possible with code manipulation).
A better fix would to add a listener for the wallet and process
the mailbox msg once wallet is ready and trade state set, but I
leave that for another PR.
We relied on the shutdwon routine to be called reliably but it seems that is not the case as some bug reports show.
So we call requestPersistence at every write access of the trade object
We saw that some seed nodes have 2 filters after filter update.
This should not be the case as the remove is broadcast before the
add but seems there is some issue in the P2P storage which does
not cover that correctly.
By adding a 5 sec delay between the remove and add we mitigate
that issue, though should be fixes in the P2P layer but that
will be a more complex and larger effort.
Seems the persistence at shutdown is too unsafe and we got bug reports where data was missing.
https://github.com/bisq-network/bisq/issues/4806
Use millisec instead of sec for delay
Rename delayInSec to delay
Showing 'x' days until limits lifted (signed, pending)
Showing clock icon (signed, pending)
Showing outlined check icon (aging accounts)
Showing account age (unsigned or aging)
Changed column name from 'Signed since' to 'Account info'
Fixed bug when switching between altcoins and fiat order books
the account info column was being added back to the table in
the wrong position.
(which can happen in rare cases) and add guards that we never create multiple instances
for a given file as well not call initialize or other API methods after shutdown was started.
