4
2
Can someone explain at a high level how the network deals with bad actors (either intentionally (ie- attacker) or unintentional (ie- misconfigured node or a node running outdated code, forked code, etc)) ?
Without knowing too much about Bitcoin's low level internals, I am assuming there are routine checks as data flows through the code on the network to test that the protocol is adhered to; and that anything outside of expected protocol becomes rejected or flagged. I assume these checks are all essentially checked exclusively against the expected 'data model' since obviously it's impossible to directly analyze what code is being run on independent miners/nodes.
So please correct me if I'm wrong here, or elaborate further to fill in the big picture a bit more.
Secondly, I wanted to know - in the case of a known hostile miner/node (or to a lesser extent, a known outdated or misconfigured network participant)- what recourse is available for other users or miners to 'report' or blacklist or avoid the affected nodes or transactions?
Ie- is there built in function for reporting a violation of protocol (either that can be executed on attacker's system or by means of other participants in the network identifying said attacker) ?
Your clarification appreciated, thanks !
Ah, so it seems the block itself can be the 'data model' I alluded to; for which nodes/miners can pragmatically check to verify validity. This is dot-connecting, thank-you for the clear explanation. – Derrick – 2017-12-06T08:40:20.960
A non-crypto solution for example, could be that a node examines the previous confirmed block and then does a 'diff' against the new block (diffing only transactions which exist on both blocks). If there are any conflicts, it knows the new block is invalid. – Derrick – 2017-12-06T08:47:01.877
However, Bitcoin blocks don't contain old transactions. So, this is where some of the heavy crypto math comes in - from my understanding, protocol says the new valid block needs to contain a hash which is a result of all previous blocks' hashes combined - as such, if you were to remove any one of those blocks/hashes (or tamper with the transactions contained within) the new hash would not compute. Therefore your block validity logic needs not examine transaction history specifically - it only needs to check that the new hash correctly returns the expected result of all previous hashes. – Derrick – 2017-12-06T08:48:17.287
If the hash doesn't line up - then it's invalid - at this point the node should reject it and optionally take defensive measures against the source of that block ie- flag or blocklist it. – Derrick – 2017-12-06T08:48:33.397