Page 28, it is unclear if cost of opposing a motion is similar to cost of making a motion.

To oppose do users need 0.1% reputation and stake 0.1% in token as a fraction of domain holding?

Document states 'if keep side receives sufficient support, a dispute is created'. What is defined as sufficient support? Reaching 50% reputation?

Section 7.7 models a worst-case DoS attack on rep mining, but the figures given don't quite add up and some of the assumptions aren't fully stated (such as being based on a 10-minute defense window, and requiring a manual hash invalidation). Make the example more clear and up-to-date.

Here we list changes that are a result of implementing the white paper (see work in JoinColony/colonyNetwork repo). These are grouped by corresponding section to ease updates so insert in appropriate order.

• 6.2.1 Reputation change from contributing to a task

• Specify the reputation earned by Task evaluator, e.g. For the purposes of calculating earned reputation the rating of the evaluator is assumed to be the same as the maximum of that of a manager, i.e. a 5.

• Be explicit about the domain or skill where reputation is earned i.e for manager and evaluator: domain rep for worker domain + skill rep.

• 7.4 Submission of a new root hash

• Use the uint256 converted keccak256 hash for comparison to target in keccak256(address, N, hash) < target

• In "Who can submit a new root hash?" section the following is actually implemented so that the target increases to that maximum in the space of an hour rather than 150 blocks.

At the beginning of the submission window, the target is set to 0 and slowly increases to 2^256 - 1 after 150 blocks

• WP says that stake is divided by 10**15 to determine N. In fact, it is divided by the MIN_STAKE which is 2000 * WAD == 2000 * 10**18

• 7.8 Costs and Rewards of mining

• "Finally, this transaction also makes the miners eligible to claim their CLNY token reward." - there is no such claim process. Rewards for mining are immediately reinvested.

In section 7.8 (reputation mining rewards), equation 3 is incorrect:

w_n = (1 - exp{t_n / T})(1 - (n - 1)/N)

The term (1 - exp{t_n / T}) should be (1 - exp{-t_n / T}), with the exponential term going to 0 as t_n goes to infinity.

Page 24, editing TotalRequested resets funding proposal reputation to zero.

It is unclear how this reset helps the stated intention of "for changes to funding to be potentially quick".

Shoudn't Zero reputation decrease the rank of the FP, and slow its funding streams?

See JoinColony/colonyNetwork#195 for starters.

Regarding the custom fork of ganache, it's better to use block.timestamp rather than the number of blocks to measure duration on chain - with hardforks, block times can change and may do so drastically when PoS arrived. I realise the whitepaper says 500k blocks, but frankly that is a holdover from us being idiots and not knowing any better. Replace this with sixty days, which I imagine is what we were aiming for in the first place.

I hope the delving you did in to ganache was educational though! It's been a while since I got grubby in its internals, but I learned a lot when I did so.

Page 25, with 100 % of domain reputation backing the BFP, funding rate is 50% of domain tokens per week.

Does that mean quickest funding rate for a BFP is two weeks?

PFP can be used for immediate funding needs with explicit voting.

Is there a funding rate in between? Or can the 50% rate be adjusted? Now our only options are get money now, or in the best case in 2 weeks.

• 6.3 On-chain representation of skills and domains

The parent_n_id line in
https://github.com/JoinColony/Colony-Whitepaper/blob/master/reputation/reputation.tex#L69-L82

evolved into an array
https://github.com/JoinColony/colonyNetwork/blob/develop/contracts/ColonyNetworkStorage.sol#L47

We should have something like:

parents[...]: array of ancestors where parents[i] is the (i ^ 2)th ancestor of the node. parents[0] is the direct ancestor.

I found the description & code somehow confusing, a few notes on what I understood:

Skills / Domains are Tree of Nodes.
Each node has a pointer to its parent (s.parents[0]), this is how we represent the tree hierarchy.

In the end this is just a regular Tree with a few fields used for optimisation / caching.

• the children[] field contains EVERY children (recursive) of this Node

  • It's used to speed-up Nested Set Operations ("get all children"),
  • The usual terminology would be descendants.

• The parents[i] field contains ancestor(i ^ 2)

  • It's used to speed-up navigation Operations ("find nth ancestor"),
  • The usual terminology would be ancestors or even ancestors_cache.

• We store the total number of parents and the total number of children

  • nParents doesn't relate to parents the same way than nChildren relates to children maybe use a different naming to avoid confusion,
  • The usual terminology for nParents would be depth.

• Maybe add a few more nodes on the Domain tree from 4.2 Domains (p.10) so it doesn't look like a binary tree (the use of power of two with indexing got me confused).

Too much d r a m a.

We need to decide whether we're going to use tries or trees. But that's bikeshedding so let's skip over that for now.

Currently, as described, reputation mining revolves around Merkle trees. However, in the event of a successful Colony Network, it would be much more efficient for miners to be able to use Patricia Trees. An implementation already exists, too. The fundamental benefit of the Patricia tree, aside from this efficiency, is that they only depend on the state, not the order in which the tree was constructed, which is currently the case for our Merkle trees.

Aside: why does it matter what they use? To avoid a consensus failure, I have an overwhelming desire for the code used to create the Reputation Root Hash to be the same as the code used to determine what the correct Reputation Root Hash is in the event of a dispute, which suggests Solidity. If we're running a local chain to build our tree, then the space required for the Merkle tree described in the paper is going to be much larger than the space required for a hypothetical Patricia tree where the key is e.g. ColonyAddressUserAddressSkillID, as there will little-to-no redundant data stored

Unfortunately, I cannot see a way past an issue that arises if you use a Patricia Tree during the dispute resolution process. Fundamentally, we need an order in order to decay existing reputations, and that order needs to be accessible on-chain (so that we know which reputation they were meant to update during that calculation, and we can calculate it ourselves. In the case of the Merkle tree, this essentially comes from the path of the leaf. There is no obvious such equivalent for the Patricia Tree, and I am having great difficulty finding a cunning workaround.

Update the WP to introduce the concept of domain-level permissions and how we use DLP to implement functionality via extension contracts.

This will entail reorganizing a few sections (such as voting, funding, and so on) to fall under the aegis of "extensions".

See this doc for a more comprehensive discussion.

ToC

Here is the proposed new structure (sections in bold represent new content).

• TL;DR
• Overview

The Colony

• Domains & Permissions
• Expenditures
• Staking (permissionless task management)
• Own Token & Reputation
• Revenue & Rewards
• Upgradability & Recovery

Extending Functionality

• Tasks
• Voting (Token / Rep / Hybrid)
• Objections & Disputes
• Funding Queues (& mention Budget Box)
• Token vesting?
• More about extensions & complex behavior (salaries, etc)

The Colony Network

• CLNY tokenomics & auctions
• Reputation mining (incl. token locking)
• Role of the Meta Colony & path to decentralization

Appendices, etc as-is.

Notes

• Do this:

While I remember, one thing we get asked about a lot and I always struggle explaining effectively, is why we have reputation decay rather than dilution. I feel like we have a lot of reasons for this, but we haven't captured them coherently anywhere. This might be a good opportunity to do so. - Jack

• Mention we have a modified Token contract.

Page 22, footnote 6.

It is unclear how a pre-commit and reveal scheme will avoid retaliatory grading in future task assignments.

Manager assigns worker and evaluator. If manager is also the evaluator he already knows the worker (address, reputation, past activity).

Hiding gradings with reveal and commit helps current task retaliation, i.e. oh you graded me a 1, even though you did a good job, i will grade you one.

What about future tasks with same mix of worker, manager/evaluator? Perhaps, manager would not want to assign that task to that worker again or vice versa worker not wanting to submit a task for that manager. Also this brings the question of the right or not of worker to refuse a task as not to incur a reputation penalty if they ignore manager assignment....

Just thinking out loud while am reading the document, i realise this gets into human psychology at work.

This section is out of sync with the current implementation, unclear whether implementation or WP should be changed:

\subsubsection*{Revenue earned in a colony's own token}
When a colony earns back some of its \emph{own} tokens as revenue, the revenue distribution process transfers them directly to the working capital, where they become part of the general fund allocation system of regular and priority funding proposals (Section \ref{sec:pots-and-fp}).

In the WP section on disputes, we have the following paragraph:

10\% of the staked tokens are set aside to pay voters when they vote:
if a voter has 1\% of the reputation allowed to vote on a decision,
they receive 1\% of this pot that is set aside. They receive this payout
when they reveal their vote, regardless of the direction they voted in
or the eventual result of the decision. This payout regardless of opinion
is to avoid us falling victim to the Keynesian beauty contest \cite{KeynesianBeauty},
by which voters might feel compelled to be on the `right side' of the dispute,
even if they personally agreed with the losing side. Any tokens that would have
been awarded to users who abstained from voting, or are not revealed in the
reveal window, are sent to the root domain funding pot once the poll closes.

The implication seems to be that users will be incentivized to vote for the "winning side", even though only stakers participate in the win/loss of tokens. So how are users incentivized to be on the right side, when they have nothing at stake? We may want to pay voters to participate to ward against apathy, but I'm not sure that the KBC argument is correct.

Can someone explain the original thinking?

Page 35, is the 3 % fee reasonable? How did we arrive at that number?

Thinking of small to medium business that might become a colony DAO will this fee sound reasonable to them? If we think about a dao colony as a digital administration and finance/accounting service for the firm, how does 3% compare to what businesses are paying for those services? Assuming, colony replace 50% of these traditional services, and they usually cost 10% of firm revenues, incremental value created for the firm is a saving of 2%.

Since this number is critical to attract and onboard businesses, you are asking for a 3% paycut on each employee paycheque, i would love to see more in depth analysis about the economics for the dao business.