How much would it cost to attack the HIVE and STEEM DAOs?

in LeoFinance3 years ago

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

First, the return proposal #0 - $All

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.

Second, "Stabilizer": #169 - $19,200 | #166 - $9,600 | #159 - $4,800 | #158 - $2,400

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.

Considering Cronyism

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.

Considering a full frontal assault

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.

  • Overwhelming attack assumes coins will need to be powered up to achieve take down. This is the worst case attack resulting in 30 days of payouts.
  • With high volumes of HBD stabilizer the market will already support full liquidation of HBD
  • Outsider assumes the attack currently has zero coins.
  • Infinite liquidity at the current price
  • Largest Stakeholder Used the largest witness voter
  • The Margin is the price stability needed in the next 13 or 4 weeks, to recover an investment in coins or acquiring allies, if you cared to make a break. 0% means you can pull more from an attack than your current stake is worth.
ScenarioDAO *BDCost OutsiderCost AccountPayoutMargin
A$11,000$12.9M (30M HP)$7.74M@freedom(12M)$330,00097.45%
B$27,000$12.9M (30M HP)$7.74M@freedom(12M)$1,620,00079.6%
C$11,000$35M (35M SP)$0 (dev365 35M)$2,640,00092.46%
D$100,000$12.9 (30M HP)$7.74@freedom(12M)$3,000,00076.75%
E$20,000$35M (35M SP)$0 (dev365 35M)$60,000,0000%
F$2,750,000$3,000M(30M HP)$1,800M@freedom(12M)$82,500,00097.25%
G$100,000$3M(30MHP)$1.8M@freedom(12M)$3,000,0000%
H$100,000$300M(30MHP)$180M@freedom(12M)$3,000,00099%
I$100,000$12.9M(30MHP)$7.7M@freedom(12M)$6,000,00053%
J$100,000$12.9M(30MHP)$7.7M@freedom(12M)$12,900,0000%
K$10,000$3.5M (35M SP)$0 (dev365 35M)$3,500,0000%
L$116.667$3.5M (35M SP)$0 (dev365 35M)$3,500,0000%
M$11,667$3.5M$0 (dev365 35M)$3,500,0000%
N$27,000$1.62M$972K@freedom(12M)$1,620,0000%

Scenarios:

  • A: Hive $0.43, HBD $1 : Stable
  • B: Hive $0.43, HBD $2 : Sharp Trend
  • C: Steem $1, SBD $8 : With relative budgets even an 800% sbd increase only drops the margin ~8%
  • D: Hive $0.43, HBD $1 : Shows a stress with increased budgets versus supporting price.
  • E: Steem $1, SBD $100 : Breaks SBD~$58
  • F: Hive $100, HBD $1 : Relative budgets show safety with peg
  • G: Hive $0.10, HBD $1 : Breaks with a high budget, can be just as dangerous as a lost peg
  • H: Hive $10, HBD $1:
  • I: Hive $0.43, HBD $2:
  • J: Hive 0.43, HBD $4.3: At HBD of 4.3 The budget would quickly find it's way here in a month or two.
  • K: Steem 0.10, SBD $116.67: With Low Budgets
  • L: Steem 0.10, SBD $1: Never spending the return will make a budget fairly large. Even with a Stable Dollar
  • M: Steem 0.10, SBD $10: Things can get scary with even a retracement of Steem without SBD
  • N: Hive 0.054, HBD $2: Especially dangerous is a debt available and a market supporting an outrageous price for it.

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.

A fix for the DAO needs to work under all cases

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.

Proposed changes and their effect to the DHF:

Weight Votes Based of Percent of Outflow Voted On

Vote Weight as f(outflow)

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.

ScenarioDAO *BDCost OutsiderCost AccountPayoutMargin
A$11,000$12.9M (30M HP)$7.74M@freedom(12M)$160,00098.76%
B$27,000$12.9M (30M HP)$7.74M@freedom(12M)$810,00093.72%
C$11,000$35M (35M SP)$0 (dev365 35M)$2,640,00096.22%
D$100,000$12.9 (30M HP)$7.74@freedom(12M)$1,500,00088.37%
E$20,000$35M (35M SP)$0 (dev365 35M)$30,000,00014.28%
F$2,750,000$3,000M(30M HP)$1,800M@freedom(12M)$41,250,00098.63%
G$100,000$3M(30MHP)$1.8M@freedom(12M)$3,000,00050%
H$100,000$300M(30MHP)$180M@freedom(12M)$1,500,00099%
I$100,000$12.9M(30MHP)$7.7M@freedom(12M)$3,000,00076.74%
J$100,000$12.9M(30MHP)$7.7M@freedom(12M)$6,450,00050%
K$10,000$3.5M (35M SP)$0 (dev365 35M)$1,750,00050%
L$116.667$3.5M (35M SP)$0 (dev365 35M)$1,750,00050%
M$11,667$3.5M$0 (dev365 35M)$1,750,00050%
N$27,000$1.62M$972K@freedom(12M)$810,00050%

Of course this also means it's easier to take advantage of a year long attack.

Downvotes

With Downvotes the first scenario really doesn't change. It's an arms race to the most voting power.

Weighted Votes with Equally Weighted Downvotes

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.

Final Thoughts on the Stabilizer

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.

Sort:  

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.

I went into this thinking, "If it ain't broke, don't fix it," but this particular point won me over to the notion. Good point about the assumption of knowledge. Almost a "yeah right" filter.

To be honest, that would also be a good filter for witness approval, but I guess we already have a form of that with the hard maximum of 30 votes.

Would it be possible to make a test ( like the first 10 votes count) with a maximum of 10 votes?.

How would it look like? is the network more secure or less?

Besides this, because not everyone is voting, we have more head-heavy voting in total.

I think with more use cases for the Hive power, more Hive will be powered up, which should secure the network even more.

Posted Using LeoFinance Beta

On another note, I find the way that you present your argument difficult to follow...maybe it's just me. I would evaluate the risk of attack by constructing a table with cost/benefit analysis.

image.png

The table above shows the current cost of siphoning funds from the DHF. Each row represents the cost/benefit of the stake needed to displace each of the proposals that are receiving funding at the present time.

An attacker also needs to consider the possibility of losing the stake with a hard fork (it's not like we haven't shown a willingness to do that). In order to successfully carry out an attack, the malicious stake needs to sustain its actions well beyond the break-even date.

Note: I am considering a Hive price of 0.45 USD and an HBD worth one dollar. The "Honeypot" is the available daily budget at each attack level. Of course, the days to break even would decrease with a higher HBD and the cost of the attack would vary in tandem with the Hive price.

EDIT: This model assumes that the attack is coming from an outside agent that is able to purchase its stake over the counter. In practice, that is difficult to do (although not impossible). A group of existing whales colluding is more difficult to counter.

Given the costs and the time that it can take to profit from an outside attack on the network via the DHF, I find that possibility to be a remote one. It's much more profitable to simply buy low and sell high or invest in a yield farm.

You're right, this is easier to follow. I tried to find the scenarios where either the budget has grown too far either through HBD stabilizer or SBD runaway, both are currently happening. The most interesting one to me was what would happen with current budget levels and an HBD price of $4.30. I did consider forks, but even that probably won't lead to a full loss as ETC shows.

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.

Since the last hardfork the debt ratio is not affected by the HBD balance in the @hive.fund account by design.