Track failed tx broadcasts #1193
Comments
|
For the benefit of handling any future incidents of this kind, here are the messages I just sent to the traders involved with To the buyer-as-maker, who had already realized his maker fee and deposit transactions had not been broadcast, I wrote:
To the seller-as-taker who I had not yet spoken to and I presume was not yet aware of the missing transaction situation, I wrote:
|
|
Trades: 21502 (Jan. 12), n8T2n (Jan. 11), ooeeaqe3 (Jan. 11), NDQKYOB (Dec. 31), abzphlpw (Jan. 1) have the same issues. Dates are trade dates. Different combinations of two out of maker fee, taker fee and deposit are not in the mempool. It seems the deposit never is in the mempool. |
|
This is almost certainly due to our changes to timeout handling in v0.6.3. @ripcurlx, @ManfredKarrer and I talked about the possibility of exactly this scenario, in fact. The logic was that it would be better to let a trade go to arbitration because a transaction didn't broadcast at all, than it would be to fail a trade due to timing out listening to hear back from a quorum of nodes that our transaction was successfully broadcasted. We seem to be looking at an example of that happening. This scenario has still led to a transaction that must be reimbursed (the taker fee tx that did successfully brodcast), so it no longer qualifies as a workable "fix". With that said, it is far better to have a failed trade like this get routed via usual channels to arbitration, instead of presenting the user with an in-app error message and forcing them to go to the forum or GitHub. So, we seem to have improved the nature of this problem, but we haven't gotten rid of it yet. Hopefully we'll see some logs to analyze shortly. @ManfredKarrer, do you have any thoughts on this already? |
v0.6.3 was shipped just 4 days ago, on the 10th. If you've been seeing this behavior before then, that means my analysis above is, if not wrong, at least not complete. It's strange that you've seen 5 of these and I've only seen 1. Should have been half and half, but could just be the lumpy nature of randomness. I guess I should expect to see more of these issues soon. |
|
All, see attached logfile. Let me know if I need to provide any further information. Thanks! |
|
@ManfredKarrer, I've taken a first pass through @MaximFL's log file and I see no record of maker/taker or deposit hashes for this trade, and the only record of its transaction id ( What follows is this trade's JSON contract, encrypted against your 57D66BDA pubkey: |
|
@ManfredKarrer, this is the seller-as-taker's log. I have not had time to analyze, but did quickly see record of the transactions for |
|
Another trade with this issue just came my way, id: contract.jsonseller-as-taker.log |
|
bisq.log-bak.txt |
|
@noideawho: please confirm the trade id you're reporting on here. |
|
I have two new trades impacted by this issue, ids: |
|
I am the Maker (BTC buyer) in the trade with id TBTVBNKI. As requested by the arbitrator I am uploading bisq.log here. |
|
@pmknutsen Wait, don't you mean Maker (SC buyer) in the trade? I am the Taker (BTC buyer) as I am selling SC in exchange for BTC. |
|
bisq.log |
|
I see looks there are multiple trades involved in this post that share the same issue. |
|
Support asked me to place the log file here for transaction EJOLDw EDIT: Removed uploaded files for privacy reasons. JSON Contract trade with ID EJOLDw.txt |
CORRECTION: |
|
I've just created #1195 to deal with fixing the cause of this issue. |
|
@cbeams just edited my comment withe the id, thanks |
|
Another new trade with this issue just showed up in my arbitration queue, id: |
|
@cbeams Damn, seems the assumption that the broadcast will succeed sufficiently even we don't hear back from peers was wrong. I will not be able to look closer to it until weekend due traveling... When searching the log the tx id and the broadcast attempt should be visible. If there are no logs for hearing back from peers then the broadcast did not get confirmed by back reporting peers and our timeout triggered the completion of the broadcast. The app logs a msg like: People should not post json contract here as it contains the payment method details. I will remove the one above from user @Splitter8. Instead the json contract the trade ID, taker fee tx, maker fee tx and deposit tx are sufficient. Would be good to post them in the posts so its easy to look up explorer and search log files with it. All those data are not privacy relevant and can be posted in plain text here. The deposit tx is always failing if one of the trade fee txs was not getting into the blockchain. We should also check logs on the bitcoin nodes to see if there was any issue. Reporting users should also post the Bisq version they used at the time when they did the tx. We should find anyone who knows more about the Tor network of has contact to Tor devs to get more background about the Tor issues. I saw that Tor connections are much slower and less reliable as they have been in the past. For BitcoinJ we could fall back to clear-net connections in the worst case (has some privacy issues). For the P2P network we don't have any alternative though. |
|
Another new trade with this issue just showed up in my arbitration queue, id: |
|
Another: |
|
Trade id For reference, here are the transactions that I see in the trade details:
Both maker and taker transactions were broadcast successfully, and at first glance, so too was the deposit transaction, but on review—and this is the strange part—the deposit transaction appears to have nothing to do with this trade. Indeed, the maker and taker transactions do not feed into this deposit transaction as expected, and the deposit transaction has actually already been paid out. So it appears that some other, already complete, trade's deposit transaction has shown up in the . trade details for In any case, I will queue this trade's maker and taker transactions up for reimbursement, let the traders know that this trade must be canceled, and so forth, as I just documented in #1195 (comment). |
|
@ManfredKarrer, an update from my side on your requests above:
I am going back through my arbitration queue now to see if I missed any. If you do not need them anymore, please let me know asap, so I don't waste time on it.
I've reached out in the dedicated issue for this case at bisq-network/support#52 (comment). Per the support protocol in bisq-network/support#35, there is a good chance that both traders involved will be subscribed to this issue. I've also asked @keo-bisq to re-open the ticket and ask the maker to upload their log.
I've done this at bisq-network/support#39 (comment). Again, if @keo-bisq can ask the other trader directly via re-opening the arbitration issue, that's would be good.
This was already worked out above between you, @Entity325 and @Splitter8, but I've carried over the comments, etc to the dedicated issue at bisq-network/support#44 in any case. |
ATTENTION ALL PARTIES—TRADERS, ARBITRATORS AND MAINTAINERS:Please continue any conversation, log analysis, etc in the dedicated support issue for each trade. You can easily find your trade's support issue by looking at the reimbursements project board here: https://github.com/bisq-network/support/projects/1. Just search that page / filter the board for your trade ID. It is important to have dedicated threads for each case, because, as can be seen above, a mega-thread like this can quickly get unmanageable. Especially from the point of view of individual traders who don't want to get spammed about details of every other trade affected by this issue. Thanks! |
|
Please restrict further comments on this issue to the issue's original purpose: which is to track occurrences of these tx broadcast failures. This is how we as @bisq-network/arbitrators and @bisq-network/exchange-maintainers keep track of how the problem is trending over time. To track your support case, see the instructions above re the reimbursements project board https://github.com/bisq-network/support/projects/1. To track the ongoing investigation about causes of this incident, subscribe to #1195. To track the specific fix we believe is going to resolve this problem in v0.6.4, subscribe to #1244. Thanks again, everyone. It's been excellent to see the quick responses. We'll get this sorted out! |
|
Trade ID |
|
Trade ID @keo-bisq is the arbitrator for this trade. |
|
all of those trades with a Trade ID
have problems, because the taker transaction did not get broadcasted. |
|
Trades: |
Thanks. |
|
Trade |
|
Maybe we can post that reimbursement of the tx fee is only done if the user used the latest version? the trade fee we still can reimburse. |
|
Closing as complete. v0.6.5 seems to have resolved this issue completely, and while may have a few more instances show up due to folks not yet having upgraded, I don't think there's a need to keep this tracking issue open any longer. We can reopen if that assumption gets proved wrong. Thanks to everyone who participated here. |
|
Hope so. Might be that the Tor network dos attacks are more under control and so the tor netwokr more stable and reliable again. Updated at #1241 |
|
Hi, i have th same issue with trade id WPREIBWQ. Trade took place at: Jun-10 21:28:56.112 |
|
@pfischer1290, please open a dispute for this trade if you haven't already (you can do so with |
|
@cbeams i would but i get this error and it cannot find the correct entry: |
|
I've created bisq-network/support#121 to track this. Let's take the conversation there, thanks. |
|
@cbeams thanks an bunch. If you need more input, logs, etc. Just let me know :) |
|
This issue is still prevalent. A quick search on the forum yields a few recent cases: And one of the most recent cases #2992 |
I just encountered a trade (id:
TBTVBNKI) in which both taker and deposit fee transactions failed to be broadacast to / propagate through the Bitcoin network. These transactions are not unconfirmed, but are rather non-existent on any node (so far as we know) and certainly not via any block explorer, e.g. bitaps.com or tradeblock.com.I know @keo-bisq has had at least one other trade with these kind of tx broadcasts. Keo, let's use this issue to track these issues as they come up. Please add a comment for each one you encounter, and I'll do the same. Please ask everyone to attach their log file in a comment on this issue, too, so that @ManfredKarrer and I can analyze them.
The text was updated successfully, but these errors were encountered: