<p>Thanks for the clarification, glad I was able to help.</p>
<p>Yes, I realize that a bad seed may delay the startup for a client that uses the long timeout setting. I was just worrying whether this setting could potentially have a <strong>wider</strong> impact on the entire network (like a DoS vector) that I'm not aware of.<br>
If not, and the impact is limited to the specific client, then it might make sense to implement the more tolerant timeout setting as an opt-in command-line option, and leave the choice to the user.<br>
Most users will never need to use this option, however, for a few edge cases like mine, it would offer a choice between (a) the risk of startup delay due to hitting a bad seed node and (b) the certainty of no-op. Simply put, it would make a world of difference.</p>
<p>Agreed, a better approach would be to eliminate the bandwidth peaks by protocol design, but that sounds like a lot of work :)</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq/issues/2547#issuecomment-482012299">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AkpZtg8mbUY4AUfpGCq_kCb-_AJwa1Biks5vfuzrgaJpZM4b4HAA">mute the thread</a>.<img src="https://github.com/notifications/beacon/AkpZtsowizovQ9tYx66-ubFQEofRzQxrks5vfuzrgaJpZM4b4HAA.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/bisq","title":"bisq-network/bisq","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/bisq"}},"updates":{"snippets":[{"icon":"PERSON","message":"@agb19 in #2547: Thanks for the clarification, glad I was able to help. \r\n\r\nYes, I realize that a bad seed may delay the startup for a client that uses the long timeout setting. I was just worrying whether this setting could potentially have a **wider** impact on the entire network (like a DoS vector) that I'm not aware of.\r\nIf not, and the impact is limited to the specific client, then it might make sense to implement the more tolerant timeout setting as an opt-in command-line option, and leave the choice to the user. \r\nMost users will never need to use this option, however, for a few edge cases like mine, it would offer a choice between (a) the risk of startup delay due to hitting a bad seed node and (b) the certainty of no-op. Simply put, it would make a world of difference. \r\n\r\nAgreed, a better approach would be to eliminate the bandwidth peaks by protocol design, but that sounds like a lot of work :)"}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/bisq/issues/2547#issuecomment-482012299"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/issues/2547#issuecomment-482012299",
"url": "https://github.com/bisq-network/bisq/issues/2547#issuecomment-482012299",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>