<p></p>
<p>Call discussion nodes with <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/freimair/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/freimair">@freimair</a> about how to tackle this:</p>
<ol>
<li>fix mempool fee estimation <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="579705286" data-permission-text="Title is private" data-url="https://github.com/bisq-network/projects/issues/27" data-hovercard-type="issue" data-hovercard-url="/bisq-network/projects/issues/27/hovercard" href="https://github.com/bisq-network/projects/issues/27">bisq-network/projects#27</a></li>
<li>mitigate causes of the too-long-mempool-chain issue from reproducing by implementing a "soft limit" and "hard limit" in many various places on both maker and taker sides</li>
<li>since we can't prevent all causes, we still need to handle the currently-unhandled exception state of when you get a broadcast fail error (due to too-long-mempool-chain error), because it could actually get confirmed later, and</li>
<li>we need to add a "refund" by doublespending funding TX back to a fresh unused address</li>
<li>this bug blocks the GRPC API from being possible because a trading bot creating many offers quickly would immediately trigger this bug and corrupt the wallet (cc <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/cbeams/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/cbeams">@cbeams</a> )</li>
<li>as an additional verification step, to check if a deposit TX is valid, since Bisq cannot know (due to limitations of SPV), we could possibly query a REST API backend running on a federated btcnode, if the TXID exists in that full node's mempool - if it does, then it's probably valid</li>
<li>the final answer (end of the flow chart) must either be that the deposit TX got confirmed, or a refund TX got confirmed (refund of funding TX)</li>
<li>don't need all of the above ideas implemented, can add one at a time, as they all help to mitigate the severity of the issue</li>
</ol>

<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/3705#issuecomment-600037511">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNS4NPTCLRPAVB7AC4DRH5SQHANCNFSM4JSMDJDA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNSJX5AFQ5JC43PYFQLRH5SQHA5CNFSM4JSMDJDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEPB5RBY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/issues/3705#issuecomment-600037511",
"url": "https://github.com/bisq-network/bisq/issues/3705#issuecomment-600037511",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>