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.
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.
it's no longer POW, what would cause the log to show that message?
other nodes requesting ... data. ..
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.
