-
Notifications
You must be signed in to change notification settings - Fork 54
add vulnerable nodes #620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add vulnerable nodes #620
Conversation
|
cc @m3dwards, in case you fancy playing around with some easier scenarios :) |
|
Yep happy to |
630d77e to
e016877
Compare
|
concept ACK |
|
A few of these vulns are way too easy to exploit and they end up crashing right after the network starts up! 99.1.0-unknown-messageThere are old nodes on this network still sending "reject" packets, which were removed and therefore unknown in newer nodes. 99.1.0-disabled-opcodesCouldn't tell exactly what happened to this one but some tx from the tx_flood scenario knocked it over. I'll try to dig up the evil tx for analysis 99.0.1-5k-invThis one took a while with tx_flood so it might be ok, just very very fragile |
e016877 to
a058022
Compare
Ok I have attempted to mitigate this by only counting unknown p2p messages from nodes who are using protocol version 70016 (new nodes).
I don't understand how this could hit from tx_flood, so logs would be ideal here.
Mitigated (slightly) be requiring 5k invs counted per node now, which should slow things down a bit? Perhaps I should also bump the numbers though too... |
a058022 to
b6e4bc6
Compare
Few easy vulns, based on bitcoin core v28rc2
To use add the custom version string into version of the graph.