|
Title: can someone explain to me what 'received getdata (X invsz)' means in debug.log Post by: paradigmflux on June 17, 2014, 03:18:24 AM Hi all, I have been trying to find an answer to this - what does lines like this mean in a debug.log?
received getdata (2 invsz) what is actually happening, and what does 2 invsz stand for? There are various numbers other than 2 at times, too. There are also some entries in the db.log at the same time: unable to allocate memory for mutex; resize mutex region Title: Re: can someone explain to me what 'received getdata (X invsz)' means in debug.log Post by: gweedo on June 17, 2014, 03:35:37 AM https://en.bitcoin.it/wiki/Protocol_specification#getdata
It means you client asked for some data. Title: Re: can someone explain to me what 'received getdata (X invsz)' means in debug.log Post by: paradigmflux on June 17, 2014, 03:53:16 AM Does anyone know how this would work for a POS-only altcoin?
If getblocks and getwork have been disabled becaue it's no longer POW, what would cause the log to show that message? I am starting to think that there may be some epic train robbery going on with some of these POS altcoin (some sort of POS exploit that is allowing the dev's to continue to mine POW blocks on POS coins) (I suspect that this might be done via the daemon's directly ala <coin>d setgenerate true. Is there a deep dive anywhere on how POS coins work internally? I am referring to the actual implementation (they use cpuminer code if I am not mistaken) that they use internally to generate valid blocks. Title: Re: can someone explain to me what 'received getdata (X invsz)' means in debug.log Post by: bitcoinreactor on June 17, 2014, 07:42:01 AM Does anyone know how this would work for a POS-only altcoin? If getblocks and getwork have been disabled becaue it's no longer POW, what would cause the log to show that message? I am starting to think that there may be some epic train robbery going on with some of these POS altcoin (some sort of POS exploit that is allowing the dev's to continue to mine POW blocks on POS coins) (I suspect that this might be done via the daemon's directly ala <coin>d setgenerate true. Is there a deep dive anywhere on how POS coins work internally? I am referring to the actual implementation (they use cpuminer code if I am not mistaken) that they use internally to generate valid blocks. you did not read a single line in the above answer (from gweedo) to your question. Quote getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an inv packet, after filtering known elements. It can be used to retrieve transactions, (...) we're speaking of btc p2p messages here, nothing to do with rpc commands ; p2p network should still work whatever the 'coin' use to create new blocks. Quote it's no longer POW, what would cause the log to show that message? other nodes requesting ... data. ..Quote I am starting to think that there may be some epic train robbery going on with some of these POS altcoin (some sort of POS exploit that is allowing the dev's to continue to mine POW blocks on POS coins) (I suspect that this might be done via the daemon's directly ala <coin>d setgenerate true. are you seing pow blocks ? if you know anything about pow/pos they are easy to identify. If you don't, have a look at sourcecode to see what rules a pos block must follow to be valid I don't know what fork we're speaking here, but i think it should clearly state (in its sourcecode) that pow blocks are invalid past a given block height / timestamp / whatever, if it's a pos only fork. AcceptBlock() and/or CheckBlock() should refuse pow blocks past the switch point. |