(SCP) When does a node get its higher-layer software's input?

External question — Stellar Stack Exchange Author: Donghwan Shin Original post: https://stellar.stackexchange.com/questions/1293 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. According to the SCP document (draft-mazieres-dinrg-scp-04, https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ ), the following paragraph describes how a node get its higher-layer software's input: Nodes must not send an "SCPNominate" message until at least one of the "voted" or "accepted" fields is non-empty. When these fields are both empty, a node that has the highest priority among its neighbors in the current round (and hence should be echoing its own votes) adds the higher-layer software’s input value to its "voted" field. Nodes that do not have the highest priority wait to hear "SCPNominate" messages from the nodes whose nominations they are echoing. However, I think it can be the case that the higher-layer software's input is empty for a node. This leads a questionable case: when the highest priority node has no higher-layer software's input while another node whose priority is not the highest has higher-layer software's input, should this node wait for the highest priority node even though it has its own higher-layer software's input? Of course, it is not a big problem because the priority of the nodes changes as the round increases, but it seems to hinder the quick agreement.

External answer — Stellar Stack Exchange Author: MonsieurNicolas Original post: https://stellar.stackexchange.com/a/1301 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. The solution is actually quite simple : a different set of priorities will be picked after a timeout (lookup the "n" parameter) which allows the protocol to proceed in the event of dead nodes for example.

External answer — Stellar Stack Exchange Author: user3188445 Original post: https://stellar.stackexchange.com/a/1313 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. The protocol requires all nodes to be able to produce a value. That value could be empty--for instance, in the case of Stellar, it might contain no new transactions. But it would still contain a time stamp, a previous ledger hash, and a bucket list hash that must potentially be reorganized according to the bucked list structure.