Possible exploit - block inventory spam #476
Comments
|
Is this happening on 1.6 or 1.7? |
|
1.6 |
|
Can you try 1.7, see if that fixes this? It's a major re-engineering under the hood, should be a lot more robust.... |
|
Is 1.7 stable for mining?
|
|
I've had it running as a miner on the test network for 5-ish days in a row with no hiccups, so... you'd probably be first big test on live, but I think we're ready for it. Would want @langerhans or @leofidus to give a thumbs-up too, though. |
|
I've used 1.7 a lot for solo mining on the testnet, and have been doing that for longer than this is an official Dogecoin branch. Using it for larger-scale mining should be safe and it would be great to get a few testers before the official release. |
|
I'll test it out on one of my nodes, and if it works out OK I'll move it to the other two. |
|
Getting this error when trying to compile: /usr/bin/ld: ../src/leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against configure is simple ./configure --gui=no --with-incompatible-bdb |
|
Looks like something's gone wrong with the configure process. One thing to try first would be to "make distclean" in the top directory, clear everything out, then run "./autogen.sh" and "./configure" again. Failing that, what's your build OS and I'll try reproducing the problem over the weekend? |
|
Oh, meant to ask, which other Scrypt wallets are you seeing this with? |
|
I've noticed it on both MOON and TIPS as well. I did not spend much time troubleshooting the compile issue, I just added -fPIC to the CFLAGS in the Makefile. |
|
Adding -fPIC should solve this, but I'd still like to see if I can recreate the problem so we can get a permanent solution. What OS are you building on? |
|
Compilation issue: bitcoin/bitcoin#3864 |
|
Ubuntu Trusty
|
|
@flound1129 We've had a major concern raised in #479 which if you haven't moved to 1.7 yet, is probably a reason to hold off. We're investigating now, and I'll update you on whether we can reproduce the problem or not. |
|
At this point the attacks on the network have grown to the point where it's worth the risk to implement the new version. I'll keep you in the loop with any issues. Thanks. |
|
I'm getting a LOT of these in my logs now.. Is this a problem? 2014-05-07 18:54:42 force request: block 400d76cde441c6bf418aa992e684dd20d3d5f56ddec9354b0d9e2be30cc57cdf |
|
Looks like a random hiccup with block 212267... probably a broken peer. To other devs; something to check DDoS handling for? |
|
No I get a lot of these for many different blocks. |
|
Do I understand right from the source that prints this (link) that this is done when we're working on a sidechain (like we're racing someone else)? So "we" are on the sidechain, not "them"? I checked the surrounding blocks on sochain: https://chain.so/block/400d76cde441c6bf418aa992e684dd20d3d5f56ddec9354b0d9e2be30cc57cdf and this one followed another block from f2pool very quickly. @flound1129: did you find an orphan on top of this block? when did you start seeing this, and how often does it happen? Perhaps we can investigate some more blocks? If it's because 2 pools found a block at the same height, that would explain it I think? |
|
No, my orphan rate is very low. I hardly ever see an orphan. 2014-05-07 20:11:12 force request: block 0b6768f67b74fd14a0d3f8116568ad912ad80dce13422a1026a60bba9e45945f 2014-05-07 20:05:38 GetNextWorkRequired RETARGET |
|
It's possible that this is just two pools finding a block very close together, and one becoming stale (not orphaned) and discarded. I just want to make sure it's not some kind of attempted dos. |
|
Our block stale rate on doge has been at or over 10% for the past couple days so I'm looking into any possible cause. |
|
To me that would make sense, yes, but would like someone else to confirm. If you can map the find time of the stale blocks to the time the 'force request' occurs, then that would further confirm this suspicion. |
|
It looks like those It's worth noting that Bitcoin 0.10 will be removing that particular piece of code with PR3514. |
|
Just coming back to very old issues; did 1.7 help this at all in the end? Can we close or is this still outstanding? |
|
I'm not sure whether 1.7 helped, because in the end I wound up creating a 'border' set of Doge instances that weren't being used for mining to connect to the outside world. Also, I don't think 1.7 logs that info anymore. So it's difficult to say whether it helped. |
|
1.10 includes basically a massive set of changes to relay network from upstream (Bitcoin), so I'm going to close this for now. If you do see the problem again, do let us know! |
Wallt getting spammed constantly with messages like these. I have seen this with several other scrypt coins. Wallet starts using huge amounts of data transfer, spamming disk logs with info, and using tons of cpu.
2014-04-17 20:45:52 getblocks stopping at limit 80215 cd99fff87d39080f616ac28a3aa987fb8ff50dde0e57258a43c4790534259dca
2014-04-17 20:45:52 sending: inv (18003 bytes)
2014-04-17 20:45:52 sending: inv (73 bytes)
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: getdata (37 bytes)
2014-04-17 20:45:52 received getdata (1 invsz)
2014-04-17 20:45:52 received getdata for: tx 06268a935536caae5616a59650c46bce1a514a2f79b4d0dd1bb8dc6a4d0f048a
2014-04-17 20:45:52 sending: tx (521 bytes)
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: addr (31 bytes)
2014-04-17 20:45:52 received: getblocks (933 bytes)
2014-04-17 20:45:52 getblocks 80216 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
2014-04-17 20:45:52 getblocks stopping at limit 80715 e833bca6e7f2a331edb2ef91eb10b1ecbf55f673798f76e253c56b2441fa9f6b
2014-04-17 20:45:52 sending: inv (18003 bytes)
2014-04-17 20:45:52 received: inv (73 bytes)
2014-04-17 20:45:52 got inventory: tx 5c5999c4300e2640ad6e2bd708f70a364a85014d81b7538125d7b371bb7c55cf have
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: getblocks (933 bytes)
2014-04-17 20:45:52 getblocks 80716 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
2014-04-17 20:45:52 getblocks stopping at limit 81215 ecd3de91892ed2ffc4ecef7a8d0606c539d490ffc0f481f856c4e2b8a065b3ca
2014-04-17 20:45:52 sending: inv (18003 bytes)
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: inv (73 bytes)
2014-04-17 20:45:52 got inventory: tx 5c5999c4300e2640ad6e2bd708f70a364a85014d81b7538125d7b371bb7c55cf have
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: inv (37 bytes)
2014-04-17 20:45:52 got inventory: tx 1dd5da5a819fbe17ededcab8d0e107e4bbe5f16f4b629af1caa7124e2dba9fd3 have
2014-04-17 20:45:52 received: getblocks (933 bytes)
2014-04-17 20:45:52 getblocks 81216 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
2014-04-17 20:45:52 getblocks stopping at limit 81715 d3966271ae821fd8143597b00a1e18ae408243f382304a342b915fa44d01f738
2014-04-17 20:45:52 sending: inv (18003 bytes)
2014-04-17 20:45:52 received: addr (31 bytes)
The text was updated successfully, but these errors were encountered: