[feature] Scheduled Transaction Broadcast

optout21 commented at 4:44 pm on December 19, 2025: contributor

Please describe the feature you’d like to see added.

Overview

In certain cases the user creating a transaction would like to broadcast it to the bitcoin network delayed, not immediately. It’s practical to implement scheduling in the node, as it is a software component designed to be always-on.

With Scheduled Transaction Broadcast the bitcoin node accepts a transaction for later broadcast, stores it, and broadcasts automatically at the specified target time.

No response

Describe the solution you’d like

Details / Caveats

Uses. Delayed transaction broadcast can be useful for/when (among others):

hiding the real time of transaction creation (with random delay; for non-urgent transactions; typically in the range of few hours – few days)
broadcasting a transaction at a future date

Result, error check. As the actual broadcast happens later, the broadcast result – success or some error – is not available at acceptance time. Only parsing checks are done at acceptance time. The client can check the result only by monitoring the bitcoin network. Note: some checks are not possible to be done at acceptance time, as conditions may change (e.g. inputs with timelocks). (Note: it could be possible to offer an API to query for broadcast result, but that’s not planned.)

Absolute time vs. block time. The target time can be specified as an absolute time or a block height.

No guarantees. Delayed broadcast is best-effort, there is no delivery guarantee.

Fee. The transaction fee is contained in the scheduled transaction, and it is not possible to be changed. In case the network fee rate goes up by the time of submission, the fee may be insufficient. CFCP can be used to bump the fee if needed.

Retries. It is possible to specify a number of retries, and a retry period. Then the scehduled broadcast is retried accordingly in case of failure.

Describe any alternatives you’ve considered

The following alternatives are identified, though they are outside of the scope of the node software:

Scheduling implemented in the wallet software. The drawback is that wallets are typically active (running) only for a short period, while there is user interaction. Running in the background may impose some design issues.
Implemented in a separate component sitting along the bitcoin node, proxying all RPC API calls, and implementing scheduled (delayed) transaction broadcast.

Miscellaneous

Note (added Jan 15): earlier feature request #30471 also includes delayed broadcast.

This could interfere with the feature “Broadcast own transactions only via short-lived Tor or I2P connections” (PR ##29415). This feature could be combined with this feature, to further mask the real transaction creation time, by creating the dedicated sending connection sometimes between the scheduling time and target time (randomized).

An APIs for cancelling an unsent scheduled TX would be possible to offer as well.

Please leave any additional context

Implementation Details

Scheduled transactions are kept in a separate memory structure, and are persisted to a separate file (for persistence accross restarts). The file is read at startup, and written whenever there is a relevant change to its content, and at shutdown.

A new RPC ‘schedulerawtransaction’ is proposed, with syntax very similar to ‘sendrawtransaction’. However, the transaction is not sent rigth away, but stored for later broadcast.

Status

Delving discussion: https://delvingbitcoin.org/t/scheduled-delayed-transaction-broadcast/2148

Prototype: https://github.com/optout21/sched-tx-ptoto/ https://github.com/optout21/bitcoin/tree/sched-tx-proto1 https://github.com/optout21/bitcoin/tree/sched-tx-proto0

History

Jan 14: Added ref to #30471, @craigraw . Jan 5, 2026: Edits w.r.t. to the alternative of implementing in the client; removing speculative fuzzy use case; in response to comments by @ismaelsadeeq . Dec 19, 2025: Created.

optout21 added the label Feature on Dec 19, 2025

ismaelsadeeq commented at 1:28 pm on December 22, 2025: member

In certain cases the user creating a transaction would like to broadcast it to the bitcoin network delayed, not immediately. This scheduling can be done on the client side, but it’s practical if it’s handled by the node.

there is some precondition that is expected to occur in the future (e.g. occurrence of a transaction), condition that is not possible (or desired) to be expressed in bitcoin scripts.

These two points are not convincing enough IMO.

As you mentioned, this can be easily handled by the client.
The preconditions you mentioned are unclear and a bit speculative. The specific example you gave can still be achieved from the client: we already have mechanisms for clients to query the state of the mempool, via RPC, REST, as well as push-based ZMQ notifications.

So, conceptually, I’m ~0. This adds complexity of maintaining an additional pool of scheduled transactions on the node side for a niche use case.

optout21 commented at 9:58 am on January 5, 2026: contributor

These two points are not convincing enough IMO.

For the client part, if I consider the client-node pair, typically the client is active (running) only for short time, while there is user interaction. The node on the other hand, is designed to run in the background. This is an argument for implementing the delayed broadcast in the node. I will re-word my description to be more explicit on this.
Indeed, probably best is to remove the speculative use case altogether from the description.

Thanks for the feedback.

craigraw commented at 7:33 am on January 15, 2026: none

This functionality has already been proposed in #30471 (although I am happy to see further support for this feature).

optout21 commented at 11:00 am on January 15, 2026: contributor

Thanks for the info, I was not aware of it! My proposal here deals only with delayed broadcast, and it is a subset of #30471. There are several different things considered:

Mitigation for the case when a submitted transaction gets lost (when it is dropped from the node mempool and does not live on in any other mempool). Done by keeping pending local transactions and periodically resubmitting.
Mitigation for disappearing/reappearing pending transaction (when a tx is dropped from the node mempool but later it gets confirmed; this is mostly a UX issue). Done by providing info about txs stored in the local pool (and also periodical resubmit)
Delayed tx broadcast, for extra privacy
Using more private means (connection) when broadcasting, for extra privacy – #29415

All of these are related, but have different goal and technical issues.

Except for the last, which has to be handled inside the node, the rest could be handled:

in the wallet software – here the main issue is that wallets are not designed/used in an ‘always-on’ mode
inside indexer (electrum) implementation (I have no idea how much of these different electrum implementations do)
as an add-on next to the bitcoin core node (think RPC proxy style with enhancement)
inside the node

[feature] Scheduled Transaction Broadcast #34118