Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification Needed Regarding the Definition of 'Majority' #7

Open
venezuela01 opened this issue Jan 30, 2024 · 0 comments
Open

Clarification Needed Regarding the Definition of 'Majority' #7

venezuela01 opened this issue Jan 30, 2024 · 0 comments

Comments

@venezuela01
Copy link

venezuela01 commented Jan 30, 2024

The blog post at https://oxen.io/blog/session-token-rewards-contract states:

"We’re utilising BLS signatures, allowing us to take multiple signatures and shrink them down into an aggregated signature which can be validated by our smart contract. This way we can make sure a majority (for example, 95%) of the network agrees on the amount before it can be claimed."

However, there seems to be a discrepancy between this blog post statement and the actual smart contract function described below. The function appears to define the 'majority' differently, so clarification on this matter would be appreciated.

    /// @notice Updates the internal threshold for how many non signers an aggregate signature can contain before being invalid
    function updateBLSThreshold() internal {
        if (totalNodes > 900) {
            blsNonSignerThreshold = 300;
        } else {
            blsNonSignerThreshold = totalNodes / 3;
        }
    }

One reason I sought clarification is that defining 'majority' as 95% like the blog post suggests appears too risky. This threshold enables a potential attack on the network by a 'whale' like L6qq who controls 5.41% of the network and could disrupt every signature aggregation by being non-cooperative (or by suffering a server crash if all their nodes are on the same server). A threshold of 66.6% seems more resilient to such whale attacks, or even to potential OPTF attacks in the event that OPTF's servers are compromised by a third party.

In other words, I guess the code is fine, but the blog post might require some edits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant