Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error broadcasting transaction #3306

Open
huey735 opened this issue Sep 22, 2019 · 9 comments

Comments

@huey735
Copy link
Member

commented Sep 22, 2019

Summary

Generalizing, a user makes a transaction and unbeknownst to them the transaction isn't successfully broadcast to the Bitcoin Network. This has happened in all types of Bisq transactions:

  • make offer
  • take offer
  • deposit
  • payout
  • withdraw

@sqrrm @ripcurlx

@sqrrm

This comment has been minimized.

Copy link
Member

commented Sep 22, 2019

@huey735 Thanks for collecting these cases. I only found one log file and it seems to have issues with the tor connection #3282 that might be causing broadcast failures. Are they all issues with tx not being broadcast or are some of them a lack of fee?

@huey735

This comment has been minimized.

Copy link
Member Author

commented Sep 22, 2019

@sqrrm I'm not sure if I fully understand your question, but I assume that all transactions related to the trade protocol are having issues due to issues in the Bisq Network/software. The fees for the makerOfferTx, takeOfferTx, depositTx and payoutTx aren't under control of the user and are usually high enough to get accepted into the mempool.
The issues with the withdraw transactions however can be result of poor fee calculation but I doubt that that's mostly the case.

@sqrrm

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

From #3305 I see at least one tx being rejected as dust.

Sep-22 14:18:20.261 [BlockingClient network thread for r3dsojfhwcm7x7p6.onion:8333] ERROR o.b.core.Peer: [r3dsojfhwcm7x7p6.onion]:8333 /Satoshi:0.16.3/: Received Reject: tx b2bcaabc9b1f9b2a67901730bdabb50a8b484e7b5357addb4230d174506bd670 for reason 'dust' (64)

@sqrrm

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

@huey735 The more logs we can get the better. We need to see if we can find a pattern on why the txs aren't properly broadcast.

@huey735

This comment has been minimized.

Copy link
Member Author

commented Sep 23, 2019

@sqrrm I'm not sure that tx is one of @bitsanity's. So I don't think that it's relevant here. For #3305 they were able to solve it with a resync of the spv chain which implies problems with the propagation of the transaction and not with its fee amount.

@sqrrm

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

That rejection is due to 'dust' which is strange, bisq should not produce dust txs. The other case I saw was the bad tor connection. We need more data to understand if there is a common cause for these failed broadcasts. It would also be good to do rebroadcast automatically, or perhaps even manual but at least not forcing users to do an spv resync.

@wiz

This comment has been minimized.

Copy link
Member

commented Oct 1, 2019

I just reproduced the issue, I had set fee = 1 sat/byte and Bitcoin node rejected it for having too low of a fee
Oct-01 13:22:11.344 [BlockingClient network thread for jiuuuislm7ooesic.onion:8333] ERROR org.bitcoinj.core.Peer: [jiuuuislm7ooesic.onion]:8333 /Satoshi:0.18.1/: Received Reject: tx 3fd5922bdc88fab8ee866610edc3e54b62dcbf5945813e08813157ad0c842dc6 for reason 'min relay fee not met' (66)

@wiz

This comment has been minimized.

Copy link
Member

commented Oct 1, 2019

It seems bitcoinj creates invalid transactions in multiple cases, so far I've seen:

  1. The "dust" consensus rule is being violated, not sure how to reproduce this yet

  2. The "min relay fee" consensus rule is being violated when user sets custom fee to 1 sat/byte and virtual TX size gets rounded down and effective fee becomes 0.995 sat/byte

Obviously these 2 bugs should be fixed, but maybe we can also improve the handling the exceptional case of rejected transaction broadcast:

  1. The Bisq app should display an error if bitcoinj peer rejects broadcasting of the TX, with the reason given together with the full TX encoded in hex for further debugging

  2. The Bisq app should have a method to export the raw TX from the UI list of transactions, encoded in hex for further debugging

  3. The Bisq app should have a (hidden) method to manually remove unconfirmed transactions from the wallet so if the broadcast fails the user can try creating a new TX

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.