Skip to content

wallet: asset unregister waits for CA.LockPeriod like the node (#1875) - #2164

Open
vsnation wants to merge 1 commit into
BeamMW:masterfrom
vsnation:fix/1875-asset-unregister-lock-period
Open

vsnation wants to merge 1 commit into
BeamMW:masterfrom
vsnation:fix/1875-asset-unregister-lock-period

Conversation

@vsnation

Copy link
Copy Markdown

Fix: the wallet allows unregistering an asset once CA.LockPeriod has passed, the same rule the node enforces, instead of waiting for MaxRollback.

Why: the node checks m_LockHeight + CA.LockPeriod > h (node/processor.cpp:4227), but AssetUnregisterTransaction pre-checked with WalletAsset::CanRollback, which is m_LockHeight + MaxRollback > h. On mainnet both are 1440, so nobody noticed. On a network with a different --CA.LockPeriod:

  • shorter lock period: the wallet fails the unregister with AssetLocked although the node would accept it;
  • longer lock period: the wallet sends a tx the node rejects.

That's what #1875 observed ("to change --CA.LockPeriod you also need --MaxRollback"). It's a wallet bug, not a documentation gap.

How to see the bug: on a test network started with, for example, --CA.LockPeriod=10 (default MaxRollback 1440), burn an asset completely, wait 11 blocks, and run beam-wallet asset_unreg --asset_id N. Master fails with AssetLocked until 1440 blocks have passed; this PR succeeds after 11 blocks, which is when the node accepts it. In code: compare node/processor.cpp:4227 with aunregister_transaction.cpp:120 on master.

Improvement

network rules master's wallet node this PR
LockPeriod 10, MaxRollback 20 locked until +20 unlocked at +10 unlocked at +10
LockPeriod 20, MaxRollback 10 allowed at +10 (node rejects) unlocked at +20 unlocked at +20
mainnet (1440 / 1440) +1440 +1440 +1440 (unchanged)

How: a new WalletAsset::IsLocked(h) uses the node's rule and is used for unregistering. CanRollback stays where it really is about rollbacks (asset info confirmation in base_transaction.cpp).

Testing: new TestAssetLockPeriod in wallet_assets_test covers LockPeriod/MaxRollback = 10/20, 20/10 and 20/20. If IsLocked is made to follow MaxRollback (the old rule), 2 checks fail. The existing asset flow (register, issue, burn, unregister of a locked asset, then unregister after the lock period) passes unchanged; its only failure is the known macOS-only check at line 195, which passes in CI. Fork CI (running): https://github.com/vsnation/beam/actions/runs/

Fixes #1875

…W#1875)

The node lets an asset be unregistered once CA.LockPeriod has passed
since it was burned (processor.cpp: m_LockHeight + CA.LockPeriod > h
means locked). The wallet pre-checked with WalletAsset::CanRollback,
i.e. MaxRollback, instead. Both are 1440 on mainnet, so it didn't show
there, but on a network with a different --CA.LockPeriod the wallet
followed MaxRollback: with a shorter lock period it refused
(AssetLocked) although the node would accept, with a longer one it sent
a tx the node rejects. That's why BeamMW#1875 found that --CA.LockPeriod
"only works together with --MaxRollback".

Add WalletAsset::IsLocked(h) with the node's rule and use it for
unregistering. CanRollback stays where it's about rollbacks (asset info
confirmation).
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.

Add to doc --MaxRollback affect --CA.LockPeriod for test network

1 participant