-
Notifications
You must be signed in to change notification settings - Fork 0
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
Test PR for address freezing for centrally managed tokens #82
base: 0.2.99-Z-DevelopBaseline
Are you sure you want to change the base?
Conversation
Note: waiting period activated by feature 14
Note: rejected after interpretation so the transactions can still be viewed
…roperty is managed
Note: includes minor comment correction
… frozen address/property
…g' transactions Note: TX71 no longer has a state. TX71 enables & TX72 disables.
Note: during some testing I picked up that while loading the freeze state at startup if there are multiple freeze/unfreeze transactions in the same block they may not be loaded in the correct order. Unlikely scanerio but we need to cover it just the same. This change just adds the tx position within the block to the sort order.
Note: addressBytes size check failed (didn't include version) so was never truncated to remove checksum. Note: also removes "unexpected size from DecodeBase58 when decoding address" erros from log.
Note: if we need to reverse a disable due to a reorg, we need to know when freezing was previously enabled to comply with waiting periods
liveBlock = block; | ||
} else { | ||
const CConsensusParams& params = ConsensusParams(); | ||
liveBlock = params.OMNI_FREEZE_WAIT_PERIOD + block; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing something, but can you quickly clarify what happens, if the sender wants to activate freezing at block height 1000? Does he have to send 1000-waitperiod or 1000?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sender doesn't have a choice in the wait period, it's defined in the consensus rules bud
Note, freezing should only affect the available balance, not prior actions The following steps could be done by anyone and would have tripped the assert: 1) List a trade from address A for prop N 2) Freeze address A for prop N 3) List a matching trade from address B
No description provided.