BUIP013 (passed X): Upgrade alert system so that Bitcoin Unlimited can send message alerts to nodes

[Lee Adams]

That has to be fine.

I'm very sorry @solex but you do not seem to understand my concerns.

The only real difference between the options is that a) gives keys to elected officials. I do not see any difference in this and when satoshi gave Theymos access to the alert key.
[doublepost=1453848140][/doublepost]The wording of proposals is very important. It is like when Scotland wanted independence and suggested the wording of:

"Do you agree that Scotland should be an independant Country?"

instead of:

"Should Scotland be an independent country?"

 

[solex]

It's not feasible to allow voting to get too deep into the details of technical BUIPs. It is to approve or reject the whole initiative. If BUIP013 gets voted down, no changes are done.

Here, if option B has a majority then deactivation will happen and it does not matter who has the alert keys, they will be useless for BU nodes.

@Lee Adams I like the subscriber idea. What we could do is to have the user place the public key(s) in the config file. That way there is nothing hard-coded in the application and its entirely up to the user if they want to receive and process alerts from (1) Gavin, Theymos et al. (2) Somebody else who publishes their pubkey.

If the membership vote option A over option B, and it is decided to keep the alert mechanism the keys might not be given to elected officials. The implementation details are up to the Developer and the BUIP author @bitcartel to decide. He likes your suggestion above and maybe this will be the route chosen.

 

[sickpig]

it seems to me that this comment on bitcoin classic PR #27 is quite relevant:

https://github.com/bitcoinclassic/bitcoinclassic/issues/27#issuecomment-172995064

Yes, I've looked into this. It doesn't happen immediately, but peer banning will kick in if enough alerts signed by an unrecognized key come through.

If classic doesn't relay alerts signed by core it will cause network issues.

user @123lee further expand the analysis of the issue

There's two changes that can lead to inter-node bans:

1. We add a new alert key. When forwarding our alerts, core nodes see it as invalid, and increase our DoS count (which can eventually lead to a ban).
2. We remove the old alert key. When core forwards alerts, our nodes see it as invalid, and increase their DoS count (which can eventually lead to a ban).

We can fix 2 by special-casing the old key as "invalid but not DoS".

both things decribed above are the same also for BU nodes. I've quickly skimmed this thread and I didn't find any counter arguments to those issue.

Ami missing something obvious?

 

[Lee Adams]

Ideally the BUIP would have just stated 1 idea. My objection is that it stated 3 ideas. 2 of which I whole-heartedly agree with. 1 of which I vehemently against.

Which way should I vote?

 

[theZerg]

I don't understand which you agree with vs disagree with either...

 

[Lee Adams]

I agree that the alert key should be deactivated asap.
I agree that the security fixes should be implemented.
I disagree that the key should be handed over to elected officials.

Sorry I thought that was clear.

 

[solex]

@sickpig,

How high does the DoS count go before disconnect? If alerts are used it would surely be a low volume activity.

@Lee Adams
What is the worse situation? Now, when thermos and an unknown number of anonymous people can send alerts to BU nodes, or, the mere possibility that this gets changed to the known BU officers.

Bearing in mind that your suggested modification has been well received, you can still provide input while the BUIP is worked on, and there is nothing to prevent you raising a future BUIP to change this again if the final result is not what you like..?

 

[bitcartel]

@Lee Adams I've updated the BUIP to rev 3, new wording should allay any concerns about officialdom. Basically, somebody has to create the keypair on behalf of the BU project and this public key should either be hardcoded or made available for users to add to the config file i.e. they subscribe to the alerts they want to.

 

[sickpig]

@sickpig,

How high does the DoS count go before disconnect? If alerts are used it would surely be a low volume activity.

you get 10 ban "point" every time you send a not-correctly-signed alert, once you reach 100 point the recipient peer will immediately ban you:

