Send raw transactions to explorer API for better redundancy at tx broadcast

[chimp1984]

Description

As we have the unresolved issue that sometimes transactions does not get successfully broadcast and we have not managed to find out the issue which causes that (likely a bitcoinj problem as it does conceptual not support well multiple wallets as we use with BSQ and BTC) I suggest that we send the raw transcation to an explorer API for increasing the chances that the tx gets into the mempool.

A requirement is that the API is running as hidden service, so there are no privacy issues.

Bisq contributors run a few mempool space explorer nodes and we could use those as default nodes. We can add a setting that the user could define their own node as well (I guess its not needed for the first version).

Another option would be to use Electrum or send it to Bitcoin core nodes.
Requires a bit more thought and investigation whats the best option here.

We should also keep in mind that using external APIs for blockchain data can be used for further use cases like look up if a tx is in the mempool, look up if peers trade fee tx is in the mempool and confirmed, lookup miner fees used in peers txs,...
So the choosen model should be usable for those use cases as well.

@wiz Does mempool.space API support broadcast of raw txs?
@jmacxx Would you be interested to work on that?

[oscarguindzberg]

I think the broadcasting problems we had recently are not really broadcasting problems, but a consequence of a previous problem that made bisq to create invalid txs.

In any case, it is good to be on the safe side.

Broadcasting means exposing privacy to the server.

Electrum seems a good trade-off.
Ideal solution:

• Electrum servers provided by trustworthy persons of the bisq community
• Electrum servers running behind tor
• using SSL to communicate to the server

I wrote a java API to communicate to an electrum server: https://github.com/electrumj/electrumj/
This is the method for broadcasting a tx: https://github.com/electrumj/electrumj/blob/main/src/main/java/org/electrumj/ElectrumClient.java#L385

[chimp1984]

FYI: https://mempool.ninja/de/api

[chimp1984]

I discussed with @sqrrm the topic to use Eletrum or mempool.space and we got convinced its better to use mempool.space for now.
The reasons are:

• Our use case is very simple and impl. can be done faster more robust and using patterns we already use in other cases (http request over tor)
• The main reason why Electrum was considered was for possible future use cases which require more sophisticated features. So far we have nothing concretely planned for that. The next feature we might integrate is tx lookups but that is easily done by mempool.space as well. Migrating away from BitcoinJ will require another updated research about best alternatives (back then we ended up with Electrum, but quite some time has passed and might be Neutrino is ready now to use or there are other new candidates which follow a more decentralized model). Starting with Electurm now would be premature.
• Adding another library comes with new dependencies. We want to avoid new dependencies as far as possible. A simple http request is much cheaper than to do it via a Electrum client supporting the Electrum protocol.
• The use case is for getting more redundancy to mitigate proplems from a system which suffers from a too high level of complexity (BitcoinJ). Keeping newly added complexity for that "backup" solution at the minimum seems to be the better choice here.

[wiz]

FYI the mempool.space backend can be configured to support the electrum RPC API as well as the REST API if necessary so you can have both, just let me know if you need it

[ghost]

@jmacxx Would you be interested to work on that?

Thanks for the offer but I don't currently have the bandwidth to take this task.

[wiz]

@jmacxx Really? should be easy, all you need to do is HTTP POST the TX in hex to a URL :)

[cd2357]

Fixed with #4943 and #4958