DAO v1.1 Public Testing Report

  • Slow Path is a framing of the situation.
  • Another framing: burden passed on to the Community.

Without a reference Audit tool, both reads the situation equally well.

Any tool from any origin that support those 9 requirements is good on my book.

Yesss, that would be good!! Something like docker compose of docker images? :star_struck:

So long that we can audit the code, fork it and own it, I feel like we are good on this side :handshake:

My question was more there will be an operator who will have complete control on V1.1 Votes. This tool addresses that.

Another solution was reworking the design & code causing the issue in the first place.

2 Likes

That is an comparison example of how a simpler initial design could have avoided all this messy situation.

See: On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal

As a reference to Fellow Community members:

One use-case proving the change in voting eligibility:

Agreed, clarity on the matter from @zz_tovarishch (Transitional period coordinator), @terrytai, @janx & @Cipher (DAO v1.0 Committee) would be appreciated.

Love & Peace, Phroi

I understand and fully respect your motivations, but I don’t think we can hold every situation to the same levels.

A bridge hack has a very high, instant financial reward, that in most cases can’t be stopped in time before the damage is done.

This is a completely different situation to the very slow and public system of DAO voting.

While I obviously don’t understand all the ins and outs of the ‘whitelist exploit’, it sounds like something that is unrealistic and infeasible for someone to achieve.

  1. Who is going to/has the ability to do this?

I’m assuming the most likely person/people would be the DAO 1.1 team.

All members are well known and I think the chances of this are very low, but I’ll admit, never zero.

But even if they do…..

  1. What do they have to gain financially?

Affecting the stewards elections holds no real value, especially financial, but not even really from a power point of view.

Affecting the vote on a standard proposal would definitely have a financial reward, but in the scheme of ‘hacks’ this would be minuscule and they would also still have to meet all the development milestones.

They could just take the initial $10k and run, which is an acceptable risk imo, especially due to the issues the exploiter would need to deal with below.

  1. Changing the Meta Rules – This is the most dangerous possibility for sure.

But how can this realistically happen?

They still need to meet the minimum CKB amount and the quorum, so they would need to secretly prevent enough people with enough CKB from voting against their position.

I’m assuming that after someone votes, they will be able to see their votes counted on the dashboard and everyone else will also see the vote tally changing?

So how can it be possibly that enough people (remember, these are people that actually care enough to vote in the first place, so I’m sure they will also care that they’re votes are tallied) are prevented from voting but then when they realise their vote hasn’t been accepted, they wouldn’t immediately voice this issue publicly?

(EDIT: I just had a thought that maybe the votes can be removed afterwards, in which case, this would be harder for the voter to realise themselves and then prove after the vote has ended. I’ll accept that this changes things a bit if it’s the case.)

Of course there might be lots of community members who might not have an understanding or interest in making sure their vote was tallied, but how could the exploiter possibly know they are targeting these users specifically?

It seems totally unrealistic that over a 7 day voting period, this sort of exploit wouldn’t be recognised.

Do you see the light?!

image

Yes, it’s vulnerabilities all the way down!! “Forgetting” to count votes is just a simple hackity hack on the Postgres DB :rofl:

Possible Fixes:

  1. Fully redesign the protocol, see for example On-Chain Tally
  2. Release a locally runnable tool that support those 9 requirements

Solution:

  • Ideal: 1 and 2
  • Acceptable: 2
  • Team: not 1, nor 2

Glad you stopped drinking the Kool-Aid!
Phroi

1 Like

Wouldn’t say I’ve stopped drinking yet, still thirsty haha

My other points still stand I think, how feasible is this exploit without making it obvious that something is going on?

How does the exploiter know which addresses to secretly remove?

For example, they might be able to pull the wool over my eyes, but how do they know they aren’t removing you from the whitelist, in which case they will almost certainly be caught?

It just seems like massive risk with very little reward or chance of success.

Assume that for a vote we have a dump of all the voting data in a nice to review report, how can we know that no deposits / DIDs / votes were omitted?

We need tools for that.

Nope, it’s a low risk, high reward game:

  • If the hack is not discovered, high reward for hacker.
  • If an hack is actually discovered the following happens:
    • Operator team will consider himself hacked (as in Force Bridge)
    • Hacker will go on living his peaceful life as before, losing nothing (as in Force Bridge)

Phroi

1 Like

Yeah, I can see this is a problem, even if there is no issue, if there’s no way to prove it, then it is always an unknown. I’ll concede this one for sure.

But I’m probably missing something here, but in the metaforo system, when you submit your vote, your vote/username is immediately added to the publicly visible list.

Won’t the idividual user know that they are prevented from voting?

And won’t everyone know if votes start just disappearing from the list?

This is where I disagree and was why I said earlier that they are completely different scenarios.

Forcebridge hack = Gets $3 million USD

DAO hack = Gets to be a DAO Steward

I’m using the extremes here to make my argument look better :sweat_smile:…but seriously, what is the reward at this stage?

I’m not saying that we don’t work towards a far better and more secure voting system, that should be a top priority, but at this stage right now, I think the system they are putting forward is probably sufficient.

just want to clarify (for the 2nd time to you directly) that I would be ok with a 100% centralized solution, my motivation is in building technology that takes full inventory of the trade-offs and simply makes sense, rather than making decisions in isolation and refusing to question them.

This will be my last message on the subject of DAO v1.1 implementation

Link in case you missed it On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal - #17 by matt_ckb

Individual view of voting can still be consistent (“I see my vote”), but final tally still not account for them. Depends on how sophisticated is the hack.

Final report is different if published as immutable PDF on GitHub, not served from Operator controlled website.

That said, have you ever audited a final voting report to check if your vote was accounted for properly?

  • It can be direct: like asking for a big funding chunk for a wildly overpriced project, then again and again
  • It can be indirect: like slowly allowing one party to pass Stewards and MetaRules that favor them (like altering Whitelist Vote scope)

We just want a proper Voting platform with basic functionalities and basic voting assurances.

Something we can actually rely upon,
Phroi

PS: V1.1 Rules actually have a clear resolution for this kind of contested Milestone scenario

2 Likes

Hi Phroi, I think I need to be clear here, that my opinion on this issue is based totally on my experience of all past proposals, where the level of participation has been low enough that it seems to be easily tracked.

Even when I would check the voting on a daily basis, I would have a pretty accurate idea of what the vote totals were previously and I would take note of who the new users were and their voting weight etc.

So under the current participation levels, I think the chances of all of these things happening is extremely low if not impossible:

1 - One or more of the DAO 1.1 team being corrupt

2 - None of the remaining non-corrupt members of the team realizing something’s wrong.

3 - The exploiter knowing which addresses to remove without setting off alarm bells.

3 - No user who’s vote was disallowed/removed noticing that it happened.

4 - No observant community member noticing that the daily vote tallies were not making sense.

This is why I think that it’s in the best interest of the DAO to move forward with the current system that the team has designed with an aim to improve the system in the future.

But if we already had hundreds or thousands of voters OR if we were at the point where the Secondary Issuance was involved, then I would be in 100% agreement with you and Matt and everyone else who is against the current system.

2 Likes

Observant community members needs tool for that: you may not realize but this system one order of magnitude more complex than the previous one.

Phroi

PS: apologies in advance, I find pretty funny the following over-simplification:

  • Team & @Yeti: Trust, don’t Verify! :flexed_biceps:
  • Rest of the Community: Wait a second, wasn’t don’t Trust, Verify!? :thinking:

Gee Phroi, I thought we were having a pretty respectful conversation :sweat_smile:…not sure you could say ‘the rest of the community’ supports your position.

It’s ironic that a good amount of the community has left, many of which I think might support my stance of not continuing to kneecap CKBs progress for extremely unlikely edgecases.

Until not long ago another team was thinking exactly the same,
Phroi

Again, they are not even close to being the same thing.

On both a reward level and detectability/stopability/rectification level they are worlds apart.

Feel like we both already expressed at lengths our opinions. If you agree, I’d leave space for anyone else who wants to add something new to the discussion.

Phroi

1 Like

Yeah, for sure mate, we could go on forever here :grinning_face_with_smiling_eyes:

I’m just going to add one more thing, not specifically to you, there’s no need for a reply, but I want to put into context my position here.

I woke up one night years ago and checked my phone to see how much ETH I made since going to sleep, right in the middle of this hack.

https://www.theguardian.com/technology/2022/apr/18/beanstalk-cryptocurrency-loses-182m-of-reserves-in-flash-attack

I lost over $45k here, (which was a hugely substantial amount to me) due to this exploit which like most ‘hacks’ in my opinion was an inside job, even though the rest of the community seemed to just accept the generic explanation of a North Korean hacking team.

I actually DMed Matt on the day of the Forcebridge hack and said this was obviously an inside job and of course it turned out to be.

Anyway, what I’m getting at here is I am very aware of the possibilities and the consequences of blindly ‘trusting’ project teams.

But I personally trust this team and I also trust the community here to all be keeping a very close eye on the processes, which for me is enough to move this thing forward.

If something can be done to meet everyone’s requirements, then of course that is the best way forward, I fully support that.

But if the only 2 options are to go forward with the proposed system or stagnate with this current system, then we just have to take the risk and move forward with DAO 1.1 imo.

2 Likes

yes and this is why the issue should be voted on instead of us arguing on the internet like a bunch of teenagers

2 Likes

My position as a community member is as follows

In an ideal world, a clear view of the design prior to the original vote may have mitigated some of this situation and enabled a more informed decision making process. Although I understand some details aren’t set in stone and are formative during the process. The first problem we have is that a number of people have expressed concern that what is being delivered is unexpected in that context.

Overall, I support Phroi’s enquiry and persistence on design issues. I also respect and support the v1.1 team’s overall efforts and desire to see resolution to this issue before proceeding. The second problem however is that the current discussions are losing productivity, creating negative sentiment.

I believe everybody would like to see resolution in a way that is mutually accepted to both sides.

The two solutions I see are:

  1. A mediation process between both sides with selected representives to navigate what a suitable settlement looks like. This may be something around open sourcing an audit tool that meets mutually agreeable criteria. (I would prefer this option)
  2. If 1. fails, and if the v0 committee agrees, then a new vote. If the committee sees differently, then a decision to bring some closure to the issue.
4 Likes

最近我关掉了 DAO 1.1 相关的讨论,因为现在讨论已经没有办法得出更多有意义的结论。

我也同意对话进入了僵局,所以我和项目的负责人 Baiyu 沟通了一次,我说明了现在的情况和困难。我认为团队有可能有一些决定需要做,请大家给团队一些时间,暂时不要做重复的对于 DAO 1.1 的讨论。

这里我代表委员会澄清几个流程和事实上的误解:

  • 从流程上委员会的职责是判断一个项目提交 milestone 后是否完成了之前的 proposal,如果完成,委员会释放本次 milestone 的资金. 这是在正常流程中委员会需要做的判断。
    • 团队上线了 DAO 1.1 新 milestone(此时委员会尚未对该 milestone 是否完成做出判断),之后团队与社区交流后自行下线。在当前状态下,因为不存在一个待判定的 milestone,所以委员会暂时不需要就支付问题做决定。
  • 我理解 @phroi 的测试行为是一种社区个人行为(个人对社区的贡献),但并不代表委员会的观点。
    • 团队确实应该交流听取社区意见,但是并不意味着团队要做的 trade off 必须完全和 “社区” 一致。这是难以做到的,“社区”本身也有各种不同的观点和不同的 trade off.
    • 团队充分搜集意见,最终做自己的选择求同存异,并解释清楚自己的 trade off 然后继续推进,在规则上是完全OK的。
  • 关于大家提到的投票
    • 投票是一种选择,而不是必然。如果最终委员会认为需要用这种方式帮助我们做一些核心决策,委员会可以选择这种方式,当然也可以不选择。
    • 这里委员会希望秉持一种原则,尽量不要扩大用投票的方式解决问题的范围,因为投票往往是成本高、信息损失较大的决策方式,尽量作为万不得已的选择
9 Likes