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

ReorgSafe - Test PR for address freezing for centrally managed tokens #83

Open
wants to merge 65 commits into
base: 0.2.99-Z-DevelopBaseline
Choose a base branch
from

Conversation

zathras-crypto
Copy link
Owner

No description provided.

theuni and others added 30 commits December 8, 2017 09:03
The most recent update replaced the minimal image with a large one for the
'generic' image. Switching back to 'minimal' should reduce dependencies and
maybe speed us up some.

It should also eliminiate the need for aa2e0f0.
033b11a travis: move back to the minimal image (Cory Fields)
Note: rejected after interpretation so the transactions can still be viewed
zathras-crypto and others added 30 commits December 10, 2017 18:12
…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, 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
Note: Behaviour of AbortNode() can be inconsistent and we cannot be sure of the state the client will be left in.  During testing it was possible in some circumstances to simply restart the node and continue on after a forced shutdown.  This change destroys the persistence state to force a reparse in this case.
a6dd8a4 Force a reparse if a shutdown is forced (Zathras)
d630b68 Add test for client expiry (Zathras)
b8ceef1 Add back in forced (manual) client upgrade (Zathras)
cacfd70 Add foundation 3 of 5 multisig to authorized senders (Zathras)
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.

3 participants