confirmation_quorum details on node

[tundak]

I am using RPC call confirmation_quorum and getting response. In response there is peers_stake_total, I am bit confused

1. what is this peers_stake_total for ?
2. how peers_stake_total value impact to block confirmation ?
3. how peers_stake_total value define for node ?
4. Is peers_stake_total same for all nodes across the network ?

[renesq]

"Peers" are the nodes you are directly connected to. Every participant most likely has a different peer list. Therefore, the peers_stake_total is the cumulated representative weight your peers bear. As far as I know, the number is not relevant and listed "for your interest" only, because votes are forwarded by the other big representatives for the case you didn't get a vote on the direct route.
What's probably more interesting of a metric though is online_stake_total because it's used to calculate the actual quorum_delta (the minimum voting tally required to be deemed confirmed) by being multiplied by online_weight_quorum_percent/100

online_weight_minimum is the "circuit breaker" in case too many nodes go down. It shouldn't really be raised much, because it's borderline triggered already when the top three representatives go down.

online_weight_quorum_percent could be raised in your config as well, but it's not very useful to do so, because two-stage-voting and block cementing will make the 50% number safe AFAIK. With the current implementation, there might still be a slight attack vector present, allowing to replace blocks despite having reached 50% quorum already.

If anyone has more precise information, correct or complement this post.

[tundak]

related issue with above query: i have joined betanet from local PC node and this keep saying for blockinfo "confirmed": "false", but i did join the network from cloud server machine and same blockinfo "confirmed": "true",

I am bit confused because of this difference. why local confirmed is false.

[wezrule]

Blocks are confirmed after an election of the block itself or an election for a block higher up the account chain (which can also happen iteratively for receive blocks on another chain). This happens naturally from live transactions or a background confirmation update process, but it is node specific. If you explicitly want to confirm a block then call the block_confirm RPC command. Not sure what version you are using, but there may be an issue for some nodes with confirm requests in RC3.

[tundak]

Not sure, tested on 2 local PC with different IP, both having same issue "confirmed": "false", for blockinfo hence 2 cloud server working fine. "confirmed": "true",
Is this something related to "allow_local_peers": "false", // To allow local host peering working with RC3.

[zhyatt]

@tundak This shouldn't be related to the allow_local_peers. I would recommend trying with RC4 or upcoming RC5 on beta and verifying you have enough peers_stake_total to confirm blocks. You should then see those unconfirmed blocks get confirmed, and if they aren't currently, they should be resolved after call block_confirm as wezrule indicated.

[zhyatt]

@tundak Any updates available on this issue?

[zhyatt]

Closing due to no response.