-
Notifications
You must be signed in to change notification settings - Fork 787
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
Update online_weight_quorum default to 67 #3052
Conversation
PR nanocurrency#2884 was originally intended to include changes to the default quorum value from 50% to 67%. This update includes this change. Previously the online weight minimum of 60M was being applied as the floor for the number of votes required for quorum, but this caused the actual quorum % required to increase as online weight dropped towards that minimum 60M instead of staying consistent. With nanocurrency#2884 the quorum % is consistent regardless of online weight and thus the more online weight there is, the higher the vote amounts required. In order to provide similar security on the network prior to nanocurrency#2884, this update sets a 67% default value for quorum. Given current online weight of 92M on the main network, this 67% requirements equates to ~61.6M votes required, just above the previous 60M, so little impact to confirmation times is expected.
Adding some notes from discussions on Discord in #protocol. Are there any concerns about the lower floor/minimum this change along with #2884 ? Prior to either of these PR's the network would stall below 60M weight, whereas now it seems that it would stall below 40.2M weight. If an attacker controlled 40.2M could they send 2 forks to different nodes along with votes for each and cause forks to be confirmed on different nodes? Previously it would require 60M minimum weight to confirm so this is reducing the weight required to confirm a block if the online weight drops to 60M or less. I think it's certainly debateable what should happen in that circumstance, should the protocol adapt automatically or should a change in the node be required if the weight drops that low? In the short term should the minimum online weight be increased to 90M which would result in a stall happening at 60M again instead of 40.2M to keep that consistent? The concern is reducing security in favor of liveness as the weight drops below 90M compared to what has historically been in place. |
is it possible to keep this description accurate? if the value across every PR has to be set to 90M to stall at 60M, and is effectively 40.2M when it's set to 60M, that introduces a lot of confusion |
Most of the discussion I think comes from the purpose of the online_weight_minimum term. Internally the node tracks the network's online weight total. The online_weight_minimum setting is a failsafe intended to be the lowest online weight that is expected. This would come in to play if, over a long period of time, the actual online voting weight from reps approached this value. The confirmation quorum requirement of 2/3, tolerating 1/3 byzantine actors, now fully scales with changes in calculated online weight. Setting the quorum too high eats in to the "stall budget", where a byzantine actor can withold their votes to stall the network. Too low and eats in to the "byzantine budget" where the network is less tolerant to byzantine actors. Prior to these changes online_weight_minimum was also being used as a quorum delta. As online network weight was trending down, this was eating in to our stall budget. Now it will always approximate the optimal going forward. |
Thanks for the discussion Colin. Here is a proposed attack for a malicious actor Bob, who doesn't even need a substantial vote weight: After the trended online vote weight of Fragment has been reduced to Fragment's weight, Bob reconnects to Fragment, while remaining connected to Primary. Primary sees no change and a secure network. Fragment now has 45M vote weight, sufficient to resume verifying and cementing transactions. Bob now spends a potentially large sum on Fragment, broadcasting to Fragment transactions he hasn't broadcast on Primary. These can be confirmed and cemented. Then Bob broadcasts different transactions, from the same accounts, to Primary, and has them confirmed and cemented. Bob was able to earn twice whatever nano stake he acquired, potentially depositing at exchanges and cashing out. Furthermore, when the networks are allowed to interact once again, both versions of his transactions are cemented which will presumably cause issues for those funds down the road. Here's a summary. Without 60M minimum: These are difficult and unlikely attacks, to be sure, but they were impossible with the 60M minimum, and their consequences seem grave. As such they should be strongly defended against. The removal of the 60M minimum marginally helps liveliness, but it also appears to immediately open new attack vectors that were not previously possible. Surely security should take priority over liveliness in all situations where the liveliness benefits haven't been demonstrated to be substantial and significant? |
@Vyryn Maybe I'm misunderstanding your comment, Colin's comment, or the code changes, but I believe that the 60M online_weight_minimum still exists, so your 80M vs 45M partition scenario can't happen, even after two weeks. The minority partition won't confirm transactions: https://github.com/nanocurrency/nano-node/blob/develop/nano/node/online_reps.cpp And if the malicious entity is operating in both partitions, then the quorum requirement is still the max of "2 week trended online weight" or the "online peers' stake" times .67 EDIT: @Srayman corrected me on Discord, and it looks like Vyryn's right. Per have_quorum in election.cpp, online_weight_minimum would not get checked in this change, so theoretically you could have an 80M and 45M partition (after 2 weeks trended) and achieve confirmation in both partitions (though the non-communicating partition requirement + 2 week timeframe would admittedly make this extremely unlikely). Proposed develop branch:
Current V21 branch
While manually setting the online_weight_minimum number to online would effectively re-enable a v21-style online_weight_minimum, I have to agree with Vyryn that this seems like a change that would slightly prioritize liveness over security by default, and given Nano's deterministic finality with no easy way re-merge partitions, I personally would prefer the default behavior be to stall |
@qwahzi I do agree it is unlikely, but if allowed it would become the least expensive double spend that can be done on Nano. You can also dos individual nodes for a while and double spend on them, eventually de-syncing all the nodes on the network. Dosing just one node is something quite achievable for an attacker. |
PR #2884 was originally intended to include changes to the default quorum value from 50% to 67%. This update includes this change.
Previously the online weight minimum of 60M was being applied as the floor for the number of votes required for quorum, but this caused the actual quorum % required to increase as online weight dropped towards that minimum 60M instead of staying consistent. With #2884 the quorum % is consistent regardless of online weight and thus the more online weight there is, the higher the vote amounts required. In order to provide similar security on the network prior to #2884, this update sets a 67% default value for quorum.
Given current online weight of 92M on the main network, this 67% requirements equates to ~61.6M votes required, just above the previous 60M, so little impact to confirmation times is expected.