Closed nopara73 closed 6 years ago
If it should be handled by the library user, maybe a function that let's the user set a hardcoded checkpoint, that tells the headerchain: this block is the valid one, here, no matter if you find a longer one chain, they must build on top of mine.
This can potentially be added to the Network.cs
class. And make the ChainBehavior to reject such block.
I am not sure it is needed, this is unlikely at this point that B2X survive. And people should anyway always connect to trusted node with NBitcoin. If you are a SPV (HiddenWallet is?), then it makes sense though.
If you want to prepare the code for that I am ok. As far as I see, the only classes impacted will be ChainBehavior.cs and Network.cs
And make the ChainBehavior to reject such block.
Would be good. Also will I have a list of nodes who sent me malicious blocks, so I can disconnect, or an event, or does it disconnect automatically?
Keep in mind: while HiddenWallet (and Breeze Wallet) are SPV nodes, we can validate blocks, because we have full blocks.
I don't think the ChainBehavior is kicking or banning. (you need to verify, it might)
I am Concept ACK, if there is a way, at the Network level to blacklist some particular hashes, it would be definitively useful. I forgot, the NetworkBuilder
also need to be updated.
@nopara73 planning to do something for that?
:)
NBitcoin's headerchain is going to follow the longest chain, without knowing if the acutal blocks are valid or not. Which may be not be the Bitcoin chain for a couple of days or months until miners are economically forced to mine valid blocks.
Is this unintended behavior should be handled by the library user or by NBitcoin?