<blockquote>
<p><strong>Does the Bitcoin Network still have a way of notifying nodes of a potential fatal bug/error?</strong></p>
</blockquote>
<p>No.</p>
<p>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.</p>
<p>The <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html" rel="nofollow noreferrer">discussion of this feature</a> is illuminating</p>
<blockquote>
<p>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 &quot;the developers&quot; would use it to remotely change the
difficulty-- apparently with no idea how abhorrent others would find
it.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
</blockquote>
<hr />
<blockquote>
<p><strong>If not, what is done if the Bitcoin Network is compromised?</strong></p>
</blockquote>
<p>Presumably lots of different people do different things while attempts at coordination are managed through media popular with Bitcoin developers.</p>
<p>You could look at what happened in earlier crises such as the <a href="https://en.bitcoin.it/wiki/Value_overflow_incident" rel="nofollow noreferrer">Value Overflow incident of 2010</a>. 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</p>
<p>See <a href="https://www.cvedetails.com/vulnerability-list/vendor_id-12094/Bitcoin.html" rel="nofollow noreferrer">https://www.cvedetails.com/vulnerability-list/vendor_id-12094/Bitcoin.html</a>. 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.</p>

CC BY-SA 4.0
2022-05-06T13:01:07.543Z
2022-05-06T13:25:52.783Z
2022-05-06T13:25:52.783Z
RedGrittyBrick
<p>I know that the Bitcoin Network would send an alert message which follows:</p>
<p>int32_t nID</p>
<p>The alert identification number - this allows nodes to identify double-messages.</p>
<p>int64_t nExpiration</p>
<p>The alert-expiry time.</p>
<p>int64_t nRelayUntil</p>
<p>Instructs nodes to cease rebroadcasting of the message.</p>
<p>int32_t nMinVer ---&gt; int32_t nMaxVer</p>
<p>The range of bitcoin protocol versions that this alert applies to.</p>
<p>std::setstd::string setSubVer</p>
<p>The current client software update that this alert message applies to.</p>
<p>int32_t nPriority</p>
<pre><code>  The priority of the alert message - however, this function has been rarely used.
</code></pre>
<p>However, this was later abandoned in 2016 where the public and private keys of the message were released to the public.</p>
<p>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?</p>

<bitcoin-core><mining-theory><21-bitcoin-computer>
Does The Bitcoin Network Have A Way To Alert Nodes Of A Network Issue/Bug?
Jamo
# Does The Bitcoin Network Have A Way To Alert Nodes Of A Network Issue/Bug?

(Asked by: username_0 on 2022-05-06)

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?

**Tags:** bitcoin-core, mining-theory, 21-bitcoin-computer


---

## 1 answers

### Answer by username_1 on 2022-05-06. Score: 1

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

No.

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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html) 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](https://en.bitcoin.it/wiki/Value_overflow_incident). 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.


---

