Fee reimbursement for trade EJOLDw

[cbeams]

This issue has been created per the process detailed in #35 to track the reimbursement of trading and mining fees lost due to the 'failed transaction broadcast' problem being tracked at bisq-network/bisq#1193 and under investigation at bisq-network/bisq#1195.

If the trade ID in the title of this issue is yours, then please click the Subscribe button in the right menu of this issue to be notified about the status of your reimbursement.

If you do not see a Subscribe button, then you are not logged in to GitHub. Please log in or create an account if necessary. You'll then be able to Subscribe to this issue and you will get updates by email.

[cbeams]

Maker: 56c7e5f69c4fc1abc5c070a0e5eab48351a9b4e398a3adf2132413d9502e14d4
Taker: 587ee108ac433dcb3c66c776c02c20e0351e230724b99e8d19fc911b0897f804
Deposit: c5f4c5cab6b78fc45b5159d4e561915b0ead71c85aacf60784be531379e6e7c5

[cbeams]

@Splitter8 wrote in bisq-network/bisq#1193 (comment):

Support asked me to place the log file here for transaction EJOLDw
bisq.log
Also attached JSON Contract info

EDIT: Removed uploaded files for privacy reasons. JSON Contract trade with ID EJOLDw.txt
Relevant data:
"id": "EJOLDw-97aaa90e-9e14-4cb9-9f9f-060e7a8aedad-063",
"offerFeePaymentTxId": "56c7e5f69c4fc1abc5c070a0e5eab48351a9b4e398a3adf2132413d9502e14d4",
"takerFeeTxID": "587ee108ac433dcb3c66c776c02c20e0351e230724b99e8d19fc911b0897f804",

@Entity325 wrote in bisq-network/bisq#1193 (comment):

bisq.log
I am the Taker in trade EJOLDw, arbitrator asked me to upload bisq.log here.

@ManfredKarrer wrote in bisq-network/bisq#1193 (comment):

@Splitter8 I saw in the older log that the maker fee tx 56c7e5f69c4fc1abc5c070a0e5eab48351a9b4e398a3adf2132413d9502e14d4 was failing because you was only connected to 1 btc peer at that time. You should have been connected to a localhost BTC node but probaly because that node was not synced up (was still downloading blocks) the connection failed and then Bisq connects to any public clearnet node (that is a known issue need to get fixed). That explains why BitcoinJ expects the normal connection nr (min 4 nodes) but only gets 1. With only one node the probability that the tx does not get broadcasted is rather high.

Summary:
Tx failed because of wrong behaviour of Bisq when the localhost BTC node is not fully synced and a single public clearnet node is used instead. See: bisq-network/bisq#1154

@ManfredKarrer wrote in bisq-network/bisq#1193 (comment):

@Entity325 I looked into your logs. Here is my result:

Taker fee tx 587ee108ac433dcb3c66c776c02c20e0351e230724b99e8d19fc911b0897f804 was broadcasted successfully thought the deposit tx failed.
The taker fee tx got triggered by the timeout but later 1 peer reported back. 9 peers have been available. Tx fee was 235 sat/byte.

Deposit tx c5f4c5cab6b78fc45b5159d4e561915b0ead71c85aacf60784be531379e6e7c5 had a fee of 253 Satoshi/Byte. 9 peers have been available at broadcast time (sent to 9) but we never heard back from any peer. Nothing suspicious found in the log (node seems well connected also on the p2p network side). Broadcast happened 4 min. after startup and node was running for 8 more minutes.
OS is Windows 8.1.

There have been Tor startup errors like that:
Jan-11 22:00:39.563 [NetworkNode-9999] ERROR i.b.n.p.n.TorNetworkNode: Tor node creation failed: java.io.IOException: java.io.IOException: Auth cookie not created
Jan-11 22:00:39.564 [NetworkNode-9999] INFO i.b.n.p.n.TorNetworkNode: Restarting Tor

The startup when the tx failed was without such an error but the time between shutdown and startup was only 7 sec.

Time of shutdown: Jan-13 11:24:37.311
Time of startup: Jan-13 11:24:44.205
Time of broadcast: Jan-13 11:28:34.028

I am wondering if the fact that there was a very short time between the restart has any impact on the situation (e.g. Tor route to Bitcoin nodes recreated fast and might get flagged by Tor as DDoS?).

UPDATE:
Did not connect the 2 log files (the other from @Splitter8). So is same issue as:
bisq-network/bisq#1193 (comment)

Summary:
Tx failed because of wrong behaviour of Bisq when the localhost BTC node is not fully synced and a single public clearnet node is used instead. See: bisq-network/bisq#1154

@ManfredKarrer wrote in bisq-network/bisq#1193 (comment):

@Entity325
I checked the log for trade EJOLDw:

Peers trade fee tx 56c7e5f69c4fc1abc5c070a0e5eab48351a9b4e398a3adf2132413d9502e14d4 was not confirmed.

@cbeams , @keo-bisq : Could you request from the other peer the full log for trade EJOLDw?

UPDATE:
Just saw that @Splitter8 was the peer and has posted the log.

Jan-10 22:39:44.338 [PeerGroup Thread] INFO o.b.c.PeerGroup: Localhost peer detected, trying to use it instead of P2P discovery

Jan-13 01:32:04.526 [JavaFX Application Thread] INFO o.b.w.Wallet: completed: 56c7e5f69c4fc1abc5c070a0e5eab48351a9b4e398a3adf2132413d9502e14d4

The issue has the same reason as above case (@Splitter8)

Summary:
Tx failed because of wrong behavior of Bisq when the localhost BTC node is not fully synced and a single public clearnet node is used instead. See: bisq-network/bisq#1154

[Entity325]

"There have been Tor startup errors like that:
Jan-11 22:00:39.563 [NetworkNode-9999] ERROR i.b.n.p.n.TorNetworkNode: Tor node creation failed: java.io.IOException: java.io.IOException: Auth cookie not created
Jan-11 22:00:39.564 [NetworkNode-9999] INFO i.b.n.p.n.TorNetworkNode: Restarting Tor

The startup when the tx failed was without such an error but the time between shutdown and startup was only 7 sec."

This happens sometimes if I start Bisq when my internet connection is either under heavy use or not yet stable (such as while the computer itself is still going through the boot-up process). It fails to connect to the TOR network properly and flashes up a warning that my ISP may be blocking TOR. So far, I have remedied this by simply closing Bisq, waiting a few seconds for my connection to stabilize, and then re-starting the program. For this reason, I don't consider the anomalous messages to be noteworthy.

[cbeams]

Staged for reimbursement in 8e6814b

[cbeams]

Closing as reimbursed via the batch transaction documented at #35 (comment).