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

V0.12.1.x -- merging trigger/generic object/superblock changes for testnet phase II #932

Closed
wants to merge 44 commits into from

Conversation

eduffield222
Copy link

These are changes from Timothy Flynn and I that recreate the superblock creation process in sentinel, using generic objects and triggers. The code implements the following:

  • Proposals are now referred to as "Governance Objects", propasals are a type of governance object
  • Implement generic objects via new governance system
  • mngovernance is now gobject, so to see all proposals/objects you would execute "gobject list"
  • added serialized data to generic objects, allowing dashd a data agnostic way of storing user data
  • implemented triggers, which execute actions on the network after the network has voted approval. These are competitive, so if two triggers want to execute on the same block, only the winner, the one with more support will execute.

Evan Duffield and others added 30 commits June 3, 2016 15:11
- disable fCached values
- use two maps for storing votes, by hash and parent-hash/type
- disable part of flatdb.dump (still overwriting)
- fixed govobj/votes relay and sync
- Uncommented sync block
- Protocol min 70201
- Fixed bug which flags invalid votes incorrectly
- Formatting
- Should not collide based on the outcome
- Recalculate the cached status flags of various items when masternodes change status
  - Added some more debugging messages to track handling of trigger objects
  - Fixed GetDataAsString
  - Fixed handling of JSON structure from sentinel in LoadData
  - Fixed missing iterator increment in GetActiveTriggers
eduffield222 and others added 9 commits August 7, 2016 08:17
   trigger manager access is now protected only by the governance.cs mutex
 - Removed unsafe caching of govobj pointer in CSuperblock
 - Moved status from map to CSuperblock
 - Reduced width of public interfaces to CTriggerManager and CSuperblockManager
 - Implemented removal of executed and invalid (but not expired) triggers
 - Reordered CSporkMessage members to avoid structure padding
   (note serialization format is unchanged)
 - Replaced X11 hash with CHashWriter for CSporkMessage
   now causes the removal of the underlying govobj
 - Added many LOCK(governance.cs) calls to hopefully make access to
   CGovernanceManager safe.  This needs heavy testing or better yet
   static analysis to guarantee correctness.  Deadlock conditions cannot
   yet be excluded.
…to remotes/upstream/v0.12.1.x-triggers

Merged change from upstream.
    - Implemented caching of block height in CGovernanceManager to avoid
      possible deadlock between cs_main and governance.cs mutexes
    - Implemented expiration of unexecuted triggers approximately
      one month after their scheduled trigger time (per Evan's request)
    - Removed unused chain tip pointer in rpcgovernance.cpp.  Fixes compiler
      warning and avoids an unnecessary lock on cs_main.
@schinzelh
Copy link

Nice - it needs to be rebased though :-)

@@ -77,6 +77,7 @@ class CMainParams : public CChainParams {
consensus.nMasternodePaymentsIncreaseBlock = 158000; // actual historical value
consensus.nMasternodePaymentsIncreasePeriod = 576*30; // 17280 - actual historical value
consensus.nBudgetPaymentsStartBlock = 328008; // actual historical value
consensus.nSuperblockCycle = 576; // Superblocks can be issued daily

Choose a reason for hiding this comment

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

AFAIK this value is to high, there are only ~554 blocks/day

@UdjinM6
Copy link

UdjinM6 commented Aug 10, 2016

some file permissions are broken100644 → 100755, this should be reverted to old permissions

@eduffield222
Copy link
Author

Closing in favor of #944

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.

5 participants