Make banning in graphene less aggressive

dtr-org / unit-e

A digital currency for a new era of decentralized trust

https://unit-e.io

MIT License

45 stars 15 forks source link

Make banning in graphene less aggressive #951

Closed AM5800 closed 5 years ago

AM5800 commented 5 years ago

Graphene block %s from peer %d was not requested\n Causes issues in testnet already. I am removing other bans proactively. So current strategy in graphene is:

ban if received something obviously wrong
ban if corresponding validation functions wants to ban

Signed-off-by: Aleksandr Mikhailov aleksandr@thirdhash.com

frolosofsky commented 5 years ago

Causes issues in testnet already. I am removing other bans proactively.

Is it expected somehow? Do you have an explanation why it happens? Doesn't it hint that something goes wrong in graphene implementation?

I mean, in the current testnet we have only "good" nodes so that I'm wondering how is it possible?

AM5800 commented 5 years ago

I think I have a theory what is going on. But need to confirm it. We just discussed banning and think that it should go away in any case. That is why I created the PR

thothd commented 5 years ago

Causes issues in testnet already. I am removing other bans proactively.

Is it expected somehow? Do you have an explanation why it happens? Doesn't it hint that something goes wrong in graphene implementation?

I mean, in the current testnet we have only "good" nodes so that I'm wondering how is it possible?

Synchronisation issues, you can get blocks from different nodes using different methods (compact / Graphene) at the same time - I wouldn't ban here but discard the data

frolosofsky commented 5 years ago

utACK c76ebb139bfca8cabe350bdef8d4ac5d39fb3e63