I know that the Bitcoin Network would send an alert message which follows:

int32_t nID

The alert identification number - this allows nodes to identify double-messages.

int64_t nExpiration

The alert-expiry time.

int64_t nRelayUntil

Instructs nodes to cease rebroadcasting of the message.

int32_t nMinVer ---> int32_t nMaxVer

The range of bitcoin protocol versions that this alert applies to.

std::setstd::string setSubVer

The current client software update that this alert message applies to.

int32_t nPriority

  The priority of the alert message - however, this function has been rarely used.

However, this was later abandoned in 2016 where the public and private keys of the message were released to the public.

Does the Bitcoin Network still have a way of notifying nodes of a potential fatal bug/error? If not, what is done if the Bitcoin Network is compromised?

1 Answer 1


Does the Bitcoin Network still have a way of notifying nodes of a potential fatal bug/error?


After all, it is a peer-to-peer network without any central control. Either no-one can issue alerts or everyone can, including the malicious. Changing this would go against the founding principle of Bitcoin - avoiding any need for trusted third-parties. It seems to me the removal of the alerting mechanism moved the Bitcoin network closer to its founding principles.

The discussion of this feature is illuminating

The alert system was a frequent source of misunderstanding about the security model and 'effective governance', for example a years ago a BitcoinJ developer wanted it to be used to control fee levels on the network and few months back one of Bloq's staff was pushing for a scheme where "the developers" would use it to remotely change the difficulty-- apparently with no idea how abhorrent others would find it.

The system also had a problem of not being scalable to different software vendors-- it didn't really make sense that core would have that facility but armory had to do something different (nor would it really make sense to constantly have to maintain some list of keys in the node software).

It also had the problem of being unaccountable. No one can tell which of the key holders created a message. This creates a risk of misuse with a false origin to attack someone's reputation.

Finally, there is good reason to believe that the key has been compromised-- It was provided to MTGox by a developer and MTGox's systems' were compromised and later their CEO's equipment taken by the Japanese police.

If not, what is done if the Bitcoin Network is compromised?

Presumably lots of different people do different things while attempts at coordination are managed through media popular with Bitcoin developers.

You could look at what happened in earlier crises such as the Value Overflow incident of 2010. Nowadays it would probably be much harder as there are a greater variety of software applications in use. I don't know if it can be argued that the Value overflow incident was a bug in one software application rather than a bug in the network protocol. In which case it isn't a good example. Another example might be the removal of vulnerable or unused opcodes from Bitcoin script because of the OP_LSHIFT bug

See https://www.cvedetails.com/vulnerability-list/vendor_id-12094/Bitcoin.html. This is perhaps a clue to how discovered vulnerabilities are handled. There may be little advantage in having a network specific mechanism. Certainly the history suggests that securely embedding an alerting mechanism in a purely peer to peer network protocol is a difficult problem to solve.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.