Currently there are few reports with unconfirmed deposit transactions.
There is a very fast rise of unconfirmed txs on the blockchain (currently > 180k).
We just adjusted our fee estimation to have more competitive (higher) miner fees to get faster into the blockchain. Usually in the past such sudden mempool explosions have been created by spam attacks. 2 days ago the mempool was fine.
So we cannot do much more than to increase the fees and wait.
There are NO FUNDS AT RISK!
Once the transaction gets confirmed (usually over weekend the mempool clears) the trade can be continued or the arbitrator makes the payout (that payout tx will also not be confirmed as long the deposit is not confirmed).
If you have a trade and getting close to the trade period end (or it has ended already) because the deposit tx is still not confirmed, the best thing is to NOT open a dispute but wait until it is confirmed and then continue the trade. Ignore the open dispute button. If both traders just go on after the deposit tx is confirmed the trade can be completed without the arbitrator.
If you open a dispute or it takes too long for you and prefer to not continue the trade but cancel it, you can open a dispute. Tell the arbitrator the the tx is not confirmed and if one of the traders prefer to cancel the trade the arbitrator will close the case so the seller gets back his BTC and both get back their deposit.
Do NOT send Fiat or altcoins before you have at least 1 confirmation!
In the worst case if the transaction don’t get into the blockchain after a few days or weeks (mempool removes unconfirmed txs after a while) I will instruct users what to do. You will see that once your tx cannot be found in several explorers anymore.
But no worry a transaction which is not in the blockchain is simple irrelevant (no funds have left your wallet in such a case). But the wallet might not recognized that by itself and need some extra love to display the correct balance. A wallet resync and/or restore by seed words will do the trick.
Another side note:
Some explorers don’t display unconfirmed transactions which have OP_RETURN data (the Bisq deposit tx has OP_RETURN data), so you might not see it. Just check out and alternative explorer like https://bitaps.com and check there. You can change the explorer in the settings.
Some show the OP_RETURN output as Non-Standard or other terms which sounds like there is an error. Ignore that and change the blockexplorer. E.g. http://blockchain.info/ is pretty bad with that.
Yeah, I also have two transactions which are still lacking a single confirmation after 13 hours. With the market the way it is at the moment, that sort of delay makes the software a bit unusable - the market price could be completely different before we even get to starting fiat transfers. I for one would prefer at least an option to pay a higher / byte fee to be sure of getting a prompt confirmation. My deposit transaction went out with a fee of 246 s/byte which is pretty low in the current context - I think more like 360 is necessary to get transactions completed in a reasonable timeframe.
We just increased the fee estimation. It is difficult to find the right balance. Before it was mostly overpaid…
If there is a dispute because of the delay you have the option to cancel the trade. Tell the arbitrator if you prefer to continue or cancel.
Thanks for the response - I get that it’s hard to get the right balance. Have you considered using something like: https://bitcoinfees.earn.com/ to set the fee dynamically based on current estimated transaction times?
As concerns my trade I’m very keen for it to go ahead because I agreed that sale at the top of the market. The transaction finally confirmed after about 17 hours and I’m now waiting for the counterparty to start the fiat transfer. My worry is that they may well decide to renege because the market has dropped enough that the deposit is worth significantly less than the difference between the agreed trade price and the current market value. Unless I’d asked for a deposit worth several thousand dollars this was always going to be an issue…
I’m not sure how I feel about this. On the one hand, the deal is that you commit to buy at a price and you should really honour that or lose your deposit. As the seller, I’ve committed bitcoins here that I could have sold elsewhere, so if the buyer decides not to go through with it, they’ve potentially cost me thousands of dollars.
On the other hand, if there’s a hugely unpredictable difference in the time it takes to complete a trade - could be a few hours, could be several days - it’s pretty unrealistic to expect people to honour those commitments in a market as volatile as the current one.
I guess in the end the volatility can cut both ways and I could just as easily have been on the losing side of this if the price correction hadn’t happened yesterday. In the event that the buyer drops out, who keeps their deposit?
Yes, Bisq already uses dynamic fees as far as I know.
The issue is now in Bitcoin transactions being slow, Bitcoin price volatility, security deposit and trade amount. As you can see all of these things are up to users and not Bisq. Bisq can work on other base currencies as well, not just Bitcoin and trade amount and security deposits are up to users to set. It is just that this is very new technology and it is sometimes hard to provide best default options or adapt to rapid changes in the crypto ecosystem.
Bisq is a decentralized exchange. It is focusing on trustless trading. Centralized exchanges will always be able to be easier to deal with, because when you give someone else money to take care of them you don’t need to know or do much, but you do need to trust them.
Bisq is about taking the power and responsibility in your own hands, just like Bitcoin is to fiat.
The one that brakes the rules is the one that loses the security deposit. Not going with trade is breaking the rules.
Ah ok, I hadn’t realised that. Obviously I just got unlucky with going in at a point when transaction times were getting longer very rapidly. I guess now that many clients use dynamic fees it’s very easy to get stuck at the bottom of the pile because many subsequent transactions will start using higher fees, compounding the issue. Perhaps bisq could incorporate eventually a small derivative component into its fee calculation in an effort to cope with rapid changes in network congestion levels? I do also think there would be a place for allowing the user to increase the fee manually with the minimum set dynamically as it is now. That way I can choose to overpay if I value speed in times of high volatility.
I totally get the decentralized thing and I love the concept; that’s why I’m here not on an exchange. As you say, the tricky thing right now is knowing how to set the variables when things are changing so quickly. As I’ve said in another thread I do think there’s room for allowing buyers to explicitly choose to “break the rules” by cancelling the transaction before fiat transfer. Sure, you can do this by asking the arbitrator, but that’s unnecessary work for the arbitrator (there’s no dispute involved) and it’s extremely non-obvious that this is possible in the UI before the trade expires.
We use earn.com for fee estimation but adjust it because it was way too high usually. Just recently with the rapid increase that model did not work so well anymore and we already adjusted it. We might manually adjust from time to time to not overpay too much in normal times. Fee estimation is still pretty bad…
The maker can set the amount of the security deposit for the buyer (who can “cancel” the trade in case of high volatility. With that we give it in users hand to adopt to market conditions. You can see it also as of insurance for the buyer to not lose more then the security deposit in case of high volatility.
The duration of the trade period depends on the payment method.
The current situation that the deposit does not get confirmed fast enough is exceptional and not covered by the normal rules. That is why we have the policy that in such a case it is up to the users to continue the trade or cancel it. Of course volatility can bite on or the other here. But it would be unfair to force a user into the trade when it tool longer as the expected max. period due to those issues.
We hope with improvements in the fee estimation we get rid of such issues in future.
The trade fee cannot be set by the user because it affects the other peer as well. So if you want to have very low fees and take the risk of a delay the other peer might have the opposite preference.
No the trade fee is not split. Its a bit more complicate…
It is if you create an offer and pay the trade fee and use a very low miner fee there is high risk that when an taker takes the offer the deposit gets delayed. So you extend your risk to the peer as the deposit uses the output of the trade fee tx as input so it depends on it to be confirmed.
But we get more resilient each time.
Spam attack in April led to alternative base currencies, so we have that fallback option now.
B2X threat led that we use provided Bitcoin nodes which avoids the severe privacy issue with Bloom filters.
This time we learned how to adopt our fee estimations faster (not fast enough though). In future we will work on some dynamic fee estimation adjustment.
Just added a bounty task for that: https://github.com/bisq-network/exchange/issues/1077
It seems I am the only one following protocol in this trade.
I told you as soon as I got the dispute message that I want out of the trade which is 32h+ ago and there was no response till today morning. But I don’t know why my tradepartner still sent fiat, he was clearly instructed to wait for confirmation.
I want out of the trade, since I already exchanged BTC otherwise as I told you in the dispute it was urgent and I coudln’t wait for confirmations.
I gladly sent him back all his fiat. That he shouldn’t have sent in the first place!
This is maybe due to a known bug when Bisq connects to unsynchronized local Bitcoin (base currency) node.
You can stop running the local node if you are doing that and restart your Bisq so it connects to other nodes instead when it boots up.
You can then try deleting the SPV chain file in Settings and restarting Bisq two more times.