Status of the project. How you can get involved.

This document presents some attempt at helping developers. It covers:

  1. How to run a node, on the testnet (which will give you some data of each type to look at and play with).
  2. The data structures and messages of HM, and where they are located in the code and documentation.
  3. A list of already-completed dev work.
  4. A list of remaining dev tasks.
  5. Other ways to help.

I will post a new roadmap, as we move further along the road.

1 Getting Started

  1. Project Github
  2. Setting up a Hivemind node / installing dependencies
  3. Setup the testing environment and connect to the testnet
  4. After you have everything setup:
    1. Read the whitepaper
    2. Read doc/notes_blockchain.txt
    3. Read doc/notes_hivemind.txt
    4. Check out the issues page for Hivemind
    5. View the “Development TODO” section of this document.
    6. Do work in your own fork, and submit pull requests when you want to merge your progress.
    7. Submit improvements, bugs, via the Github Issues page.

2 Hierarchy of the Hivemind project

  1. To learn about the data structures and messages of Bitcoin-Hivemind please visit the whitepaper (Specifically appendix X) You may also want to take a look at src/primitives/market.h (mentioned later in the document in more detail)
  2. Important classes & files:
    1. tc_mat (src/linalg/tc_mat.h)
      1. SVD.
      2. RBCR.
      3. Matrix creation, deletion, clearing, resizing.
      4. Matrix manipulation (Multiplication, Scalar Multiplication, Subtraction, Addition, Transposition, Normalization).
    2. src/rpcwallet.cpp
      1. RPC calls for creating hivemind objects.
        1. createmarket
        2. createdecision
        3. createbranch
        4. createtrade
        5. createstealvote
        6. createsealedvote
        7. createrevealvote
      2. Informational RPC calls about hivemind objects.
        1. getmarket
        2. getdecision
        3. getbranch
        4. gettrade
        5. getvote
        6. getoutcome
    3. CMarketTreeDB (src/txdb.h)
      1. Access to the market database (blocks/market/).
        1. Note 1: Access is provided by global variable pmarkettree. You can access this by adding the following line to your source code: extern CMarketTreeDB *pmarkettree;
        2. Note 2: See class CMarketTreeDB in the file src/txdb.h for a list of accessors.
    4. src/primitives/market.h
    5. CHivemindAddress src/base58.h
      1. Code related to the addition of Votecoin addresses can be found here.
    6. GUI Classes
      1. ResolveVoteDialog – src/qt/resolvevotedialog.h
        1. for demonstrating the core functionality of Hivemind in the best possible testing environment without waiting for an entire TAU period / voting round. Essentially, a simulation of the Hivemind project’s functionality, which uses the actual code but does not affect the network in any way.
        2. With this dialog developers can simulate the core functionality of Hivemind without waiting what could be a long time for a voting period (n*tau).
        3. Additionally note that this is a good file to look at if you are trying to find functions that Hivemind uses, because most of them are used here.
      2. AuthorPendingTableModel – src/qt/authorpendingtablemodel.h
        1. This class is the backbone for the AuthorView. Functions for creating markets, decisions and combos is located here
        2. Note: Combo creation means that the user is creating a decision, and a market based on that decision at the same time. To allow for this, the decision is created first which will result in the decision creation transaction moving into the mempool. Then, decisions owned by the user in the mempool are moved into the local database. The market is then created based on the decision in the database, before it is ever mined
      3. AuthorView – src/qt/authorview.h
        1. The AuthorView is the widget from which Decisions and Markets are created GUI. This view provides access to both the DecisionCreationWidget and the DecisionMarketCreationWidget.
        2. This is the front end, the functionality of the AuthorView (actually creating decisions / markets) is implemented in the AutorPendingTableModel class
      4. DecisionCreationWidget
        1. The DecisionCreationWidget provides users with access to create a decision by creation json_spirit objects and passing them to the RPC.
      5. DecisionMarketCreationWidget
        1. The DecisionMarketCreationWidget provides users with access to the parameters to create a Decision.
      6. DecisionView
        1. The Decision view is an element of the old GUI, and is going to be removed / entirely replaced before release. That being said, it is also a great place to look if you are a developer, as from this widget users are able to create:
          1. Decisions
          2. Markets
          3. Trades
          4. Branches

3 Already Completed

  1. Multiple coin-type coexistence (Bitcoin, Votecoin, market share tokens) on the same blockchain
  2. Required additions to the database for data types of Hivemind (Decisions, Markets, Votes, Trades, Ballots etc)
  3. Added opcode for Hivemind market objects (Word = OP_MARKET)
  4. Creation of Decisions.
  5. Creation of Markets.
  6. Creation of Trades (buy/sell orders)
  7. RPCWallet calls to create the Hivemind market objects (Decisions, Markets, Trades etc)
  8. Informational RPCWallet calls related to Hivemind market objects
  9. Modifications to mining to add new market objects (trades, markets, decisions etc) to the blockchain at n * tau intervals
  10. The MarketTree class which allows developers access to the market branch and all of the market objects on the blockchain database
  11. The ResolveVoteDialog, for demonstrating the core functionality of Hivemind in the best possible testing environment without waiting for an entire TAU period / voting round. Essentially, a simulation of the Hivemind project’s functionality, which uses the actual code but does not affect the network in any way.
  12. The RBCR matrix algorithm - how votes become truth.
  13. Foundations of the GUI
  14. An implementation of a new GUI in QT, partially implemented on the main branch.

4 Development TODO

  1. “Canonical blockchain” for individual exploration and demonstration.
    1. Script to generate canonical data
    2. Data available to developers to sync / re sync (testnet seed node)
    3. Instructions for syncing and resetting the development environment (mostly finished on the testnet-canonical github repo)
  2. Voting cycle (votes are sealed to be revealed later, to avoid miner censorship of new votes)
    1. Create sealed votes
    2. Create “steal” votes
    3. Reveal sealed votes
  3. Finish gettrade and getvote in rpcwallet
  4. outcome->NA = defaultNA, if it conflicts it needs to be changed, i need to figure out when it can conflict and what it should be changed to in that case
  5. in getOutcomeTx() the trades that have been previously sold should be skipped
  6. Code refactoring
    1. Remove all “#if 0” disabled code blocks in the project. In many c++ and c files there are blocks of old / broken / unfinished code that is disabled by being enclosed with always false #if 0 statements. These blocks can be located with this grep command “grep -irnl ‘#if 0’”. These disabled code blocks should be either deleted or finished.
    2. Remove all goto statements that are not absolutely necessary (if not all, most of them should be removed). These statements make sense during development and are especially helpful in the large SVD functions, but they can create confusing code, especially to developers trying to get into the project. See https://files.ifi.uzh.ch/rerg/arvo/courses/kvse/uebungen/Dijkstra_Goto.pdf.
    3. A few rather large blocks of code in tc_mat should be made more modular to the extent that is sane / won’t make the class more complicated.
  7. Documentation of code (add comments to the header files etc), not of the project (which is explained in the whitepaper).
    1. Document Decisions (Relevant files & code, Purpose, How to use)
    2. Document Markets (Relevant files & code, Purpose, How to use)
    3. Document Branches (Relevant files & code, Purpose, How to use)
    4. Document Trades (Relevant files & code, Purpose, How to use)
    5. Document Votes (Relevant files & code, Purpose, How to use)
    6. Document Votecoins (Relevant files & code, Purpose, How to use)
    7. Documentation of the pmarkettree, the merkle tree for all market object (basically all hivemind specific data)
    8. Document what is unique to mining in Bitcoin-Hivemind
    9. Document OP_MARKET
  8. Merge updates and fixes from Bitcoin github repository
    1. Merge updates added to Bitcoin master, and fix the resulting issues that the new code causes. This should be done after unit tests and regression tests have been created.
  9. GUI TODO
    1. Trading Widget views
      1. Multi Dimensional
      2. High Dimensional
    2. Add QWT dependency
      1. Add to configuration and makefiles
      2. Test Linux
      3. Test Windows
      4. Test OSX
      5. Add to Gitian Building
      6. Test Gitian Building
      7. Add to github master
    3. Single Dimensional graphs - QWT
    4. Multi Dimensional graphs - QWT
    5. High Dimensional Graphs - QWT
    6. Visual representation of high-dimensional markets.
    7. Create a URI Scheme based on BIP 21 for trading views. Traders should be able to share the state of a trading window with other traders. This is useful in Bitcoin-Hivemind as traders may set up trading windows with many markets/dimensions. This trader can save time want to save that state for later to save time, or even share that trading window state with another trader.
    8. Voting Widget
    9. Ballot Widget
    10. Update Decision Widget
  10. Branch creation & branch splitting
    1. Branch creation must become a controlled process
    2. Branches must be able to split
    3. New branch should take new parameters
    4. Sub-branches should also be splittable
  11. Testing of the Hivemind project
    1. Development of unit tests
    2. Development of regression test
    3. tx-PoW (front running in non-Lightning mode)
    4. Markets built from Gratis Decisions.
    5. Assigning a new genesis block, with arbitrary Votecoin set.
    6. (low priority) Markets where you can’t sell (the assurance contract).
  12. Consensus threshold requirement for the outcome algorithm ( doc/notes_blockchain.txt ) minimum trading fee ( doc/notes_blockchain.txt )
  13. Liquidity sensitivity in markets ( doc/notes_hivemind.txt )
  14. (Discuss) Time lock Hivemind market object transactions (Specifically to set the eventOverBy and maturation values), see here
    1. Use parts of BIP 65 OP_CHECKLOCKTIMEVERIFY
    2. Decision “continuances”
      1. Buying a decision-slot in the future, before you know how much it is going to cost.
      2. Gratis Decision on the slot failing: Non-interactive time-locked refunds (See: Bip 65)
  15. Testing with real data and Bitcoin ($)
    1. Move real Bitcoin into the network (honeypot).
    2. Create other honeypots to expose vulnerabilities and implementation bugs.
    3. Solve issues, repeat.
  16. Big picture stuff
    1. Merged Mining:
      1. Modify headers for merged-mining
    2. Drivechain / 2-way-peg:
      1. Modify headers for Drivechain or 2-way-peg
    3. Communication / Integration between Hivemind & the Lightning Network
      1. Transferring shares between private keys.
    4. Sharing “Views” of markets (on social media).

5. Project (non-development) TODO

  1. Promotion
    1. Bug bounty (“open ended” – Basically, announce that money has moved into the network and see if anyone can take it, as planned)
    2. Videos
    3. Blog posts
    4. Bitcoin / general news articles
    5. Goals
      1. …attract more attention (security auditors, thieves, etc)
      2. …protocol discussion / awareness.
  2. Further research
    1. Welfare function for futarchy
  3. Upon completion of testing
    1. Create new main net genesis block
    2. If necessary, create new testnet and canonical blockchain
    3. Disable short tau testing
    4. Implement a process similar to Bitcoin core’s BIP system (we can call it HIP) and require that a HIP be submitted for any controversial changes to the project’s code.
comments powered by Disqus