transaction-scheduler

Schedule future Bitcoin transactions by leveraging nLockTime.

Use cases

Dead man's switch

A user could sign a transaction with a timelock that sends their cold storage funds to a trusted third party if they lose access to their keys. If the user retains access to their keys, they can spend the inputs and invalidate the timelocked transaction. These transactions should be RBF and multiple transactions should be created with different fees if the acceptable fees change drastically. If unsuccessful, this service can broadcast the transaction again at a future date if it drops out of the mempool. Users can also specify that they only want to broadcast the transaction if it has an acceptable fee set, and the service will only broadcast the transaction if the fee is appropriate.

Scheduled payments

Let's say you want to schedule payments to a service provider or a dependant. You could sign transactions with a future date as the timelock and send them to this service. The transaction would then be broadcast at a future date.

Send bitcoin when it reaches a certain price

Some users may wish to only send bitcoin at a certain rate, to say, an auto sell exchange. A user could create a transaction and set it to be sent to their exchange account when it hits a certain rate. This could then be sold automatically once the bitcoin is received and credited by the exchange.

Fees

The network fees may be high, and you have a non-urgent payment to make. You could sign a transaction or multiple transactions with different timelocks to be attempted. These transactions can be RBF enabled, allowing you to replace old transaction(s) stuck in the mempool. This could look like the following:

1. Sign five RBF transactions with different timelocks, in ascending order from the lowest fee to the highest fee
2. If the first transaction is still in the mempool at the time of the second timelock, broadcast the second one to replace the first
3. Hopefully, one of the timelocked transactions ends up in the mempool.

Users can also specify that they only want to broadcast the transaction if it has an acceptable fee set, and the service will only broadcast the transaction if the fee is appropriate.

Automatically resetting 2FA multisig CSV transactions

Blockstream green supports 2FA multisig, a service that requires you provide a valid 2FA code for blockstream to co-sign your transactions. Blockstream green uses CSV transactions that enable you to spend the funds with your single key after a certain time has been reached. This is useful for those who have lost their 2FA method, or in the event that blockstream's server goes down.

Users of this feature need to ensure that they send new transactions to reset the timelock. Failure to do so will mean that the security of their funds will revert to a single sig wallet.

Users of the blockstream green service can have their CSV reset automatically by signing a transaction with a future timelock, and posting it to this service. This service will then broadcast their new transaction, enabling them to reset their timelock without having to go back to their wallet.

Users can add a grace period to this timelock, enabling them to spend their funds once the original CSV becomes valid, and before the future transaction is set to become valid.

UTXO consolidation when fees are low

It is considered good practice to consolidate UTXOs when fees are low, as this enables you to reduce the fee of subsequent transactions. A user can sign a consolidation transaction with a low fee, and have it be broadcast when fees drop.

API

POST /schedule/tx

Posting to this endpoint adds your transaction to the scheduler.

Body:

{
  "rawTx": "YOUR_RAW_SIGNED_TRANSACTION_IN_HEX",
  "checkFee": "boolean",
  "price": "USD price that you want the transaction to be broadcast at"
}

rawTx: your raw transaction bytes as hex. checkFee: set to true if you want to prevent broadcasting a transaction if it has a fee that is lower than the recommendation, otherwise false. price: set to 0 if you do not care about the price at time of broadcast, else the min USD figure as a number Successful output:

{
  "body": true,
  "status": 200
}

GET /transaction/lookup/:txHash

This endpoint returns the transaction object stored in the database corresponding to the transaction hash provided.

txHash: the transaction hash of the scheduled transaction

Successful output:

{
  "body": {
    "rawTx": "RAW_TX_BYTES",
    "lockTime": "nLockTime",
    "checkFee": "true/false",
    "feePerKb": "set fee as number",
    "hash": "transaction hash"
  }
}

DELETE /delete/:txHash

This endpoint allows a user to delete a transaction from the database and prevent it from every being broadcast.

txHash: the transaction hash of the scheduled transaction