Remove p2p alert system #7692

btcdrak · Mar 15, 2016

This completely removes the p2p network alert messaging system; however, internal alerts, partition detection warnings and the -alertnotify option features remain.

The purpose of the p2p alert messaging system is to communicate severe network issues which can be achieved using a variety of traditional means rather than the Bitcoin p2p messaging layer. A decentralised system should not have privileged users able to send alert messages on the Bitcoin network.

From the perspective of the Bitcoin Core project, if we need to communicate with Core specific users, it can be done using existing public channels (website, twitter, reddit, Slack) as well as an opt-in Bitcoin Core announce only mailing list.

jonasschnelli · Mar 15, 2016

Concept ACK.
Needs rebase.

MarcoFalke · Mar 15, 2016

Concept ACK

btcdrak · Mar 15, 2016

@jonasschnelli rebased

laanwj · Mar 15, 2016

Concept ACK. I had an earlier try at this with #6260, but tt's good that there is an alternative in the form of a mailing list now - that was pretty much the only concern.

New line deleted.

Some wild editing was done in this file? Please check git diff -w. It can help to clean it.

paveljanik · Mar 15, 2016

Concept ACK.

maaku · Mar 16, 2016

This code is actually very useful for other projects that build off of bitcoin code base, and could be useful within the context of bitcoin if reconfigured. Perhaps just disable the code, not remove it entirely?

laanwj · Mar 16, 2016

This code is actually very useful for other projects that build off of bitcoin code base

Sorry, but I don't think that's a valid reason to maintain code that we shouldn't have anymore. And I'm sure there's much better ways of doing this in derived projects as well, which don't rely on one network-wide secret key.

rebroad · Mar 17, 2016

concept ACK

achow101 · Mar 17, 2016

So what has changed between now and several months ago when this was last attempted? Aren't the same reasons for not removing the alerts then still applicable today?

laanwj · Mar 17, 2016

Aren't the same reasons for not removing the alerts then still applicable today?

Just read #6260 and the OP.
A few months ago pretty much everyone was in favor of this, but there was no alternative notification system yet. There is now a mailing list for alerts instead.

The alert system suffers from many problems:

Philosophically, there should not be a key with special meaning on the P2P network, this has always been a sore point with other node implementations. Like the checkpoints, it is seen as a centralized point of control, thus should go. If there is to be a network-wide alert system, that would also need a network-wide bureaucracy for managing it.
The alert system is hardly tested and maintained. It opens an attack surface to people possessing a certain private key, even though it is a fairly small one, there may be some bug in the alert system that would turn it into a full blown backdoor.
It is not clear what kind of emergencies qualify for using it (there was no agreement on using it to warn of the UPnP issue, even though it was a local network code execution exploit).
It's possible that this guy has or had access to it:

 gpg: encrypted with 4096-bit RSA key, ID EACB3C76, created 2010-07-22
       "Mark Karpelès <mark@hell.ne.jp>"

(and Satoshi, and possibly others who shouldn't really be able to)

A notification mailing list doesn't have any of these problems - it will be about announcements and alerts about this specific software, and we can directly control who has post access.

Note that I'm in no way against a 'better' alert system later on, such as one that doesn't rely on a special P2P message. There are some suggestions in #6260. But this one should go, and soon.

achow101 · Mar 17, 2016

A mailing list would work for this specific client, but what about network wide issues like a blockchain fork like the fourth of July fork?

Also, since the alert system is network wide, what will be done about other clients that still implement the alerts?

laanwj · Mar 17, 2016

A mailing list would work for this specific client, but what about network wide issues like a blockchain fork like the fourth of July fork?

Network wide issues will also be posted to the mailing list. Also, other software can have their own mailing lists. Decentralization, you know. No one should be trusted with central responsibility to send alerts over the network.

what will be done about other clients that still implement the alerts?

They'll likely remove the code as well. Or not. In any case it will never be triggered again. It was never very useful for other clients, as they couldn't send messages of themselves (see #5160).

btcdrak · Mar 17, 2016

@achow101 Please note the alert system was not even used for the "July fork".

If Mark Karpeles has the key, how do we know he wasn't forced to hand it over to the Japanese police or that they have obtained it from accessing his computers? At this stage the key should be considered compromised at the very least, but in any case, a network wide, privileged messaging system is pretty outrageous for Bitcoin. It might have been a reasonable compromise in the early days, but we've definitely outgrown the need now.

jl2012 · Mar 17, 2016

Concept ACK

NicolasDorier · Mar 17, 2016

Concept ACK

achow101 · Mar 17, 2016

@btcdrak Wait, it wasn't used in that fork? I thought it was.

Anyways, since it looks like there are better alternatives which allow for more decentralization, I agree with removing this.
Concept ACK.

Although, if/when this is merged, all of the other wallet developers should be informed so that they remove the code for processing alerts.

Also, maybe the community should be made aware of this decision since this is a protocol rule. I think that if this was merged without letting other people "vote" or debate this, it would probably result in a shitstorm about "The core developers are taking too much power by forcing protocol rules".

instagibbs · Mar 17, 2016

Concept ACK

laanwj · Mar 17, 2016

"The core developers are taking too much power by forcing protocol rules".

We're removing our own privileged position from the P2P protocol (note: not consensus) rules. Oh no! Taking so much power.

achow101 · Mar 17, 2016

We're removing our own privileged position from the P2P protocol (note: not consensus) rules. Oh no!

Yeah, and people can be irrational and there are also shills and conspiracy theorists trying to find every reason to discredit the Core devs

btcdrak · Mar 17, 2016

@achow101 This is not a consensus rule. We are choosing to remove centralisation from the Bitcoin Core distribution.

laanwj · Mar 17, 2016

Yeah, and people can be irrational and there are also shills and conspiracy theorists trying to find every reason to discredit the Core devs

This is going very far off-topic. Let's keep it at this.

achow101 · Mar 17, 2016

@btcdrak Yes, I know. I am just saying that the reaction to this will probably be that even though it is a protocol rule.

@laanwj sorry (I've been hanging out at bitcointalk too long)

luke-jr · Mar 17, 2016

I'd prefer to see an equivalent alert system replacement first, but the risks to the current one are probably significant enough to warrant its early removal.

laanwj · Mar 18, 2016

I'd prefer to see an equivalent alert system replacement first

That was the same argument last time, and the time before that. At some point we have to cut the knot, and I'd say that is now.

Lots of proposals for alternatives, but an alert system isn't really anything people want to spend time working on, it appears. It makes sense in a way, because the only time people worry about such a system is right when they need it.

Hopefully removal will prompt people to work on something better. Although I sincerely believe a mailing list will do a better job than what we have now.

seweso · Mar 18, 2016

This would mean you move to even more centralised communication methods. So it is very weird to use decentralisation as an argument here.

Not to mention that the alert system gives information at exactly the right time: when you plan to use Bitcoin.

My advice would be to de-activate it at a certain block height, and then remove it. That should add enough pressure to build alternative, and give enough time to do so.

I also missed the discussion about this, was there any?

Aquentus · Mar 18, 2016

Wasn't an Alert sent to all nodes in 2013 to ask them to downgrade to 0.7 urgently? I think there are some irc chat logs which show that there was. Can we say, in the absence of the alert, how much longer it may take for such accidental hardfork to be quickly resolved?

Although other public announcement methods can be used, node operators may not be paying attention at that specific point, with the alert probably being the most direct way of reaching them.

I'm not necessarily against removing the alert, but I think there should first be some analysis of the effect its removal may have in times of emergencies. Would it, for example, mean that an accidental hardfork may go on for days rather than hours?

In regards to the suggestion that it is a centralised point, I do agree to an extent and individuals like MK for example should definitely not have the alert, but at the point of misuse the alert system can be revoked, thus achieving what is proposed. Until then, I am not sure what harm the alert system can do? A potential backdoor? Perhaps, but I don't see how and it sounds like high speculation with no basis. There "could" be a "potential" backdoor in every part of the code.

Even assuming the Japanese police has this key, what damage can they do when any alert they may send would be instantly revoked?

So it's a NACK from me until full analysis of the effect of removing the alert would have on emergency situations. For example, if it means that an accidental hardfork would last for days, I think that would be a disaster so I wouldn't support it's removal.

laanwj · Mar 18, 2016

This would mean you move to even more centralised communication methods. So it is very weird to use decentralisation as an argument here.

Decentralization is always a compromise, you get more of something, but all of those instances are of course centralized, controlled by one or a few persons (for example, nodes). It's more decentralized in this way: every project (Core, Btcd, Classic, etc) can have its own notification system, there is no more 'global' system where a few people have a golden key.

This is exactly how it should be - how can you call Core, having its own notification system controlled by Core developers, overly centralized? This is the project. And if you're not using Core, then you shouldn't even be arguing here!

I also missed the discussion about this, was there any?

#6260 at least.

laanwj · Mar 18, 2016

For example, if it means that an accidental hardfork would last for days, I think that would be a disaster so I wouldn't support it's removal.

That's nonsense. For the time it takes to solve an accidental hardfork it makes no difference through which mechanism people are notified.

chris-belcher · Mar 18, 2016

A malicious actor who has the private key could send an alert with a download link to malware. Even if only 5% of node operators click the link it will still provide a huge incentive to do this.

In the context of the ongoing scaling debate (this PR has been linked to reddit.com/r/btc), the alert key is known to Gavin Andresen.
Gavin could send out an alert if the 750/1000 block version Bitcoin Classic trigger is reached, going to all the bitcoin users who don't read reddit every day with a message like "Bitcoin is updating. Please download the updated node from https://bitcoinclassic.com/ to continue using the Bitcoin currency." Such an outcome would be a disaster. So from this point of view the alert system today is an existential threat to bitcoin as a decentralized currency.

The alert key was more acceptable when all the developers were in agreement politically, that's not true any longer which provides a reason for the system to be abused.

This idea from the last thread is good, where only fixed pre-programmed alert messages can be sent which would remove the chance of sending malware or alt-client download links. Although that was suggested 9 months ago with no implementation so far.

pointbiz · Mar 18, 2016

NACK
IMO security is layered and this is meant as a last line of defense. It's been used appropriately in the past. Theymos mentioned it can be made safer by using a finite list of codes instead of free form string.

Existing risks should be summarized please. I only read these:
-Mark Karpales might have the private key.
-key could be abused during contentious fork and we won't know who sent the alert (since small group shares the key)
-free form alert string might be an attack vector

Did I miss any risks?

btcdrak · Mar 18, 2016

Did I miss any risks?

Yes, the fact that the Japanese police are probably in possession of the key.

laanwj · Mar 18, 2016

The alert key was more acceptable when all the developers were in agreement politically, that's not true any longer which provides a reason for the system to be abused.

Yes, it was acceptable in the beginning of the system. Now it's time to let reins like this go.

Note that you don't have to agree with this change: if no one with the 'golden' key (which is - likely- accessible by only a few people) will ever send a legitimate alert again, this is effectively dead code, and should for that reason be removed.

This idea from the last thread is good, where only fixed pre-programmed alert messages can be sent which would remove the chance of sending malware or alt-client download links. Although that was suggested 9 months ago with no implementation so far.

Absolutely, there are plenty of good ideas abound, and as said twice already in this thread, I look forward to seeing a PR implementing one of them. It is not a blocker for this change, though. It does not rule out adding a better alert system in the future.

Would it make sense to pass strMessage through to the GUI?
Edit: Hm, it already calls getStatusBarWarnings() to get at the message. It's a bit circuitous but works, no need to change that in this pull.

theymos · Mar 18, 2016

I still think that there are cases in which all users of Bitcoin Core need to be notified immediately, such as in case of critical security flaws. In reality, almost no one is going to read the mailing list. I agree that the current alert system is kind of stupid, but I very much think that it's a bad idea to make a release without the alert system or some replacement.

@chris-belcher I wrote a draft of how the predefined messages could work: https://en.bitcoin.it/wiki/User:Theymos/Alert_codes

laanwj · Mar 18, 2016

BTW: needs mention in the release notes for 0.13. Makes sense to advertise the mailing list more, there.

In reality, almost no one is going to read the mailing list

Not so sure about that. This is a low-traffic mailing list, there will be no discussion just notifications of critical alerts and new (final) releases. It may be easier to keep track of than some obscure message in the client, and you can see it while you're not attending your node.

I very much think that it's a bad idea to make a release without the alert system or some replacement.

Well there's still time to work on that! See #7679 for 0.13 release schedule. The feature feeze is planned for 2016-05-15.

btcdrak · Mar 18, 2016

@theymos

I agree that the current alert system is kind of stupid,

It's not that it's stupid, it's that it is a Bitcoin network wide system that grants privilege to a few people. It's just plain wrong. Not to mention that we shoudl consider the keys compromised now by the Japanese police at the very least.

In reality, almost no one is going to read the mailing list

This is a new double-optin list only for alerts and release notification. It's not a discussion list. If you include all the communication mediums we have we very good coverage on top of this list. See https://bitcoincore.org/en/list/announcements/join/

aalness · Mar 18, 2016

This seems foolish to me. Most users aren't reading email lists (it's an increasingly antiquated concept with much latency) and various forums have different audiences speaking a variety of languages. There's no better way to alert the network immediately than directly through their client. If the goal is to be petty towards Gavin, fine rotate the key. But this seems like the most effective means to get the network's attention in the event of an emergency or hard fork -- which seems increasingly possible as the days go on.

laanwj · Mar 18, 2016

fine rotate the key

That's not actually possible with the current system (without introducing DoS risk to the network).

theymos · Mar 18, 2016

To cleanly change the key, you can add a restriction that the old key can't send alerts with priority greater than some number. Then old nodes can still be alerted, but the old key can always be overridden by the new key(s). Also, the old key can be set to completely expire after some time.

btcdrak · Mar 18, 2016

@theymos Doesn't work for unupgraded nodes or fork-of-the-day clients either.

laanwj · Mar 18, 2016

@theymos A new system should not be based on the P2P alert message, but something that:

Can be used by different software on the network in parallel, with relaying not dependent on being accepted by that software - for example, by using a transaction. With the current system, there is no communication across 'islands' of software with different keys.
Needs multiple developers to sign before sending a message - so that one leaked key isn't fatal, and one drunk (or forced) dev can't abuse the system
Needs to be transparently documented who owns which key, with the public keys hardcoded in the client, so that messages are attributable
Needs a way to safely rotate keys in a scheduled way, so that the same keys don't stay in use for years

As said (now for the third time) I'd be happy to see an implementation of a better alert system, some have been discussed in #6260. I'm not against systems to notify Bitcoin Core users in general, but the current one should go. The mailing list was just fastest to set up as a replacement and easy to use, and is not restricted to certain versions of the software.

laanwj · Mar 18, 2016

This is getting repetitive.

From now on, please only comment on the actual code change here. PR discussion are for reviewing code, not for endless discussion, the format isn't suited to it - people apparently comment here with their opinion ready without reading any of the preceding discussion.

Implementations of new, better alert systems are welcome in new PRs.

petertodd · Mar 18, 2016

Concept ACK

FinalHash · Mar 18, 2016

Concept NACK

Reason per Peter Todd:
In general, removing a component of a messaging layer that has extreme censorship resistance is a bad idea. I feel like this is simply a waste of time and meant to only boot folks with said keys out of the system and overall serves no real purpose. If you can cite why this will be beneficial for Bitcoin, I might be more likely to ACK. But this serves no purpose other than removing people from the system. This is a trivial thing, but a decentralized messaging layer should stay intact as is now. 3 people have the keys and it is overall not affecting anything. Engineering power should be put towards more urgent matters.

petertodd · Mar 18, 2016

@FinalHash NACKs have to be accompanied by reasons why you are NACKing:

https://github.com/bitcoin/bitcoin/blob/ea0f5a2b04bbbc80448e883824448acb3c5d1921/CONTRIBUTING.md#peer-review

Here you are deleting the only RAW_TEST_FILE definition - please remove it in the rest of the file or leave this variable empty here to not cause confusion (and keep it for the future).

I think it may be better to empty it instead, in case raw test files are added in the future

I added it back.

Remove class CAlert is still used in the developer documentation as an example, but I think it is OK: doc/developer-notes.md:class CAlert.

The documentation is unrelated. Just happens to be an example.

afk11 · Mar 18, 2016

Code review & concept ACK, though orphaned constants need removing: btcdrak#7

paveljanik · Mar 18, 2016

Wiki should be updated: https://en.bitcoin.it/wiki/Alert_system

As we are going to not react on ALERT messages, shouldn't proper deprecation-BIP be created as the meaning of one of its messages is going to be changed?

If you run with -debug=net, alerts will be logged as unknown commands, which is probably OK.

laanwj · Mar 18, 2016

As we are going to not react on ALERT messages, shouldn't proper deprecation-BIP be created as the meaning of one of its messages is going to be changed?

If you want - note that there was never a BIP introducing the alert message either. Also: the meaning of the message is not being changed, we'd just be no longer paying attention to it. This was already possible with the option -alerts=0. Other software is free to still support it if they decide so (but as said, there is usually little point, as they can't send messages of themselves.)

paveljanik · Mar 18, 2016

Can be removed as well now:

src/chainparams.h:    const std::vector<unsigned char>& AlertKey() const { return vAlertPubKey; }
src/chainparams.h:    std::vector<unsigned char> vAlertPubKey;

btcdrak · Mar 18, 2016

@paveljanik done.

gmaxwell · Mar 19, 2016

utACK. This should be removed.

3 people have the keys

Many more people than three have the keys; the complete set is not made public for personal safety reasons (and given the likely compromise, is not even known to any person). But now, understanding that this misunderstanding exists, some of the strange opposition makes a lot more sense to me, and this only increases my belief that this should be removed.

dcousens · Mar 21, 2016

concept ACK

laanwj · Mar 21, 2016

ACK cfd519e

whatisgravity · Mar 24, 2016

The fact that this introduces a greater attack surface for an unknown group of people should be enough to remove it immediately.

Edit: Also isn't there clear conflict of interest issues with anyone who holds a key from arguing/voting on the existence of this feature?

This code is actually very useful for other projects that build off of bitcoin code base

They can look at previous commits, thats the point of version control.

gmaxwell · Mar 24, 2016

@whatisgravity It's removed now-- it's worth noting that the main contributors to Bitcoin Core have been trying to remove it for a couple years now, but have (and continue to) suffered pushback from some parties... it took a while to overcome that.

maaku · Mar 24, 2016

Sorry, but I don't think that's a valid reason to maintain code that we shouldn't have anymore. And I'm sure there's much better ways of doing this in derived projects as well, which don't rely on one network-wide secret key.

That's the wonder of open source -- having code in a repository doesn't mean that you or the other core committers are required to personally support it, other than make sure that your own merged patches don't break automated unit tests.

If the features of the bitcoin core repository are limited to those which some subset of developers are specifically interested in supporting, it makes bitcoin core a rather uninteresting project to the wider community.

laanwj · Mar 25, 2016

That's the wonder of open source -- having code in a repository doesn't mean that you or the other core committers are required to personally support it, other than make sure that your own merged patches don't break automated unit tests.

No, I disagree - at least how our project is structured - trying hard to handle issues and fix bugs that come up, for example - there is at least a little responsibility to the maintainers for what is in the repository.

Only passing the automated tests is short-sighted. At least as long as the automated tests don't cover everything on every scenario on every platform (and some things, like people that act in unpredictable ways, can hardly be covered by automated tests).

I do agree that you could structure an open source project that way. We're hampered also by the monolithic structure of the code. E.g. if the alert system was an external plugin, people who care about it could still maintain it, and we'd only have to make sure that our side of the API does what is advertised. But for better or worse, we have this bottleneck.

it makes bitcoin core a rather uninteresting project to the wider community.

Possibly. But on the other hand, what we do support we try to keep working as well as possible. It's a bit of a compromise, where on one side you have a heap of barely-third-party-maintained hacks and on the other side you have a cathedral. I try to keep to a sensible middle, as said above, as far as the code structure allows.

jonasschnelli added the P2P label Mar 15, 2016

paveljanik commented on an outdated diff Mar 15, 2016

src/test/alert_tests.cpp

-BOOST_AUTO_TEST_SUITE_END()

+BOOST_AUTO_TEST_SUITE_END()

paveljanik Mar 15, 2016
Contributor

New line deleted.

paveljanik commented on an outdated diff Mar 15, 2016

src/test/alert_tests.cpp

static bool falseFunc() { return false; }

BOOST_AUTO_TEST_CASE(PartitionAlert)

-{

paveljanik Mar 15, 2016
Contributor

Some wild editing was done in this file? Please check git diff -w. It can help to clean it.

btcdrak added some commits Mar 6, 2016

btcdrak Update alert notification and GUI 9206634

btcdrak Remove `-alerts` option 01fdfef

btcdrak Remove p2p alert handling bbb9d1d

btcdrak and others added some commits Mar 6, 2016

btcdrak Remove alert keys 1b77471

btcdrak Formatting ad72104

afk11 protocol.h/cpp: Removes NetMsgType::ALERT 6601ce5

btcdrak Add release note documentation

cfd519e

laanwj added this to the 0.13.0 milestone Mar 18, 2016

laanwj merged commit cfd519e into bitcoin:master Mar 21, 2016
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

This was referenced Mar 22, 2016

Closed

Remove p2p alert system goatpig/BitcoinArmory#27

Closed

Remove p2p alert system bitcoinxt/bitcoinxt#138

This was referenced Aug 17, 2016

Closed

Change/Remove alert keys/system BitcoinUnlimited/BitcoinUnlimited#76

Open

Change/Remove alert keys/system SureshMatsui/SaveCoin#3

Closed

Change Alert Keys bitcoinclassic/bitcoinclassic#27

MarcoFalke referenced this pull request Nov 26, 2016
Merged
Add option `-alerts` to opt out of alert system #6274

btcdrak deleted the btcdrak:remove_alert branch Dec 3, 2016

kyuupichan added a commit to kyuupichan/BitcoinUnlimited that referenced this pull request Mar 11, 2017

kyuupichan Removal of alert system
Backport of bitcoin#7692 with minor BU-specific tweaks
c5f9d64

kyuupichan referenced this pull request in BitcoinUnlimited/BitcoinUnlimited Mar 11, 2017
Merged
Removal of alert system #360

jonathancross referenced this pull request in bitcoin-dot-org/bitcoin.org Apr 23, 2017
Merged
P2P 'alert' messaging was removed, updating DevDocs (also updating protocol table to 70015) #1576

@@ -1566,6 +1564,26 @@ bool fLargeWorkForkFound = false;
      bool fLargeWorkInvalidChainFound = false;
      CBlockIndex *pindexBestForkTip = NULL, *pindexBestForkBase = NULL;
+    +static void AlertNotify(const std::string& strMessage, bool fThread)
+    +{
+    +    uiInterface.NotifyAlertChanged();

@@ -29,8 +29,6 @@ JSON_TEST_FILES = \
        test/data/tx_valid.json \
        test/data/sighash.json
-    -RAW_TEST_FILES = test/data/alertTests.raw

-    -        READWRITE(nMaxVer);
-    -        READWRITE(setSubVer);
-    -        READWRITE(nPriority);
-    -
-    -        READWRITE(LIMITED_STRING(strComment, 65536));
-    -        READWRITE(LIMITED_STRING(strStatusBar, 256));
-    -        READWRITE(LIMITED_STRING(strReserved, 256));
-    -    }
-    -
-    -    void SetNull();
-    -
-    -    std::string ToString() const;
-    -};
-    -
-    -/** An alert is a combination of a serialized CUnsignedAlert and a signature. */
-    -class CAlert : public CUnsignedAlert

bitcoin/bitcoin

Join GitHub today

Remove p2p alert system #7692

Conversation

btcdrak commented Mar 15, 2016

jonasschnelli commented Mar 15, 2016

jonasschnelli added the P2P label Mar 15, 2016

MarcoFalke commented Mar 15, 2016

btcdrak commented Mar 15, 2016

laanwj commented Mar 15, 2016

Show 1 comment Hide comment paveljanik commented on an outdated diff Mar 15, 2016

Show 1 comment Hide comment paveljanik commented on an outdated diff Mar 15, 2016

paveljanik commented Mar 15, 2016

maaku commented Mar 16, 2016

laanwj commented Mar 16, 2016

rebroad commented Mar 17, 2016

achow101 commented Mar 17, 2016

laanwj commented Mar 17, 2016

achow101 commented Mar 17, 2016

laanwj commented Mar 17, 2016

btcdrak commented Mar 17, 2016

jl2012 commented Mar 17, 2016

NicolasDorier commented Mar 17, 2016

achow101 commented Mar 17, 2016

instagibbs commented Mar 17, 2016

laanwj commented Mar 17, 2016

achow101 commented Mar 17, 2016

btcdrak commented Mar 17, 2016

laanwj commented Mar 17, 2016

achow101 commented Mar 17, 2016

luke-jr commented Mar 17, 2016

laanwj commented Mar 18, 2016

seweso commented Mar 18, 2016

Aquentus commented Mar 18, 2016

laanwj commented Mar 18, 2016

laanwj commented Mar 18, 2016

chris-belcher commented Mar 18, 2016

pointbiz commented Mar 18, 2016

btcdrak commented Mar 18, 2016

laanwj commented Mar 18, 2016

laanwj commented on the diff Mar 18, 2016

theymos commented Mar 18, 2016

laanwj commented Mar 18, 2016

btcdrak commented Mar 18, 2016

aalness commented Mar 18, 2016

laanwj commented Mar 18, 2016

theymos commented Mar 18, 2016

btcdrak commented Mar 18, 2016

laanwj commented Mar 18, 2016

laanwj commented Mar 18, 2016

petertodd commented Mar 18, 2016

FinalHash commented Mar 18, 2016

petertodd commented Mar 18, 2016

paveljanik commented on the diff Mar 18, 2016

paveljanik commented on the diff Mar 18, 2016

afk11 commented Mar 18, 2016

paveljanik commented Mar 18, 2016

laanwj commented Mar 18, 2016

btcdrak added some commits Mar 6, 2016

paveljanik commented Mar 18, 2016

btcdrak and others added some commits Mar 6, 2016

btcdrak commented Mar 18, 2016

laanwj added this to the 0.13.0 milestone Mar 18, 2016

gmaxwell commented Mar 19, 2016

dcousens commented Mar 21, 2016

Hide details View details laanwj merged commit cfd519e into bitcoin:master Mar 21, 2016 1 check passed

1 check passed

laanwj added a commit that referenced this pull request Mar 21, 2016

laanwj commented Mar 21, 2016

This was referenced Mar 22, 2016

whatisgravity commented Mar 24, 2016

gmaxwell commented Mar 24, 2016

maaku commented Mar 24, 2016

laanwj commented Mar 25, 2016

This was referenced Aug 17, 2016

chjj added a commit to bcoin-org/bcoin that referenced this pull request Aug 25, 2016

MarcoFalke referenced this pull request Nov 26, 2016

btcdrak deleted the btcdrak:remove_alert branch Dec 3, 2016

kyuupichan added a commit to kyuupichan/BitcoinUnlimited that referenced this pull request Mar 11, 2017

kyuupichan referenced this pull request in BitcoinUnlimited/BitcoinUnlimited Mar 11, 2017

paveljanik commented on an outdated diff Mar 15, 2016

paveljanik commented on an outdated diff Mar 15, 2016

laanwj merged commit `cfd519e` into bitcoin:master Mar 21, 2016
1 check passed