<p></p>
<blockquote>
<p><em>This is a Bisq Network proposal. Please familiarize yourself with the <a href="https://docs.bisq.network/proposals.html" rel="nofollow">submission and review process</a>.</em></p>
</blockquote>
<p>An alternative idea to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="761432340" data-permission-text="Title is private" data-url="https://github.com/bisq-network/proposals/issues/286" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/286/hovercard" href="https://github.com/bisq-network/proposals/issues/286">#286</a> would be to allow traders to create an alternative payout tx from a deposit tx which got stuck in case miner fee was too low in the tx chain.</p>
<p>If the deposit tx is not confirmed after a certain number (e.g. about 3-5 days) both users would get displayed a popup explaining the context and suggesting to make a refund tx which refunds the trade amount to the seller and the deposits to both trades but also increases the miner fee so both traders will receive a bit less from that cose.</p>
<p>The way how the costs are calculated and distributed would be the same as in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="761432340" data-permission-text="Title is private" data-url="https://github.com/bisq-network/proposals/issues/286" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/286/hovercard" href="https://github.com/bisq-network/proposals/issues/286">#286</a>.<br>
There is not need that both peer are online at the same time. The peer who acts first on the popup will create a payout tx which serves as CPFP and send the half signed tx to the peer as mailbox message. As soon the peer goes online and the miner fee used in the peers tx matches his calculation (with some tolerance as time delay will change fee rate) he can accept the suggested payout and sign and publish the payout. With that the whole stuck chain should be released.<br>
If the miner fee has changed too much in the meantime he can reject and make instead another suggestion and send that to the peer. On the peers side its the same, he can accept or reject and make another suggestion... This can be repeated until the miner fee of both peer is inside the tolerance window.</p>
<p>I am not sure if we should allow that the peer does not accept at all, as that might lead to kind of extortion scenarios if the problem of follow up locked up txs is on the peers side (e.g. more risky for market makers).</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/proposals/issues/287">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNSTPLLQOPFYSDL2FRLSUEHRLANCNFSM4UVNNGTQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNQ5WXXJXPAJGXC6GQTSUEHRLA5CNFSM4UVNNGT2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4LLDP45Q.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/proposals/issues/287",
"url": "https://github.com/bisq-network/proposals/issues/287",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>