[bisq-network/bisq] Takers deposit transaction rejected for 'too-long-mempool-chain' causing issues (#3705)

wiz notifications at github.com
Tue Mar 17 12:13:55 UTC 2020


Call discussion nodes with @freimair about how to tackle this:

1) fix mempool fee estimation https://github.com/bisq-network/projects/issues/27
2) 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
3) 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
4) we need to add a "refund" by doublespending funding TX back to a fresh unused address
5) 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 @cbeams )
6) 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
7) 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)
8) 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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/3705#issuecomment-600037511
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200317/864ffa16/attachment.html>


More information about the bisq-github mailing list