offer alternative methods for customizing TX broadcast privacy

[conduition]

Transactions which are first seen being broadcast from a user's node are more likely to be heuristically associated with the node runner personally. To break this heuristic, node runners might choose to broadcast a TX indirectly through alternative channels to disassociate that TX from the bitcoin node. Unfortunately bitcoind does not offer this option natively (yet).

This PR adds two new ways for users to broadcast transactions submitted to an electrs server:

1. The pushtx crate. This initiates a short-lived set of P2P connections which publishes a transaction to random peers resolved from DNS seeds. The most private way to do this is using TOR, hiding the IP address of the sender.

2. A custom script option. This allows users to customize the behavior of electrs broadcasting. It should return a zero status if the broadcast was successful, and emit an error message with a non-zero status otherwise.

[conduition]

I doubt that sending a tx to random peers over clearnet helps

@Kixunil I strongly agree, and that's why the pushtx-tor option is preferable for most people. But it's possible that the user's networking setup already accounts for this, and so we shouldn't force them to use a TOR localhost proxy if they don't want to. For instance, electrs may be running on a machine with a VPN connection which the user relies on for network-level TX broadcasting privacy, while the bitcoind node runs on a separate machine without such protections.

Perhaps I could add some extra warnings to the pushtx-clear option to make it clear this option will degrade privacy if used incorrectly?

[conduition]

Added extra warnings for pushtx-clear: https://github.com/romanz/electrs/pull/1056/commits/36b7bc48b47b33ae6b68c17e91f9cf639cbc4a05

[Kixunil]

But it's possible that the user's networking setup already accounts for this, and so we shouldn't force them to use a TOR localhost proxy if they don't want to.

Good point but this should be explicitly documented, so good that you did. FTR this is also useful on Whonix I think.

[conduition]

Thanks for the suggestions @Kixunil, added both :slightly_smiling_face:

[conduition]

Hi @Kixunil and @romanz, sorry it's been a while since I fixed conflicts on this PR.

I've been using the pushtx options from this PR on my own electrs node for 9+ months now, and it has worked well across different electrum clients. The biggest problem is if using pushtx-tor, broadcasting can sometimes take 20-30 seconds, and occasionally some clients will time out waiting for the broadcast to succeed, but this is a minority occurrence, maybe 2-3% of attempts. Usually the client shows the TX as having been broadcast correctly. Eventually the TX makes its way through the P2P network and back to your own node, where electrs indexes it, and it finally shows up in the electrum client app's TX history. This usually takes just a few seconds after the initial broadcast with pushtx succeeds.

As for the script option, i have tested it last year when I made this PR, but not used it extensively with my own node. I'll do some more extensive testing soon with the updated code in this PR.

[conduition]

One minor annoyance is that the pushtx crate v0.4.0 relies on [email protected] whereas electrs uses [email protected]. Please let me know if that is a problem and I'll file a PR upstream to pushtx for a version bump.