Conditional broadcast

[keblek]

Is your feature request related to a problem? Please describe.

I want to upgrade my cold storage (or try out a new wallet) but I want to pay the least amount of money for it. However the mempool is often very full, so I have to wait and watch it like a hawk and then make sure I am close to my computer with the signed tx ready to go when the time comes.

Describe the solution you'd like Have electrs have a restful API that I can curl or some CLI option to broadcast a tx when the mempool is small enough or at a certain time (sunday night US time). I can then make either a very simple app

Describe alternatives you've considered I have a short bash script that uses tor to broadcast a tx to a blockexplorer on the condition, it works but I think this functionality is useful enough to have in this program (which is used by lots of users personally).

Ideally this would be done at the wallet level but with good wallets it's easy enough to export the transaction. Also wallets can't always access the network, what if the laptop goes to sleep overnight? It's very convenient to have this on the node itself.

Additional context

I run electrs personally and so does everyone that runs the node helpers which is now quite a few people. If this functionality were added then I am also sure that wallet devs would be happy to include it.

It seems so trivial but I do think it would be greatly appreciated. Not sure if it can be done simply of if the whole program needs to be reworked to extend the existing functionality.

I would be happy to try to implement this (I have been trying to learn rust lately) but I don't know what your intentions are with the project. If this feature doesn't fit the project then I can happily use my script and run it on the node.

If there is some other reason for the feature not existing then I would be happy to learn why.

[Kixunil]

I think it'd be nicer to have electrs store the transaction broadcased through it and then rebroadcast if it fell from mempool and the fees are sufficiently low.

[craigraw]

This would indeed be a useful feature, but would require another parameter to the blockchain.transaction.broadcast call to specify a timestamp. Ideally, the protocol specification needs to change first so that all implementations follow.

I have a short bash script that uses tor to broadcast a tx to a blockexplorer

Broadcasting from Electrs over Tor to a public block explorer (instead of the node) would be nice additional feature for privacy. Again though, it sounds like a protocol specification change first to support this.

I think it'd be nicer to have electrs store the transaction broadcased through it and then rebroadcast if it fell from mempool and the fees are sufficiently low.

Actually, there are good privacy-related reasons to delay broadcasting (to avoid timing analysis). See the https://github.com/txCastOrg/txCast project for more detail on this.

[Kixunil]

Right, one way to do it without having to modify the protocol is by using time lock. That should be used anyway if one wants to pretend living in a different time zone.

[craigraw]

Yes, that is one way, although there are some privacy drawbacks to that approach. If we assume timing analysis is being done by watching the mempool (as opposed to examining onchain transactions) then future timelock transactions will actually be easier to identify.

[Kixunil]

You can't broadcast transaction with future timelock anyway, so I implied keeping such transaction in electrs memory only and broadcasting it when the timelock can be satisfied.

[craigraw]

Ah right, makes sense.

[AndySchroder]

I think it'd be nicer to have electrs store the transaction broadcased through it and then rebroadcast if it fell from mempool and the fees are sufficiently low.

I feel like this approach is the better solution to the original problem statement. It's becoming much more relevant today as fees are so high and variable. For many users, making the electrs mempool just slightly larger and making that extra space reserved for transactions submitted via the electrum protocol, not having a minimum fee for these personal transactions, it could really help with usability. This would need to be an option though. For public electrum servers, it wouldn't work, but for private electrum servers, it is not really an issue at all. If a user uses a public server, they would need a client wallet side approach to periodically watching the mempool fee distribution and broadcasting when the time is right.

I also like the idea of having the ability to set the time when the electrum server broadcasts a transaction would be useful too, but from a privacy perspective, not a fee perspective. As a user, you'd only want to use this if you trust your electrum server.

Likely though, I don't think public electrum servers are going to want to implement a time based broadcast because they are not going to want to accept a bunch of transactions and have a separate, mempool fee priority management for for the scheduled transactions that no one else knows about. Therefor, I think clients wallets will also need to implement a scheduling system on their end too, but people running their own private electrum server that supported a time based broadcast, they can not be required to keep their wallet online for extended periods of time.

[craigraw]

I have looked into rebroadcasting from Sparrow in detail. Unfortunately, there is no escaping the fact that in order to do this properly, Sparrow would need to replicate Core's consensus. Otherwise there is no way to keep the UI "synchronized" since now Sparrow and the Electrum server both have independent and potentially conflicting state that must be eventually resolved.

I think it'd be nicer to have electrs store the transaction broadcased through it and then rebroadcast if it fell from mempool and the fees are sufficiently low.

From an engineering perspective, this certainly appears to be the more practical solution.

[Kixunil]

@AndySchroder electrs is not intended for public use thus adding this unconditionally would be OK from that perspective.

@craigraw I don't understand what the problem is. Can't you simply fetch the state from the server? But surely, having it in electrs has the advantage of not having to run the wallet if you have a dedicated machine.

[craigraw]

@Kixunil I was referring to Sparrow keeping a copy of a transaction that it has previously broadcast, showing it in the UI, and possibly rebroadcasting it occasionally if it remained unconfirmed (or at least allowing the user to RBF/CPFP it even if it is purged from the local mempool).

Unfortunately, this is not as simple as it sounds - any approach that does not simply fetch and use the state from the server "as is" must deal with consensus related issues like RBF rules. In addition, the Electrum protocol is very efficient but somewhat rigid - for example it is impossible for Sparrow to construct an accurate script hash based on it's own state, since that state may be out of date, resulting in a much more complicated and less performant wallet loading algorithm.

I concluded that it is far simpler for the server side to handle these kind "where is my broadcasted transaction" problems, and for the client to simply represent what the server tells it (as is currently the case). Fwiw I think this would be a useful feature to add - there are several related UX issues, like not being able to perform CPFP or RBF on a previously broadcasted transaction because it has been purged or expired from the mempool.

[AndySchroder]

Fwiw I think this would be a useful feature to add - there are several related UX issues, like not being able to perform CPFP or RBF on a previously broadcasted transaction because it has been purged or expired from the mempool.

Does this comment apply if my idea of "making the electrs mempool just slightly larger and making that extra space reserved for transactions submitted via the electrum protocol, not having a minimum fee for these personal transactions" is implemented?