Thanks for the remarks!
Hiding the real time of transaction creation could be done on client side, what would it be the real benefit of doing this on the node size?
Yes, I did start my writeup mentioning that this could be solved on the client side as well. You could solve it by the user (get up in the middle of the night and broadcast manually), or by the client. This requires a client that keeps running. an I haven’t came across a wallet that offers this. The node capable of scheduled broadcast is probably most useful for the power user scenario, when he has his own node. The node is up continuously, it’s a natural place to host the scheduling logic.
Also, if you want to broadcast a transaction based on a precondition (e.g. occurrence of a transaction) I wonder how you would implement it on the RPC.
Maybe that was a bit misleading / too general statement. I imagine target time specified in absolute real time terms, or maybe block height. No other conditions. What I meant is a situation that you know that you expect an incoming payment at a certain data, and you want to make a payment after that (of course transactionwise these would be independent). In situations when it’s possible to express the time condition with a timelock on the transaction, then there is no need for scheduling.
Correct, I was thinking of that. However, as generally this is a fire-and-forget style usage, the ability to check the result is secondary. If I’m available at the time of broadcast, I can broadcast it myself. But cancelling prematurely could be useful.