Change Details

It is possible for a node to send a null delegation as part of the avahello message, telling the peer it supports avalanche but has no proof. This diff lets that node send another avahello with a non-null delegation to signal that it has a proof. This enables delaying sending our proof to our peers until certain conditions are met, like checking we are accepting inbound connections. Note that setting the m_avalanche_enabled flag after the peer is added doesn't change the behavior but makes more sense. Also setting/checking the pubkey with no lock is safe: it can only cause failures to check an avaresponse signature in the event a peer sent an unrequested message, which would have caused it to get banned anyway.

It is possible for a node to send a null delegation as part of the avahello message, telling the peer it supports avalanche but has no proof. This diff lets that node send another avahello with a non-null delegation to signal that it has a proof. This enables delaying sending our proof to our peers until certain conditions are met, like checking we are accepting inbound connections. Note that setting the m_avalanche_enabled flag after the peer is added doesn't change the behavior but makes more sense. Also to keep the operation thread safe now that the flag isn't used as a state lock anymore, a new mutex has tp be added to guard the logic surrounding the pubkey.

It is possible for a node to send a null delegation as part of the avahello message, telling the peer it supports avalanche but has no proof. This diff lets that node send another avahello with a non-null delegation to signal that it has a proof. This enables delaying sending our proof to our peers until certain conditions are met, like checking we are accepting inbound connections. Note that setting the m_avalanche_enabled flag after the peer is added doesn't change the behavior but makes more sense. Also setting/checking the pubkey with no lock is safe: it can only cause failures to check an avaresponse signature in the event a peer sent an unrequested messagto keep the operation thread safe now that the flag isn't used as a state lock anymore, which would have caused it to get banned anywaya new mutex has tp be added to guard the logic surrounding the pubkey.