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

Yet another fix for reported withdrawals in transactions + underflow in case of key deposit reclaim #2010

Merged
merged 2 commits into from
Aug 10, 2020

Conversation

KtorZ
Copy link
Member

@KtorZ KtorZ commented Aug 7, 2020

Issue Number

#2009 + TODO

Overview

  • 5757a55
    📍 highlight reported failure in integration scenarios by adding more assertions

  • d5b4335
    📍 report our withdrawals differently from external withdrawals.
    We haven't been quite careful here when introducing the reward redemption and the transaction amount are looking weird again.
    This commit fixes several issues:

    1. It only counts withdrawals on the "spent" side of the balance if they are coming from OUR reward account. Indeed, in the case of external withdrawals, the money is coming from elsewhere and not from the wallet itself.

    2. Fix an underflow in the amount calculation in the case where we spent less than we receive. This can be the case when:
      a. We are redeeming from an external account and the reward brings more than the fee. From the redeeming wallet, it'll look like the wallet is receiving money.
      b. We are reclaiming a key deposit back, and it brings more money than what's actually spent.

    3. Discover transactions that are spending our withdrawals without belonging to our wallet. This happens when the reward is redeemed from another wallet. That transaction should still show up in the redeemed wallet, without which rewards would just "vanish" without any trace reported by the wallet.

Comments

  We haven't been quite careful here when introducing the reward redemption and the transaction amount are looking weird again.
  This commit fixes several issues:

  1. It only counts withdrawals on the "spent" side of the balance if they are coming from OUR reward account. Indeed, in the case of external withdrawals, the money is coming from elsewhere and not from the wallet itself.

  2. Fix an underflow in the amount calculation in the case where we spent less than we receive. This can be the case when:
    a. We are redeeming from an external account and the reward brings more than the fee. From the redeeming wallet, it'll look like the wallet is receiving money.
    b. We are reclaiming a key deposit back, and it brings more money than what's actually spent.

  3. Discover transactions that are spending our withdrawals without belonging to our wallet. This happens when the reward is redeemed from another wallet. That transaction should still show up in the redeemed wallet, without which rewards would just "vanish" without any trace reported by the wallet.
Copy link
Contributor

@paweljakubas paweljakubas left a comment

Choose a reason for hiding this comment

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

I thought we have already ourWithdrawal in model ... and what is left to be accounted are inputs when multisig txs are added. Using distance seems fine to avoid underflow error. So I bet in this or another PR the ourWithdrawal logic is going to be only in Model, right?

@KtorZ
Copy link
Member Author

KtorZ commented Aug 10, 2020

bors r+

@KtorZ KtorZ added the RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG label Aug 10, 2020
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Aug 10, 2020

Build succeeded

@iohk-bors iohk-bors bot merged commit 34a923c into master Aug 10, 2020
@iohk-bors iohk-bors bot deleted the KtorZ/2009/amounts-and-withdrawals branch August 10, 2020 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants