You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"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.
The text was updated successfully, but these errors were encountered:
The blog post at https://oxen.io/blog/session-token-rewards-contract states:
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.
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 controls5.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.
The text was updated successfully, but these errors were encountered: