Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

Fix Index reuse for zero ExistentialDeposit configured chains#1966

Closed
mnaamani wants to merge 4 commits intoparitytech:masterfrom
mnaamani:mok-indices-reuse
Closed

Fix Index reuse for zero ExistentialDeposit configured chains#1966
mnaamani wants to merge 4 commits intoparitytech:masterfrom
mnaamani:mok-indices-reuse

Conversation

@mnaamani
Copy link
Copy Markdown
Contributor

In chains that choose to allow zero ExistentialDeposit, the definition of a dead account is no longer the same as when existential deposit is greater than zero. In other words an account with zero balance is not considered dead. This has an impact on when an account index is (incorrectly) reused.

In addition it really only makes sense for an account index to remain associated with the same account as long as the total balance is still positive. After an account is reaped it is reasonable to create a new account index.

This PR addresses these two points:

  1. prevents incorrect account index reuse by changing implementation of the IsDeadAccount trait for the balances module.

  2. Only calling new_account() when both the freebalance and reservedbalance components of an account don't exist

@parity-cla-bot
Copy link
Copy Markdown

It looks like @mnaamani signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

1 similar comment
@parity-cla-bot
Copy link
Copy Markdown

It looks like @mnaamani signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@mnaamani
Copy link
Copy Markdown
Contributor Author

Should my PR make necessary changes to runtime spec version and update package version and dependencies or is that left to maintainers?

@mnaamani mnaamani changed the title Fix case for zero ExistentialDeposit configured chains Fix Index reuse for zero ExistentialDeposit configured chains Mar 12, 2019
UpdateBalanceOutcome::AccountKilled
} else {
if !<FreeBalance<T>>::exists(who) {
if !<FreeBalance<T>>::exists(who) && !<ReservedBalance<T>>::exists(who) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This should probably call Self::is_dead_account

@bkchr
Copy link
Copy Markdown
Member

bkchr commented Mar 12, 2019

I think your changes does alter the logic in a way, that you would need to modify more of the module to make this correct. But I'm no expert for this module.

@bkchr
Copy link
Copy Markdown
Member

bkchr commented Mar 12, 2019

Let's wait for @gavofyork.

@xlc
Copy link
Copy Markdown
Contributor

xlc commented Mar 12, 2019

The easy way (not sure if it is the best way) is just supply a trait implementation of IsDeadAccount that always return false and it should disable indices reuse.

@gavofyork
Copy link
Copy Markdown
Member

gavofyork commented Mar 12, 2019

I'm still unclear on precisely which circumstances this PR is designed to change.

{
fn is_dead_account(who: &T::AccountId) -> bool {
Self::total_balance(who).is_zero()
!<FreeBalance<T>>::exists(who) && !<ReservedBalance<T>>::exists(who)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Under what conditions do you expect these not to be equivalent?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

When existential deposit >= 1 they will always be equivalent because if the balances become too low, the FreeBalance::remove() and ReservedBalance::remove() will be called to remove the account and calling total_balance(who) will return zero.

The condition where these two are not equivalent is when existential deposit is equal to zero, with the expectation that an account will never be considered closed/dead after it has received a transfer, even if its total_balance goes to zero at some later time.

@bkchr
Copy link
Copy Markdown
Member

bkchr commented Mar 13, 2019

I think this one will not be merged, so I will close it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants