You really only have to look at Steem's DAO to see one account effectively killed the entire thing. One account, dev365, has 35M powered tokens for witness voting and therefore controls about 35/43rds of all DAO Votes. This account could just as easily make a proposal that funnels all funding to itself, and as it stands would need to have nearly 5 times the engagement from other users to stop it.
There are of course reasons to be able to vote for 30 witnesses, such as if a witness goes off line the back up slots become much more important, and if you could deny service to a few PrivEx clusters then many of the top witnesses would fall off and back up slots could force the chain to fork. But we also saw an attack where you ony need to vote in 4 witnesses to force a stalemate; which is why Hive and Steem are separate today.
Really the key to decentralization is decentralization. The system as it stands allows one to overextend large stake, which nullifies smaller voices and builds centralization in practice.
Let's discuss how to attack the current system
For the next nine years this proposal will take any conceivable amount of outflow and redirect it to the funding account. On Steem this is the only proposal with enough funding votes, ~35M SP. Effectively just building a bigger honeypot, as 10% of inflation continues to go into the DAO, ripe for attack which comes in the form of voting for a proposal with a beneficial outflow, on Steem, this could be dev365 building a proposal that directs funds to itself, and voting for it.
These proposals have an even greater effect than the return proposal in many ways. First they should act to stabilize the value of HBD to $1. Currently 1,000 HBDs per hour are buying Hive on the internal market. Then the purchased Hive is sent back to the DHF like return. While HBD has been high this also increases the value of the DHF at a rate commiserate with the excess value of our debt token: HBD. There would also be a small loss if the value was below $1.
It's interesting to note that the Hive returned to the DHF is converted back into HBD at the feed price instantly. This means that at $2 HBD, any funds being used to stabilize HBDs price also increases the debt ratio at the rate of two times the Price over Stabilizer Funded. As HBD just goes to whoever sold Hive on the Internal Market, and therefore remains as Debt; and Hive is converted to HBD debt when returned. Having the DHF hold this new debt isn't the worst idea as it's daily outflows are capped at 1/100th of it's holdings, and in practice it has been hodling even better with these return initiatives; but what remains is debt creation at an unscheduled pace.
Additionally the @hbd.funder account makes periodic posts which further funds the HBD stabilizer and therefore the DHF at higher than the 10% inflation rate, and lowers the contents rewards by the same mechanism.
When one votes for a return proposal, or more outflow than is available, they are placing a funding hurdle in the exact amount of their vote. Subsequently, when they vote for any proposal they are removing that hurdle. This means on the most fundamental level that they can not vote on proposals with the best knowledge of interested parties. You could have a PhD in distributed rocket science and only vote for development proposals after careful review, but you couldn't market water to somebody on fire, and therefore the wisdom of your vote or non-vote doesn't result in the best knowledge of the crowd. This leads to cronyism and centralization in fact, while preaching of decentralization in code.
The stabilizer proposal has been working for ~2 months and has returned $2M to the HDF. With daily outflows climbing from 11K to 27K in that time period.
On Steem this number appears to be near 11K currently but it hasn't benefited from confiscated stake or convert mechanisms from donations I believe(researching steem isn't what I like to do). The two ecosystems are nearly the same, the biggest factor to consider between them is size of an account to overall participation.
Factors to Consider.
|Scenario||DAO *BD||Cost Outsider||Cost Account||Payout||Margin|
|A||$11,000||$12.9M (30M HP)||[email protected](12M)||$330,000||97.45%|
|B||$27,000||$12.9M (30M HP)||[email protected](12M)||$1,620,000||79.6%|
|C||$11,000||$35M (35M SP)||$0 (dev365 35M)||$2,640,000||92.46%|
|D||$100,000||$12.9 (30M HP)||[email protected](12M)||$3,000,000||76.75%|
|E||$20,000||$35M (35M SP)||$0 (dev365 35M)||$60,000,000||0%|
|F||$2,750,000||$3,000M(30M HP)||$1,[email protected](12M)||$82,500,000||97.25%|
|K||$10,000||$3.5M (35M SP)||$0 (dev365 35M)||$3,500,000||0%|
|L||$116.667||$3.5M (35M SP)||$0 (dev365 35M)||$3,500,000||0%|
|M||$11,667||$3.5M||$0 (dev365 35M)||$3,500,000||0%|
These scenarios show the dangers of increasing the size of the fund relative to the market cap of Hive. Also, the fact that the fund increases in size with HBD rising off the peg. Of course some additional factors exist, but with these assumptions it's easy to find the zero's in the equations.
PoS systems should inherently stand in such that an attack will always cost more than the value destroyed. Above we can see how a mixture of factors like low voting participation, returns from peg stabilizers, not spending, can bear attack vectors that can yield returns with near certainty. These attacks don't always have to look like attacks.
Any proposal can have a story attached to it, making a strong case for 60 days of all proceeds, Then a few accounts in cahoots can vote on it and legitimize it. How much would one be willing to chase for an extended score? 1 year of funding would only need 9% of the budget to yield the same returns, and any attacker/buyer could legitimize themselves with a "we're investing in hive story", lower the cost of initial investment, and be given years of runway through social engineering.
In practice we want the best people voting in the things they are most interested in; Which often includes their friends.
If you vote for more than 10% outflow your vote starts to lose weight. It starts at 10x, assuming you can know 10% of funding goals better than most and gives incentives you to focus in one area. At 100% outflow each vote will be worth less than 1x.
This allows accounts to distribute their influence in a limited way with out so much influence that similar accounts can't fight with them. Effectively doubling the margins for attack. It also attempts to keep strong outflows to limiting the take of an attack. Below are the same scenarios, this time the payout will change and therefore the margins will change.
|Scenario||DAO *BD||Cost Outsider||Cost Account||Payout||Margin|
|A||$11,000||$12.9M (30M HP)||[email protected](12M)||$160,000||98.76%|
|B||$27,000||$12.9M (30M HP)||[email protected](12M)||$810,000||93.72%|
|C||$11,000||$35M (35M SP)||$0 (dev365 35M)||$2,640,000||96.22%|
|D||$100,000||$12.9 (30M HP)||[email protected](12M)||$1,500,000||88.37%|
|E||$20,000||$35M (35M SP)||$0 (dev365 35M)||$30,000,000||14.28%|
|F||$2,750,000||$3,000M(30M HP)||$1,[email protected](12M)||$41,250,000||98.63%|
|K||$10,000||$3.5M (35M SP)||$0 (dev365 35M)||$1,750,000||50%|
|L||$116.667||$3.5M (35M SP)||$0 (dev365 35M)||$1,750,000||50%|
|M||$11,667||$3.5M||$0 (dev365 35M)||$1,750,000||50%|
Of course this also means it's easier to take advantage of a year long attack.
With Downvotes the first scenario really doesn't change. It's an arms race to the most voting power.
Now it's both possible accurately vote, lower the margins to profitability, and prevent long term attacks.
For Steem this would result in ~20-25% outflows with 8M SP against 35M SP... Which of course is a fair split of 8/43rds of stake. Hopefully from there the largest holder uses their wisdom to benefit the community.
With the scenarios above it should be clear to see that controlling the value of our debt is important to overall security. However this avenue has it's limits, as declines in price put tremendous pressure on the debt ratio. This might be solved by not converting HIVE returned to HBD if the debt ratio is too large, instead leaving it with the ninja mine. Possibly capping the outflow in relation to inflation; steady state this will be 10%, and 20 or 25% may be a good cap with additional just serving as a supply buffer for price shocks, and quicker growth of outflow with price appreciation. It might be a good idea to bake the stabilizer functionality into the code instead of relying on proposals: where additional funds in the account are virtual op'd to buy on the internal market, which doesn't pose a votable risk of exit.