.

[unusedd]

.

[1714053730]

1714053730

[1714053730]

1714053730

[1714053730]

1714053730

[1714053730]

1714053730

[1714053730]

1714053730

[Pieter Wuille]

0.6.0rc5 rewrites addr.dat completely, so it's likely to expose previously undetected corruptions it seems. We've seen several reports of such cases, and worked around some.

I can give you a build or the source code with a potential fix, but it seems unlikely to solve it. Would you like to try?

[kjj]

I would just delete addr.dat.  I don't have this problem, but I've had several corrupted address databases before, and deleting always works for me.

I would even suggest that as a good choice for the default behavior in the client.

[Pieter Wuille]

Deleting addr.dat indeed works, and if no better solution is found, that will indeed be the advise for people who get stuck.

Still, it shouldn't happen, and it's not very compatible with the idea of decentralization: deleting your addr.dat makes you boot off dns seeds and built-in seeds. This works very well, currently, but I don't like the idea of people depending on it and not maintaining their own peer databases.

[kjj]

Oh, of course.  But deleting the address list and pretending that you are a brand new node so that you can use the bootstrap mechanisms seems like a better approach than failing, whether silently or with a notice.