Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent that a wrong tx is set as deposit tx #4880

Conversation

chimp1984
Copy link
Contributor

@chimp1984 chimp1984 commented Dec 2, 2020

Fixes #4873

Beside what is mentioned in #4873 I found another (minor) issue. We use an immutable list for address entries but the coinLockedInMultiSig value was set in the object via a setter. This change would be lost when accessed as when one open the wallet tool with cmd+j (after take offe the value was 0 there instead of the locked up funds). As the field is only used for lookup for locked funds from failed trades the bug was not very visible.
coinLockedInMultiSig is now a final field set by the constructor.

EDIT: used wrong issue before...

We check if the txIds of the inputs matches our maker fee tx and taker fee tx and if the depositTxAddress we
use for the confidence lookup is use as an output address.
This prevents that past txs which have the our depositTxAddress as input or output (deposit or payout txs) could
be interpreted as our deposit tx. This happened because if a bug which caused re-use of the Multisig address
entries and if both traders use the same key for multiple trades the depositTxAddress would be the same.
We fix that bug as well but we also need to avoid that past already used addresses might be taken again
(the Multisig flag got reverted to available in the address entry).
…ries.

Remove swap for MULTI_SIG entries at resetAddressEntriesForPendingTrade
…ructor.

Rename getCoinLockedInMultiSig to getCoinLockedInMultiSigAsCoin
Add comments

We use an immutable list when operating on AddressEntry so changes on the
object would not be reflected in the list.
The only mutable field (beside non critical cache fields) is the keyPair.
Might be good to refactor that as well at some point.
- resetCoinLockedInMultiSigAddressEntry
- setCoinLockedInMultiSigAddressEntry
- renamed methods
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK - I have tested this applied to release/v1.5.0 codebase.
It does close #4873.
However I do not see any relation to #4879. In my view they are separate issues.
[EDIT] Scratch that, on further thought, it could definitely relate to #4879. When the problem was happening, I saw the same "protocol did not complete in 30 seconds" issued by the maker side of the trade (but I was mostly focusing on the taker side where the bug manifested). 👍 So yes, all good.

@chimp1984
Copy link
Contributor Author

However I do not see any relation to #4879. In my view they are separate issues.

Sorry I made a mistake with the issue #. Have not looked closer to #4879 so not sure if its the same issue. Might have been from missing persistence as well...
A clear indicator for that bug is an error message with wrong phase as the old tx is confirmed and that let the trade protocol fail as that is not expected at that stage.

@chimp1984
Copy link
Contributor Author

After a look to #4879 I dont think thats related.

NullPointerException
at bisq.core.trade.protocol.ProcessModel.getTradeWalletService(ProcessModel.java:342)

If it was a pre 1.5.0 version it is likely fixed.

@ghost
Copy link

ghost commented Dec 3, 2020

Repeat ACK

@chimp1984
Copy link
Contributor Author

Replaced by #4883

@chimp1984 chimp1984 closed this Dec 3, 2020
@chimp1984 chimp1984 deleted the fix-bug-with-wrong-deposit-tx branch December 3, 2020 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant