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. This scheduling can be done on the client side, but it’s practical if it’s handled by the node.
With Scheduled Transaction Broadcast the bitcoin node accepts a transaction for later broadcast, stores it, and broadcasts automatically at the specified target time.
Is your feature related to a problem, if so please describe it.
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)
- 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.
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
Miscellaneous
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