https://github.com/bitcoin/bitcoin/blob/6a0720838873c7e13a936a74349147b954e50255/src/main.cpp#L5095

that said I agree alerts are not used very frequently and probably I'm overreacting. I'll take more time to think about possible ways to exploit the alert system to segment the network (my main worry), though.

 

[YarkoL]

Alert system is kind of a risky, because it is centralization and the keys can be compromised. I think it is useful only in the case when a new release has been deployed, as an ultimate safety net in case of some uncaught bug breaking havoc. At least this is how I intepret Satoshi's intention here

Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this [the alert system] can be scaled back. I'm not arguing that this is the permanent way of things forever.

So I think it would be best to have them off by default and enable alerts for X blocks in connection with each new release.

ps. I don't think Theymos et al. would be so foolish so as to muck with the alert keys and take a massive negative public relations hit upon themselves.

 

[theZerg]

Transactions are sent to all nodes (also) so I am not worried about DDOSing by alerts. If there is a concern, we could simply limit the relaying of alerts to once every 15 minutes.

To support a heterogeneous network, we should not penalize nodes that relay alerts by unknown keys, we should just penalize nodes that relay too many alerts.

WRT other people holding "our" alert keys, any idiot who wants to spam BU also has to spam all the other clients so I'm not really worried about that.

However, it is important that we are able to issue an alert and Theymos should be removed from any and all positions of influence so I support the addition of BU alert keys.


But I do not think that this issue should consume too much time (development or discussion). Its not going to significantly improve the user's experience...

 

[solex]

VOTING IS OPEN for this BUIP

If you are in the membership then please go to this thread to cast your vote:

### VOTING IS OPEN for BUIPs 2, 4, 5, 10 & 13 ###

 

[Aquent]

So, I understand voting is now open and not sure whether further comments are allowed, but when Classic was considering the same thing Gavin was against it because it needs co-ordination with other nodes and clients. An improper alert can be de-activated anyway. So, I'll be voting against.

 

[solex]

Voting for BUIP013 is now closed

 

[solex]

Unfortunately, neither A or B met the minimum vote threshold, although both together do, so I invite @theZerg to give his opinion on what can be done (i.e. what is common to A&B), or whether another BUIP is required.

 

[bitcartel]

@theZerg I recommend disabling the alert system per A (which got more votes than B) and then open a dialogue with Classic (when they have time) as to how they intend to upgrade their alert system

Update:

@solex With Classic binaries now available, BU should move to prevent a rogue message being broadcast. Since the private key is shared by several individuals, there is no way to know who actually sent out a message. So there is plausible deniability if an alert like "Critical consensus bug found in Classic/BU, please shut down immediately" is circulated.

I can make a patch/pull request - should I do it against this repo? https://github.com/BitcoinUnlimited/BitcoinUnlimited/tree/0.11cfg_stats

 

[Aquent]

The problem is, from what I understand, that removing the alert causes node synchronisation problems, so this should be taken with great care moving forward.

Obviously I want theymos to have 0 say, but, priorities and all that, plus, you can retract an alert so there is some game theory going there which I think means theymos wouldn't use it in an immature way because it would be retracted in seconds making his attempt pointless.

 

[Roy Badami]

Right, so we shouldn't blacklist a node for sending us a validly signed Core alert, but if we wanted we could just sliently drop the alert, right? EDIT: There's a problem of how we should handle a new BU alert key, though. We need to avoid sending such alerts to non BU nodes, since they may blacklist us as a result.

 

[bitcartel]

@Aquent There should be no sync issues by accepting a valid alert message signed with the Core key, but silently dropping the message, i.e. 1. not broadcasting it, 2. not displaying it locally.

@Roy Badami Yep, at the moment we are only talking about deactivating the alert system. Later we should coordinate with Classic to see how they intend to use the alert system.

 

[Roy Badami]

Any reason not to broadcasting it? No need to interfere with Core's ability to message other Core nodes IMHO.