Remove p2p alert system #7692

btcdrak commented at 9:45 AM on March 15, 2016: contributor

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 commented at 9:47 AM on March 15, 2016: contributor

Concept ACK. Needs rebase.

jonasschnelli added the label P2P on Mar 15, 2016

MarcoFalke commented at 9:54 AM on March 15, 2016: member

Concept ACK

btcdrak force-pushed on Mar 15, 2016

btcdrak commented at 10:42 AM on March 15, 2016: contributor

@jonasschnelli rebased

laanwj commented at 2:06 PM on March 15, 2016: member

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.

in src/test/alert_tests.cpp:None in 535be2ac32 outdated

 307 | -}
 308 | +        SetMockTime(0);
 309 | +        }
 310 |  
 311 | -BOOST_AUTO_TEST_SUITE_END()
 312 | +BOOST_AUTO_TEST_SUITE_END()

paveljanik commented at 7:15 PM on March 15, 2016:

New line deleted.

in src/test/alert_tests.cpp:None in 535be2ac32 outdated

 194 | -}
 195 |  
 196 |  static bool falseFunc() { return false; }
 197 |  
 198 |  BOOST_AUTO_TEST_CASE(PartitionAlert)
 199 | -{

paveljanik commented at 7:16 PM on March 15, 2016:

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

paveljanik commented at 7:18 PM on March 15, 2016: contributor

Concept ACK.

btcdrak force-pushed on Mar 16, 2016

maaku commented at 5:39 PM on March 16, 2016: contributor

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 commented at 7:16 PM on March 16, 2016: member

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 commented at 11:02 AM on March 17, 2016: contributor

concept ACK

achow101 commented at 2:34 PM on March 17, 2016: member

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 commented at 3:06 PM on March 17, 2016: member

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 commented at 3:55 PM on March 17, 2016: member

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 commented at 4:28 PM on March 17, 2016: member

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 commented at 4:42 PM on March 17, 2016: contributor

@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 commented at 4:45 PM on March 17, 2016: contributor

Concept ACK

NicolasDorier commented at 4:49 PM on March 17, 2016: contributor

Concept ACK

achow101 commented at 5:18 PM on March 17, 2016: member

@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 commented at 5:18 PM on March 17, 2016: member

Concept ACK

laanwj commented at 5:19 PM on March 17, 2016: member

"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 commented at 5:23 PM on March 17, 2016: member

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 commented at 5:28 PM on March 17, 2016: contributor

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

laanwj commented at 5:29 PM on March 17, 2016: member

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 commented at 5:31 PM on March 17, 2016: member

@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 commented at 8:19 PM on March 17, 2016: member

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 commented at 9:50 AM on March 18, 2016: member

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.

btcdrak force-pushed on Mar 18, 2016

seweso commented at 12:57 PM on March 18, 2016: none

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 commented at 1:04 PM on March 18, 2016: none

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 commented at 1:11 PM on March 18, 2016: member

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 commented at 1:15 PM on March 18, 2016: member

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 commented at 1:39 PM on March 18, 2016: contributor

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 commented at 1:46 PM on March 18, 2016: none

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 commented at 1:48 PM on March 18, 2016: contributor

Did I miss any risks?

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

laanwj commented at 1:50 PM on March 18, 2016: member

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.

in src/main.cpp:None in 17b81d7639 outdated

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

laanwj commented at 2:35 PM on March 18, 2016:

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 commented at 4:09 PM on March 18, 2016: none

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 commented at 4:34 PM on March 18, 2016: member

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 commented at 4:35 PM on March 18, 2016: contributor

@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 commented at 4:48 PM on March 18, 2016: contributor

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 commented at 4:49 PM on March 18, 2016: member

fine rotate the key

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

theymos commented at 4:53 PM on March 18, 2016: none

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 commented at 4:57 PM on March 18, 2016: contributor

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

laanwj commented at 4:59 PM on March 18, 2016: member

@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 commented at 5:11 PM on March 18, 2016: member

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 commented at 6:05 PM on March 18, 2016: contributor

Concept ACK

FinalHash commented at 6:07 PM on March 18, 2016: none

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 commented at 6:10 PM on March 18, 2016: contributor

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

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

in src/Makefile.test.include:None in 17b81d7639 outdated

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

paveljanik commented at 6:15 PM on March 18, 2016:

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).

laanwj commented at 7:29 PM on March 18, 2016:

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

btcdrak commented at 7:57 PM on March 18, 2016:

I added it back.

in src/alert.h:None in 17b81d7639 outdated

  71 | -
  72 | -    std::string ToString() const;
  73 | -};
  74 | -
  75 | -/** An alert is a combination of a serialized CUnsignedAlert and a signature. */
  76 | -class CAlert : public CUnsignedAlert

paveljanik commented at 6:18 PM on March 18, 2016:

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.

btcdrak commented at 7:09 PM on March 18, 2016:

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

afk11 commented at 6:24 PM on March 18, 2016: contributor

Code review & concept ACK, though orphaned constants need removing: https://github.com/btcdrak/bitcoin/pull/7

paveljanik commented at 6:27 PM on March 18, 2016: contributor

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 commented at 7:16 PM on March 18, 2016: member

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.)

Remove p2p alert handling bbb9d1d123

Update alert notification and GUI 92066344fd

Remove `-alerts` option 01fdfeffc4

paveljanik commented at 7:43 PM on March 18, 2016: contributor

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;

Remove alert keys 1b77471bd6

Formatting ad7210408c

protocol.h/cpp: Removes NetMsgType::ALERT 6601ce508e

Add release note documentation cfd519e942

btcdrak force-pushed on Mar 18, 2016

btcdrak commented at 7:55 PM on March 18, 2016: contributor

@paveljanik done.

laanwj added this to the milestone 0.13.0 on Mar 18, 2016

gmaxwell commented at 1:55 PM on March 19, 2016: contributor

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 commented at 12:42 AM on March 21, 2016: contributor

concept ACK

laanwj merged this on Mar 21, 2016

laanwj closed this on Mar 21, 2016

laanwj referenced this in commit 29b2be6ad7 on Mar 21, 2016

laanwj commented at 12:42 PM on March 21, 2016: member

ACK cfd519e

whatisgravity commented at 5:55 PM on March 24, 2016: none

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 commented at 7:03 PM on March 24, 2016: contributor

@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 commented at 9:12 PM on March 24, 2016: contributor

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 commented at 10:07 AM on March 25, 2016: member

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.

chjj referenced this in commit 7c1c2b2d15 on Aug 25, 2016

btcdrak deleted the branch on Dec 3, 2016

sickpig referenced this in commit ba35f7f700 on Mar 31, 2017

PastaPastaPasta referenced this in commit b7f946a63e on Jun 20, 2019

PastaPastaPasta referenced this in commit e6701c70a1 on Jun 20, 2019

PastaPastaPasta referenced this in commit b3c82560cc on Jun 20, 2019

PastaPastaPasta referenced this in commit a1770b0c25 on Jun 22, 2019

PastaPastaPasta referenced this in commit cf19020f63 on Jun 22, 2019

PastaPastaPasta referenced this in commit 1cd303278a on Jun 22, 2019

barrystyle referenced this in commit 7d9aadaa5f on Jan 22, 2020

random-zebra referenced this in commit 59fdfee134 on Mar 13, 2020

akshaynexus referenced this in commit fbd7def7b6 on Mar 13, 2020

akshaynexus referenced this in commit def52e1d69 on Mar 15, 2020

DrahtBot locked this on Sep 8, 2021